uwes

thats correct. a virtual sequence running on a null sequencer can start other virtual sequences(on this or other sequencers) or other BFM sequences/items (when a real sequencer handle is supplied). The 'funky' stuff like grab/lock does probably require a sequencer instance. priorities should only be in the picture for items. /uwe

hi, just guessing: since you start an instance of tr_sequence on a NULL sequencer i do assume this is a virtual sequence. if you start an non-virtual sequence or item without setting the sequencer you should be seeing this or a similar error. it could also be an issue similar to http://eda.org/svdb/view.php?id=4980 /uwe

hi, running a sequence on a "null" sequencer is only valid for virtual sequences. /uwe

hi, i assume that you hit a bug which was fixed some time back. the cadence internal ccr number is 1248722. the fix should be in 13.20s9+ /uwe

hi, please provide a the cmdline, setup, os here or provide the information to the cadence support hotline to resolve. /uwe

hi, there should be no limitations affecting you. there might be simulator limitations (size of arrays etc.) but even those are far away. the typical bounds for the register model are defined by the number of types (registers, registerfiles,...) and instances for compile/elab/simulation. these are soft (=handling) bounds (memory+time) rather then implementation bounds. /uwe

hi, you cannot use wildcards in the set_report_* functions (all act on specific values). but you can use a catcher to match the id once the message is emitted. if this is feasible depends upon your exact scenario (do you want to remove or enable that particular message?) /uwe

hi, if you just want a low-level raw access why not to send that (address,direction,data) tuple directly to the low level sequencer. if you want a register/memory why not use uvm_reg_map::get_reg_by_offset() or uvm_reg_map::get_mem_by_offset() and then perform the read/write on the one returned. btw: there might be some pitfalls such as requesting a register from an address which is not a registers base address or similar regards /uwe

hi, both should be equivalent ::set(null,....) and ::set(uvm_root::get(),....) /uwe

hi, i think the answer is "simple" 1. the active path reg.read()->seqr->adapter->driver->adapter->seqr->reg.read()-end always needs that the driver supplies the final data and the adapter translates it. if your driver finishes the transaction before the transfer is complete (posted transactions, out of order, pipelined transactions, etc) OR doesnt provide the correct data then the result of the read() does not reflect the right value. there is no other way to return data to the caller than via this path. 2. the difference auto_predict() makes is that with auto_predict(1) the active path will update the shadow register while with auto_predict(0) some other instance needs to take care of that (monitor->predictor).in other words - auto-predict() has no influence of what data is being returned to the caller of a reg.read() call. 3. the adapters bus2reg and reg2bus should be kind of "inverse" - if they are not its likely that wrong data is provided, the wrong register updated with wrong data etc. /uwe

hi, if these are bus-accessible registers (not just 'reg' s) then use the register model together with the hdl backdoor instead of directly forcing the values. /uwe

hi, there are various ways to implement that. the actual way would depend upon you actual requirements. >This is similar to run sequences in sequential way and it enforce a requirement for test developer well, you either have to express that dependency or ordering in some way (for instance by invoking super.body()) OR you have to establish a convention to follow (such as to put the init sequence into pre_configure_phase and all user sequences into a phase afterwards) /uwe

hi, if you use the field macros then you just need something like `uvm_field_int (a, UVM_DEFAULT|UVM_HEX) if you implemented do_print() instead you need to use something like printer.print_field_int ("address", m_address, 64, UVM_HEX); /uwe

hi, in catchers, own report_server::(compose|execute)_report_message, own recording backend, the uvm_components::report_*_hook functions (and probably more places) it is problematic to invoke uvm_report_*. basically all places potentially invoked during message processing should not emit a new message while the old is processed. /uwe

hi, prior to uvm12 the library code did contain a mix of raw $display,$write and messages routed through uvm messaging. with uvm12 ALL uvm library code is routed through the uvm messaging and can be affected with uvm message controls. btw1: $display makes sense for instance in certain message callback functions and other special situations to avoid endless loops. that might happen through recursion and there is no guard in uvm to avoid this. btw2: the whole universe of verbosities, callbacks, severities, catchers, actions,... isnt that easy to use especially when it comes to adjusting/filtering and i could see that as a driver to use $display... /uwe

hi, asking for help but raise the question in some other forum isnt helpful. /uwe

hi, registers are rather "dumb" containers of register fields and there might not be a single access policy for a register. fields (uvm_reg_fields) carry most of the functionality in UVM_REG. in order to learn the access policy of the field you can query via somefield.get_access(map). since the effective access policy depends upon the uvm_reg_map used for a potential access you may pass the relevant map into the function as well. /uwe

>Is there a future bug fix release for UVM 1.1 planned? UVM 1.1e maybe for people who don't want to migrate to UVM 1.2 just yet? there will be no uvm11 release anymore. "all" bugfixes/enhancements went into uvm12. /uwe

hi, >It's a bit worrisome IMHO that this was only found/reported in (very late) 2013 and wasn't fixed. the issue was reported & fixed in dec2013. the issue is that the fix was omitted from uvm12 unnoticed because the issue was not targeted to be fixed in 1.2 in the mantis system. and actually there is a test for this scenario now but its in the same unmerged branch as the fix itself. >Coming back to your problem, qwerty, your best bet is to model the reserved fields as volatile. marking the field as volatile during creation turns off the checks. but you can also go and find all "rsvd" fields once and mark them as UVM_NO_CHECK. /uwe

hi, isnt this http://www.eda.org/mantis/view.php?id=4806 ? i think the patch is missing from uvm12 - can you try to apply http://sourceforge.net/p/uvm/code/ci/852d197932c928f526c44779e16c68bcc2854e73/ and see if your unmodelled fields are still considered? /uwe

hi, unmodelled bits are treated as "don't care" by the model - so why do you care? you may read/write the bits - you just cant access them by a "name" and of course they will not compare. the simplest way is not to model "rsvd" fields otherwise if you want to model them and label the field "reserved" or similar you have to provide a matching access policy. If you do not want to consider the field in compare then disable the check (.set_check()). if you just cannot predict the value then mark it initially a "volatile" or turn off the check afterwards. /uwe

hi, my reading is that you need >class my_concrete extends my_abstract#(T,Tname); otherwise your class extends from the default paramterization which finally leads to a type collision. (the symbol T in your my_concrete class collides because you got my_bfm#(...)::T (the param T from the module) and my_bfm#(..)::my_concrete#()::T (the param T you inherit from abstract) /uwe

hi, if you just want to check the args then you dont need to override the cmdline processor. all you need are the arguments and you can get them anywhere. currently you cant override the cmdline processor. btw: checking might be hard since not every +plusarg is for you. you might also consider that the oldstyle +plusargs (tool options) ala +incdir+... might have a dash variant (-incdir) during tool invocation. the difference between the two is that dash-args are checked which plus-args go unchecked (and then hope you dont have a typo). /uwe

hi, you dont need to override run_test() for this. there are a couple of options 1. if you control the cmdline then you can change +UVM_TESTNAME to "test2" yourself - no need for another switch 2. you can in the sv code add an override for test->test2 so that when choosing "test" actually test2 is run 3. you can add your logic before the run_test() call and then pass the new test so that the normal run_test() will become run_test(string:"test2") 4. depending upon your simulator vendor you might be able to set overrides from the simulator prompt. that allows you to run with +UVM_TESTNAME=test but then from the tcl prompt do #2 interactively probably there are more ways here /uwe

hi, keywords are keywords - you cant use them for identifiers. even if the language would support that it is nothing which helps to survive in your project.even if you find a tool which does that its very likely the next tool down the road will refuse to handle it. small example: typedef typedef; // forward define of a class typedef typedef foo; // is this an instance now(of the type typedef) or a forward typedef of foo ?