Jump to content

Any way to force uvm_reg::update() to do a transaction on the bus

Recommended Posts


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:


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.write(status, my_reg.get());



ps- Is there a way to format code on this forum? Seems bbcodes are turned off.

Link to comment
Share on other sites

I don't know if you can force this behavior outside your patch. Using multiple sets() are fine, usually you do a single update to the hardware -- as if you were loading a packet/ppayload /memory in 0 time.

I think your problem is in the auto_prediction logic (which may be affected by randomiztion). For the most part, most of the DUT type accesses (write, read, update, peek and poke) -- usually calls auto predict internally in the library.

The library also has built-in (for efficiency) that it will not read/write a register on updates, peek, poke -- if it is the same value as the desired value in the model

Check the Mantis database to see if this is "issue" -- it's not a bug, just optimization. I guess the best thing someone could ask for is similar to no_check (which is done automatically and causes prediction errors with volatile registers), this was fixed in 1.1c

I'd look at Mantis an see if they are changing the behavior -- if not bring it up again here.

Or you can continue with your path. The Accellera library (being built by multiple vendors -- where they are free) may not have all the optimizations that you want like older languages like 'c' - where you choice your level of optimization.

All the mark-ups seem to be broken right now.

Edited by lisakb1963
Link to comment
Share on other sites

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.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...