Packaging and Integrating a Register Model

Packaging a Register Model

The following practices are recommended, but not required.

• Block types, and all the register, register file, and memory types they require, should be located in separate packages
• Register, register file, and memory types shared by more than one block type should be located in separate packages
• A header file, with all the required import statements to use the register model, should be generated
• A lengthy build() method may be split into several, shorter sub-methods. The sub-methods shall be declared local and called by the build() method

Integrating a Register Model

• A register model must be integrated with the bus agent
• The integration with the bus agent must only be done on root blocks
• Root blocks model the entire DUT and they are the only ones who have access to and knowledge of the externally-visible address maps.i.e in the environment of the testbench

class tb_env extends uvm_env;
  reg_model  regmodel;
  subblk_env subblk;

  virtual function void build_phase(uvm_phase phase);
    if (regmodel == null) begin
      regmodel = reg_model::type_id::create(“regmodel”, this);
      regmodel.build();
      regmodel.lock_model();
    end
    subblk = subblk_env::type_id::create(“subblk”, this);
    subblk.regmodel = regmodel.subblk;
  endfunction
endclass

❮ Previous Next ❯

Constructing Register Model

This section describes how to construct a UVM register model for register and memory access.

Register Field

Register fields are declared with uvm_reg_field class type.

uvm_reg_field reg_name;

• Register fields are declared in register class
• The field name must be unique within the scope of its declaration
• The access policy of a field is specified using the uvm_reg_field::configure() method
• Configure method has to be called from the build() method of the register that instantiates it (refer to register example)

Pre-defined Field Access Policies

Access Policy	Description	Effect of a Write on Current Field Value	Effect of a Read on Current Field Value	Read back Value
RO	Read Only	No effet	No effet	Current Value
RW	Read, Write	Changed to the written value	No effet	Current Value
RC	Read Clears All	No effet	Sets all bits to 0’s	Current Value
WRC	Write, Read Clears All	Changed to the written value	Sets all bits to 0’s	Current Value
WC	Write Clears All	Sets all bits to 0’s	No effet	Current Value
W1C	Write 1 to Clear	If the bit in the written value is a 1, the corresponding bit in the field is set to 0. Otherwise, the field bit is not affected	No effet	Current Value
W0C	Write 0 to Clear	If the bit in the written value is a 0, the corresponding bit in the field is set to 0. Otherwise, the field bit is not affected	No effet	Current Value

Reserved Fields

• There is no pre-defined field access policy for reserved fields
• Reserved fields should be left unmodelled, where they will be assumed to be RO fields filled with 0’s

Register

The register is constructed by writing a class extended from the uvm_reg class. There must be one class per unique register type

class my_reg extends uvm_reg;
  rand uvm_reg_field Field_0;
  rand uvm_reg_field Field_1;
endclass

• The name of the register type class must be unique within the scope of its declaration
• The uvm_reg_field::configure() method shall be called from the register type build method

class my_reg extends uvm_reg;
  virtual function build();
    this.Field_0 = my_reg::type_id::create(
      .name(“Field_0”),
      .parent(null),
      .contxt(get_full_name()));
    this.Field_0.configure(this, ...);
  endfunction
endclass

Register File

A register file type is constructed by writing a class extended from the uvm_reg_file class

class my_reg_file extends uvm_reg_file;
  `uvm_object_utils(my_reg_file)
endclass

• 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

class reg_file extends uvm_reg_file;

virtual function build();
  uvm_reg_block blk = get_block();
  this.rf = reg_file_0::type_id::create(
             .name($psprintf(“%s.rf1”, get_name())),
             .parent(null),
             .contxt(blk.get_full_name()));
  this.rf.configure(get_block(), this, ...);
  this.rf.build();
  this.rf.add_hdl_path();
endfunction

endclass

map() Method

• A virtual map() function, with uvm_reg_map and address offset arguments map() method shall call uvm_reg_map::add_reg() for all register class properties, adding the value of the address offset argument to the offset of the register in the register file map() method shall call the map() method of all register file class properties, adding the value of the address offset argument to the offset of the register file base offset
• The map() method may call the add_hdl_path() method for all register or register file class properties

virtual function map(uvm_reg_map mp, uvm_reg_addr_t offset);
  mp.add_reg(this.reg_0, base_addr + 'h0);
  mp.add_reg(this.reg_1, base_addr + 'h4;
  this.rf.map(mp, base_addr + 'h100);
endfunction

set_offset() Method

• A virtual set_offset() function, with a uvm_reg_map and address offset arguments, may also be implemented
• The set_offset() method shall call the set_offset() method for all register and register file class properties

virtual function set_offset(uvm_reg_map mp, uvm_reg_addr_t offset);
  this.reg_0.set_offset(mp, base_addr + 'h0);
  this.reg_1.set_offset(mp, base_addr + 'h4);
  this.rf.set_offset(mp, base_addr + 'h100);
endfunction

Memory Types

• A memory type is constructed using a class extended from the uvm_mem class
• The name of the memory type class must be unique within the scope of its declaration

class my_mem extends uvm_mem;
  `uvm_object_utils(my_mem)
endclass

Register Block

• A block is constructed by writing a class extended from the uvm_reg_block class
• The name of the block type class must be unique within the scope of its declaration

class my_blk extends uvm_reg_block;
  `uvm_object_utils(my_blk)
endclass

The block type must contain a class property for each,

• named address map
• register
• register file
• memory
• sub-block

• These shall have the rand attribute
• The build() method shall instantiate all named address maps by calling the uvm_reg_block::create_map() method

❮ Previous Next ❯

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.

Refer to UVM RAL Base Classes for a detailed description of UVM RAL Base Classes and its Methods.

Register classes cant be used as it is, they must be specialized via extensions to provide an abstract view that corresponds to the design registers and memories.

Above block diagram shows that,

• 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

Below block diagram shows the mapping of register model components to the environmental components.

Due to a large number of registers in design, this specialization shall be done by a register model generator.

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 tedious. 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).
❮ Previous Next ❯

What is UVM RAL model why it is required?

What is the RAL Concept, What are the Benefits of it?

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. UVM Register Layer is also referred to as UVM Register Abstraction Layer (UVM RAL).

For register access, can’t we proceed without RAL?

Yes, we can. But as mentioned above, RAL provides a set of base classes and methods with a set of rules which easies the effort required for register access.

Advantages of UVM RAL

The advantages of UVM RAL Model are,

• 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

Below block diagram shows using RAL in the verification testbench.

The below diagram shows the detailed components and connection of RAL with testbench.

For Detailed description on RAL Concepts refer to UVM RAL TUTORIAL.

UVM Register Model Tutorial

• Introduction
• Overview
• Usage Model
• Access Methods
• Constructing Register Model
• Packaging and Integrating Register Model
• Predictor
• Adaptor
• Integrating RAL to Bus Agent
• UVM Register Defines
• UVM RAL Base Classes
• UVM RAL Examples
  • Register accessing without RAL
  • Register accessing with RAL

❮ Previous Next ❯