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

[ljepson74]

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?

 

thanks

 

 

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.

 

[ljepson74]

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);
   phase.raise_objection(this);

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

   `uvm_info("dmx_rg3_reg_test", "Running register test reset_phase. Dropping objection", UVM_LOW);
   phase.drop_objection(this);
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.

 

anyhow,

Case Closed.