UVM RAL

- Samiyan
Content,.
• Introduction
• Advantages of UVM RAL
• UVM Register Model Overview
• Register model generator
• RAL Building blocks
• Register block
• Register File
• Register
• Register fileds
• UVM Register layer
• Pre-defined Field Access Policies
• UVM Predictor
• Implicit Prediction
• Explicit Prediction
• Steps involved in Explicit Prediction
• Passive Prediction
• Register and register fields
• Syntax’s along with an example
• Adapter
• Register defines
• UVM RAL Base Classes
• references
Introduction
• The UVM Register Layer provides a standard base class
libraries that enable users to implement the object-oriented
model to access the DUT registers and memories.
• RAL model mimics the design registers and this entire model
is fully configurable.
 Advantages of UVM RAL
• Provides high-level abstraction for reading and writing DUT
registers. i.e, registers can be accessed with its names
• UVM provides a register test sequence library containing predefined
test cases these can be used to verify the registers and memories
• register layer classes support front-door and back-door access
• Design registers can be accessed independently of the physical bus
interface. i.e by calling read/write methods
• The register model can be accessed from multiple concurrent
threads. it internally serializes the access to the register.
• Reusability, RAL packages can be directly reused in other
environments
• Uniformity, Defines the set of rules or methodology on register
access, which can be followed across the industry
• Automated RAL model generations, Tools or open-source scripts are
available for RAL Model generation
UVM Register Model Overview
• The register model is composed of a hierarchy of blocks that
map to the design hierarchy, which means the RAL model
consists of equivalent which will refer to the design register
fields, registers, and memory.Blocks can contain,
registers
register files
memories
other blocks
• UVM RAL library provides the base class of each and each class
has the default builtin methods in it.
Cont,.
• uvm_reg shall consist of one or more uvm_reg_field
• uvm_reg_file shall consist of one or more uvm_reg
• uvm_reg_block shall consist of one or more uvm_reg_file or
uvm_mem
 Register model generator
• Register model generators are outside the scope of the UVM library.
• A register model can be written or it can be created using
a register generator application. Writing or Generating the
register model is based on a design register specification.
• Writing a register model is easy, but complex designs will be having
hundreds or thousands of registers. in that case, writing the register
model is bit tougher. The easiest way to construct a register model is
by using a register generation application or automation tool.
• Automation tools will generate the register model by taking register
specification as input, this includes reg name, width, register fields,
access permissions, etc.
• There are paid and free register generators available. some of them
are RGM – Register and Memory Package by Cadence, ralgen by
Synopsys, Semifore’s RDL, Duolog’s graphical Bitwise, Agnisys’
IDesignSpec, Mentor Graphics’ Certes Testbench Studio, and 
Magillem MRV (Magillem Register View).
RAL Building blocks
The major building blocks of RAL are

• Register block
• Register file
• Register
◦ Register Filed
Register block
• The reg block is written by extending the uvm_reg_block.
• A block corresponds to a design component/hierarchy with its own
interface(s), registers, register files, memories, and sub-blocks.
Register File
• The reg file is written by extending the uvm_reg_file.
• The reg file shall be used to group the number of registers or register files.
below block diagram shows the register file consists of reg_file_0,
reg_file_1 and reg_file_2. and each register file consists of a set of registers.
( registers are shown only in reg_file_2, Assume that there are registers in
reg_file_0 and reg_file_1 )
Register
• The uvm register class is written by extending the uvm_reg.
• A register represents a set of fields that are accessible as a single entity.
• Each register contains any number of fields, which mirror the values of the
corresponding elements in hardware.
Register fileds
• The register field is declared with the type uvm_reg_filed.
• Fields represent a contiguous set of bits. All data values are modeled
as fields.  A field is contained within a single register but may have
different access policies. access policies are explained in the
upcomming slides.
UVM Register layer
Pre-defined Field Access Policies
UVM Predictor
the register model has a built-in self-checking mechanism. Whenever a register
is accessed, uvm_reg is updated with the same value and that becomes its
predicted value. This prediction can happen in three different ways:
• Implicit Prediction
• Explicit Prediction
• Passive Prediction
 Implicit Prediction
• This is the simplest and the most common approach. Whenever register
write/read operation happens, UVM RAL model base class calls predict()
method of that particular uvm_reg class. And to enable this, user has to call
set_auto_predict(1) method of uvm_reg_map as shown below. By default, it
is disabled.

• As shown in the above diagram, when auto prediction is on, the register
model predicts the value with every write/read operation. 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 class. This predictor class needs to be connected
with the sampler/monitor class. Here, 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 bus transaction
into the register transaction with the help of the adapter and then calls the
predict() method of that register. The user has to call set_auto_predict(0)
method of uvm_reg_map to disable the implicit prediction
 Steps involved in Explicit Prediction
• In terms of coding efforts, there are three basic steps to do explicit prediction:
creation, configuration, and connection.

• Advantage of this approach is, here register model is always up to date with the actual
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 data.
Passive Prediction
• This approach is useful when register read/write operation is not happening
via the register model. Here, register value is predicted based on the
operation observed on the bus interface. This approach is very similar to the
explicit prediction approach.
Register and register fields
Register field configure method
 Register File
• A register file type is constructed by writing a class extended from
the uvm_reg_file class
• The name of the register file type class must be unique within the scope of
its declaration
• Register files can contain other register files.
• The build() method shall call the configure() method for all register and
register file class properties
• specifying get_block() for the parent block and this for the parent register
file
Register block
Instantiation of register block in env
Adapter
 Register defines
• UVM register library has the defines declared in it. these are being used in
the RAL model base classes, user can override these defines.
UVM RAL Base Classes
• UVM RAL types
uvm_reg_data_t: 2-state data value with
`UVM_REG_DATA_WIDTH bits
uvm_reg_data_logic_t: 4-state data value with
`UVM_REG_DATA_WIDTH bits
uvm_reg_addr_t :2-state address value with
`UVM_REG_ADDR_WIDTH bits
uvm_reg_addr_logic_t:4-state address value with
`UVM_REG_ADDR_WIDTH bits
uvm_reg_byte_en_t: 2-state byte_enable value with
`UVM_REG_BYTENABLE_WIDTH bits
uvm_reg_cvr_t : Coverage model value set with
`UVM_REG_CVR_WIDTH bits
 Cont,.
• UVM RAL Enums
uvm_status_e
Return status for register operations
UVM_IS_OK
Operation completed successfully
UVM_NOT_OK
Operation completed with error
UVM_HAS_X
Operation completed successfully bit had unknown bits.
uvm_path_e
Path used for register operation
UVM_FRONTDOOR
Use the front door
UVM_BACKDOOR
Use the back door
UVM_PREDICT
Operation derived from observations by a bus monitor via the uvm_reg_predictor class
UVM_DEFAULT_PATH
Operation specified by the context
 Cont,.
uvm_endianness_e
Specifies byte ordering
UVM_NO_ENDIAN
Byte ordering not applicable
UVM_LITTLE_ENDIAN
Least-significant bytes first in consecutive addresses
UVM_BIG_ENDIAN
Most-significant bytes first in consecutive addresses
UVM_LITTLE_FIFO
Least-significant bytes first at the same address
UVM_BIG_FIFO
Most-significant bytes first at the same address
uvm_elem_kind_e
Type of element being read or written
UVM_REG
Register
UVM_FIELD
Field
UVM_MEM
Memory location
 Cont,.
uvm_predict_e
How the mirror is to be updated
UVM_PREDICT_DIRECT
Predicted value is as-is
UVM_PREDICT_READ
Predict based on the specified value having been read
UVM_PREDICT_WRITE
Predict based on the specified value having been written
uvm_coverage_model_e
Coverage models available or desired.  Multiple models may be specified by bitwise
OR’ing individual model identifiers.
UVM_NO_COVERAGE
None
UVM_CVR_REG_BITS
Individual register bits
UVM_CVR_ADDR_MAP
Individual register and memory addresses
UVM_CVR_FIELD_VALS
Field values
UVM_CVR_ALL
All coverage models
UVM RAL pre-defined sequences
UVM package provides a readymade set of sequences to test the
functionality of registers such as their access or their reset value. All
these sequences are unique in terms of their operation and out of them,
description of a few register sequences are shown in the following table:
• 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 1’s and 0’s in each bit of
the register and based on its read-write access, expects the value to be
set.
• 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 operation where write happens via backdoor and checking
happens through frontdoor.
• uvm_mem_walk_seq: Writes walking pattern into each of the memory
location and compares it with the read value.
 Cont,.
• uvm_mem_access_seq: For each location of the memory, writes via frontdoor
and checks the if the value is set correctly via backdoor. Then, do the reverse
operation 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 address maps.
• uvm_mem_shared_access_seq: Writes all the memory 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 attribute for each of the above test, by which the user can skip
particular testing of any register/memory. By setting the attribute,
“NO_REG_TEST” or “NO_MEM_TEST” user can exclude particular
register/memory from all the above tests.
 References
• cluelogic.com/2012/10/uvm-tutorial-for-candy-
lovers-register-abstraction/
• https
://verificationguide.com/uvm-ral/uvm-ral-tutoria
l
/
• https://
www.design-reuse.com/articles/46675/uvm-ral-
model-usage-and-application.html
• https://www.edaplayground.com/x/3zes