Jump to content


  • Content Count

  • Joined

  • Last visited

About dwikle

  • Rank
    Junior Member

Profile Information

  • Gender
    Not Telling
  1. The only thing in the register API which could help you is uvm_reg::backdoor_watch(). However this is not implemented since there it's dependent on a simulator feature. The note from the documentation is: The other options you have are to: 1) Create your own monitor on some internal DUT signal/register and call predict() when it changes. 2) Simply don't check the register value on reads. This may be desired for status fields that you're not fully modeling, or fields that return non-deterministic values on reads such as counters. For option (2) you need to call field.set_compare
  2. If you know when the status values are changing, and what the updated values are, you can update the reg model value by calling predict(). This updates the mirrored value in the model.
  3. If you can modify the sequence, you can add a field to control whether or not to raise objections. Then don't raise objections at all in sequences which run forever loops. As an example, this is from a base sequence class for a component: // Field to control whether objection should be raised. This can be set to // zero by free-running sequences (those which contain foverer loops). bit enable_objection = 1; // Automatically raise/drop objections virtual task pre_body(); if (starting_phase != null && enable_objection) begin starting_phase.raise_objection(this, {get_type_n
  4. Uwe, I like your suggestion. Do you have any example code showing how to change the behavior of the FATAL and do the phase jump? -Doug
  5. Guess I should have checked the docs first. This can be accomplished by implementing uvm_component's pre_abort(). // // UVM pre_abort() : Called prior to UVM_EXIT, e.g. when a fatal occurs // virtual function void pre_abort(); // Call extract and report so that the state of the scoreboard is printed // if the test ends with a UVM_FATAL extract_phase(null); report_phase(null); endfunction
  6. Hi, I have a scoreboard which raises an objection against the run phase ending while there are pending items to be checked. In the case where a DUT bug causes the expected item to never get generated, the scoreboard will keep the objection raised forever. I want my test to end due to the phase timeout, so I set the global phase timeout using uvm_top.set_timeout(t). This all works fine, but when the test ends with a UVM_FATAL due to the timeout, the extract_phase function in my scoreboard is not being called. I want my scoreboard to print out the pending items after the UVM_FATAL, to sig
  7. Steve, That's a great presentation, thanks for sharing it. I wish I would have seen that before I started with UVM_REG. -Doug
  8. Thanks for the feedback. While I have the backdoor access set up for peeking/poking, in this case I really want to trigger of the bus transaction which represents a write to a specific register bit. But rather than monitor the bus transaction and decode the address again, I just want to hook into the register model. I have it working with callbacks and will likely just stick with that. It works fine... I just wanted to see what other options there were. Thanks, Doug
  9. I am building a model of my DUT, and the model will include a reference to the UVM register models for the DUT. The model will need to generate predicted transactions when certain register fields in the DUT are written to, with certain values. For example, when a GO bit is set to 1, the DUT and model should both produce a transaction. What is the proper/best way to do this with uvm_reg? So far I have experimented with creating a callback (extending from uvm_reg_cbs), registering it with the register field I want to trigger on, and then checking for "kind == UVM_PREDICT_WRITE" in post_pre
  10. Hi, We have started using UVM-REG (coming from OVM-RGM) and I have run into an issue. The flow we use for writing registers in the DUT is to update each field value in the model, then execute the write. It seems that uvm_reg::update() is the proper way to do this, so our code looks something like this example: my_reg.a_field.set(1); my_reg.b_field.set(1); my_reg.update(status); What I have found is that if the register value is the same as in the model, the call to update() does NOT result in a transaction on the bus. I guess this is the desired behavior, since the documentation
  11. Is the ralgen register generator tool from Synopsys available to non-VCS users?
  • Create New...