RAL :: What is uvm_reg_fifo?

Hi

While understanding the RAL classes, i came to know the uvm_reg_fifo also there, which is extended from uvm_reg.
I gone through the implementation and I have following queries on the same.

  1. In which application this can be used?
  2. Here, We have only set() (which will push the data into fifo queue) and update() (which will perform write operation if fifo size if not null) methods, so why fifo size is taken care for write operation? Actually, for any FIFO, ideally there should be pointer mechanism, which will decide that fifo is full or emty, and if it is in good shape then only the operation is performed.
  3. Why there is no such mechanism for read the multiple data from same source? as same as write.
  4. Here, pre_read() hook-up of uvm_reg is overrided, and checked that if FIFO size is null then it will covert the status to UVM_NOT_OK. Here, if i want to perform read operation only(with out doing any write/set to fifo) then it will misguide the operation. so is it a limitation of this?

Please provide your inputs.

Thanks and Regards,
Mitesh Patel

In reply to mitesh.patel:

It is broken: uvm_reg_fifo broken? | Verification Academy

And from the UVM bug tracking system:

0006952: uvm_reg_fifo is fully broken…
Description
I am writing to report a fairly large issue with uvm_reg_fifo.svh which makes it unusable.

the use model for the fifo is the following:

  1. create reg_fifo of depth n
  2. do a set() to add values to fifo. A check in set() ensures filling fifo till it is full and discarding after that.
  3. fifo.update() to flush the values to the rest of register model and update the DUT.

Now,
uvm_reg_fifo extends from uvm_reg. The set() in uvm-reg is virtual

so, the set() method in uvm_reg_fifo overrides the implementation in uvm_reg.
when fifo.update() is called, the update() method calls write() which then calls set() which then goes back to uvm_reg_fifo and adds another entry to the fifo queue. (duplicated basically)

This repeats till the fifo fills up, regardless of how deep the fifo is.

The end result is that you see as many transactions on the bus adapter as there are entries. for example if the fifo is 8 deep, and you did 4 set() calls, you will still see 8 transactions on the bus.

The fix is to do a check of m_is_update_pending member from the uvm_reg base class before appending to the fifo (1 line fix) which is set to 1 if an update() is in progress in the set() method in uvm_reg_fifo.

That will prevent the fifo from filling up.

In reply to dave_59:

Oh ok. i got it. Thanks for providing such a good description.
Hoping that next version of uvm will update this. :)

Thanks and Regards,
Mitesh Patel