What does volatility do in UVM_REG_FIELD

[mszabo]

Alternately is there a way to perform a uvm_read via the front door that does not update the prediction value? I would have thought that setting volatility would disable the mirroring so I would be free to manually set prediction values, but this doesn't seem to be the case. I'm not actually sure that volatile does anything.

I have several volatile status registers in my design and I am capable of accurately predicting these at certain points in the simulation, however the design calls for reading of the register via the model and this read will set the prediction value to the current state of the register.

It just works out best for my design if I read the register and then manually check to see if matches a prediction value. I suppose I could derive from uvm_reg and add a separate prediction value for my purpose but this seems like overkill.

[janick]

Volatility is simply an indicator/introspection bit/documentation. It does not change the behavior of the mirror or comparison function.

Use uvm_reg_field::set_compare() if you want to disable the comparison of fields in pre-defined test sequences.

If you are able to predict the value you are about to read back, set it via the predict() method, then read the field using the mirror(CHECK) method.

[mszabo]

I actually tried just setting predict first and that works most of the time, except my bus is a pipelined bus with multiple masters attempting to access. In this environment the predict() method doesn't work all that well. So I can have the register modeled perfectly, but we can't predict when the read happens and what it will compare against. There is a legitimate race condition if predict() is called while a read()/mirror() is simultaneously being accessed. Unfortunately for me UVM handles this completely in the predict() method with generating a warning and worse not taking the new predicted value. Perhaps my design is bad, but I didn't want to have to setup a queue mechanism setup to repeatedly check registers for whether they are being accessed and only updating predict() when they aren't. Even then this wouldn't solve the issue as delaying an update on the prediction value would still result in miscompares. As a hack, you can call predict() with UVM_PREDICT_READ and bypass the error checking within predict().

To solve the actual race condition around the register checking I had hoped to check the predict value both before and after a call to read the register. If the 2 predict values didn't match I could skip this particular compare. i.e:

exp1 = reg.get()

reg.read(..., rcv);

exp2 = reg.get()

if(exp1==exp2) && (exp1 != rcv) //Legitimate miscompare found since my registers are all "W1C"

So this had potential, except the call to read() updates the prediction value so exp2 always equals what was read out of the RTL masking any legitimate errors.

[janick]

The mirror is a best-attempt at keeping track of the register values in the DUT. In the presence of a pipeline bus and/or volatile fields, that best effort is probably not sufficient. It would be difficult to come up with a solution that fits all possible designs and busses out there. Probably the best is for you to keep your predicted value(s) in an associative array indexed by the field handle and do an explicit comparison instead of using the mirror() method and the mirrored value.

[mszabo]

Thanks, I ended up just instantiating a second copy of the register model strictly for compare purposes unattached to the bus through a predictor, but monitoring the bus for compare purposes. This was probably the correct idea from the start. There are no race conditions down at the bus level in my system so everything just works there, and the predict function is still useful to update data after the compare in the case of some write 1 to clear status registers.

[vishal.jain]

Hi,

The main issue here is that there is no clear separation between driving and shadow. If predictor strictly works on 'mirrored' values then this problem will go away. This whole issue pops up because predictor uses 'desired' value for predicting which is dangerous. This has been raised to the Accelera committee. Lets see how it goes.

Otherwise, your solution of keeping a separate copy is good. Only thing is it should not hurt performance. If there are large number of registers, you would begin to feel it.

-Vishal

[kiranbhaskar]

I am using a pipelined bus as shown below

1 -- 2 -- 3 -- 4

addr1--data1,addr2--data2,addr3--data3,addr4

I am using explicit monitoring for my prediction

But when i am using the mirror function to check for readback value i am getting an error as the mirrror value first does a check on the readback value and then does the updation.

ie when i use a mirror for addr2 register, the error is thrown up in cycle 2 when the actual update happens in cycle 3.

How do i go around this problem.I am also not able to use all the uvm_reg predefined sequences as all the predefined sequences use the mirror method for the comparision

Regards,

Kiran Bhaskar

Edited January 20, 2012 by kiranbhaskar