Jump to content
Sign in to follow this  
ljepson74

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?

 

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.

 

post-2891-0-19934800-1379988552_thumb.png

post-2891-0-43235600-1379988564_thumb.png

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);
   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.

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  

×