In my previous post, we learned about “What is UVM RAL?“. If you’ve not already gone through that post, I will encourage you to go through that post first. As a quick recap, in that post – we discussed about what are different types of registers inside the design, what makes up a design register, its different fields, and different properties of the those fields. We also discussed about different types of register accesses. Apart from all that, most important we learned that UVM RAL is a layer which is DUT abstraction level independent & not effected by the type of interface which is being used in the UVM environment. For more, please visit the post and read it.

Let’s first understand the core purpose of UVM methodology – re-usability and configurability are two main aspects of UVM supporting both dynamic and static components. If you want to know more about what are dynamic and static components in UVM, you may refer my another post i.e. “UVM Environment Components“. RAL (Register Abstraction Layer) is another effort in the same direction.

As per the topic of this post – lets understand Why UVM RAL is needed and how it helps to support the core purpose of UVM?

To understand this, lets first see what it take to write a UVM register testcase? As we know, a UVM test starts a UVM sequence as part of it and this UVM sequence have to contains information about the register address which we wanted to access (WRITE or READ) and the corresponding data (in case of WRITE).

In the above snippet of a UVM sequence, its defining the type of command, address and data to be driven by the UVM sequence using the tx sequence item. As we’re aware that DUT (design containing registers to verify) could be at block level, sub-system level or at SoC level so if the major motivation of UVM is to be applied, we should be able to re-use the stimulus at different abstraction levels. But as we know, address is going to be different at block level, sub-system level and SoC level. So the main question is –  How to re-use the stimulus (means testcases or UVM sequences) at different abstraction level because different addresses needs to be supplied at different abstraction levels?

To solve this situation, Address map that is called “Register map” is an important element in this puzzle which helps to map a particular registers name i.e. R0 to the correct intended address required for a particular abstraction level and UVM sequence just uses the name of the register and desired operation i.e. WRITE or READ (as shown in the image below) with it.

Figure below, shows the high level picture of the RAL implementation where Testcase/sequence just use the register name e.g. R0 to drive WRITE and/or READ transaction. Register name is mapped to the appropriate address in the register map and the register block containing the corresponding register map is connected to the UVM Agent which in turn is connected to a specific interface to access the desired register inside the DUT.

                           (Figure: Simplified UVM RAL environment)

So why do we need UVM RAL??

Here are some key and important benefits –

1. Testcase/Sequences re-usability.
2. Register coverage
3. Pre-built Register sequences availability as part of UVM base classes
4. Back-door access of the DUT registers (Difficult in case of SystemVerilog package usage)
5. Provides a standardized approach for register verification

We’re approaching towards now end of my this post on WHY do need UVM RAL? Hope you got fair idea about the benefits of using UVM RAL. In summary, though it appears that we may achieve the intended goals of our design registers verification without UVM RAL and UVM RAL is extra bit of work but for what?

But the fact is if you see the above listed benefits and review in terms of register stimulus re-usability, register coverage, many powerful pre-built-in sequences, many additional functions like for backdoor access, quirky registers support etc. you will find its a big advantage to use UVM RAL. It is really helpful to move from block level to SoC level register verification in a systematic way and quicker than in non-UVM RAL approach.

With that, I would like to conclude here this post, hope you like it and find it useful. If yes, please share me your comments below. Next, in my plan is to write posts on RAL implementation where showing what to do to create UVM RAL environment. Wish you to see again soon! 

Take care and stay safe! Till next time, Bye! Keep Smiling 🙂