![](http://content.invisioncic.com/r164598/set_resources_1/84c1e40ea0e759e3f1505eb1788ddf3c_pattern.png)
uwes
Members-
Posts
625 -
Joined
-
Last visited
-
Days Won
11
Content Type
Profiles
Forums
Downloads
Events
Everything posted by uwes
-
Starting sequences on null sequencer?
uwes replied to cliffc's topic in UVM (Pre-IEEE) Methodology and BCL Forum
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
-
Starting sequences on null sequencer?
uwes replied to cliffc's topic in UVM (Pre-IEEE) Methodology and BCL Forum
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
-
Unable to load the implicit shared object
uwes replied to sidharth.sankar77's topic in UVM Simulator Specific Issues
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, 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, 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
-
How to do multiple writes using uvm_hdl_force
uwes replied to qwerty's topic in UVM (Pre-IEEE) Methodology and BCL Forum
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 -
initialization sequence question
uwes replied to twk1156's topic in UVM (Pre-IEEE) Methodology and BCL Forum
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
-
who can interpret use of soft constraint ?
uwes replied to wszhong631's topic in UVM SystemVerilog Discussions
hi, asking for help but raise the question in some other forum isnt helpful. /uwe -
UVM reg model access policy of registers
uwes replied to qwerty's topic in UVM (Pre-IEEE) Methodology and BCL Forum
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
-
Incompatible complex type usage error from VCS; Questa is OK
uwes replied to mea1201's topic in UVM Simulator Specific Issues
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 -
extending uvm_cmdline_processor - problem
uwes replied to ljepson74's topic in UVM (Pre-IEEE) Methodology and BCL Forum
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- 2 replies
-
- uvm_cmdline_processor
- virtual
-
(and 2 more)
Tagged with:
-
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 ?
- 3 replies
-
- emacs
- indentation
-
(and 1 more)
Tagged with: