Can Ral Backdoor Read Only Registers

By Mitesh Patel , Bonny Vora (eInfochips Ltd.)

Abstract

There are two major challenges typically faced in whatsoever system design: shrinking size of the engineering nodes and TTM (Time to Market). To cope with the speed of the competitive market landscape, most of the systems are designed in a generic way - which means the same design can exist used in different ways with different configurations. More the number of configurations, more the number of registers in the blueprint. On height of it, due to the high demand for data storage in the current market, retentiveness size is also getting larger. To access and verify the numerous registers and the huge size of memory, some innovative approach is required. Therefore, UVM provides a base class library for register direction and their access, chosen UVM RAL (Register Abstraction Layer).

UVM RAL as the name suggests, is a high-level object-oriented abstraction layer to admission design registers. RAL model mimics the design registers and this entire model is fully configurable. Due to its abstraction beliefs, RAL model can be easily migrated from block level to organisation level.

From the RAL model overview to register coverage, this paper provides different levels of information on UVM RAL - how aforementioned RAL model can be used with multiple interfaces, retentiveness implementation within the RAL model and their access methods, information on predictor model to predict the register value based on their operation, etc.. Information technology has likewise a listing of prepare-fabricated UVM annals sequences. By merely configuring these sequences users tin admission and verify the functionality of all the pattern registers and memories.

Introduction

The primary step of any design verification is its register verification where register accessibility and its functionality is checked. To perform this register verification information technology is not necessary to use UVM RAL model simply when it is performed without using it, the user has to take care of each registers' attributes and reset value. Also, the user has to make sure that each annals field has been verified using all the possible values. To perform all these checks manually for the entire range of registers is a time-consuming task and therefore using the UVM RAL model is a much efficient approach.

UVM RAL is an object-oriented model for registers inside the pattern. To access these design registers, UVM RAL provides gear up-made base classes and APIs. Some of the RAL model features are:

• Just similar blueprint, it supports different register attributes like R/Westward, RO, WO, W1C, etc.
• Supports two different paths for register access, frontdoor and backdoor.
• The same model tin can be accessed by multiple buses.
• Its abstraction nature allows the same model to be used at the block level equally well as system level.
• Provides a connectedness to sample the user-defined coverage bins.
• Built-in comparing method to compare annals value with its predicted value.

Each RAL model has majorly three levels of hierarchies:

• uvm_reg_block is the topmost hierarchy, normally, uvm_reg_block has an case of all the registers (uvm_reg) or information technology may take an instance of other uvm_reg_block.
• uvm_reg mimics the annals within the pattern. Based on its definition each register may accept one or more uvm_reg_field.
• uvm_reg_field represents the field of the annals.
  

Effigy i. RAL bureaucracy diagram

RAL model mimics the blueprint register, value by which design register is updated, with the same value RAL model register is too updated. And for that, UVM has a common API to update both the design likewise equally the RAL model register. Autonomously from the annals, blueprint memory tin can also exist replicated using RAL model and one of its advantages is burst operation. In the later department of this paper, an example of memory burst operation is shown followed past some information on predictor model, register coverage, and UVM pre-defined register sequences.

RAL register map and adapter

I of the essential steps of RAL model integration is the adapter class implementation. This class has two basic convert functions, bus2reg() and reg2bus(), which are used to convert the bus sequence items into uvm_reg_bus_op (known to RAL model) and vice versa. This user-defined adapter grade should be implemented past extending the uvm_reg_adapter base of operations class. This implies that all frontdoor register read/write functioning happens through this adapter class. Since the implementation of the adapter form is dependent on the jitney and for that, each bus has to take its own adapter class. Below code is for reference on how 2 APIs need to be implemented inside the adapter grade:

Every frontdoor register write/read operation passes through reg2bus and bus2reg API. In the case of multiple buses, for example, APB and AXI, if they are accessing the same RAL model then adapter class needs to be created for each bus. Therefore, for each register maps, RAL model sequencer has to be set equally shown below:

Instance to access the RAL model register using a particular register map:

UVM Memory

UVM supports retentivity implementation inside the RAL model, called uvm_mem. Like uvm_reg, the purpose of this uvm_mem is also to mimic the retentiveness inside the pattern. Below code shows how memory can be implemented inside the RAL model:

One of the advantages of this memory is its burst read/write operation as shown below:

Like register, memory access tin also happen through the frontdoor and backdoor. uvm_mem does not have a space to store the expected data that means one of the drawbacks of this uvm_mem is, unlike registers, information technology does not support in-built information comparison.

UVM Predictor

As mentioned before, the register model has a built-in self-checking mechanism. Whenever a annals is accessed, uvm_reg is updated with the same value and that becomes its predicted value. This prediction tin can happen in iii different ways:

• Implicit Prediction
• Explicit Prediction
• Passive Prediction

Implicit Prediction

This is the simplest and the nearly common approach. Whenever annals write/read performance happens, UVM RAL model base class calls predict() method of that particular uvm_reg class. And to enable this, user has to telephone call set_auto_predict(one) method of uvm_reg_map as shown beneath. By default, it is disabled.

Figure 2. Implicit prediction menses

As shown in the in a higher place diagram, when auto prediction is on, the register model predicts the value with every write/read performance. Here, the expectation is that the user has to initiate register operation either by calling write() or read() method of uvm_reg.

Explicit Prediction

In this approach, the user has to create the handle of uvm_reg_predictor class, which is a RAL model base form. This predictor class needs to be continued with the sampler/monitor course. Hither, the monitor samples the register write/read operation happening on the interface and from the monitor it reaches to the predictor component. Predictor class converts charabanc transaction into the annals transaction with the help of the adapter and so calls the predict() method of that register. Below diagram explains the explicit prediction flow:

Figure 3. Explicit prediction menstruation

In terms of coding efforts, at that place are three basic steps to do explicit prediction: creation, configuration, and connection.

ane- Creation

two- Configuration

three- Connection

Advantage of this arroyo is, here register model is e'er upwardly to date with the bodily data because prediction happens based on the data driven on interface. Therefore, in the case of erroneous transaction monitor needs to have a logic to filter out the information.

Passive Prediction

This arroyo is useful when register read/write operation is non happening via the register model. Hither, annals value is predicted based on the operation observed on the bus interface. This approach is very similar to the explicit prediction arroyo.

Register Coverage

UVM RAL provides an API to sample the user-defined covergroup and to sample this covergroup, user has to override the sample() method of uvm_reg/uvm_reg_block class. For RAL model coverage, user has to enable register prediction as explained above.

Below code shows the covergroup implementation inside the extended uvm_reg_block where registers and their operations are covered.

Below instance of covergroup implementation inside uvm_reg class is shown where the intention is to embrace different values by which register is beingness accessed.

Selective covergroup sampling is also possible, for that, user has to provide the suitable functional coverage type identifier.

UVM RAL pre-defined sequences

UVM parcel provides a readymade set of sequences to exam the functionality of registers such as their access or their reset value. All these sequences are unique in terms of their functioning and out of them, description of a few annals sequences are shown in the following tabular array:

Sequence name	Functionality
uvm_reg_hw_reset_seq	Checks the reset value of each register is matching with the specified reset value.
uvm_reg_bit_bash_seq	Sequentially writes ane's and 0'southward in each fleck of the register and based on its read-write access, expects the value to exist set up.
uvm_reg_access_seq	Writes each register with frontdoor access and checks the value of the register is been set correctly via backdoor. Then do the reverse functioning where write happens via backdoor and checking happens through frontdoor.
uvm_mem_walk_seq	Writes walking design into each of the memory location and compares it with the read value.
uvm_mem_access_seq	For each location of the retentiveness, writes via frontdoor and checks the if the value is gear up correctly via backdoor. Then, do the contrary performance where write happens via backdoor and verification occurs through frontdoor.
uvm_reg_shared_access_seq	Writes all the register via each address map and confirms its written value by reading from all the accost maps.
uvm_mem_shared_access_seq	Writes all the retentiveness locations via each address map and confirms its written value by reading from all the address maps.
uvm_reg_mem_shared_access_seq	Executes uvm_reg_shared_access_seq followed by uvm_mem_shared_access_seq.
uvm_reg_mem_built_in_seq	Executes selected/all of the above pre-defined sequences.
uvm_reg_mem_hdl_paths_seq	Checks the specified HDL path is accessible or not.

There is a disable aspect for each of the in a higher place test, by which the user tin skip particular testing of whatever register/retention. By setting the aspect, "NO_REG_TEST" or "NO_MEM_TEST" user tin can exclude particular register/memory from all the above tests.

Summary

UVM RAL is a simpler approach to admission and for the verification of design registers and memories. Like the real design, uvm_mem supports burst write and read operation. On elevation of accessing the registers, UVM also has ready-fabricated APIs, which can be used to sample the annals coverage. Also, due to multiple scenarios in different UVM register pre-defined sequences, the task of register verification has go like shooting fish in a barrel. Because of its hierarchical structure and a large number of bachelor APIs, it provides an ample amount of flexibility. Apart from accessing APIs in the standard way, the user can do a listing of other things using these APIs; such as, accessing register by their address or updating any item register field. Overall, UVM RAL is a powerful abstraction layer, which supports all the features required for register verification and due to its organized construction, information technology is a highly recommended approach for annals verification in the UVM based testbench.

If yous wish to download a re-create of this white paper, click here

Can Ral Backdoor Read Only Registers,

Source: https://www.design-reuse.com/articles/46675/uvm-ral-model-usage-and-application.html

Posted by: staceysenter.blogspot.com

Share this post