chr_sue

You should be very carefully when using set_draintime, becaus it stops your simulation when set. You'll never know how long your simulation is running exactly. set_draintime is useful when you are running a series of tests maybe overnight. If one of the jobs hangs and does not come to an end the other ones wll never be executed.

I can't see what you are saying. The simulator shows a PASS. I changed only the simulator. Please see here: https://www.edaplayground.com/x/Va3L

After writing registers you can simply read the registers. Then you know the real content of the register.

I do not know how Riviera is calculating the coverage. But you are calling the sample method only one. You should call it in the loop after each new data set for bit and addr. BTW you are using the $random which is again Verilog and not SV. Use $urandom instead.

Your verification environment is not a UVM environment. It is a Verilog testbench written in SV. You do not construct it in accordance with the UVM rules. Your driver is never going through the build_phase, because you are calling in your toplevel module simply the constructor of your driver. But this call is not related to any virtual interface.

I believe you can employ the array querying functions like $high, $low, $left, $right. Plese visit the SV LRM for more details.

In the correspondig pahse function/task you can use a `uvm_info to state in which phase you are.

Did you inclide te UVM macros file like this: `include "uvm_macros.svh"

The message you are showing indicates only that all run_phases have been completed. It doies not say anything about dropping objections. Where did you insert the objection mechanism? Please show some mor code, especiually from the driver and the monitor.

You are discussing 2 different things. (1) What happens when you are reading a WO register or filed. (2) What happens when you are setting a field in a WO register. Reading a WO register does not have a dependency on the design.

The scoreboard and the sequence item do not know anything about the timing, like clock cycles or absolute time. On the transaction level only the order of the items counts. What you can do is to count your items. Any timing is only related to so called transactors, i.e. drivers and monitors.

The simulators are showing if the assertions are active or not. I believe you can rely on this. Checkin gthis should belong to the assertion development/integration.

A queue or a dynamic array do not have any content when declared, i.e. there is nothing to randomize. When you have entries in your queue/array you can simply call shuffle. This will randomize the order of the elements in the arrays.

1. uvm_resource_db is a datbase which is used as basis for uvm_config_db. uvm_config_db is adding more flexibility to uvm_resource_db. 2. You should never use uvm_resource_db 3. Is obsolete because of 2.

Both cases do exectly what you are instructing in your code. The fatal in case 1 comes from waiting for the 2nd event which never happens. See the log-file here: UVM_INFO verilog_src/questa_uvm_pkg-1.2/src/questa_uvm_pkg.sv(215) @ 0: reporter [Questa UVM] QUESTA_UVM-1.2.3 # UVM_INFO verilog_src/questa_uvm_pkg-1.2/src/questa_uvm_pkg.sv(216) @ 0: reporter [Questa UVM] questa_uvm::init(+struct) # UVM_INFO @ 0: reporter [RNTST] Running test uvm_top_test... # UVM_INFO case1-uvm_event.sv(91) @ 0: uvm_test_top [uvm_top_test] Starting run phase for uvm_test_top # ---------------------------------------------- # Name Type Size Value # ---------------------------------------------- # <unnamed> uvm_root - @13 # uvm_test_top uvm_top_test - @466 # simple_comp uvm_simple_comp - @473 # u_top_comp uvm_top_comp - @480 # ---------------------------------------------- # UVM_INFO case1-uvm_event.sv(44) @ 0: uvm_test_top.simple_comp.u_top_comp [uvm_top_comp] calling wait_for_match 1 # UVM_INFO case1-uvm_event.sv(20) @ 0: uvm_test_top.simple_comp.u_top_comp [uvm_top_comp] Before trigger HI # UVM_INFO case1-uvm_event.sv(40) @ 0: uvm_test_top.simple_comp.u_top_comp [uvm_top_comp] calling message receiver task # UVM_INFO case1-uvm_event.sv(28) @ 0: uvm_test_top.simple_comp.u_top_comp [uvm_top_comp] Before trigger 1 # UVM_INFO case1-uvm_event.sv(30) @ 0: uvm_test_top.simple_comp.u_top_comp [uvm_top_comp] After trigger 0 # UVM_INFO case1-uvm_event.sv(22) @ 0: uvm_test_top.simple_comp.u_top_comp [uvm_top_comp] After trigger HI run -a # UVM_INFO case1-uvm_event.sv(64) @ 100: uvm_test_top.simple_comp [uvm_simple_comp] calling wait_for_match 2 # UVM_INFO case1-uvm_event.sv(20) @ 100: uvm_test_top.simple_comp.u_top_comp [uvm_top_comp] Before trigger Hello # UVM_FATAL verilog_src/uvm-1.1d/src/base/uvm_phase.svh(1251) @ 9200000000000: reporter [PH_TIMEOUT] Default timeout of 9200000000000 hit, indicating a probable testbench issue # This is caused by the topdown execution of the components in your hierarchy. case 2 looks differently: # UVM_INFO verilog_src/questa_uvm_pkg-1.2/src/questa_uvm_pkg.sv(215) @ 0: reporter [Questa UVM] QUESTA_UVM-1.2.3 # UVM_INFO verilog_src/questa_uvm_pkg-1.2/src/questa_uvm_pkg.sv(216) @ 0: reporter [Questa UVM] questa_uvm::init(+struct) # UVM_INFO @ 0: reporter [RNTST] Running test uvm_top_test... # UVM_INFO case2-uvm_event.sv(135) @ 0: uvm_test_top [uvm_top_test] Starting run phase for uvm_test_top # ---------------------------------------------- # Name Type Size Value # ---------------------------------------------- # <unnamed> uvm_root - @13 # uvm_test_top uvm_top_test - @466 # simple_comp uvm_simple_comp - @473 # u_top_comp uvm_top_comp - @480 # ---------------------------------------------- # UVM_INFO case2-uvm_event.sv(67) @ 0: uvm_test_top.simple_comp.u_top_comp [uvm_top_comp] calling wait_for_match 1 # UVM_INFO case2-uvm_event.sv(27) @ 0: uvm_test_top.simple_comp.u_top_comp [uvm_top_comp] Before trigger HI run -a # UVM_INFO case2-uvm_event.sv(98) @ 100: uvm_test_top.simple_comp [uvm_simple_comp] calling wait_for_match 2 # UVM_INFO case2-uvm_event.sv(27) @ 100: uvm_test_top.simple_comp.u_top_comp [uvm_top_comp] Before trigger Hello # UVM_INFO case2-uvm_event.sv(39) @ 100: uvm_test_top.simple_comp.u_top_comp [uvm_top_comp] Before trigger 2 # UVM_INFO case2-uvm_event.sv(43) @ 100: uvm_test_top.simple_comp.u_top_comp [uvm_top_comp] After trigger 0 # UVM_INFO case2-uvm_event.sv(31) @ 100: uvm_test_top.simple_comp.u_top_comp [uvm_top_comp] After trigger Hello # UVM_INFO case2-uvm_event.sv(157) @ 100: uvm_test_top [uvm_top_test] Ending run phase for uvm_test_top # UVM_INFO case2-uvm_event.sv(31) @ 100: uvm_test_top.simple_comp.u_top_comp [uvm_top_comp] After trigger HI # UVM_INFO verilog_src/uvm-1.1d/src/base/uvm_objection.svh(1267) @ 100: reporter [TEST_DONE] 'run' phase is ready to proceed to the 'extract' phase case1-uvm_event.sv case2-uvm_event.sv