Jump to content
Sign in to follow this  

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.




Share this post

Link to post
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.

Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this