ljepson74 Posted September 24, 2013 Report Share Posted September 24, 2013 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. Quote Link to comment Share on other sites More sharing options...
ljepson74 Posted September 24, 2013 Author Report Share Posted September 24, 2013 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.