RAL (Register Abstraction Layer)

NOTES

An Introduction to the VMM Register Abstraction Layer

Contributor: Synopsys, Inc. July 30, 2007 -- Modern SOC, ASIC and FPGA designs often have hundreds or even thousands of on-chip registers that are used to configure the device for different modes of operation. These memory elements play a critical role in the proper functioning of the device and must be thoroughly verified prior to tape-out. Use of the VMM Registr Abstraction Layer greatly simplifies the process. Register verification is a growing challenge. Register specifications address ranges, reset values, access modes, etc. change constantly during the design process. These changes must be propagated throughout the verification environment and the various testbench components. Updating the testbench every time a single register is added, a field is changed or a memory is modified becomes a very time-consuming task. In addition, manual approaches to register verification can easily miss errors or bugs, especially as the number of registers to be verified exceeds two hundred or so. Each test for a register is unique and incorporates a variety of information, resulting in a huge amount of data required to verify all registers. A register test specifies the addresses to the registers and memories to be accessed, the access size, the data to be written, the reset values, etc. The test should also incorporate the access mode for each bit of the registers r/w, r/o, etc. With hundreds or thousands of registers, the effort involved in updating the tests to reflect a new register specification can be enormous. This effort is compounded if the environment gathers coverage on the registers or if assertions are used to check for correct access procedures. Every time the design changes, the functional coverage groups and assertions must be changed accordingly. Figure 1 shows a common topology of a test environment which is used to verify a device under test (DUT).

Figure 1. Generic testbench with directed tests.

VMM Register Abstraction Layer

The VMM Register Abstraction Layer (RAL) automates the verification of large register sets in complex designs. It improves verification productivity by automatically generating verification components for registers including tests, functional coverage, assertions, backdoor access, and mirroring from a high-level register specification. Once generated, these components are compiled with the rest of the user environment to help verify proper connectivity and functionality of registers, and to provide a fast backdoor register access mechanism that can be used after basic tests have passed. RAL components will gather functional coverage and ensure correct accesses to the registers and memories via the built-in functional coverage groups and optional user-defined assertions. As a VMM application, RAL integrates seamlessly in verification environments using the VMM methodology, defined in the book "Verification Methodology Manual for SystemVerilog." Figure 2 shows the basic RAL architecture. The RAL model will send R/W transactions to a user-written bus functional model (BFM) which will in turn access the registers in the DUT. The RAL model also provides the verification environment with backdoor access to the registers which will by-pass the physical interface all together for higher performance after basic tests have passed. RAL functional coverage and assertions are generated for each register to ensure that all bits and modes of operation are fully verified during random testing.

Figure 2. RAL architecture

Features of the RAL

RAL has many features which will help in the task of verifying DUTs with complex register and memory areas.

Abstract physical location of the registers and the fields. - This means that the user only needs to
know the name of the register or the field to be accessed. There is no need to know the exact address of a register or bit position of a field. RAL will figure out the address and will access the correct location based on its name.

Transparently switching from front door to back door access. - This is a powerful feature for testing

correct bus connections. For example, one can use the front bus to write to a register and read the register using back door. This would expose any bus misconnects. It will also reduce DUT configuration time to zero once the correctness of the register and memory accesses has been ascertained.

Portability of configuration code from block level to system level. - For example, if there is a UART
which needs to be configured in the DUT, then one can write the UART configuration code using RAL. When the UART is embedded in an SOC, the same configuration code which was used to configure the stand-alone UART can be reused to configure several instances of it within the context of the SOC. This saves time and reduces errors.

Independence of tests and register specifications. - Register fields can be moved between physical
registers without test modification.

Independence of registers and interface protocols. - Registers and memories can be located in different
address spaces, each accessed using a different physical interface or protocol. RAL will use the proper interface or protocol to access the desired register or memory. Registers can also be shared across different physical interfaces. This removes the environment, configuration code and testcases from knowing which interface to use to access a specific register.

Pre-defined register and memory tests. - These include: mem_access: Uses front/back door to access memory locations. hw_reset: This is used to check reset values of the registers. bit_bash: To verify the correct operation of the fields/registers. mem_walk: Write/Read memory locations. gen_html: Generates an HTML report of the registers/memories. The content of registers is mirrored in an external data structure. - Once front door access is verified
to access registers and these registers are configured, their value is saved in the mirror. The register values can then be accessed in zero-time by accessing the mirror instead of the actual registers. Their mirror values can similarly be modified. RAL can then update the DUT to reflect the values programmed in the mirror.

Using RAL

The use of RAL begins with the creation of a high level register specification derived from the DUTs functional specification. The specification contains a description of the registers, their widths, fields, access types, offsets and reset values, and is captured in a simple textual format known as an RAL file. A utility (ralgen) processes the RAL file and generates the various RAL components as SystemVerilog code. The RAL components contain RAL abstract classes. A variety of tests, as well as functional coverage models, are also generated. The user then integrates the generated RAL model with the project-specific BFM which is used to access the DUT. To that end, the user customizes the methods in which RALs generic read/write transactions are converted to an interface specific transaction. Figure 3 explains the RAL use model. First the RAL file is processed via ralgen and the outcome of that step which is the RAL model is integrated with the BFM.

Figure 3. The RAL use model.

RAL file syntax

The RAL file uses a simple syntax to describe registers and their fields, the same with memory areas. Five different elements can be described:

Systems (Systems can contain other Systems and/or Blocks) Blocks (Blocks can contain Registers and/or Memories) Memories Registers Fields
Table 1 shows an example of a group of registers and a memory in a block called BANK1 which is part of a system called ROUTER, and Figure 4 shows an example block diagram.

Table 1. Example register and memory specification.

Figure 4. Example block diagram.

Figure 5 shows an example RAL file. This description of the registers and the memories can be modified every time the hardware spec is modified. Once the RAL file is complete, the ralgen utility will read its contents and generate an updated RAL model with the abstract classes representing the registers along with the details in the RAL file.

Figure 5. Example RAL file description.

Integrating the RAL model with the BFM

Once the RAL model is generated, it will be connected to the BFM and integrated in the verification environment. The RAL model uses a transaction-level interface, and will pass generic vmm_rw_access objects via a channel to send and receive data between the RAL model and the BFM.

Integration involves extending the execute_single() task method of the vmm_rw_xactor class, and customizing it to translate the generic vmm_rw_access objects to project specific ones. For example, if the DUT has a PCI configuration interface then the BFM which will be used to access the DUT should be translating the generic vmm_rw_access objects to PCI read/write transactions.

Figure 6 shows a block diagram of the vmm_rw_xactor and the BFM.

Figure 6. Block diagram of the vmm_rw_xactor and the BFM.

Several additional steps help complete the integration process.

vmm_ral_env is used to extend vmm_env. This environment contains: An instantiation of the RAL model which should be registered with the RAL access class (The
RAL access class is part of the VMM RAL env);

An instantiation of the BFM which should be registered with the RAL access model as well; Definition of the vmm_ral_env::hw_reset() task; used to reset the DUT. RAL tests are compiled, together with the RAL functional coverage and the remainder of the
verification environment to test and exercise the memories and the registers in the DUT.

In summary

RAL will save time, improve productivity and increase verification quality when verifying large register sets. It will reduce the error rate when modifying the registers and hence increase productivity. The built-in features such as tests, functional coverage groups and back-door access will enable a more productive verification of the design. RAL can be used with SystemVerilog using the VMM methodology, or with OpenVera using Synopsys Reference Verification Methodology (RVM).

The VMM RAL is a application package used to automate the: Registers memories in the design It also includes test to verify the implementation of: registers and memories functional coverage model to ensure that every bit of every register

 The Register Abstraction Layer Format(RALF) file is a specification of the host-accessible registers and memories available in a design. It can be captured manually using an Excel spreadsheet RALF representation: The smallest unit in RALF is block The name of the block should be relevant and unique It allows to instantiate the block in RALF description Do not name a block DUT The width of the physical data path for registers and memories is defined using bytes Assumption of RAL: The address granularity is equal to the width of the data path Example: block slave{ bytes 4; .. } The registers are described in the block using a register description The address offset of each register within the blocks is also specified at the same time Example: File: RAL/slave.ralf block slave { bytes 4; register CHIP_ID @h0000 { ... } register STATUS @h0010 { ... } register MASK @h0014 { ... } register COUNTERS[256] @h1000 { ... } ... } If no address offset is specified for a register, it is assumed to be incremented by one from the previous address offset. The fields inside each register are then specified using a field description. A field is the smallest of information and describes a set of consecutive bits with identical behavior. It is not necessary to specify unused or reserved bits if they are read-only and read as zeros. Fields are assumed to be contiguous, and justified in the least bits. Fields can be positioned at a specific bit offset within a register by specifying the bit number in the register that corresponds to the least significant bit of the field. File: RAL/slave.ralf block slave { bytes 4; register CHIP_ID @h0000 { field REVISION_ID { bits 8; access ro;

reset h03; } field CHIP_ID { bits 8; access ro; reset h5A; } field PRODUCT_ID { bits 10; access ro; reset h176; } } register STATUS @h0004 { field BUSY (BUSY) { bits 1; access ro; reset h0; } field TXEN (TXEN) { bits 1; access rw; reset h0; } field MODE (MODE) { bits 3; access rw; reset 3h0; } field READY (RDY) @16 { bits 1; access w1c; reset h0; } } register MASK @h0005 { field READY (RDY_MSK) @16 { bits 1; access rw; reset h0; } } register COUNTERS[256] @h0400 { field value { bits 32; access ru; reset h0; } } memory DMA_RAM (DMA) @h0800 { size 1k; bits 32; access rw; } }