Jump to content

ljepson74

Members
  • Content Count

    107
  • Joined

  • Last visited

  • Days Won

    3

Reputation Activity

  1. Like
    ljepson74 got a reaction from Hermanmeds in functional coverage collection - what is collected?   
    While I am waiting for an answer from the simulator vendor, I think I can form a non-tool-specific question about my problem.
     
    I am running a simulation which dies when I collect functional coverage.  I can turn on/off functional coverage collection and when it is on, at the very end of simulation, I get: "ncsim: *F,INTERR: INTERNAL EXCEPTION".  It seems to be that while coverage is gathered, the problem occurs.
     
    I can run tests which flow thru some channels of the dut and don't have the problem, but thru a specific channel of the dut, I often encounter the problem.
     
    question1: What is classified as functional coverage?   I'd like to leave functional coverage collection on and comment out all coverpoints/covergroups.  (Actually I think I have, or am close, and the error still occurs.)  So, I am wondering, what must I grep for to remove to be sure that functional coverage collection has no meaning? My thought is to divide and conquer.
    Am I not just looking for "coverpoint" and "covergroup", but also "assert" (as some code might have assertion based functional coverage)?  Is there anything else?
     
    question2: (This is perhaps a bit tool specific.)  If the -covdut, or scope of where coverage should be gathered is targetted to a sub-sub-module, would you expect that (possibly bad) coverage code at a higher level (or different area) would have zero affect on the coverage collection?  (I've unsuccessfully tried to leave functional coverage collection on, but to move the target-scope to a trival part of the design, to see if the problem goes away.)
     
  2. Like
    ljepson74 reacted to bhunter1972 in Good practice   
    By not writing the do_print, do_compare, do_everything functions yourself, you're avoiding writing your own bugs. Let the tool do this for you for free whenever possible because it works correctly. It's not that UVM doesn't have bugs--it does--but everything we write has bugs so the less you write the cleaner it will be.
     
    We also use the macros for configuration fields in components, so we don't have to write the uvm_config_db::get calls. Again, the less time I spend coding the fewer bugs I'll make.
     
    We do not have m_ and h_ prefixes, but we do have suffixes. Classes are _c, virtual interfaces _vi, packages _pkg, etc. We also have standard names for drivers (drv), sequencers (sqr), monitors (mon), etc. Then, we lump all of our different kits into packages to avoid namespace collisions.
     
    Virtual interfaces get put into the resource database by the testbench where they're instantiated, and they're given a name. The base test then assigns these names to configurations fields in monitors and drivers as strings. Then, during the build phase, once the interface name has been pulled out of the configuration database the monitor/driver pull the virtual interface assignment from the resource database. We simplify this by putting it all in macros (see "The Less You Write" argument, above).
     
    I've been wanting to publish our coding guidelines but I've gotten too much resistance from management here. Maybe it's time I revisit the issue.
  3. Like
    ljepson74 reacted to cristian_amiq in UVM support in the DVT IDE   
    More UVM oriented features are available starting with the 3.5 release. For example UVM Browser for exploring all the components of an UVM-based verification environment or Verification Hierarchy to inspect the topology of an UVM-based verification environment.
     
    For an overview of the UVM features in the DVT Eclipse IDE see http://www.dvteclipse.com/UVM_Support_in_DVT_Eclipse.html.
     
     
              
  4. Like
    ljepson74 got a reaction from CliffordPersechino in TLM transaction w/o a transaction type? (or w/ simple transaction type, like just "int")   
    We are using TLM to pass transactions from SystemVerilog to SystemC.
    I have two cases where I am stuck.  Actually, it is the same case, but I have two angles to my question.
     
    1) Is it possible to still use a TLM setup, but without a transaction type.  (I realize that this is contradictory to the acronym.)  A c-model has a debug function which takes no input arguments.  So, when the SV testbench runs into a problem, it can call this function in the SystemC/c-model.  As all of our connections now are sc_port/sc_export, with TLM, I'd like to stick with that flow if possible, rather than adding DPIs/VPIs/(PLIs) or any other mechanism to communicate between languages.  However, since the function has no input arguments, I don't need a transaction type.   So, is there a way to do a TLM call without a transaction type?  (I suppose I could just use another transaction type and ignore the data.)
     
    2) Imagine the above c-model input function that takes no input arguments.  Let's say now that the c-model function takes a single integer as its input.  So, now I do have a transaction type, but a very simple one.  It seems like overkill, but do I still need to define matching .h and .svh (that extends uvm_sequence_item) transcation types and the related do_pack, do_unpack, etc. routines?   It seems like overkill.  I suspect that I must, if I want to use TLM.
    (Given that the answer to this question must be, yes, does anyone out there just use a generic grab-bag transaction type for cases like this?)
     
    //my thought of passing a transaction which is just an int
    in sv tb:
       uvm_blocking_put_port #(int)  sb_debug_call1_to_cmodel;
    in sc c-model
       public tlm::tlm_blocking_put_if<sc_int <32>>     //or smthg like that
     
     
    Any thoughts?  I know I just need to refresh myself on DPIs, but answers to the above question are welcome.
     
  5. Like
    ljepson74 reacted to getvictor in Free systemverilog/uvm simulator for small amounts of code exists?   
    Update: EDA Playground now supports SystemVerilog and UVM. You can edit and simulate this simple UVM testbench: http://www.edaplayground.com/s/example/546
  6. Like
    ljepson74 got a reaction from cliffc in simple override example - with error   
    Thanks a lot for stepping up to that one, Cliff.  That answer is very clear to me and was well worth the wait.
  7. Like
    ljepson74 reacted to cliffc in simple override example - with error   
    Hi, Linc -
     
    I'll take a stab at this one.
     
    Without knowing the Doulos terminology, I think they are referring to "static hierarchy" (top-module, DUT and interface), "dynamic hierarchy" (UVM testbench components - class based), and "transaction objects" (class based data - sequences and sequence_item transactions).
     
    UVM has a predictable set of phases. All UVM testbench components are first built (build_phase) similar to module instantiation during compilation, once all components have been constructed in the build phase using factory calls, then we can connect them (connect_phase) which is little more than passing class handles to each other (since classes cannot have module-like input/output/inout ports) equivalent to wiring instantiated modules together during the elaboration phase, then we can run a simulation.
     
    This is pretty much the same as building a Verilog testbench using modules. You are not allowed to start instantiation (compile) then start wiring modules together (elaborate) then go back and instantiate more modules after elaboration, and then start simulating for 10ns and then instantiate more modules, wait 10ns and then wire the new modules together.
     
    UVM components are referred to as being semi-static, because they are built after you execute the run_test() command at time 0 and they remain in place and unchanged until the run phase is done, which is the final time-slot of the simulation. Since testbench components are classes, they are dynamic, but for all practical purposes, they are as static as the rest of the testbench but they are created at time-0 as soon as you call the run_test() command in the top module.
     
    Hope this helps.
     
    Regards - Cliff Cummings
    Verilog & SystemVerilog Guru
  8. Like
    ljepson74 got a reaction from Annossyenudge in TLM transaction w/o a transaction type? (or w/ simple transaction type, like just "int")   
    We are using TLM to pass transactions from SystemVerilog to SystemC.
    I have two cases where I am stuck.  Actually, it is the same case, but I have two angles to my question.
     
    1) Is it possible to still use a TLM setup, but without a transaction type.  (I realize that this is contradictory to the acronym.)  A c-model has a debug function which takes no input arguments.  So, when the SV testbench runs into a problem, it can call this function in the SystemC/c-model.  As all of our connections now are sc_port/sc_export, with TLM, I'd like to stick with that flow if possible, rather than adding DPIs/VPIs/(PLIs) or any other mechanism to communicate between languages.  However, since the function has no input arguments, I don't need a transaction type.   So, is there a way to do a TLM call without a transaction type?  (I suppose I could just use another transaction type and ignore the data.)
     
    2) Imagine the above c-model input function that takes no input arguments.  Let's say now that the c-model function takes a single integer as its input.  So, now I do have a transaction type, but a very simple one.  It seems like overkill, but do I still need to define matching .h and .svh (that extends uvm_sequence_item) transcation types and the related do_pack, do_unpack, etc. routines?   It seems like overkill.  I suspect that I must, if I want to use TLM.
    (Given that the answer to this question must be, yes, does anyone out there just use a generic grab-bag transaction type for cases like this?)
     
    //my thought of passing a transaction which is just an int
    in sv tb:
       uvm_blocking_put_port #(int)  sb_debug_call1_to_cmodel;
    in sc c-model
       public tlm::tlm_blocking_put_if<sc_int <32>>     //or smthg like that
     
     
    Any thoughts?  I know I just need to refresh myself on DPIs, but answers to the above question are welcome.
     
  9. Like
    ljepson74 got a reaction from Annossyenudge in ncvlog: *E,EXPENC - Expecting the keyword 'endclass'.   
    In my earlier UVM days I ran into this confusing error message a number of times.  I just hit it again, so am posting my solution here, to share and to help myself rediscover when it is time.   Error (running IUS 13.1):    uvm_analysis_imp_my_snoop #( xyz_trans, my_scoreboard) my_snoop_port;                            | ncvlog: *E,EXPENC (/user/goblin_dev/tb/my_scoreboard.svh,60|50): Expecting the keyword 'endclass'.  
      Below is the pseudo code w/o the error.  In converting the real code to pseudo code (to make it more succinct and sterilized), I do not believe I created any inconsistencies, but this is not what was compiled, of course.   `uvm_analysis_imp_decl(_my_snoop) class my_scoreboard extends uvm_scoreboard;    `uvm_component_utils(my_scoreboard)    uvm_analysis_imp_my_snoop #( xyz_trans, my_scoreboard) my_snoop_port;     function void build_phase(uvm_phase phase)         my_snoop_port = new("my_snoop_port",this);     endfunction : build_phase     function void write_my_snoop( xyz_trans t );         //guts here      endfunction : write_my_snoop endclass : my_scoreboard  
    The error occurred when the following line was missing from above.   `uvm_analysis_imp_decl(_my_snoop)     So, without this macro called, the uvm_analysis_imp_my_snoop class is not declared.  So, I would think that the error message would instead say that the class was not found.  (I should try removing some random class that my tb needs and see what error message appears - b/c that is the error message I would expect here as well.)     Appendix: The following code is taken from uvm-1.1/uvm_lib/uvm_sv/src/macros/uvm_tlm_defines.svh :  
    // MACRO: `uvm_analysis_imp_decl // //| `uvm_analysis_imp_decl(SFX) // // Define the class uvm_analysis_impSFX for providing an analysis // implementation. ~SFX~ is the suffix for the new class type. The analysis // implemenation is the write function. The `uvm_analysis_imp_decl allows // for a scoreboard (or other analysis component) to support input from many // places. For example: // //| `uvm_analysis_imp_decl(_ingress) //| `uvm_analysis_imp_decl(_egress) //| //| class myscoreboard extends uvm_component; //|   uvm_analysis_imp_ingress#(mydata, myscoreboard) ingress; //|   uvm_analysis_imp_egress#(mydata, myscoreboard) egress; //|   mydata ingress_list[$]; //|   ... //| //|   function new(string name, uvm_component parent); //|     super.new(name,parent); //|     ingress = new("ingress", this); //|     egress = new("egress", this); //|   endfunction //| //|   function void write_ingress(mydata t); //|     ingress_list.push_back(t); //|   endfunction //| //|   function void write_egress(mydata t); //|     find_match_in_ingress_list(t); //|   endfunction //| //|   function void find_match_in_ingress_list(mydata t); //|     //implement scoreboarding for this particular dut //|     ... //|   endfunction //| endclass `define uvm_analysis_imp_decl(SFX) \ class uvm_analysis_imp``SFX #(type T=int, type IMP=int) \   extends uvm_port_base #(uvm_tlm_if_base #(T,T)); \   `UVM_IMP_COMMON(`UVM_TLM_ANALYSIS_MASK,`"uvm_analysis_imp``SFX`",IMP) \   function void write( input T t); \     m_imp.write``SFX( t); \   endfunction \   \ endclass  
  10. Like
    ljepson74 reacted to arno in problem on clone   
    clone() returns a uvm_object, which you need to cast. Your code should be :
    $cast ( chk_pkt , rcv_pkt.clone())
×
×
  • Create New...