janick

That depends on the timeout mechanism you are using, the timescale that is active in the timer code and how long your need the timer to be. That value should then be set in each test where it needs to be different than the default value set in the base test. Probably best to set it in the build phase. And as Uwe pointed out, timeout's should only be use to catch run-away conditions, not to terminate the test gracefully.

Three things must happen 1) A coverage model must be included in the generated model. See your generator options to ensure this is ON. 2) The register model must be built with the coverage model using uvm_reg::include_coverage(). You appear to have done so. 3) Coverage sampling must be turned on using uvm_reg_block::set_coverage().

ralgen is a tool provided and supported by Synopsys. I suggest you contact your Synopsys AC.

Hadn't realized overriding with same didn't work. I'll file a bug against this. A work-around is to create a dummy extension that does not add/do anything and use it to "undo" the override.

Yes, your understanding is correct. The value in the RegPredict predict message ends up in the register model. But the mirror(CHECK) function has to check the value read back against the value that was mirrored in the register model BEFORE it gets updated by the new readback value (which in your case comes via the monitoring path).

The advantage as that they are just that: default sequences. Thus a test need only worry about the non-default stuff it needs to do. if every test has to start everything, it will become a maintenance headache should the default behavior shared by many tests need to change.

See $UVM_HOME/examples/simple/phases/timeout for an example on how to add a global per-phase timer.

Even simpler: start the configuration sequence in the base_test::config_phase() task then test-specific sequences can be started in the test's main phase via a virtual sequencer's main_phase.default_sequence or by explictly starting them in a test's main_phase task(). The run phase runs for the entire duration of the test hence it is NOT possible for the driver to be aborted if it is implemented in that phase (as is should). Alternatively, raise the current phase objection if you want to prevent being aborted and drop it for those times where stopping is OK.

Avoid using any undocumented variable or method, especially if prefixed with "m_". Since SystemVerilog does not support friend classes, they are public for implementation reasons. They are not part of the standard and are subject to removal/renaming/modification. Use uvm_component::get_parent().

You can't undo a factory type override, but you can simply override it with the original type: b::type_id::set_type_override(b::get_type()); Is this a trivial example that does not accurately reflect what you are trying to do, because here you simply need to use variables of different types: task body(); b bb; d dd; `uvm_do(bb) // run b `uvm_do(dd) // run d `uvm_do(bb) endtask

Each are happening only once. The fact that there are two messages produced does not imply that there are two transactions. One is produced by the explicit prediction path and the other is produced by the stimulus path. Now, looking at the last two messages, it seems that the read back value is correctly observed, but is not properly sent back to the register model to be returned via the read() method. Make sure your bus2reg() conversion function returns the data value back to the register model.

Since you define the report catcher, you can make it part of your scoreboarding mechanism. What you describe would indeed work. For simple error-detection tests, I keep a counter of expected-and-seen messages in the catcher and check that is has the expected value at the end of the test in the report_phase(). If you see more or fewer messages, the test fails. Another way is to use the uvm_report_server::get_id_count() method to get a count of (presumably demoted) messages of a specific ID that were issued . And demoting expected messages to INFO is indeed a good idea -- with a modification to the text to state that it is an expected warning/error/fatal.

My bad: there is a trivial example in the introduction section of the uvm_report_catcher section in the Reference Manual.

That's what the report catcher is for. As long as the assertion reports its failure using the UVM reporting system, you can catch messages, look at them, and if the ones you are looking for, demote them or simply swallow them so they are never displayed. That's how negative tests are implemented in UVM. There are no examples in the distribution but if you are an experienced OO programmer, it should not be too difficult to figure out.

Avoid using the new()-based approach. It is a hold over from OVM when some simulators were unable to properly implement the singleton pattern. Use svr = uvm_report_server::get_server(); Your syntax error is caused by declaring a variable in the statement block. Move your variable declation to before the call to super.report_phase().

Roman, you are confusing the Cadence uvm_rgm package (which is *NOT* part of the UVM standard) with the UVM register library. There is no such thing as a "Module UVC" in the UVm register library, but instead a register predictor. In explicit mode, the predictor updates the mirror based on observed READ and WRITE transactions on the bus agent. If you do a get() after the read(), I bet a 0 is returned. You do not provide enough information to identify the cause of your problem. For example, if Reg_A is a WO-register, the desired value will be updated to the written value but a physical read will always return 0's (or the value of whatever RO register is mapped at the same address).

The message is triggered by the actual registration of the sequences in the deprecated sequencer-based sequence library by the `uvm_update_sequence_lib statement. By using uvm_sequencer#(base_item) directly, you are not using that macro in the constructor, hence you do not create populate the (obsolete) library.

The register classes abstract the address away so you don't need to know the address. You can simply do blk.subblk.reg.write(status, 'hDEADBEEF);

This is a known issue that will be fixed in 1.1b: http://www.eda.org/svdb/view.php?id=3985

It looks like the read() method does not block until it can return the readback data. Even with explicit monitoring, read() has a blocking completion model and should return the read-back data -- and thus wait until the the transaction has completed before returning.

Check the example in the UVM_HOME/examples/integrated/codec directory. It uses phase jumping to verify hardware reset.

s/Questa/VCS/g ;-)

Those are not documented and thus should not have been used, despite the fact that they were not named "m_*". However, it does make sense to have these macros should these situations (which should be minimized by not accessing anything that is not documented) arise. See http://www.eda.org/svdb/view.php?id=4004

Tjis is the expected behavior. uvm_reg::update() will update the entire register. Sub-register access is only supported when accessing fields (which are alone in their byte lane and the protocol for the address map supports byte enables).

Use uvm_config_db#()::get() (and you should similarly use uvm_config_db#()::set) as they do not depend on the component hierarchy. Further, the set/get_config_*() methods are being deprecated.