UVM Read Problems

[kiranbhaskar]

I do the following in my register sequence

write_reg(regmodel.reg_file.Reg_A,status,data1)

i see the data written to the DUT

Then i check the desired value using

desired_value = regmodel.reg_file.Reg_A.get();

I see the desired value is same as the data1

But when i do a

Read_reg(regmodel.reg_file.Reg_A,status,expected_value)

The expected value is always zero.

I have tried everything and not able to figure out why this is happening.

Regards,

Kiran Bhaskar

[Roman]

Hi There,

I think you need double check if the write data is really written to the Register model via Module UVC.

I guess this reg's reset value is zero in your design, you didn't update the register model when writing data to the DUT.

Then this is why you read the zero at the second time.

[kiranbhaskar]

Hi ,

I have a small question regarding the register model updation,

when i am using the explicit monitoring

does the predictor update the register model or the driver ?

i see these two messages what is the difference b/w the two and which is doing the update on the model.

[Regmodel] wrote register via map regmodel.spi_rf.register = `h42 ( i see that this is controlled by the driver)

[Reg_predict] observed UVM_WRITE transaction to the regmodel.spi_rf.register: value = `h42 (This is controlled by the monitor)

Regards,

Kiran Bhaskar

[janick]

I think you need double check if the write data is really written to the Register model via Module UVC.

Roman, you are confusing the Cadence uvm_rgm package (which is *NOT* part of the UVM standard) with the UVM register library. There is no such thing as a "Module UVC" in the UVm register library, but instead a register predictor.

does the predictor update the register model or the driver ?

In explicit mode, the predictor updates the mirror based on observed READ and WRITE transactions on the bus agent. If you do a get() after the read(), I bet a 0 is returned.

You do not provide enough information to identify the cause of your problem. For example, if Reg_A is a WO-register, the desired value will be updated to the written value but a physical read will always return 0's (or the value of whatever RO register is mapped at the same address).

[Roman]

Hi,

Your driver will drive the bus .

Your monitor will collect the bus , then send data to the predictor via analysis port, it could update the register model using "reg.predict()".

I am using the Cadence RGM now, and the Module UVC with monitor could update the RDB as the same requirement.

[kiranbhaskar]

Hi Janick,

If the predictor is doing the update on the register model ,why does the write and read to the register model happen twice.

as shown in the messages below.

[Reg_predict] observed UVM_WRITE transaction to the regmodel.spi_rf.register: value = `h42 (message is printed from uvm_reg_sequence.svh -- line no 710 )

[Regmodel] wrote register via map regmodel.spi_rf.register = `h42

(message is printed from uvm_reg.svh -- line no 2299)

[Reg_predict] observed UVM_READ transaction to the regmodel.spi_rf.register: value = `h42

(message is printed from uvm_reg_sequence.svh -- line no 710 )

[Regmodel] read register via map regmodel.spi_rf.register = `h0

(message is printed from uvm_reg.svh -- line no 2299)

can you please clarify what is the difference in the two messages and when is the actual update happening .(FYI -- the two updates are not in sync ie [Reg_predict] happens first and then [regmodel])

Regards,

Kiran Bhaskar

[janick]

Each are happening only once. The fact that there are two messages produced does not imply that there are two transactions. One is produced by the explicit prediction path and the other is produced by the stimulus path.

Now, looking at the last two messages, it seems that the read back value is correctly observed, but is not properly sent back to the register model to be returned via the read() method.

Make sure your bus2reg() conversion function returns the data value back to the register model.

Edited February 7, 2012 by janick

[kiranbhaskar]

Hi Janick,

I was able to solve this problem ..By doing the following things

in the stimulus path (driver),

I wrote the read back value from the VIF to the transaction that i was driving ..

ie

trans.data = vif.data;

And the now the messages look like this

[Reg_predict] observed UVM_WRITE transaction to the regmodel.spi_rf.register: value = `h42 (message is printed from uvm_reg_sequence.svh -- line no 710 )

[Regmodel] wrote register via map regmodel.spi_rf.register = `h42

(message is printed from uvm_reg.svh -- line no 2299)

[Reg_predict] observed UVM_READ transaction to the regmodel.spi_rf.register: value = `h42

(message is printed from uvm_reg_sequence.svh -- line no 710 )

[Regmodel] read register via map regmodel.spi_rf.register = `h42

(message is printed from uvm_reg.svh -- line no 2299)

From what i understand [Regmodel] message is controlled from the stimulus side and [Regpredict] message is controlled from the monitor side.

The model is only updated when the [Regpredict] happens.

Is my understanding correct?

And when i use a mirror method the value in the [regmodel] message (ie stimulus) is checked against the mirrored value in the register model and not the value in the [Regpredict] message.Any particular reason?

Regards,

Kiran Bhaskar

[janick]

Yes, your understanding is correct.

And when i use a mirror method the value in the [regmodel] message (ie stimulus) is checked against the mirrored value in the register model and not the value in the [Regpredict] message.Any particular reason?

The value in the RegPredict predict message ends up in the register model. But the mirror(CHECK) function has to check the value read back against the value that was mirrored in the register model BEFORE it gets updated by the new readback value (which in your case comes via the monitoring path).

[rajivhasija]

Hi Kiran/Janick

i am facing the same problem as you and I see the same messages as you were getting . I dont see the read data going back to register model. I didnt exactly get what your solution is .

I connected the predictor with bus monitor through the analysis port and bus2reg is also fine.

I see one strange behaviour .. bus2reg is called even in the case of writing the register through regmodel and reg2bus is also called as expected. Could you please elaborate what exactly was your solution to fix the problem?

Thanks

Rajiv

[hvgbl]

Hello Hi.
I am facing the same problem rite now.
When Monitor sees a particular transaction, it calls the BUS2REG function, which gives correct data/value, But again when it (bus2reg) is called (using READ Method) the data is lost.

My Issues is:
When i do simple write-read transaction, 
Using WRITE METHOD the value of a register is written successfully, (I checked using GET() Method).
But when i use READ, the monitor receives the DUT output, write it to Analysis Port, and on same time, the BUS2REG is called, which shows correct data value.
But that BUS2REG is not called by my READ METHOD, that is called coz of monitor.
So when my read sequence starts, the next bus2reg overwrite the previous data value by ZERO.

Do you have any solution for the above problem ??

Thank you.

[Reuben Mijares]

I'm having the same issue too. Has there been any solution for this?

[valuedCustomer]

I had a problem w/the same symptoms (bus2reg being called twice) and the read data not being set. After removing the predictor all together, I still wasn't getting the read data. I actually thought you needed the predictor, but you don't.

Then I tracked it down to the fact that with RAL your DRIVER needs to latch the return read data, whereas a monitor was doing that for me before. I was learning how to use UVM, so I started w/a monitor first, then moved to try RAL. So instead of checking via the monitor, I'd be checking via the RAL. BUT I didn't update my driver to return the read value. Even though I had the predictor connected to the monitor analysis port, and the monitor was recording the read value, this didn't propagate to the driver/reg read.

For my case, I had a driver that requested that the DUT return the read data on the bus but not care about the read data as I had the monitor doing that comparison. W/O the monitor, and using RAL, the driver now has the responsibility to latch the data on a read and return it to the sequencer.

xx.get_next_item(myseq);
...
// before I didn't care to latch the return since the monitor was doing it
if (myseq.rw == READ) myseq.data = busif.data); // new code
xx.item_done();

Now the two bus2reg calls return the correct read data to the reg_read side of the RAL.