Does Backdoor Write To Read Only Registers Succeed

When I began using UVM RAL, I could not sympathize what the UVM base class library had to say about updating the values of desired value and mirror value registers. I besides felt that the terms used do non reflect the intent precisely. Subsequently spending some time, I came up with a table which helped me to empathize the behavior of register model APIs, and how best they can be called.

Here'due south where you lot tin can detect more information on our Verification IP.

Before I innovate the tabular array, let the states take a wait at the process of creating the annals model:

Creating the register format specification
Converting the specification into UVM register model
Using the register model

Creating the register format specification: There are many register formats available to depict the designer'south register specification. You are perhaps familiar with the widely used Synopsys RALF format. The figure beneath illustrates the menstruation to convert the RALF format into the register model using Synopsys Ralgen tool. The dotted lines betoken that you tin can generate register models for different methodologies:

Using the register model: The register model has a set of variables for desired and mirror annals values. The document uses the termsdesired and mirror, but I phone call them as Master and Mirror beneath to avoid confusion. The intent of the mirror variable is to concur or represent the RTL'due south value all the time so that it can be used as Scoreboard. In that location are a bunch of API's available to operate on these variables. The intent here is to clarify what happens to the master and mirror variables when any of these API'south are called during simulation.

Permit u.s. have a look at the available API's. I classify them into three groups: active, passive and indirect.

Active: Physical transactions go out on the bus to do the read and write performance. Read(), write(), update()and mirror() are active API's which operate on the DUT using the physical interface. You tin optionally use backdoor mechanism in which case it will non consume simulation cycles. You can expect the same RTL register behavior which would accept happened using the front end door admission.

Passive: Simply operates with the register model. prepare(), get() and predict() are passive API's which directly operate on the model. I also call peek() passive as this will not alter the annals value during the read process. For instance, read to articulate register – volition not be cleared when peek() is executed.

Indirect: At that place are a set up of API's which indirectly operate on the DUT and they are peek() and poke(). Please note that peek() and poke() API's are backdoor access simply. Though poke can update the RTL register, it can't mimic the actual register behavior which might happen during the physical read. For case, write one to clear.

Allow u.s.a. accept a cursory look at the widely used API definitions. You tin can discover more details in the UVM Class Reference Guide.

Read(): Read the value form the DUT annals using front end-door or backdoor access.

Write(): Update the DUT annals using front end-door or backdoor access.

Update(): If you have changed any values in the main register variables using set(), y'all can write all those registers in the DUT using employ this 1 method (batch update). Y'all can call individual write() method to achieve the aforementioned results.

Mirror(): Mirror maintains a copy of the DUT register value. Mirror() method reads the register and optionally compares the read back value with the current mirrored value if check is enabled.The mirroring can be performed using the physical interfaces (front end door) or peek() (backstairs) machinery.

Peek(): Read the value form the DUT register using the backdoor access machinery.

Poke(): Write the DUT annals with the specified value using the backdoor access machinery.

Predict(): You lot can employ this method to change the mirror variable value with the expected values.

I ran a few experiments and the following tabular array shows what happens in the register model and the DUT when any of these API's are executed from the examination bench.

Abbreviation
UMV – Update Main Variable, UMrV – Update Mirror Variable,  AP – Auto predict
RDR – Read DUT Register,  UDR – Update DUT Register, RMV – Read Principal Variable
FD – frontdoor,   BD – Backdoor,   *  – bank check if UVM_CHEK is used,   NA – Not Applicable

A few points to go on in mind

I didn't expect peek() and poke() methods to update the mirror value unconditionally. After looking into the UVM source code, I found that the do_predit() method is chosen unconditionally inside peek() and poke() methods. I also noticed that the write() and read() methods using backdoor mechanism would update the mirror register every bit the do_predict() is called without checking the output of this get_auto_predict() method. The but identify where I see this conditionally called is the write () and read() method with frontdoor access.

Later on discussing with experts, I sympathise that the intended functionality is to make sure the mirror variable has the most up-to-date register value in it. Similarly read()/write() using backdoor access update the mirror register — this besides is intentional. Because the backdoor is used, there won't be a transaction on the physical interface that will be observed (when auto-predict is turned OFF) to update the register model. It must thus be updated in all cases.

Authored by: Vidyashankar Ramaswamy

Here's where yous can find more information on our Verification IP.