uwes
Members-
Posts
625 -
Joined
-
Last visited
-
Days Won
11
Content Type
Profiles
Forums
Downloads
Events
Everything posted by uwes
-
hi, it appears that you are mixing field automation and uvm_config_db. if you do use the field macros you have to use uvm_config_db#(uvm_object)::set+get. this is a common pitfall with the new config_db: the type arg has to be the same! when doing the get() and the set(). (so even base type + derived type doesnt work). this becomes a problem specifically when the field automation is used with the config_db - because the type parameter used to store is not widely known (its documented but ... the ref says: //| get_config_int(...) => uvm_config_db#(uvm_bitstream_t)::get(cntxt,...) //| get_config_string(...) => uvm_config_db#(string)::get(cntxt,...) //| get_config_object(...) => uvm_config_db#(uvm_object)::get(cntxt,...) so for integral types(enums,ints,...) use uvm_bitstream_t, for strings use string and for objects use uvm_object ...
-
#1 no, because a uvm_objection is not a uvm_callbacks_objection - you could use a uvm-call_backs_objections as uvm_phase.objection() but uvm doesnt allow you to set the objection. im not sure if just the setter is missing or if there are other places holding references to the objection object. only option now is probably to sync two objection objects (basically phase.objectio(raise+drop) will cause some_uvm_call_backsobjection raise+drop. #2 you could probably create a derived class from uvm_callbacks_objection which holds additionally a ptr to an objection and hooks into the objection raise/drop. but you cant use a base call as replacement for a derived class.
-
Sequence with parameterized transactions
uwes replied to gustn's topic in UVM (Pre-IEEE) Methodology and BCL Forum
hi, i agree with gordon here. you should NOT use parameters in places where a runtime constant or field is good enough. making it a parameter is only required if you need compile time or elab time constants (bit width or similar). parameters are fine for certain things but they come with the downside that paramterized classes are only assignment compatible if ALL parameters are the same. -
About the config class usage
uwes replied to hugemx830202's topic in UVM (Pre-IEEE) Methodology and BCL Forum
hi, there is no need to 'push' back the modified object. what you actually share is an object reference. your testcase::test_obj points after the get to the same object as the TB_env::myobj. /uwe -
what's the exact usage for set_drain_time(xx,xx)?
uwes replied to Roman's topic in UVM SystemVerilog Discussions
hi, the drain time is a 'grace' period after the objections have been dropped until the effect becomes visiible. the most prominent case is uvm_test_done. without a drain time your simulator would be stopped right with dropping the last objection however in most cases you still want to spend some simulation cycles to shitdown your whole system gracefully (no transfers going on anymore, no assertions running, ...) the length of the drain time depends upon your device. it should be slightly larger then the maximum time your device needs to complete the remaining activities -
hi, just to add: not calling 'super.*' and providing a full replacement of the functionality (buried in the base classes) also means that ANY enhancements to the base class need manual attention in you derived class later.
-
About the config class usage
uwes replied to hugemx830202's topic in UVM (Pre-IEEE) Methodology and BCL Forum
hi, apart from the overhead you may want to generate config_class instances after the end_of_elaboration_phase for instance in a multi-test/config scenario. you cant generate uvm_components once you pass the elaboration_phase. /uwe -
TLM PORT,IMPORT and EXPORT
uwes replied to keyur_san88's topic in UVM (Pre-IEEE) Methodology and BCL Forum
hi, i think the model is simple to remember: 1. TLM1 interaction is always 'initiated' at a PORT 2. the started interaction is always handled finally by an "IMP"lementation 3. the path between the starting PORT and the final IMP may contain other "EXPORTS" (which are a simple proxies between PORT and IMP) or PORTS you can see connection rules PORT-[PORT|EXPORT,IMP] + EXPORT-[EXPORT|IMP] but NOT IMP-IMP ps: i know there is a broadcast scenario which allows [EX]PORT-IMP* could you please explain more of you usage model? regards /uwe -
hi, #1 both raise_objection raise an objection. the one on "phase" objects to the end of the current phase - the one on 'test_done' objects to that. and as you spotted correctly they are somehow doing very similar stuff. 'uvm_test_done' comes from 'ovm_test_done' and was the original way to end the run "phase" of ovm (ovm did only have a single runtime phase). the correct way for uvm10 is probably to use "phase.(raise|drop)_objection" to stop the current phase from progressing to the next phase. #2 you cant use the uvm_phase.get_object() in place for a uvm_callbacks_objection - that would mean that you expect in your simulation a raise|drop to end the current phase within the heartbeat window.
-
hi, the point is that: env_type#(PARAM)::get_type(),env_path); especially the PARAM is not "constant". the part "#(..)" are parameters and have to be constant at elab time BUT for you they are runtime selected. this does not work that way - you have to make a generate loop around your initial (+the genvar 'i'). that way 'i' is a elab time constant and it should work.
-
hi, the objection and the event for the heartbeat can be considered as two separate things. usually they are controlled from two separate threads: 1. the uvm_event trigger() defines the heartbeat window. 2. the associated uvm_objection is expected to happen in the heartbeat window. the heartbeat feature now would stop the simulation if there are NO objection "events" (RAISE|DROP) between two conseq. events in the heartbeat window defining uvm_event. with that you should split your functionality into two parts: 1. defining a window (could be time based or based on specific event in your simulation (start-of-frame|end-of-frame)...) and 2. something which triggers your objection as sign of "being alive" (like "processing finished",...., interrupts) attached is an example of the heartbeat // -*- test: irun -uvmhome ~/src/uvm/distrib/ ~/src/uvm/distrib/src/dpi/uvm_dpi.cc test72.sv +UVM_TESTNAME=test +UVM_OBJECTION_TRACE module test72; import uvm_pkg::*; `include "uvm_macros.svh" class test extends uvm_test; `uvm_component_utils(test) uvm_heartbeat hb; uvm_callbacks_objection myobj; function new(string name, uvm_component parent); super.new(name,parent); myobj = new("heartbeat-objection-source"); hb = new("this-heartbeat", this, myobj); hb.add(this); endfunction task run_phase(uvm_phase phase); uvm_event e = new("e"); int i =5; super.run_phase(phase); // stall the phase until WE are done phase.raise_objection(this); // this is a component to monitor hb.add(this); // start the heartbeat hb.start(e); // now run the thing fork // window definition forever #10 e.trigger(this); // raise+drop // at least one of RAISE|DROP must be in the heartbeat window defined by conseq // event triggers begin repeat(10) begin myobj.raise_objection(this); i++; #i myobj.drop_objection(this); end end join_any hb.remove(this); hb.stop(); // now WE are done phase.drop_objection(this); endtask endclass initial run_test(); endmodule regards /uwe
-
how to create virtual sequencer
uwes replied to loglong's topic in UVM (Pre-IEEE) Methodology and BCL Forum
hi, i didnt mean "local" or "protected" visibility. in sv you cant change the visibility of types with local/protected (only the visibility of instances). what i meant that very often users make simple mistakes such as a mistyped type name, a missing import statement importing the type, missing to compile the type, missing to include the file or similar. -
how to create virtual sequencer
uwes replied to loglong's topic in UVM (Pre-IEEE) Methodology and BCL Forum
hi, there are two causes i know for this: 1. you really need to make the declaration of the datatype visible. potentially you forgot to include the definition or you didnt import the package. please cross cehck that the datatype is really visible in that scope. 2. i see you are running with IUS. there is a known issue in recent versions of IUS which lead to an incorrect E,SVNOTY error. regards /uwe -
UVM_DEPRECATED message
uwes replied to uvm_rookie's topic in UVM (Pre-IEEE) Methodology and BCL Forum
yes, these are the steps # Switch uvm_sequence_utils to uvm_object_utils # Switch uvm_sequencer_utils to uvm_component_utils # remove the `uvm_update_sequence_lib* macros # If your sequences use “p_sequencer†add `uvm_declare_p_sequencer(<p-sequencer-type>) # create a new style sequence lib (if wanted) class master_seq_lib extends uvm_sequence_library #(bus_10_transaction); `uvm_object_utils(master_seq_lib) `uvm_sequence_library_utils(master_seq_lib) ## Associate sequences with a sequence lib add_typewide_sequence(read_modify_write_seq::get_type()); # Configure the “default_sequence†config setting to point to the library to point either to your seqeunce or your sequence library typedef uvm_config_db#(uvm_object_wrapper) phase_cfg; phase_cfg::set(this,"demo_tb0.whateverbus.initiator_agent.sequencer.run_phase","default_sequence",whateverbus_initiator_nested_seq::get_type()); -
hi, answering your questions: #1 yes #2 the difference is (as noted before) run* gets spawned in parallel to all other runtime phases. main IS one of a set of runtime phases. "run" is there to support old-style OVM/UVM10EA envs within UVM10. #3 once all fine-grained phases have ended and the parallel run has ended simulation progresses to extract, report etc
-
UVM_DEPRECATED message
uwes replied to uvm_rookie's topic in UVM (Pre-IEEE) Methodology and BCL Forum
hi, seems there is a misunderstanding. that switch apparently REMOVES all deprecated code from the library. so in that sense code which refers to deprecated features will now fail to compile. -
UVM_DEPRECATED message
uwes replied to uvm_rookie's topic in UVM (Pre-IEEE) Methodology and BCL Forum
hi, you got three choices here: 1. ignore the deprecated msg 2. switch the deprectated msg off 3. migrate the code to the new sequence library schema /uwe