uwes

as another alternative you may use the commandline something like: +uvm_set_action=uvm_test_top,ID,_ALL_,UVM_NO_ACTION more examples can be seen here: tests / 50cmdlineproc / 40uvm_set_action /

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.

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.

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

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.

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

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

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.

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

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, please check your versions. UVM10 has been qualified for IUS10.2s11+ (and 9.2s35+) only. I see that you indicate to run with 10.2s10 but the version in the header shows 10.2p8. regards /uwe

hi, i would suggest to file a mantis item (as described in the .pdf) first. the viptsc does discuss the current mantis items during the regular calls and at the same time the issue is captured in a tracking system where also others can view those issue, /uwe

hi, can you please file a mantis (bug report/question/suggestion with the uvm bcl) here http://eda.org/svdb/bug_report_advanced_page.php? this is the primary errata database for uvm and might also have infos about already filed issues (or resolved issues) /uwe

hi, can you please file a mantis (bug report/question/suggestion with the uvm bcl) here http://eda.org/svdb/bug_report_advanced_page.php? this is the primary errata database for uvm. /uwe

hi, can you please file a mantis (bug report/question/suggestion with the uvm bcl) here http://eda.org/svdb/bug_report_advanced_page.php? this is the primary errata database for uvm. /uwe

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

hi, yes, so here you migrated directly to a UVM10 env with the new phasing. once you do that you dont need the UVM_USE_OVM_RUN_SEMANTIC anymore.

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.

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

hi, just to let you know that if you have UVM10EA environments or OVM envs converted via the ovm2uvm.pl to UVM(10EA) you most likely require to add +UVM_USE_OVM_RUN_SEMANTIC to your cmdline switches. otherwise the simulation completes in zero time.