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(UVM_NO_CHECK) after the field has been created and configured. -Doug
  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_name(), " pre_body"}); end endtask virtual task post_body(); if (starting_phase != null && enable_objection) begin starting_phase.drop_objection(this, {get_type_name(), " post_body"}); end endtask
  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 signal the user what the problem was that caused the timeout. How can I accomplish this? Thanks, Doug
  7. Thanks Dave. Can anyone file a bug or enhancement request there? -Doug
  8. Steve, That's a great presentation, thanks for sharing it. I wish I would have seen that before I started with UVM_REG. -Doug
  9. Thanks for the suggestion. How does one access the Mantis database?
  10. 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
  11. 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_predict. But I'd prefer not do have to use a bunch of callbacks if I can avoid them. I'd rather have the register class contain some event that fired on reads/writes, but it doesn't seem to exist in the BCL. That way my model could just wait on the event and then query the current register value. I realize I can get that behavior with a callback... just want to see if there is some other facility that I'm missing. Thanks, Doug
  12. 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 says this: "Write this register if the DUT register is out-of-date with the desired/mirrored value in the abstraction class, as determined by the uvm_reg::needs_update() method." My question is, is there a way to force the register to be written via the bus (frontdoor) even if the DUT register and the model register are the same value? This is the best that I came up with, but it seems clunky and I'm hoping there is a simpler way. I have to get() the current value of the model and send it to the bus using write(). my_reg.a_field.set(1); my_reg.b_field.set(1); my_reg.write(status, my_reg.get()); Thanks, Doug ps- Is there a way to format code on this forum? Seems bbcodes are turned off.
  13. Is the ralgen register generator tool from Synopsys available to non-VCS users?