Jump to content

chr_sue

Members
  • Posts

    25
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by chr_sue

  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.
  15. You do not say anything about a relationship between interface A and B, i.e. can you do a few transactions on the cmd interface without needing the data from the data interface or vice versa. Please elaborate.
  16. Make it easy. Do a type cast to string. See below the code: module top; typedef enum {alpha, beta, gamma, delta, epsilon} my_enum; string my_string; my_enum state; initial begin state = beta; my_string = string'(state.name); $display("string = %s", my_string); end endmodule
  17. Please look here at Using UVM_LOG in https://verificationacademy.com/cookbook/messaging/usingmessaging
  18. You dot need a reference to the covergroup class. You can omit this line of code: cg_fsm_state cg_fsm_state_inst; In the constructor you are calling new directly on the coverage class name: cg_fsm_state = new();
  19. If you do not know from which piece of code this message comes set a reasonable timeout in the toplevel module of your UVM testbench.
  20. I believe the problem comes from here. The UVM Reference Manual says: If unmapped is True, the register does not occupy any physical addresses and the base address is ignored. Unmapped registers require a user-defined front door to be specified. The default value of unmapped shall be 0, which is FALSE. Because there is no physical address for this type of registers it will not be updated.
  21. I found an example on the Doulos webpage. The code is in the EDAPlayground: https://www.edaplayground.com/x/4vf Hope this helps.
  22. I believe you have a wrong understanding of the UVM RAL. A few aspects only: (1) the frontdoor sequence you are mentioning is not frontdoor/backdoor. It is a specific class to define a complex sequence related behavior. See the UVM Ref.Manual for the details. (2) the OSPI sequence does not go through the adapter using reg2bus and bus2reg. (3) The adapter is used to convert a generic UVM RAL sequence into a OSPI sequence. (4) Each register sequences has to have a specific access type like RO, RW etc. This might be a few ideas to work on your issue.
  23. The register adapter contains 2 functions: (1) bus2reg (2) reg2bus bus2reg implements the path from the pinlevel interface to the register layer. This is the path which returns the rD-data (ahb_hrdata). reg2bus implements the path from the register layer to the pimlevel interface. This is the path which is used to send the WR-data ahb_hwdata) from the register layer to the DUT.
  24. Unfortunately you do not show a piece of code. But the 3rd argument has to be a bit type (1'b1 for replacing).
×
×
  • Create New...