Jump to content

chr_sue

Members
  • Posts

    25
  • Joined

  • Last visited

  • Days Won

    2

chr_sue last won the day on May 14 2020

chr_sue had the most liked content!

Recent Profile Visitors

323 profile views

chr_sue's Achievements

Member

Member (1/2)

3

Reputation

  1. In the correspondig pahse function/task you can use a `uvm_info to state in which phase you are.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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
  9. Calling check_config_usage in the check_phase is not really helpful, because this is after the run_phase. It prints all set to the config_db without get. Otherwise it is silent. This is a typical command to clean-up the access of the config_db. A good plaace to do this is prior to the run_phase as shown here: function void start_of_simulation_phase(uvm_phase phase); check_config_usage(); endfunction
  10. The "default liblist" is followed by libs. The first one is gates_lib and the second work. "work" is the default library name for Questa.
  11. You have to specify the data direction for the enable port.
  12. Could you please explain what you mean saying 'verify register file content through assertion'. What is 'register file content'? Assertions are used to verify dynamic behavior. What you are sayying sounds static.
  13. These terms are different. A virtual sequence defines how the local/agent sequences should behave. A virtual sequence contains sequences of different types/inheritence. The sequence library allows you to add sequences of the same type/inheritence to it. Then you can start the sequence library like a single sequence and all the sequences belonging to it will be executed in a certaim order, defind by the specified execution mechanism.
  14. You have a few weaknesses in your code: (1) Your class seq seems to be a virtual sequence, because you do not parameterize it for a ceratin seq_item. In the body task you are creating seq_items. (2) You are declaring vsqr as p_sequencer and at thge same time you are using it as virtual sequencer. (3) If you do not have a forever loop in your sequence it comes always to its end. It is useless to stop sequences with the corresponding commands. (4) run_test instantiates your test implicitly You do not have to construct it explicitely. (5) sequences are transient objects and no components. They will not be constructed in the build_phase. I guess your problem comes from calling stop_sequences.
×
×
  • Create New...