bhunter1972 Posted August 7, 2012 Report Share Posted August 7, 2012 When the hardware undergoes a hard reset, I'd like to be able to call the uvm_reg_field.reset() function to have it reset the mirrored value of the field. That way, when reset is deasserted, I can call update() on the fields and they will be re-written to their previously randomized values. However, the reset function also clears out the desired value. This means that the randomization on all of the fields is lost upon reset and you would have to re-randomize everything, which may not be what you want. It would be nice if the reg_block, reg_file, reg_field, (etc.) supported a conditional second argument that allows you to retain the desired value (changes in bold): function void uvm_reg_field::reset(string kind = "HARD"[B], bit keep_desired=0[/B]); if (!m_reset.exists(kind)) return; m_mirrored = m_reset[kind]; [B]if(!keep_desired)[/B] m_desired = m_mirrored; value = m_mirrored; if (kind == "HARD") m_written = 0; endfunction: reset After searching through the code, I see no clean way to do this in 1.1b. Quote Link to comment Share on other sites More sharing options...
janick Posted August 7, 2012 Report Share Posted August 7, 2012 You want a "save-and-restore" capability. You are correct that there isn't an easy way to do this today. I would suggest you iterate over all the registers in a block using uvm_reg_block::get_registers() then save their current value using uvm_reg::get(), apply reset, then restore the saved valued by using uvm_reg:: put() on the same iteration. You'll then be able to call uvm_reg_block::update(). Quote Link to comment Share on other sites More sharing options...
bhunter1972 Posted August 7, 2012 Author Report Share Posted August 7, 2012 I think you mean uvm_reg::set() above. But anyway, I used a factory override on uvm_reg_field instead to give me the same result: virtual function void reset(string kind = "HARD"); uvm_reg_data_t curr_desired = get(); super.reset(kind); set(curr_desired, `__FILE__, `__LINE__); endfunction: reset This seems like it would be a useful feature. Any chance it could be registered as an enhancement request? An alternative implementation to the keep_desired argument above might be simply a reset_mirror() function (up and down the stack). Thanks! Quote Link to comment Share on other sites More sharing options...
janick Posted August 7, 2012 Report Share Posted August 7, 2012 (edited) Anything can be done. Adding a new kind of reset might be a better solution. Edited August 7, 2012 by janick 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.