Jump to content

soloist_huaxin

Members
  • Content Count

    9
  • Joined

  • Last visited

Posts posted by soloist_huaxin


  1. background: I have a image processing IP that comes with a C model. C model takes an array input representing a picture and sends out an array representing a picture. RTL has a pixel-based ready-ready interface on both input and output side. 

    My question is: What's the best-practice approach when building UVM-based DV environment for this IP? What I'm thinking is build an agent for the pixel-based interface, and in block-level environment, have a predictor that takes a sequence of pixel-level sequence_items, call C over DPI, and send out a stream of pixel-level items for checking. Test will be responsible for starting sequence on the agent's sequencer as well as sending sequence(as one object) to predictor. Is there any downside to this?

    any suggestion is appreciated.


  2. 10 minutes ago, dave_59 said:

    Works for me in Questa, and in the  VCS on edaplayground.com. I mean I get no compilation errors, did not check the functionality of your code. Maybe you are using an older version,

    Also, I suggest using *.SystemVerilog as file extension of using *.v and -sverilog switch. That helps keep legacy Verilog files working. 

     

     

    That's interesting...I'm using VCS 2017.03 so definitely not old version...

    result from VCS on edaplayground.com seems to match my expectation on functionality. It's using VCS 2014.10 so I'm not sure about what happened between the versions...

    Agreed on the second point - I just quickly typed up the file as example.


  3. I'm building a SV class where it basically acts like broadcaster(see attached, class "bcast" is what I'm building) where it gets data object from one channel and broadcast it to others. I got the following error when compiling:

    vcs -sverilog -debug_all scratch.v

    Error-[ICTTFC] Incompatible complex type usage
    scratch.v, 45
      Incompatible complex type usage in task or function call.
      The following expression is incompatible with the formal parameter of the 
      task. The type of the actual is 'class data_p::myD3', while the type of the 
      formal is 'class data_p::myD2'. Expression: this.data_obj
      Source info: base_p::\chan#(data_p::myD2)::get (this.in_chan, 
      this.data_obj);

    My understanding is that the parameter for class "bcast" should get passed down when declaring the class member "in_chan", but VCS doesn't think so...Is there something I'm missing?

     

     

    scratch.v


  4. Say I have these sequences:

    class cfg_seq extends uvm_sequence #(obj_type1);
      `uvm_object_utils(cfg_seq)
      rand int unsigned size_x;
      rand int unsigned size_y;
    ...
      task body;
        //Generate objects based on size_x and size_y
      endtask
    endclass
    
    class item_seq extends uvm_sequence #(obj_type2);
      `uvm_object_utils(cfg_seq)
      rand int unsigned size_x;
      rand int unsigned size_y;
    ...
      task body;
        //Generate objects based on size_x and size_y
      endtask
    endclass
    

    I want to use them in a virtual sequence like this:

    class test_vseq extends uvm_sequence;
      `uvm_declare_p_sequencer(some_vseqr)
      `uvm_object_utils(test_vseq)
    
      rand int unsigned size_x;
      rand int unsigned size_y;
    
      rand cfg_seq cfg;
      rand item_seq item;
    
      //This is what I'm trying to achieve
      constraint size_c {
        cfg.size_x == this.size_x;
        cfg.size_y == this.size_y;
        item.size_x == this.size_x;
        item.size_y == this.size_y;
      }
    ...
      task body;
        `uvm_do_on(cfg, p_sequencer.cfg_seqr)
        `uvm_do_on(item, p_sequencer.item_seqr)
      endtask
    endclass
    

    What I'm trying to do is that I set "size_x" and "size_y" in test_vseq and have cfg and item pick it up from test_vseq, so I don't have to set them separately in config_db. What's the best way to do this?

     


  5. Even so, using your idea you can still add a "`define CLASS_PKG_DEFINE" before including the class instead of importing the package and you haven't solved anything (I'd even go so far as to say you've done more harm than good). This is an issue that you can't fix by coding alone. You have to train people to use packages, pure and simple. If you use a linting tool, you could also catch such issues, by not allowing any user code (except packages) to include any file (maybe with the exception of uvm_macros.svh).

     

    Thanks for the insight. I fully agree on "This is an issue that you can't fix by coding alone. You have to train people to use packages, pure and simple."


  6. In the package file, if you add the define before you include the class file, then the condition for the ifndef won't be true anymore and you won't include the class definition. 

     

    That's why I put the class definition in the "`else" part of ifndef.(double-negative?) We have been using per-file guards, but we weren't using packages so it's a necessity. What I'm trying to achieve is to make sure a class can ONLY be included with package, prohibiting others from including class on their own. Yes, it would cause compile failures if others are interfacing with classes included in package, but they could(and I think they will) ignore the package altogether(like we did in the past) and the per-file approach won't stop them from doing it. 


  7. Seeing as how you have analysis ports of different types (different parametrizations), you can't use the analysis FIFO approach. Going by way of the macro is your best bet.

     

    You shouldn't have any problems with conflicts because you define these new analysis imports inside the same package where you define your scoreboard (you are using packages, aren't you?). This way, if the same analysis imp is declared in some different package, you're perfectly safe because it's defined in a different scope.

     

    Thanks. Guess I have to go with macro, which isn't that undesirable to me.

     

    As for packages I have a follow-up question: for classes in a package, would you suggest adding guards around class as a safety measure? for example:

     

    file: class_pkg.v

    package class_pkg;

    `define CLASS_PKG_DEFINE

    `include "class1.vh"

    endpackage

    --end of file--

    file: class1.vh

    `ifndef CLASS_PKG_DEFINE

    //Something that will cause compile error

    ***this class should ONLY be included in a package

    ***use package import to include this class

    `else

    class class1;

    ...

    endclass

    `endif

    -end of file-


  8. This is somewhat old but I wish I could find better ways. I need a scoreboard class that takes in 2 types of transaction via uvm_analysis_imp, and currently the only way of doing it is using `*_decl macro. I'm hoping there is a better way since I'm not sure about the impact of using such macro on other classes. If I understand the class reference correctly, using _decl macro essentially creates a different set of uvm base classes, so if I have 2 scoreboards, both using the same _decl macro with same suffix would there be a conflict? for example:

     

    file:scoreboard1.svh

     

    `uvm_analysis_imp_decl(_rd)

    class scoreboard1 extends uvm_scoreboard;

      uvm_analysis_imp_rd #(T1,scoreboard1) imp1;

      uvm_analysis_imp #(T2,scoreboard1) imp2;

     

      function void write_rd(T1 t); //Have to add _rd due to imp_decl macro

      endfunction

     

      function void write(T2 t); //Default method

    endclass

     

    -end of file-

     

    file:scoreboard2.svh

    `uvm_analysis_imp_decl(_rd)

    class scoreboard2 extends uvm_scoreboard;

      uvm_analysis_imp #(T1,scoreboard1) imp1;

      uvm_analysis_imp_rd #(T2,scoreboard1) imp2;

     

      function void write(T1 t); //Method for T1

      endfunction

     

      function void write_rd(T2 t); //Method for T2

    endclass

     

    -end of file-

     

    Would this create a conflict at compile time? What is best practice for implementing multiple analysis_imp in a single class?

×
×
  • Create New...