uwes

hi, yes the sequence library is in active use. it has replaced the old sequence libary model (which actually was an association of sequence+sequencer, but sometimes also the file with the sequences was decalred as sequence library). with the uvm10 sequence library the old conceptual model became a real object and therefore a sequence library is really an "entity". the most common use model is as "meta" sequence to start associated sequences. an advanced usage could include user defined schemes such as 'randomize sequences but only those without an "deprecated" in their name'. /uwe

hi, the error is (probably) not related to the problem of contructor or not althrough i agree the better place is the constructor. /uwe

hmmm, interesting, the code has been run on IUS-10.20s40 without issues... which version do you use? (i know that the line with selection_mode is violating the enum assignment rules in sv)

hi, to see the docs your company need to be an accellera member. to file a bug in mantis you do not need to be an accellera member. /uwe

hi, filed http://eda.org/svdb/view.php?id=3566 for the issue. the attached code should fix that, i'll try that and inject the fix (if its good) function void uvm_sequencer_param_base::connect_phase(uvm_phase phase); super.connect_phase(phase); rsp_export.connect(sqr_rsp_analysis_fifo.analysis_export); endfunction

hi, all change requests should be filed here: http://eda.org/svdb/bug_report_page.php you may also want to check the latest user guide + ref (release candidate for uvm11) if you are an accellera member here: http://www.accellera.org/apps/org/workgroup/vip/download.php/4183/uvm_guide_1.1_ballot_may_11.pdf http://www.accellera.org/apps/org/workgroup/vip/download.php/4143/UVM_1.1_Class_Reference_for_member_review.pdf

hi, uvm_test_done has its roots back in OVM/UVM10EA (and even before in SN/e). it was a simple objection towards the end-of-test. with UVM10 and the phasing capabilities the decision has been made that phase progression needs to be controlled by objections to the end-of-a-phase. so my suggestion for UVM10 code is to replace uvm_test_done objections with objections to the end of phase. if you do that your sequences will work independent of the phase you are in and end of test is controlled by the ending of your last phase. /uwe

hi, here we go: class my_seq_lib extends uvm_sequence_library #(my_item_c); `uvm_object_utils(my_seq_lib) `uvm_sequence_library_utils(my_seq_lib) function new(string name="my_seq_lib"); super.new(name); init_sequence_library(); endfunction virtual task body(); string phase_name; if (starting_phase != null) begin phase_name = {starting_phase.get_name(),"_phase"}; end void'(uvm_config_db#(uvm_bitstream_t)::get(m_sequencer, phase_name, "default_sequence.min_random_count", min_random_count)) ; void'(uvm_config_db #(uvm_bitstream_t)::get(m_sequencer, phase_name, "default_sequence.min_random_count", min_random_count) ); void'(uvm_config_db #(uvm_bitstream_t)::get(m_sequencer, phase_name, "default_sequence.max_random_count", max_random_count) ); void'(uvm_config_db #(uvm_bitstream_t)::get(m_sequencer, phase_name, "default_sequence.selection_mode", selection_mode) ); super.body(); endtask endclass now you can use a cmdline setting like +uvm_set_config_int=uvm_test_top.tb.sequencer,default_sequence.max_random_count,33

hi, maybe i didnt state it clear enough. the +uvm_set_config_int cmdline option maps the set to an set_config_int (and finally to uvm_config_db#(uvm_bitstream_t)::*) HOWEVER the code in uvm_sequence_library is accessing the config db with a uvm_config_db#(int unsigned)::*. as these two types are NOT equivalent the standard implementation cant see values set using the cmdline facility. i opened a mantis for this http://eda.org/svdb/view.php?id=3560 one workaround is to "copy" over the values from the uvm_config_db(uvm_bitstream_t) to uvm_config_db(int unsigned) prior to a call to uvm_sequence_library.m_get_config /uwe

yes, uvm_update_sequence_lib refers to a deprecated facility (thats why its not documented anymore) and UVM_NO_DEPRECATED removes all deprecated code from the library. to move ahead simply remove the uvm_update_sequence_lib line. /uwe

ok, here we go. you do only object to end-of-test but not to the phase progression. thats why your started sequence in main is killed almost instantly and phasing continues with post_main_phase.

hi, 1. the set path should be by default "uvm_test_top.demo_tb0.tm.simple_tx_agent.sequencer.<typename-of-seq>.<fieldname>". you can find out the full path of your seqlib instance by printing get_full_name() 2. the handling of the standard fields of the seqlib require that the uvm_config_db is being used for the set. the reason for that is that the type specifier of "int unsigned" is used to pull the values from the config database. unfortunately this also means it has to be set using "int unsigned" which is incompatible with the bitstream_t which +uvm_set_config_int uses. 3. in order to resolve that you could in your seq lib reimplement m_get_config() and forward the config values set on uvm_config_db(uvm_bitstream_t){min_random_count, max_random_count, sequence_count } to uvm_config_db#(int unsigned) and then call the original via super.m_get_config /uwe

hi, do you raise an objection to uvm_test_done OR the current phase? you can enable the phase tracing and UVM_VERBOSITY=UVM_DEBUG to get more information about phase progression or other things going on in your tb /uwe

hi, could it be that you dont have objections in your sequence? because if no one objects in the main_phase it will be terminated instantly and your started seq doesnt really execute. so you should implement the pre_body and post_body of your root sequence to raise the phase objection /uwe

hi, the deal is the following: either (A) you compile the DPI-C code yourself and link it with the simulator using tool specific switches ( you get a precompiled binary of the DPI-C code for your architecture and you simply link it in © the vendor is providing you with a special switch in their distribution which does ( for you (and for instance the compile of the uvm library) please note that the vendors may ship extended versions of DPI-C library and/or UVM to enable additional features (such as tcl queries, commands, transaction recording). so in summary you can most likely run withput a vendor vendor overlay given you follow (A) BUT you may not get potential additional features. /uwe

hi andreas, there have been a few issues with random stability in the base classes related to cmdline switches for instance: http://eda.org/svdb/view.php?id=3403 http://eda.org/svdb/view.php?id=3139 also to note is that random stability is not easy to maintain in SV and very simple changes can cause unexpected differences. anyway if the only change you do is changing the arg of +UVM_VERBOSITY and you do not create instances/behaviour upon the severity level yourself its most likely in the UVM core. if your issue is related to http://eda.org/svdb/view.php?id=3403 it should be fixed and you can try with a more recent snapshot. /uwe

no, there is nothing special for a particular phase. can you supply a testcase and a more specific information about the problem you have. does the seq start? does it wait? is it killed? what is th exact issue you see?

hi, unless you want to edit mega-lines long netlists DVT is a good route (http://www.dvteclipse.com/), in addition to all the SV related features you can build upon all eclipse plugins such as version control support, history/diffs, you could link to bug tracking, c/c++/xml development. /uwe

hi, for debugging configuration issues you can: 1. dump the database uvm_config_db#(int)::dump() 2. trace sets and gets using the +UVM_CONFIG_DB_TRACE or +UVM_RESOURCE_DB_TRACE switches in the upcoming UVM release 3. you could switch auditing on to find readers and writers of an resource uvm_resource_options::turn_on_auditing() followed by a <resource>.print_accessors() 4. you could enable the "verbose" mode of uvm_component.apply_config_settings 5. you can check using uvm_component.check_config_usage() to detect config settings write-no-read 6. you can use uvm_component.(print_config|print_config_with_audit|print_config_settings)

hi, the code you have has many flaws starting with extensability, type safety, length and probably more but still you could do the following: // the code DOESNT run - it only compiles and shows module test85; import uvm_pkg::*; `include "uvm_macros.svh" task bla(uvm_object_wrapper seq); uvm_sequence s; uvm_object o = seq.create_object("seq"); assert($cast(s,o)) else $fatal("supplied object is not a sequence"); s.start(null); endtask class myseq extends uvm_sequence; `uvm_object_utils(myseq) function new (string name = "myseq"); super.new(name); endfunction endclass initial begin bla(myseq::get_type()); end endmodule i'm not sure if the double lookup ("run-seq1" -> "my-seq1" -> then type) is a good solution - i'd rather avoid the case graves, string mappings and searches /uwe

hi, what about task myseq::body(); uvm_sequence s = myseq::type_id::create("sequence"); s.start(); im assuming that "myseq" is the type and that the sequence has been registered with the name. regards /uwe

why not 1. split the full path into context plus path down from the current object uvm_config_db#(virtual st_if)::set(this, $sformatf("*.st%03d*",i), "vif",if_wr.if1); // you have to remove "*." if st000 is a child of the current object 2. remove the postfix wildcard match uvm_config_db#(virtual st_if)::set(this, $sformatf("*.st%03d",i), "vif",if_wr.if1); (3.) if you are really funny you can replace the whole set with a posix regexp uvm_config_db#(virtual st_if)::set(this, "/st[0-9]{3}/"), "vif",if_wr.if1); // would apply to direct subcomponents of "this" named "st000".. "st999" with a field "vif"

hi, there are a few common causes for this error 1. the if has not been set - the property "top.tb_env.st000.st_rx_agent.driver.vif" is unset (simply unset, wrong hierarchy, mistyped or similar) 2. the if has been set but the uvm_config_db parameter type is not equivalent between set() and get().

hi, one way would be to reuse the reg_op as bus_op. this means creating an env with uvm_sequencer#(bus_op) and a uvm_driver#(bus_op). then you only need to implement the get_next_item loop in the driver and there you can either rd or write.

hi, you can check in the GUI the types of m_sequencer and p_sequencer and see if there is a mismatch in the parameter set. apart from this you would need to provide more details about your sequencer types/instances etc. /uwe