Deep Dive into the UVM Register Layer

Q&A Log - Session 2 – January 2018

Resources:
You can try out the examples shown in this webinar yourself on EDA Playground using the
following links:

https://www.edaplayground.com/x/55Wh
UVM non-linear register addressing

https://www.edaplayground.com/x/58jv
UVM register - extension argument to read/write

https://www.edaplayground.com/x/6DJg
UVM register user-defined memory backdoor

https://www.edaplayground.com/x/4apk
UVM register with side-effects

https://www.edaplayground.com/x/3FUt
UVM register aliasing

Audience Question:
Q: Regular read and write sequences don't seem to allow reordering, for example writing to the upper address of a
register first to write the upper part, and then the lower addr, apologies if the question is not well elaborated.
A: Good point. User-defined front doors provide a possible solution to this, as we will see.

Audience Question:
Q: Is it a good practice to use the UVM reg model as a reference model, for example use the mirrored value (which
is 'predicted' based on different inputs) to determine if the DUT is on a particular state or for scoreboarding of
activity on different interfaces? Sometimes is hard to keep in sync or to predict the values of several fields or
registers like status registers, performance counters.
A: That is debatable. One of the purposes of the mirror values is to act as a cache of register values so you don't
need to access the registers in the DUT so frequently. Hence it may be possible to use the mirrored values as part
of the reference model, but doing so assumes that the mirrored values are actually up-to-date. So the answer is
"yes, maybe" but you have to be very careful.

Audience Question:
Q: Is it correct to assume that the update of the entire reg model is in random order? Let's say I have 4 regs to be
updated what would it be the order… I think the update will traverse using get_all_regs but not sure about the
ordering?
A: You're right. The update will traverse the register model in some specific order but you probably should not rely
on what that order is. If you need the registers traversed in a particular order it would be best to write the code
explicitly.

Audience Question:
Q: Do the callbacks apply only to frontdoor access (read/write)? What about backdoor access (peek/poke)?
A: The pre/post read/write callbacks are called for both front door and back door access. (I had to look that one up
;-) Further, post_predict() is only called after predict(), for example when a transaction is sent through the
predictor, so the front door / back door distinction is not relevant for post_predict().

Page 1 of 2
Deep Dive into the UVM Register Layer

Q&A Log - Session 2 – January 2018

Audience Question:
Q: What is the recommended way to model DUT status registers which are updated by some DUT behaviour (such
as FIFO fill status register)
A: If you wanted to represent such registers in the UVM register model, you would probably use explicit prediction
to keep the values in the register model up-to-date.

Audience Question:
Q: I have used post_predict extensively for projects without the mentioned pitfalls. With the post_read/post_write
callbacks, they will not work in the passive case.
A: Yes, I agree. The post_predict pitfall refers to calling predict() from post_predict(). As long as you don't do that,
you're okay. Thanks for the feedback.

Page 2 of 2