You are on page 1of 5

ISSN: 2055-530X

International Journal of Latest Trends in Engineering, Science and Technology
Volume 1, Issue 5

Functional Verification of Register using UVM RAL
Methodology
Amruth Kumar J
Department of ECE,
East Point College of Engineering and
Technology
amruth.kumar14@gmail.com

Arun Kumar M

ABSTRACT
In this competitive world time to market is the main scenario.
Today's designs contain several hundreds to thousands of registers
and memory elements. Starting from documentation to design
implementation to verification of each single register, each bit and its
property involves a lot of time and complexity.UVM RAL is a UVM
application package used to automate creating high level, object
oriented abstraction model of registers and memory in DUT.The
paper describes this methodology which provides an almost zerotime, low maintenance, and reusable register design and verification
system.

Keywords:
EDS: Engineering Design Specification
RTL: Register Transfer Language
HDL: High Level Description Language
RoC: RAID on Chip
RAL: Register Abstraction Layer, a UVM application package
UVM: Universal Verification Methodology, by Accellera

1. INTRODUCTION
Registers and memory elements are the building blocks of today’s
large and complex designs. Continuously increasing number of
registers makes documentation, implementation and maintenance a
growing challenge. Moreover, changing specifications during the
design cycle require repeated updates to design, test bench, and
register/memory test cases as also to documentation. Manually
managing these components increases probability of introducing
errors in the process and affects productivity.
Most times, though, registers have a regular structure, defined by
their field attributes. Using this characteristic, it is possible to define
a flow where the register architecture is defined in a high level
register description language like RAL, which in turn is used to
generate the design, documentation and verification components.
This helps to reduce the often tedious and error-prone task of
managing registers, and enables design, verification and firmware
teams to work more efficiently from consistent and synchronized
views of the chip design.

2. PREVIOUS METHODOLOGY
Register definition generally starts with an architect scoping out a
specification. Once the specification is completed the hardware
engineer, software engineer, and verification engineers can begin
coding different views of the registers described in the functional
specification. Once we have a design, verification and software
engineers can start running tests. Anytime a bug is discovered the
specification must be changed and all the subsequent outputs must be

IJLTEST – Volume I, Issue 5 (MAY-JUNE 2014)

Kundu Priyabrata

Department of ECE,
East Point College of Engineering
and Technology
akm.epcet@gmail.com

Senior Manager, LSI India
priyabrata.kundu@lsi.com

changed accordingly. But due to other priorities the designer would
have changed the code but not the document or vice versa. This
process repeats itself many times over the course of the project. Bugs
are only one source of change though. Marketing requests may also
come in at any stage of the design cycle requiring the specification to
change and all downstream code to be modified.
As an example, in a module that we are implementing, there are
hundreds of registers. Translating into number of fields, for this
hundreds of 32-bit registers we have 1000 + fields, with different
hardware and software properties. Coding the RTL with address
decoding for hundreds of registers, with fields having different
properties is a week’s effort by a designer. Developing a re-usable
randomized verification environment with tests like reset value
check, read-write check, access check, byte access check, backdoor
access check is another 3 to 4 weeks, at the least. Closure on bugs
requires several feedbacks from verification to update design or
document. So overall, there is at least a month’s effort plus
maintenance overhead anytime the address mapping is modified or a
register updated/added.
This flow is susceptible to errors where there could be disconnect
between document, design, verification and software. The automated
register design and verification (DV) flow streamlines this process.
Adopting the automated flow, it took 2 days to write the EDS. The
rest of components were generated from this source. A small amount
of manual effort may be required for items like back-door path
definition, but it is minimal and a one-time effort.

3. METHODOLOGY IN OUR PROJECT
3.1 UVM RAL INTRODUCTION
RAL is tool provided by Synopsys to implement system register and
memory space implementation in verification environment. UVM
RAL (Register Abstraction Layer) is a UVM application package
used to automatecreating high level, object oriented abstraction
model of registers and memory in DUT.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
you have generated the RAL files they can be compiled with the
existing files to verify the connectivity and functionality of the
registers.RAL have a built in functional coverage model. So that you
can analyze which registers are accesses in which mode.

1

uvm_reg_field is thelowest register-abstraction layer which represents the bits of a register. Issue 5 Why do we need RAL? Normally registers and memories are first to be verified in any verification with reset and read writetests. Functional coverage monitor that measures how much of the design specification. think of time it takes to initialize chip level DUT. Let’s look at how a register value is stored. Once the register Specification is available we write/generate register model then validate the bus adapter. yes we canusing BACK DOOR access to register using RAL model. as enumerated by features in the test plan. Features of UVM RAL Here are few features of RAL model. or the value to be constrained when the field is randomized.  Value stores the value to be sampled in a functional coverage. may be 100 registers to write to startsingle test. only way to correctlymake sure that no interconnect issue existsis to write to register using physical interface andthen check/verify same value by reading register using hierarchical access to DUT register. In reality it takes most of simulation time to initialize DUT and make it ready for dataprocessing. has been exercised. Science and Technology Volume 1. which compares the DUT output versus a BFM output. Figure 1: RAL integration in UVM environment 4. Verification Flow 4.      Abstract physical location of the registers and the fields Flexibility in switching front door and backdoor access Content is mirrored in external data structure Independence of test cases and register specification Predefined register typesaddresses. In present scenario. Some verification engineer do use abstraction level ofregister and memory verification but still they are not complete solution as they might be missingbroad acceptance and ease of use like UVM RAL. followed by register integration and then sequences and test followed by scoreboard.  m_desired stores the value of what we want to set to the DUT. Issue 5 (MAY-JUNE 2014) . performing read-back operation on register does not guarantee that design does not haveany interconnect issues.ISSN: 2055-530X International Journal of Latest Trends in Engineering. Theuvm_reg_field uses several properties to store a variety of register-field values:  m_reset["HARD"] stores a hard reset value.2 Extending flow for UVM based Verification Figure 2: The steps involved in using the register model Register Abstraction Layer. Now what if we can complete this task of writing to registers in 0 time. This methodology becomes quite cumbersome when registers count reach in hundreds and thatis common in present day designs. 2 IJLTEST – Volume I. These models are updated manually everytime new values are written or read from DUT for corresponding register or memory location. Note that the m_reset is an associative array with a kind of reset as the key. 3. It saves most valuable time in systemlevel verification by providing 0 time access to read/write Registers. There could still be issue with register addressing. rather verification engineer may choose to maintain someregister file to keep track of register values on DUT.1 Register verification flow Register verification flow will describes the flow involved in verification of registers starting for Specification till functional coverage monitor. Thequestion then is how frequently do we do it? Also. many times we tend to avoid using abstraction mechanism forregister and memory verification. In Register Abstraction. Also. RAL is a UVM application package which helps create an object oriented abstraction layer to model registers and memories in a design under test.  m_mirrored stores the value of what we think in our design under test (DUT).

. 3. done creating file ITLinkLayerRegs_regs_base.done creating file ITLinkLayerRegs.ISSN: 2055-530X International Journal of Latest Trends in Engineering.sv .sv . ...3 Output Component 2: XML file The latest Perl scripts which read the register information from the EDS are located in xml_register_parser_uvm_V2_1_32bit.Document formats supported can vary from Microsoft Word. Issue 5 4.h.done creating file ITLinkLayerRegs_regmodel. A generated document will ensure a uniform look and keep the document in sync with the other components. . Document view for the Control Status Register (CSR) is as in Table 4..2 Output Component 1: Document <?xml-stylesheet href="ITLinkLayerRegs..fm Frame maker file Save as XML which will create <block name> Register.xml" you should see something like this sample output ***************************************************** ************ ***** Parsing EDS file: ITLinkLayerRegs.csv...xml Run the script with this command >perl xml_register_parser_uvm_new..svh..log.sv and ITLinkLayerRegs_regs...sv 3 IJLTEST – Volume I.csv Creating file ITLinkLayerRegs_regs_base.h Creating file ITLinkLayerRegs.xml file! ***************************************************** ************ Table 1: Document View for CSR_EXAMPLE .pl"<block name>Registers..done creating file ITLinkLayerRegs.sv and ITLinkLayerRegs_regs..pl perl script.sv Creating file ITLinkLayerRegs_regmodel.log Creating file ITLinkLayerRegs. Science and Technology Volume 1. Issue 5 (MAY-JUNE 2014) . 4. 2.. ***************************************************** ************ Found: 52 Registers in ITLinkLayerRegs. RTF to HTML.xml ***** ***************************************************** ************ Creating file ITLinkLayerRegs. Edit the <block name> Registers.. This script parses XML files exported from EDS Frame Maker The process for generating the files is 1...done creating file ITLinkLayerRegs...svh Creating file ITLinkLayerRegs..css" type="text/css" charset="UTF-8"?> Register documentation of different IPs in a ROC may not have the same look and feel.done creating file ITLinkLayerRegs. Most third-party toolswill allow some customization in the look and information content of the document ..

parent(null). VERIFICATION VIEW The generated XML file is passed through Perl script.ISSN: 2055-530X International Journal of Latest Trends in Engineering..contxt(get_full_name())).new(). . super. . . .has_reset(1).regmodel. endfunction extends new(uvm_ral_regral_reg). uvm_reg_fieldmyControl.drop_objection(this). function super. . ……………………. . The attributes of the components in 4 IJLTEST – Volume I. reusable. super. . ……………… endtask virtual task write(). 5..n_bits(32). reg_read_write_seq_h.size(16).name(name).raise_objection(this).myStatus. to generate an object oriented. Issue 5 (MAY-JUNE 2014) . reg_read_write_seq_h= reg_read_write_seq::type_id::create("reg_read_ write_seq_h".new(. super. super. super. phase.start(rec_env_h.size(3). phase.. phase. super. function new(string name = " Control_and_Status_reg"). coverage driven UVM based register verification environment.raise_objection(this). . uvm_ral_fieldCSR_status. .drop_objection(this).reset('h0). rand uvm_ral_fieldCSR_control.new(ral_reg). Science and Technology Volume 1.pre_read(data).myStatus= uvm_reg_field::type_id::create(.configure(.lsb_pos(0). endtask :main_phase endclass:tb_rec_reg_read_write_test Table 4: UVM based System Verilog environment `include "UVM_ral. These classes are extended from RAL base classes. endtask: configure_phase taskmain_phase(uvm_phase phase). . if (has_coverage(UVM_CVR_REG_BITS)) begin. . this. . endtask endclass classral_reg_csr_example_CSR extends uvm_ral_reg. .get_full_name()).access("RW").pre_write().new.is_rand(0) endfunction : build endclass :Control_and_Status_reg function void build_phase(uvm_phase phase). if (has_coverage(UVM_CVR_FIELD_VALS)) vals_cg = new().CSR. phase. endfunction : new virtual function void build().parent(this). block and system component available in XML. . . reg_read_write_seqreg_read_write_seq_h.myControl. the RAL contains a System Verilog class. endfunction: build_phase virtual task reset_phase(uvm_phase phase).parent(this).is_rand(0) this.reset_phase(phase). this.name("Control_ and_Status_reg_c_myStatus").reset('h0). nd_vals_cg = new(). Table 3: UVM based System Verilog Test environment classtb_rec_reg_read_write_test extends tb_base_directed_test. function new().vseqr_h). `uvm_component_utils(tb_rec_reg_read_write_tes t) function new. endclass :ral_block_csr_example extends For each field. .sv" classral_reg_csr_example_CSR_bkdr uvm_ral_reg_backdoor.has_reset(1).parent(null).build_phase(phase).configure_phase(phase). register. endfunction: new ………….myControl= uvm_reg_field::type_id::create(.contxt(get_full_name())).lsb_pos(28). endfunction: new endclass :ral_reg_csr_example_CSR classral_block_csr_example uvm_ral_block. this. endtask :reset_phase virtual task configure_phase(uvm_phase phase). virtual task read (). . reg_read_write_seq_h.configure(.regmodel = rec_env_h. Issue 5 Table 2: Regmodel for CSR Example (CSR_EXAMPLE) classControl_and_Status_reg extends uvm_reg. A small part of the System Verilog code generated for CSR_EXAMPLE (above example) is shown in Table 3. end. uvm_reg_fieldmy_status.access("RW"). super. .name("Control_ and_Status_reg_c_myControl"). super.

especially useful for full-chip and sub-chip simulations where several registers need to be setup. cluster (sub-chip level) and chip level.Silpa Naidu [2] Universal Verification Methodology (UVM) 1. ACKNOWLEDGEMENTS There are two ways of accessing design registers in a verification environment: front door and back door. guidance and help. writing a register in front door and reading it from the backdoor flags any mismatch between design and the mirror register. Since the mirror register gets updated while doing front-door or back-door writes. Issue 5 XML such as base address. CONCLUSION This flow eliminates tedious and error-prone processes of manually managing registers.I might gratefully acknowledge the contribution ofmy manager KamatBambolkar Nikhilfor his encouragement.aspx Test result in vplan for few registers 5 IJLTEST – Volume I. Also acknowledge the help received from Chinni NarasimhaRao. low maintenance. VERIFICATION ASPECTS Front door and Backdoor Access 8. Shreyas Jayaprakash and Sajin CV. reset value.com/Tools/Verification/Functional Verification/Pages/VCS. there is lot of saving of effort.org/downloads/standards/uvm [5] http://www. and reusable register design and verification (DV) system. domain name are passed to the individual classes as arguments.accellera. This RAL model can be integrated in a UVM environment for complete DUT register verification RAL has several useful features that help in building verification environment for large and complex designs:  Named register access   Mirror register   Functional coverage model    Predefined tests   Access tasks  These are well documented in the RAL user guide that we need to refer for further usage details.com/en/solutions/functional_verification/ uvm_ovm_vmm [6] http://www. greater than a month’s effort can be cut down to less than a week’s by this approach. [1] Automated approach to Register Design and Verification of complex SOCby BalloriBanerjee.SubashiniRajan. and enables design.Coverage may be measured based on pass/fail status of any test. Issue 5 (MAY-JUNE 2014) . Front door is by using the design register bus. robust design and better verification. It provides an almost zero-time. 10. As seen earlier. Thus. with lot of reuse of code and environment. Backdoor access also helps in uncovering address decode design bugs. This consumes cycles and follows the register bus protocol.1 User’s Guide [3] http://www. 6. verification and firmware teams to work more efficiently from consistent and synchronized views of the chip design. enhanced productivity.ISSN: 2055-530X International Journal of Latest Trends in Engineering.aldec. Overall. Wewould like to first express our gratitude toEast Point College of Engineering and Technology andLSIIndia Research &Development pvt ltd Bangalore for giving me the opportunity to present my work and share my experiences with others who benefit from it. offset. Mapping Test Cases Synopsys Verification Planner helps in mapping of various metrics to feature list for measuring functional coverage. Science and Technology Volume 1. configuring by backdoor saves simulation time. 9.com/ [4] http://www. Once setup.specman-verification. the flow is repeatable and can be used across block.synopsys. Backdoor is a zero simulation time access by mapping to the design register directly using the HDL path and allows quick configuration of registers. REFERENCES 7.