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

[dwikle]

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.

[lisakb1963]

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 November 29, 2012 by lisakb1963

[dwikle]

Thanks for the suggestion. How does one access the Mantis database?

[dave_59]

http://tinyurl.com/uvm-list-of-bugs

[dwikle]

Thanks Dave.

Can anyone file a bug or enhancement request there?

-Doug