Jump to content

how to (best) delay the start of built-in UVM register test stimulus


Recommended Posts

I've run into the following issue using the built-in UVM register tests.

The built-in UVM register tests (seem to) start R/W-ing immediately after top-level reset is released.  

This was fine, initially.  See attached image "Capture".


We now have some delay between the release of top-level reset and the actual reset going to the register block.  This is resulting in a read occurring before reset to the rtl regblock is released, and causes the test to hang.  See attached image "Capture2".


Without modifying the built-in register tests/sequences, how would anyone suggest that we cleanly delay the stimulus?    Perhaps I just need to make the stimulus aware of the different reset when the model/stimulus is generated, or simple add some delay to a phase before the R/W-ing starts.  (The former sounds right.  If that's the solution, I'll need to figure out how we're generating the model/stimulus.)


I've just started hunting around for the built-in UVM register test sequences and will return to it tomorrow, but will anyone tip me off as to what names I should be searching for?





This has been useful, https://verificationacademy.com/cookbook/registers/builtinsequences, but it seems I need to do some more reading and hunting before I grasp how the built-in register stimulus is created and used.




Link to comment
Share on other sites

Per my co-worker Jose's suggestion:




We set up the register sequence as the "default_sequence" for the main_phase.   
    // Set the reg_agent sequence to run the uvm_reg builtin sequences
    uvm_config_db#(uvm_object_wrapper)::set(this, "*.m_reg_agent.m_seq_reg.main_phase", "default_sequence", uvm_builtin_reg_test_seq::type_id::get());
What can be done is implement a "reset_phase" in your test that raises an objection, waits for reset to de-assert, waits for some amount of time, then drop the objection.  Your reset_phase will consume simulation time until the dut is ready to run, so then the main_phase isn't started until after your reset phase has completed.  This pushes out the time that your register sequence is started, as it is only run in the "main_phase" of your test.
So, I didn't try to tamper with the builtin reg sequences or any generation scripts at all.  I simply added a reset_phase to my register test, to delay the start of (main_phase) the builtin reg sequences, like this:


task dmx_rg3_reg_test::reset_phase(uvm_phase phase);
   `uvm_info("dmx_rg3_reg_test", "Running register test reset_phase. Raising objection", UVM_LOW);

   wait (env.m_dmx_rg3_fiver_agent.m_vif.resetn);
   repeat (12) begin
      @ (posedge env.m_dmx_rg3_fiver_agent.m_vif.clk);

   `uvm_info("dmx_rg3_reg_test", "Running register test reset_phase. Dropping objection", UVM_LOW);
endtask : reset_phase


I realize a more robust solution would be to do a wait on the proper reset, instead of the combo of doing the wait on the top-level one (which I did via the m_vif above), and then overshooting the delay of the reset that is used, by waiting an addition 12 clk cycles.  I may change that.
Case Closed.
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...