Uvm Util

UVM Related Utilities
Product Version XCELIUM AGILE

September 2022
© 2022 Cadence Design Systems, Inc. All rights reserved worldwide.
Cadence Design Systems, Inc. (Cadence), 2655 Seely Ave., San Jose, CA 95134, USA.
Trademarks: Trademarks and service marks of Cadence Design Systems, Inc. contained in this
document are attributed to Cadence with the appropriate symbol. For queries regarding Cadence's
trademarks, contact the corporate legal department at the address shown above or call
800.862.4522. All other trademarks are the property of their respective holders. Trademarks and
service marks of Cadence Design Systems, Inc. contained in this document are attributed to
Cadence with the appropriate symbol. For queries regarding Cadence's trademarks, contact the
corporate legal department at the address shown above or call 800.862.4522. Open SystemC,
Open SystemC Initiative, OSCI, SystemC, and Accellera Systems Initiative Inc. are trademarks or
registered trademarks of Open SystemC Initiative, Inc. in the United States and other countries and
are used with permission. All other trademarks are the property of their respective owners.
Restricted Permission: This publication is protected by copyright law and international treaties
and contains trade secrets and proprietary information owned by Cadence. Unauthorized
reproduction or distribution of this publication, or any portion of it, may result in civil and criminal
penalties. Except as specified in this permission statement, this publication may not be copied,
reproduced, modified, published, uploaded, posted, transmitted, or distributed in any way, without
prior written permission from Cadence. Unless otherwise agreed to by Cadence in writing, this
statement permits Cadence customers permission to print one (1) hard copy of this publication
subject to the following conditions:
1. The publication may be used only in accordance with a written agreement between Cadence
and its customer.
2. The publication may not be modified in any way.
3. Any authorized copy of the publication or portion thereof must include all original copyright,
trademark, and other proprietary notices and this permission statement.
4. The information contained in this document cannot be used in the development of like
products or software, whether for internal or external use, and shall not be used for the
benefit of any other party, whether or not for consideration.
Disclaimer: Information in this publication is subject to change without notice and does not
represent a commitment on the part of Cadence. Except as may be explicitly outlined in such
agreement, Cadence does not make, and expressly disclaims any representations or warranties as
to the completeness, accuracy, or usefulness of the information contained in this document.
Cadence does not warrant that use of such information will not infringe any third-party rights, nor
does Cadence assume any liability for damages or costs of any kind that may result from the use of
such information.
Cadence is committed to using respectful language in our code and communications. We are also
active in the removal and/or replacement of inappropriate language from existing content. This
product documentation may however contain material that is no longer considered appropriate but
still reflects long-standing industry terminology. Such content will be addressed at a time when the
related software can be updated without end-user impact.
Restricted Rights: Use, duplication, or disclosure by the Government is subject to restrictions as

set forth in FAR52.227-14 and DFAR252.227-7013 et seq. or its successor.
Table of Contents
Contents
1 7
Register Verification 7
Notes 7
Running Register Verifier and the Register Verifier Demo 8
Running Register Verifier 8
Running the Register Verifier Demo 12
Working with IP-XACT Files 14
Currently Supported IP-XACT Versions 14
IP-XACT File Format Structure 14
Defining Type Names with IP-XACT 15
Defining Single- and Multi-Dimensional Arrays with IP-XACT 15
Generating HDL Paths with IP-XACT 1685-2014 16
IP-XACT Entities and Their Conversion to e 16
component 17
memoryMaps 17
memoryMap 18
addressBlock 19
Register 22
Register field 26
IP-XACT Entities and Their Conversion to uvmreg 30
Registers and Register Fields 30
Memories 32
Register Files 32
Blocks and Sub-Blocks 33
Cadence IP-XACT Vendor Extensions for Register Verifier 35
Supported Input Documents 37
Supported Locations in IP-XACT File 38
Requirements 39
Vendor Extension Container 39
Field Data 40
Memory Map, Register and Address Block Description 41
Custom Access Policies for Specific Register Fields 44
Verification Properties 46
September 2022 4 Product Version XCELIUM AGILE

Table of Contents
Optimization in Register Verifier 48

Modeling Standard UVM Register Access Modes 48
Multiple Invocation in Register Verifier 50
Migrating from iregGen to Register Verifier 51
Location 51
Input XML 52
Vendor-Extensions 52
Commmand-Line 54
Output 54
2 56
mltypemap Utility: Automatic Generation of Data Types 56
mltypemap Examples 56
Mapping from e 57
Mapping from SystemVerilog 60
Mapping from SystemC 63
Invoking mltypemap 66
xrun Arguments for Invoking mltypemap 67
xrun Examples 67
Mapping Types with mltypemap 68
maptypes Command 69
Output Files Generated by maptypes 71
Mapped Data Types 72
Mapping Scalar and Aggregate Data Types 72
Mapping Classes 76
Mapping e Structs and SystemVerilog Structs 77
Mapping e when Subtypes 81
Referencing when Subtypes in Configuration Commands 82
Mapping Enumerated Types 82
Mapping Typedefs 83
Mapping SystemVerilog Queues, SystemC Vectors, and e Lists 84
Configuring mltypemap 85
configure_scope Command 86
configure_type Command 87
configure_field Command 89
configure_enum_item Command 92
print_type Command 93

Table of Contents
configure_code Command 94
mltypemap Limitations for this Release 96

Register Verification
The Register Verifier application is delivered under the Cadence® Xcelium™ Simulator release.
The application reads IP-XACT files (described in Working with IP-XACT Files) containing address
and register definitions and generates corresponding definitions in either vr_ad (in e) or reg_mem
(in SystemVerilog). This generated code can then be included in the verification environment.
In cases where the standard IP-XACT is not sufficient, vendor extensions are needed. A list of
supported vendor extensions and their descriptions is provided under Cadence IP-XACT Vendor
Extensions for Register Verifier.
Notes
Register Verifier is supported only on Linux.
iregGen is under deprecation, and support will be removed in a future version. Cadence
recommends that you migrate to Register Verifier. For instructions, see Migrating from
iregGen to Register Verifier.
This chapter includes the following sections:
Running Register Verifier and the Register Verifier Demo
Working with IP-XACT Files
IP-XACT Entities and Their Conversion to e
IP-XACT Entities and Their Conversion to uvmreg
Cadence IP-XACT Vendor Extensions for Register Verifier
Optimization in Register Verifier
Modeling Standard UVM Register Access Modes
Multiple Invocation in Register Verifier
Migrating from iregGen to Register Verifier

Running Register Verifier and the Register

Verifier Demo
Running Register Verifier

The application is activated via a script named reg_verifier .
Syntax
reg_verifier
-top <top-file>
-domain vr_ad | uvmreg
-dut_name <dut-name>
[<global options...>] [<domain options>...]
Syntax Usage Example

The following is a vr_ad line command:
reg_verifier -top my_env.xml -domain vr_ad -dut_name apb_system -reg_prefix CMPNY_
Running this will read the file my_env.xml, parse the component named apb_subsystem, create e files
in directory reg_verifier_dir, and all defined types (register names, enums) will be prefixed with
"CMPNY_".

Parameters
Mandatory Flags
Value Global Option
-top <top-file> Top level IP-XACT file.
- Specifies whether the code is generated in e (vr_ad) or in

domain vr_ad | uvmreg SystemVerilog (uvmreg)
-dut_name <dut-name> Name of the top level DUT component.
Global Options
Value Global Option
-h[elp] Display all supported options.
-incdir <dir,...> Include directories for referenced IP-XACT files. All referenced IP-XACT
should be located (directly or indirectly) under these directories.
-target_dir <dir> Target generation directory (that is, the location of the generatede or SV
files).
Default: reg_verifier_dir
-nocopyright Disable the copyright message
- Comma separated list of alternate register groups to be selected. Where

alternate_groups applicable, registers will be generated using the selected alternative
<group,...> register, as described in IPXACT 1685-2009 6.10.4.

Domain Options (vr_ad)
Value Domain Option (uvmreg)
-reg_prefix <prefix> Prefix to add to register name
<dir,...> Keep the case specified in the XML, ignore coding

style.
Domain Options (uvmreg)
Value Domain Option (uvmreg)
-pov_intf <intf- Comma separated list of interface paths

path,...>
-cov Generate the coverage code for the register based on the input IP-XACT.
By default, coverage is off.
-quicktest Generate a testbench (quicktest.sv ) and a makefile
- Generate a register model without using the UVM factory.

no_uvm_factory
By default, reg_verifier utilizes the UVM factory to create instances for
registers, blocks, fields, and so on. Note that a UVM factory-enabled
register model is more flexible than a non-enabled model, but might result
in increased runtime overhead.
-out_file <prefix> Change the file prefix (default: cdns_uvmreg) of the generated files in the
output_directory/uvmreg directory. For more information, see the
discussion under “When the domain flag is vr_ad:” below.
-pkg=<name> Change the name of the package inside of which the register model
classes are generated. For more information, see the discussion under
“When the domain flag is uvmreg:” below.
- Generate the utils macros in the register class and no other class of
enable_callback register-file, memories, or blocks is impacted. The macros added are
“ùvm_register_cb(“name”, uvm_reg_cbs) ” and
“ùvm_set_super_type(“name”, uvm_reg)”. Note that this option will impact
the elaboration time.

When the domain flag is vr_ad:

The tool creates a directory named vr_ad in the target directory. In the vr_ad directory, creates two
files:
regs.e — Contains the definition of the registers model, as per the definitions in the IP-XACT
file.
test.e — Contains an example of using the register model to instantiate the memory map
under sys.
To check the created files and verify that they conform to your expectations, you can load the test
file and issue the gen command in Cadence® Specman® Elite:
specman -p 'load reg_verifier/vr_ad/test.e;gen'
At the specman prompt, you can also print the generated map/s. For example:
specman> show map
specman> print @1
To integrate the created files in the environment, instantiate the created maps in the appropriate
location in your verification environment. (See the test.e or regs.e files, to see the exact type of
the created map.) For example:
<'
extend my_env {
am0 : AM0 vr_ad_map;
};
'>
When the domain flag is uvmreg:

By default, the reg_verifier_dir directory is created. Inside this directory, another directory is
created named uvmreg. By default, all UVM Register Model files are generated in this directory. The
output directory can be changed using the command-line option -target_dir.
The default names of the files generated in the output directory are:
cdns_uvmreg_rdb.sv — File containing a package that contains all classes of the Register
model components generated in the Register Model file.
cdns_uvmreg_utils_pkg.sv — Package file containing all utilization functions and
structures. Package name: my_package.

cdns_uvmreg_config.dat — Configuration file listing the configuration of all Register Model

components
cdns_uvmreg_hdlpaths.dat — All hdl_path definitions for all Register Model components.
NOTE: *.dat files contain static configuration values which are applied at runtime. This separation
aims at a faster turnaround upon changes.
The default prefix cdns_uvmreg in the name of the files generated in the output directory can be
changed by specifying the -out_file option. Note that specifying this option does not affect the
package name.
The name of the package in thecdns_uvmreg_rdb.sv file (or the prefix_rdb.sv file if you changed
the prefix using the -out_file option) can be changed. The default package name is my_pkg. If the -
pov_intf option is specified, the name intf_name_pkg overrides the name my_pkg. However,
specifying the -pkg option overrides both of those names with the specified name.
Running the Register Verifier Demo

Users can run the demo with the demo scripts. The syntax is:
reg_verifier_demo -domain [vr_ad | uvmreg].
The demo script generates in the domain specified, as described below.
vr_ad
Here the demo script reads IP-XACT files and generates vr_ad definitions with the following
command:
reg_verifier -dut_name APB_SUBSYTEM_regs \
-top < install-dir>/tools/tti/examples/reg_verifier/ipxact_example.xml \
-domain vr_ad
The following files are generated:

reg_verifier_dir/vr_ad/test.e – instantiate register model
reg_verifier_dir/vr_ad/regs.e – register and memory map definitions
The following command loads the files and displays the results:
specman -p 'load reg_verifier_dir/vr_ad/test; gen; print sys.mmap0.reg_list[1]; exit'

uvmreg
Here the demo script reads IP-XACT files and generates uvmreg definitions with the following
command:
reg_verifier -dut_name APB_SUBSYTEM_regs \
-top < install-dir>/tools/tti/examples/reg_verifier/ipxact_example.xml -domain
uvmreg
The following files are generated:

reg_verifier_dir/uvmreg/cdns_uvmreg_config.dat -- Configuration file listing the
configuration of all Register Model components.
reg_verifier_dir/uvmreg/cdns_uvmreg_hdlpaths.dat -- All hdl_path definitions of all Register
Model components.
reg_verifier_dir/uvmreg/cdns_uvmreg_rdb.sv -- All classes of the Register model
components generated in Register Model file.
reg_verifier_dir/uvmreg/cdns_uvmreg_utils_pkg.sv -- Package file containing all utilization
functions and structures.
To see the results in Xcelium Simulator, enter the following commands:
setenv REG_VERIFIER_EXAMPLE_DIR <install-dir>/tools/tti/examples/reg_verifier

xrun -clean -uvm \
reg_verifier_dir/uvmreg/cdns_uvmreg_utils_pkg.sv \
reg_verifier_dir/uvmreg/cdns_uvmreg_rdb.sv \
+define+CDNS_UVMREG_CONFIG_DATA_DIR=./reg_verifier_dir/uvmreg/$REG_VERIFIER_EXAMPLE_DIR/uvc_pkg.s
v \
$REG_VERIFIER_EXAMPLE_DIR/tb_top.sv \
$REG_VERIFIER_EXAMPLE_DIR/test.sv \
-coverage U -covoverwrite +access+rw \
+uvm_set_verbosity=uvm_test_top,REG_PREDICT,UVM_HIGH,connect \
+define+NUM_REGS=10 +UVM_RECORDING=1

Working with IP-XACT Files

IP-XACT is an XML format, created as a standard by the SPIRIT Consortium, that defines and
describes electronic components and their designs. IP-XACT files are used for capturing and
integrating design IP. They are structural in nature and allow describing the desired register
database name, address spaces, register-files, registers, and fields. Like any XML file, you can
read and edit these files with an ASCII editor. In addition, you can read these files using free or
commercial editors that provide a table view and extra editing and validation capabilities.
This section contains the following:
Currently Supported IP-XACT Versions
IP-XACT File Format Structure
Defining Type Names with IP-XACT
Defining Single- and Multi-Dimensional Arrays with IP-XACT
Generating HDL Paths with IP-XACT 1685-2014
Currently Supported IP-XACT Versions

The currently supported IP-XACT versions are: 1.4,1.5,1685-2009, and 1685-2014.
IP-XACT File Format Structure

The structure of the Registers & Memory IP-XACT file consists of the following:
A header with some documentation such as vendor name, SPIRIT IP-XACT version, project
name, and so on.
An array of memory maps that specifies the memory and registers description. Each memory
map is an address space that can hold memory blocks (register-files), registers, or fields.
The XML code below illustrates an IP-XACT description of a single memory map with one register
file, containing one register that has one field.

<spirit:memoryMaps>
<spirit:memoryMap>
<spirit:name>am0</spirit:name>
<spirit:addressBlock>
<spirit:name>rf1</spirit:name>
<spirit:baseAddress>0x1000</spirit:baseAddress>
<spirit:range>0x100</spirit:range>
<spirit:width>8</spirit:width>
<spirit:register>
<spirit:name>reg0</spirit:name>
<spirit:addressOffset>0x0</spirit:addressOffset>
<spirit:size>8</spirit:size>
<spirit:access>write-only</spirit:access>
<spirit:reset>
<spirit:value>0x00</spirit:value>
<spirit:mask>0xff</spirit:mask>
</spirit:reset>
<spirit:field>
<spirit:name>reg1_f</spirit:name>
<spirit:bitOffset>0</spirit:bitOffset>
<spirit:bitWidth>8</spirit:bitWidth>
</spirit:field>
</spirit:register>
</spirit:addressBlock>
</spirit:memoryMap>
</spirit:memoryMaps>
Defining Type Names with IP-XACT

In Register Verifier, component type names are defined withspirit:typeIdentifier, which is part
of the IP-XACT grammar. The spirit:typeIdentifier grammar is supported in IP-XACT
spirit:register, spirit:registerFile, spirit:addressBlock, and memories containers.
Defining Single- and Multi-Dimensional Arrays with IP-

XACT
Arrays are defined with the spirit:dim IP-XACT grammar. Register Verifier creates the array for
the IP-XACT component based on the numeric value. The spirit:dim IP-XACT grammar is
supported in IP-XACT spirit:register and spirit:registerFile containers.
To define a multi-dimensional array, define multiple spirit:dim statements, as shown in the
following example. This example specifies the i_vendor_id_device_id_2[2][4][3] array in input:

<spirit:register>
<spirit:name>i_vendor_id_device_id_2</spirit:name>
<spirit:dim>2</spirit:dim> -
<spirit:dim>4</spirit:dim>
<spirit:dim>3</spirit:dim>
Generating HDL Paths with IP-XACT 1685-2014

If you are using IPXACT 1685-2014, you can use the input ipxact:accessHandle grammar to
generate the HDL paths for the UVM register model. HDL paths relative to the parent component
are calculated by traversing from the leaf memory map object up the memory map hierarchy and
concatenating the HDL path stored in the accessHandle associated with each memory map object.
There are several types of accessHandle elements for use with input:
simpleAccessHandle is for use with hierarchical memory mapped objects, i.e., bank
elements.
nonIndexedLeafAccessHandle is for use with memory mapped objects without a
dimension, i.e., addressBlock and field elements.
For single- or multi-diminsional arrays, you can generate HDL paths for the complete array
object or for each element in the array objects:
indexedAccessHandle is for use with memory mapped objects with a dimension, i.e.,
alternateRegister, register, and registerFile elements.
leafAccessHandle describes how to access the associated IP-XACT object.
IP-XACT Entities and Their Conversion to e

This section describes the following IP-XACT entities and their conversion toe.
component
memoryMaps
memoryMap
addressBlock
Register

Register field
component
The component is the central place holder for objects meta-data. In our context, the component is
a container of one or more memory maps (described below).
component elements & attributes
name
Name of the component, parsed by reg_verifier, mentioned in some of the comments in the
created e file.
memoryMaps
Described in detail below.
components unsupported attributes/elements

Optional in IPXACT, and not supported (-ignored) by reg_verifier:
Any of the other attributes or elements.
memoryMaps
The memoryMaps contains one or more memory maps.
memoryMaps elements & attributes
memoryMap
Described in detail below.

memoryMaps unsupported attributes/elements

Everything other than memoryMap
memoryMap
Based on each memoryMap in the IP-XACT definition file, reg_verifier defines a subtype of
vr_ad_map.
The vr_ad_map_kind type is extended, adding the name of the new map
The new subtype is extended, adding all memory blocks as described in the IPXACT file.
All types used by this map will contain the map name as a prefix. This includes enums, register
files and registers.
The top level map should be instantiated in the verification environment.
Example
The following IPXACT definitions:
<spirit:memoryMaps>
<spirit:memoryMap>
</spirit:memoryMap>
</spirit:memoryMaps>
Result in the following e code:
extend vr_ad_map_kind : [AM0];

extend AM0 vr_ad_map {
// all sub maps and address blocks to be instantiated here,
// as shown in next section
};

memoryMap elements
name
The name of created map - a vr_ad_map_kind
addressBlock
Described below.
memoryMap unsupported attributes/elements

bank
subspaceMap
memoryRemap
address
addressUnitbits
vendorExtensions
addressBlock
Based on each addressBlock in the IP-XACT definition file, reg_verifier defines a subtype of
vr_ad_reg_file.
The vr_ad_reg_file_kind type is extended, adding the name of the new file. The name of the
address map is used as a prefix for the name of the register file.
The new subtype of the reg file is extended, adding all registers as described in the IPXACT
file.
The register file is added to the address map.

Example
The following IPXACT definition:
<spirit:memoryMap>
<spirit:register>
</spirit:register>
</spirit:memoryMap>
Result in the following e code:
extend vr_ad_map_kind : [AM0];

extend vr_ad_reg_file_kind : [AM0_RF1];
extend AM0_RF1 vr_ad_reg_file {
keep size == 0x100;
keep addressing_width_in_bytes == 1;
};
reg_def AM0_RF1_REG0 RF1 0x0 {
// register definition…. Described in next section…
};
rf1 : AM0_RF1 vr_ad_reg_file;
post_generate() is also {
// Map register files to the right addresses in the map.
add_with_offset(0x1000, rf1);
// Reset all registers at start of Specman run.
rf1.reset();
};
};
addressBlock elements/attributes
name
Name of created register file, value added tovr_ad_reg_file_kind.
For example, the following:

Results in the following:

extend vr_ad_reg_file_kind : [RF1];
baseAddress
The offset of the register file within its map.
For example, this:
…

rf1 : RF1 vr_ad_reg_file;
// Map register files to the right addresses in the map.
add_with_offset(0x1000, rf1);
};
};
description
Copied as is into a comment, part of the register file header.
range
The size of created register file.
For example, this:

extend RF1 vr_ad_reg_file {

keep size == 0x100;
};
width
The addressing width of created registers file. The width in the IPXACT definition file is in bits, but
in e the width is in bytes.
For example, this:
extend RF1 vr_ad_reg_file {

keep addressing_width_in_bytes == 1;
};
addressBlock unsupported attributes/elements

vendorExtensions
typeIdentifier
displayname
Register
For each register defined in the IPXACT file, reg_verifier creates avr_ad_register.
The register name is prefixed with the name of the containing map and register file.
A new enum type is defined for each field defined with “values” (described below).
If no field is defined in the register, a field nameddata is defined and its width is the register’s
width.
If the fields defined in the registers have gaps (their total width is less than the register’s
width), reg_verifier pads the gaps with reserved fields.

Example 1: no fields
This is a definition of a write-only register, with no defined fields. A field named data I defined.
<spirit:register>
<spirit:reset>
</spirit:reset>
</spirit:register>
The following is the resulting e code:

// Field data = AM0_RF1_reg0[7:0]; Write Only; resets to 0x00;
// Path = no_ve_golden_model/am0/rf1/AM0_RF1_reg0/data
// No fields defined in the XML, defining one field, named 'data'
reg_fld data : uint (bits : 8) : W : 0x00 : cov ;
};
Example 2: "padding fields"

The following IPXACT code defines a register with one field, at offset 3 and width 3.
<spirit:register>
<spirit:description>register with unused offsets at both edges of register.
</spirit:description>
<spirit:field>
<spirit:name>f0</spirit:name>
</spirit:field>
</spirit:register>
The following is the created code. reg_verifier “filled the gaps”, that is it defined two reserved fields,
at offset 0 and offset 6.


// Field reserved_1 = AM0_RF1_reg3[7:6]; Read Write; resets to 0;
// Path = no_ve_golden_model/am0/rf1/AM0_RF1_reg3/reserved_1
// Automatically added to fill undeclared bits
reg_fld reserved_1 : uint (bits : 2) : RW : 0 : cov ;
// Field f0 = AM0_RF1_reg3[5:3]; Read Write; resets to 7;
// Path = no_ve_golden_model/am0/rf1/AM0_RF1_reg3/f0
//
reg_fld f0 : uint (bits : 3) : RW : 7 : cov ;
};
Register Elements/Attributes
name
The name of the register. In the createde file, it will be
prefixed by name of memory map and register file.
uppercase
For example, this:

…
};
addressoffset
The address, offset, of the register in the register file.
For example, this:


…
};
description
Copied as is into a comment, part of the register header.
size
The register size in bits. This value is used by reg_verifier to calculate whether there are gaps in
the register fields.
The sum of field widths should equal the size of the register. If it does not, the ipxact2crad adds
reserved fields to fill the gap.
access
Access policy of the register. This is the default value of access policy for each of the fields. It can
be overridden per each field, using the access element of the register field.
reset
Reset value of the register.
The reset has two elements:
value: value of reset
mask: optional, not implemented in first release
register unsupported attributes/elements

parameters

Register field
For each field in the register definition, reg_verifier defines a field in the newvr_ad_reg.
If the field defines values, a new enum is defined.
NOTE: Each field has its own enum type. Each enum type is prefixed with map, file, and register
names, thereby preventing name clashes.
If a field does not define access policy, it inherits the policy defined for the register. If no policy is
defined, it assumes read-write.
Example
The following IPXACT code defines a register with one field, at offset 3 and width 3.
<spirit:register>
<spirit:description>register with unused offsets at both edges of register.
</spirit:description>
<spirit:field>
</spirit:field>
</spirit:register>
The following is the created code. reg_verifier "filled the gaps", that is it defined two reserved fields,
at offset 0 and offset 6.

// Field f0 = AM0_RF1_reg3[5:3]; Read Write; resets to 7;
// Path = no_ve_golden_model/am0/rf1/AM0_RF1_reg3/f0
//
};

Register field Attributes/Elements
name
The name of the created vr_ad_reg.
For example, this:
<spirit:field>
</spirit:field>

bitOffset
Field offset in the register, directs the location of the field in the register.
bitWidth
Field width in bits.
For example, this:
<spirit:field>
</spirit:field>

description
Copied as is into a comment, part of the register header.

access
Access policy of the field. The default is the access policy of the register.
For example, this:
<spirit:register>
<spirit:name>command</spirit:name>
<spirit:access>read-write</spirit:access>
<spirit:field>
<spirit:name>word_size</spirit:name>
<spirit:access>read-only</spirit:access>
</spirit:field>
<spirit:field>
<spirit:name>source_address_enable</spirit:name>
</spirit:field>
</spirit:register>
reg_def CMPN_COMMAND CMPN_DMA_ETH 0x0 {

reg_fld source_address_enable : uint (bits : 5) : RWO : 0 : cov ;
reg_fld word_size : uint (bits : 3) : R : 0 : cov ;
};
values
Based on the described values, reg_verifier defines new enum, and the field type is of this enum.
The new type is lowercase, prefixed with map, file, and register names, suffixed with '_t'.
The enum type is uppercase.
The field name is lowercase.
NOTE: Each field has its own enum type. Each enum type prefixed with map, file, and register
names, thereby preventing name clashes if there are multiple fields.
For example, the following lines, which define the field as having four legal values 0..3 and each
value having a name:

<spirit:register>
… some fields…
<spirit:field>
<spirit:name>dirs</spirit:name>
<spirit:values>
<spirit:value>0</spirit:value>
<spirit:name>north</spirit:name>
</spirit:values>
<spirit:values>
<spirit:name>south</spirit:name>
</spirit:values>
<spirit:values>
<spirit:name>east</spirit:name>
</spirit:values>
<spirit:values>
<spirit:name>west</spirit:name>
</spirit:values>
</spirit:field>
… some more fields…
<spirit:register>
Results in the following new enum defined, to be used only by this field.
type am0_rf1_reg4_dirs_t : [north = 0,south = 1,east = 2,west = 3] (bits : 2) ;
The field is defined to be of type of the new enum:

// other fields..
reg_fld more_dirs : am0_rf1_reg4_more_dirs_t : W : north_west : cov ;
// other fields…
};
registerField unsupported attributes/elements

Optional in IPXACT, and not supported (-ignored) by reg_verifier.
typeIdentifier
parameters
vendorExtensions

IP-XACT Entities and Their Conversion to

uvmreg
The following components are generated by reg_verifier :
Registers and Register Fields

Memories
Register Files
Blocks and Sub-Blocks
Registers and Register Fields

In IP-XACT input, the fields are defined withspirit:field , as follows:
spirit:name – Name of the field
spirit:bitOffset – Offset of the field in the register or the LSB position of the field
spirit:bitWidth – Field width
spirit:reset – Reset value of the field
Register data is defined as follows:
spirit:name – Name of the register
spirit:addressOffset – Address offset
spirit:size – Size of the register
The register input in IP-XACT is represented as follows:

<spirit:register>
<spirit:name>ureg0</spirit:name>
<spirit:addressOffset>0</spirit:addressOffset>
<spirit:reset>
<spirit:mask>0xffffffff</spirit:mask>
</spirit:reset>
<spirit:field>
<spirit:name>destination</spirit:name>
</spirit:field>
……
……
</spirit:register>
With this IP-XACT input, the register class is built in thecdns_uvmreg_rdb.sv file. The configuration
of register and its fields is stored in cdns_uvmreg_config.dat file.
Register class generated is:
class ureg0_t extends cdns_uvm_reg;

ùvm_object_utils(ureg0_t)
rand uvm_reg_field destination;
rand uvm_reg_field frame_kind;
rand uvm_reg_field rsvd;
virtual function void build();

. . .
endfunction
function new(input string name="ureg0_t");
super.new(name, 32, UVM_NO_COVERAGE);
endfunction
endclass
And the register configuration is stored in the configuration file.
Every register class generated automatically is extended from thecdns_uvm_reg virtual class,
as it contains certain utility functions and pure virtual build() function. This cdns_uvm_reg
virtual class is extended from the uvm_reg class.

Memories
In IP-XACT, input for memories are represented fromspirit:addressBlock with spirit:usage value
equal to "memory." The memory configuration is defined as follows: name of the memory using
spirit:name, address offset using spirit:baseAddress, total number of memory locations using
spirit:range, width of each memory location using spirit:width and access from spirit:access.
The memory input in IP-XACT is represented as follows:
<spirit:name>mem</spirit:name>
<spirit:range>8</spirit:range>
<spirit:usage>memory</spirit:usage>
<spirit:volatile>false</spirit:volatile>
From this IP-XACT input, the memory class is generated in thecdns_uvmreg_rdb.sv file which also
includes the memory configuration.
The memory configuration is not stored in config file cdns_uvmreg_config.dat .
The code generated is as follows:
class mem_t extends uvm_mem;

ùvm_object_utils(mem_t)
function new(input string name="mem");
super.new(name, ÙVM_REG_ADDR_WIDTH'h8, 64, "RW", UVM_NO_COVERAGE);
endfunction
endclass
Register Files
In IP-XACT input, the register files are defined fromspirit:registerFile. The register file contains
registers and register files. Register files can have deep hierarchy of register file inside register file.
The register filename is from spirit:name and address offset from spirit:adressOffset. The
register file input in IP-XACT is represented as follows:

<spirit:registerFile>
<spirit:name>reg_file_level2</spirit:name>
<spirit:range>4</spirit:range>
<spirit:register>
. . .
. . .
</spirit:registerFile>
From this IP-XACT input, the register file class is generated incdns_uvmreg_rdb.sv, and the
configuration of the register file is stored in cdns_uvmreg_config.dat file. The register file class is
generated as follows:
class reg_file_level2_t extends uvm_reg_file;

ùvm_object_utils(reg_file_level2_t)
rand T_ureg4_5 ureg4;
uvm_reg_map default_map;
. . .
endfunction
. . .
endclass
The register file configuration is stored in the cdns_uvmreg_config.dat file.
Blocks and Sub-Blocks

The sub-blocks in the UVM register model hierarchy are represented usingspirit:addressBlock in
IP-XACT input. The name of the sub-block, the default width of the register inside the block, and
the base address are represented in IP-XACT input in the respective tags of the
spirit:addressBlock element.
The sub-blocks input in IP-XACT is represented as follows:
<spirit:name>rfile0</spirit:name>
<spirit:register>
. . .
</ spirit:register >
. . . .
. . .

From this IP-XACT input, reg_verifier generates the uvm_reg_block class inside
cdns_uvmreg_rdb.sv and the configuration of the sub-block inside cdns_uvmreg_config.dat .
The name generated for a given sub-block contains a concatenation of the names of the
blocks in the given hierarchy, starting with the top block. For example, for the following
hierarchy:
top_blk
sub_block1
sub_block11
sub_block2
The name generated for sub_block11 would be top_blk_sub_block1_sub_block11. The name

generated for sub_block2 would be top_blk_sub_block2.
For example, assuming that top_tb is the name of the top component in the example in this
section, then the sub-block rfile0 would have the name top_tb_rfile0 when it is
instantiated.
The sub-block class generated is as follows.
class T_rfile0_2 extends uvm_reg_block;

ùvm_object_utils(T_rfile0_2)
rand T_reg_file_3 reg_file;
. . .
reg_file.default_map.add_parent_map(default_map,'h3C);
default_map.set_submap_offset(reg_file.default_map, 'h3C);
endfunction
function new(input string name="rfile0");
super.new(name, UVM_NO_COVERAGE);
endfunction
endclass
lock_model() needs to be called manually. This enables performance of other tasks

manually, and modifications, before the model is matched to an immutable state and the
configuration of sub blocks is stored in cdns_uvmreg_config.dat file.
The configuration for sub-blocks is same as for the register files in the configuration file.
The top level block in UVM register model is generated from thespirit:component in IP-XACT.
And the map inside the top level is created from spirit:memoryMap. For the top-level block, input

IP-XACT is represented as:
<spirit:component …… . . . . .. >
. . . . .
<spirit:name>APB_SUBSYTEM_regs</spirit:name>
<spirit:version>1.4</spirit:version>
<spirit:memoryMaps>
<spirit:memoryMap>
<spirit:name>mmap0</spirit:name>
. . . .
. . .
</spirit:component>
From this IP-XACT input, the top-level block class is created which instantiates all the sub-blocks
inside the top-level block class in cdns_uvmreg_rdb.sv file. The code for the top-level block class is
as follows:
class APB_SUBSYTEM_regs_t extends uvm_reg_block;

ùvm_object_utils(APB_SUBSYTEM_regs_t)
uvm_reg_map mmap0;
rand T_mem_25 mem;
rand T_rfile0_2 rfile0;
. . . .
set_hdl_path_root("tb_top"); //Apply hdl_paths
apply_hdl_paths(this);
endfunction
function new(input string name="APB_SUBSYTEM_regs_t");
super.new(name, UVM_NO_COVERAGE);
endfunction
endclass
Cadence IP-XACT Vendor Extensions for

Register Verifier
The IP-XACT standard IEEE 1685-2009 describes an XML grammar for documents describing HW
design entities. The standard allows vendor-specific extensions in the XML document.
Vendors can define their own extensions following their own grammar. IP-XACT does not put any
restrictions on the child elements.
Vendor extensions must occur in the following container in an IP-XACT document:

Example
<spirit:component>
<spirit:vendorExtensions>

</spirit:vendorExtensions>
</spirit:component>
NOTE: This container can contain elements of type: xml:any, cadence:extensions

Cadence defines a set of IP-XACT vendor extensions to be used in the Register Verifier flow.
The extensions allow annotation of, for example, component memory map or register elements
with additional information that allow the generation of vr_ad or UVM_REG memory map source
code (e/SV).
This section contains the following subsections related to Cadence IP-XACT vendor extensions for
Register Verifier:
Supported Input Documents
Supported Locations in IP-XACT File
Requirements
Vendor Extension Container
Field Data
Memory Map, Register and Address Block Description
General Attributes
Endianess
Register Reset Value Specification
Define a "FIFO-Style" Register
Custom Register Access Model
Custom Access Policies for Specific Register Fields
Verification Properties
Define Coverage Collection Mode

Model User Defined Register Access Behavior

Add Code to Generated Code of VE Register or Address Block
NOTE: The section Custom Access Policies for Specific Register Fields describes how users can
create a custom access policy for a specific register. This section, in other words, is not a vendor
extension supplied by Cadence, but rather a custom extension that you can add manually if you
have the need for it.
Supported Input Documents

Register Verifier supports input documents adhering to the supported IP-XACT version (to see
which versions of IP-XACT are supported, see Currently Supported IP-XACT Versions“). Input
documents are validated by Register Verifier to ensure syntactic and semantic compliance with the
relevant standards. Validation can be performed also outside of Register Verifier using standard
XML validation tools (inside eclipse, xmllint or similar).
NOTE: XML document validation requires direct access to the schema URLs so that the validation
tool can download and use the referenced schemas. If the URL is not accessible (for example, due
to network issues or security considerations), an offline validation can be performed against the
schema files from the installation.
The following is example of a requested offline validation, using xmllint for the two namespaces
spirit and the vendor extensions. (Though the example ended in failure, it nevertheless shows the
flow and intent of offline validation.)

myself@vl-myself[none]~/src/ccr/1402540/ovm_switch_8$ xmllint --noout --schema

`xmroot`/tools/tti/lib/xsd/www.spiritconsortium.org/XMLSchema/SPIRIT/1685-2009/index.xsd
`xmroot`/tools/tti/examples/reg*/*xml
/grid/avs/install/xcelium/16.11/tools/tti/examples/reg_verifier/ipxact_example.xml validates
myself@vl-myself[none]~/src/ccr/1402540/ovm_switch_8$ xmllint --noout --schema
`xmroot`/tools/tti/lib/xsd/www.cadence.com/SPIRIT/1685-
2009/vendorExtensions/cadenceSpiritVendorExtensions.xsd `xmroot`/tools/tti/examples/reg*/*xml
/grid/avs/install/xcelium/16.11/tools/tti/examples/reg_verifier/ipxact_example.xml:67: element
resetValue: Schemas validity error : Element
'{http://www.cadence.com/SPIRIT/1685-2009/vendorExtensions}resetValue', attribute
'{http://www.cadence.com/SPIRIT/1685-2009/vendorExtensions}value': The attribute
'{http://www.cadence.com/SPIRIT/1685-2009/vendorExtensions}value' is not allowed.
'{http://www.cadence.com/SPIRIT/1685-2009/vendorExtensions}resetValue', attribute
'{http://www.cadence.com/SPIRIT/1685-2009/vendorExtensions}kind': The attribute
'{http://www.cadence.com/SPIRIT/1685-2009/vendorExtensions}kind' is not allowed.
'{http://www.cadence.com/SPIRIT/1685-2009/vendorExtensions}resetValue': The attribute
'{http://www.cadence.com/SPIRIT/1685-2009/vendorExtensions}cause' is required but missing.
resetValue: Schemas validity error : Element '{http://www.cadence.com/SPIRIT/1685-
2009/vendorExtensions}resetValue': Missing child element(s). Expected is (
{http://www.cadence.com/SPIRIT/1685-2009/vendorExtensions}value ).
/grid/avs/install/xcelium/16.11/tools/tti/examples/reg_verifier/ipxact_example.xml fails to
validate
myself@vl-myself[none]~/src/ccr/1402540/ovm_switch_8$
Supported Locations in IP-XACT File

The IP-XACT standard allows vendor extension in numerous places in an IP-XACT document. The
application flow analyzes vendor extensions in the following standard IP-XACT elements:
Register [spirit:register]
Register field [spirit:field]
Local memory map [spirit:localMemoryMap]
Memory map [spirit:memoryMap]
Alternative memory map [spirit:memoryRemap]
Address block [spirit:addressBlock]
Details on supported extensions for each IP-XACT element are described in the following sections.

Requirements
The Cadence vendor extension grammar includes type definitions from the following non-Cadence
grammars:
IP-XACT grammar, namespace
[http://www.spiritconsortium.org/XMLSchema/SPIRIT/1685-2009]
Therefore a complete grammar-based check on an IP-XACT file with vendor extensions will require
access to the following grammar location:
http://www.spiritconsortium.org/XMLSchema/SPIRIT/1685-2009/index.xsd.
Vendor Extension Container

Any "Register Verifier" vendor extensions must always be embedded in a top level extension
container.
Example
<cadence:extensions>
<cadence:xPolicy cadence:classname=”my_policy”/
</cadence:extensions>
HDL Information
The user can add HDL hierarchy information. The topology provided by the IP-XACT
component/instance hierarchy may not be the exact hierarchy of register or address blocks. This
property allows the user to specify the HDL representation of such elements. Defining HDL path for
a slice of e.g. a register can be done by an optional field data parent.

Example
<cadence:hdlAccess cadence:path="dut.reg1"/>
<cadence:hdlAccess cadence:path="clkdomain1.reg1" cadence:domain="GATELEVEL"/>
NOTE: This container can contain elements of type: cadence:fieldData.
Field Data
The user can specify a slice of a register, register field or address block using this construct.
Example
<cadence:hdlAccess cadence:path="top.dut.reg2_slice0_4">
<cadence:fieldData cadence:bitOffset="0x0" cadence:size="5" />
</cadence:hdlAccess>

Memory Map, Register and Address Block Description
General Attributes
The user can add an attribute value to some elements.
Example
<cadence:attribute cadence:name="aliasName">newName</cadence:attribute>
Endianess
The user can specify the endianess of a memory map or address block in case it cannot be
detected based on the endianess of an associated bus interface.
Example
<cadence:endianess>big</cadence:endianess>

Register Reset Value Specification

The user may need to specify various reset values, depending on the type of reset (e.g., SW vs.
HW reset). IP-XACT supports only one reset value.
The reset value container includes two elements:
Example
<cadence:resetValue cadence:cause="POWER_ON">
<cadence:value>0x11</cadence:value>
<cadence:mask>0xff</cadence:mask>
</cadence:resetValue>
Define a "FIFO-Style" Register

A register access may actually be implemented as a FIFO access. Adding this construct to a
register vendor extension allows the user to define the depth of the FIFO for such a special
register.

Example
<cadence:isFifoWithDepth>5</cadence:isFifoWithDepth>
Custom Register Access Model

A given register may not be accessed directly on a given address. In such case the user can define
the access behavior with the construct below.
The custom register definition may be completed by a set of property elements inside the customer
register container.
Example: Model an Indirectly Accessed Register

The application flow currently supports modeling of indirect register access through this construct.
Unlike normal access where address and data come directly over the bus, in indirect access the
address of the access is stored with a first bus transfer in a register and then the data is
read/written by accessing the data register. To access idx1[5] (the 6th register of the register array
idx1) one would need to write a 5 to the addressing reg reg1 and then access the contents of
idx1[5] via read/write operations to the (data) register. The data register is the current register
tagged with the cadence:type=”indirectAccess” vendor extension.
In this example, the user defines the address register (addrReg property) and associated (acess)

field (aregField).
<cadence:customRegister cadence:type="indirectAccess">
<cadence:property cadence:name="addrReg" cadence:value="reg1"/>
<cadence:property cadence:name="aregField" cadence:value="idx1"/>
</cadence:customRegister>
Custom Access Policies for Specific Register Fields

The user can create a custom access policy for a specific register field. To do so, the user must:
Manually add the XML for the custom policy.
Provide a custom policy package that extends uvm_reg_field to create a new class for the
given field.
Access Policy XML That Must Be Added to the IP-XACT Document

Following is an example of the XML that must be added to the IP-XACT document, in the standard
IP-XACT <spirit:field> element.
NOTE: You must provide a fully qualified type name for the field for which you are creating the
custom access policy (in this case, my_access_field).
<spirit:field>
<spirit:name>rsvd</spirit:name>
<spirit:access>read-only</spirit:access>
<cadence:accessPolicy type="xPolicy_pkg:my_access_field" >

<cadence:attribute
cadence:name="NO_REG_ACCESS_TEST" cadence:type="bit">1
</cadence:attribute>
</cadence:accessPolicy>
</cadence:extensions
</spirit:field>

The Custom Policy Package

You also need to provide a custom policy package that contains a class derived from
uvm_reg_field, or a stand-alone class file derived from uvm_reg_field.
The following is an example of such a package:
package xPolicy_pkg;
import uvm_pkg::*;
ìnclude "uvm_macros.svh"
import cdns_uvmreg_utils_pkg::*;
bit no_factory = 0;
//////////////////////////////////////////////////////
// Custom xPolicy
//////////////////////////////////////////////////////
class my_access_field extends uvm_reg_field;
ùvm_object_utils(my_access_field)
local bit is_locked = 0;
local static bit m_wres = define_access("my_access_field");
function new(string name = "my_access_field");
super.new(name);
endfunction
virtual task pre_write(uvm_reg_item rw);
// Prevent the write if the reg is_locked
// please note that the comparison of the value needs more logic
if (is_locked && rw.value[0]==value && rw.value.size()==1) is_locked=0;
else if(!is_locked) is_locked=1;
else rw.value = '{value};
endtask
virtual function void reset(string kind = "HARD");
super.reset(kind);
is_locked=0;
endfunction
endclass
endpackage
You must also add the custom policy declaration to the compile flow before the register data base
so that the data can refer to the custom field type. For example:
xrun -uvmhome default ./xPolicy_pkg.sv ./cdns_uvmreg_utils_pkg.sv \
./cdns_uvmreg_rdb.sv ./quicktest.sv -vclass_ext +UVM_TESTNAME=qt_test

Verification Properties
Define Coverage Collection Mode

The user can define whether coverage on register access shall be collected, and which kind of
coverage shall be collected. If this construct is missing on a register, no coverage will be collected
at all.
In case of a specification inside a register file, the coverage directive will be applied to all enclosed
register files and registers.
Example
<cadence:collectCoverage Cadence:accessMode="READ"/>
Model User Defined Register Access Behavior

UVM defines an enumerated list of register access modes. They can be modeled using standard
IP-XACT elements as shown in “Modeling Standard UVM Register Access Modes” on page 1-40.
In some cases, registers are implemented with user defined access modes, e.g., "clear register
field after 3 successive reads".
Such information can be attached to a register or register field using the following construct. It
requires the standard UVM access mode to be decoded as either UM (read-able) or UM (write-
only). In any other case the vendor extension is ignored.

Example
<spirit:field>
<spirit:name>Field1</spirit:name>
<spirit:modifiedWriteValue>modify</spirit:modifiedWriteValue>
<spirit:readAction>modify</spirit:readAction>
<cadence:accessBehavior>VERY_SPECIAL</cadence:accessBehavior>
</spirit:field>
The example shows a register modeled with a UVM access mode UM (read-able). It shall behave
according to a user defined scheme called VERY_SPECIAL. It is the user's responsibility to make
sure that the register access behavior VERY_SPECIAL is encoded in the VE, because Register
Verifier cannot implement the required update/checking code; it does not follow standard
update/checking modes.
Add Code to Generated Code of VE Register or Address Block

The user can specify raw code in the target language (SV, e) that is added to the generated VE
code.
Example

<cadence:xPolicy classname=”my_policy”/>
Optimization in Register Verifier

Compile and elaboration turnaround is mostly affected by the number of types compiled into a
snapshot, so it is important to reduce the number of involved types as much as possible. It is
therefore especially important to check for and control generation where either single registers
might end up as their own types, or where there might be an enormous number of types (for
example, 10,000 or more).
Register Verifier offers an automatic optimization which folds all equivalent entities into the same
type, thus reducing the overall effort. It also optimizes the register model by automatically checking
each component configuration. If Register Verifier determines same configuration of the two or
more components, it automatically creates a single type name for all the components having same
configuration.
The facility is also controlled by spirit:typeIdentifier as follows:
If the optional argument spirit:typeIdentifier is provided, it will force reg_verifier to
generate the matching type declaration using the text of spirit:typeIdentifier as the name
of the type. Providing the same spirit:typeIdentifier name in multiple places will result in
only one type declaration which is then used multiple times.
If the spirit:typeIdentifier is not provided, then reg_verifier will auto-generate a type
name. Because every entity with the same structure will result in the same type name if the
spirit:typeIdentifier is not provided, reg_verifier will only generate a single declaration for
each structural entity.
Modeling Standard UVM Register Access

Modes
IP-XACT supports programmers access right <spirit:access/> definition on the following entities:
Memory block data
Register definition group

Register field
There is some 'inheritance', meaning that a register field inherits the access right from its enclosing
container if (a) the register field has no access rights set and (b) the enclosing container has it set.
IP-XACT defines three more child entities on a register field that are used to determine access right
or "behavior".
<spirit:modifiedWriteValue/>
<spirit:readAction/>
<spirit:testable/>
The combination the register access value and those three child elements on a register field allow
modeling of UVM register access modes as follows. Within the table the value "unspecified" refers
to a situation where the property is not provided in the IP-XACT file.
NOTE: The following table is relevant for UVM e only. For details relevant to UVM SV, see the
tables in Section 5.5.1.4 “IP-XACT Field Access Mapping” in the Accellera Universal Verification
Methodology (UVM) User’s Guide.
For description on the UVM access modes, see the description ofset_access in the Accellera
Universal Verification Methodology (UVM) Class Reference.

Multiple Invocation in Register Verifier

Register Verifier supports the multi-invocation feature in which multiple-generated files from various
IP xmls can be compiled and simulated together from the same or different directories.
Consider the given examples of generating multiple invocation using -multi_invocation :
reg_verifier -dut_name APB_SUBSYSTEM -top ./top_comp.xml -domain uvmreg -pkg my_pkg1 -
out_file my_files_1 -multi_invocation
reg_verifier -dut_name AHB_SUBSYSTEM -top ./top_comp.xml -domain uvmreg -pkg my_pkg2 -
out_file my_files_2 -multi_invocation
where two different packages, my_pkg1 and my_pkg2 , can be complied and simulated together.
To generate multiple invocation using -multi_invocation , you need to:
Compile the centrally
located cdns_uvmreg_utils_pkg in <xcelium_install>/sia/lib/sv/cdn_reg/utils/cdns_uvmreg
_utils_pkg.sv file.
For every database/snapshot you create and want to use in the uvm_test or uvm_env classes,
add the call to cdns_uvmreg_utils_pkg::setup() before registering
(register_model/top_level_block).
To call the setup function, you need to provide the following details:
cdns_uvmreg_utils_pkg::setup("<path_to_config_files>", <package_name>::factory, "
<prefix_name_of_config_files>");
where,
<path_to_config_files> - Path to the generated config files(*.dat)
<package_name> - Package name generated in the rdb file that contains the register model
classes
<prefix_name_of_config_files> - Prefix name of the generated files. This name is the same
as that you use with the reg_verifier option “-out_file” at the time of generation.
Consider the given example of the testbench where setup function is called:

cdns_uvmreg_utils_pkg::setup("./",my_pkg1::factory,"my_files_1");
model0 = my_pkg1::APB_SUBSYTEM_regs_uvm_reg_ex_version_1_4::type_id::create
("model0",this);
model0.build();
model0.lock_model();
cdns_uvmreg_utils_pkg::setup("./",my_pkg2::factory,"my_files_2");
model1 = my_pkg2::AHB_SUBSYTEM_regs_uvm_reg_ex_version_1_4::type_id::create
("model1",this);
model1.build();
model1.lock_model();
.....
You can also have a look at the example by generating the test using the-quicktest option along
with the -multi_invocation option.
Limitations:
Name collisions:
For multi invocation, you need to make sure of the name collisions of register model classes
by checking the input of reg_verifier .
You need to ensure that the type names are different. If they are not different, you need to
generate the multi-invocation code with the -no_uvm_factory reg_verifier option. This does
not generate any errors at the time of compilation and simulation.
Migrating from iregGen to Register Verifier

NOTE: iregGen is under deprecation, and support will be removed in a future version. It is
recommended that you migrate to Register Verifier.
Location
The location of Register Verifier (“reg_verifier”) is:
<Xcelium_install_dir>/tools/tti/bin/reg_verifier. The old register generator iregGen is also
present in the same old location and will be continuing to ship until all its features are in Register
Verifier.

Input XML
Register Verifier supports 1.2, 1685-2009, 1.4 and 1.5 IP-XACT input formats. Note that the input
XML is always validated whenever it is given to Register Verifier, whereas input validation is done
separately (if requested) in iregGen. In the input XML, the schema location is changed slightly for
Register Verifier from that for iregGen. The component root node for Register Verifier is:
<spirit:component
xmlns:spirit="http://www.spiritconsortium.org/XMLSchema/SPIRIT/1685-2009"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:cadence="http://www.cadence.com/SPIRIT/1685-2009/vendorExtensions"
xsi:schemaLocation="http://www.spiritconsortium.org/XMLSchema/SPIRIT/1685-2009
http://www.spiritconsortium.org/XMLSchema/SPIRIT/1685-2009/index.xsd">
Register Verifier always validates the XML using the above component root node, whenever it is
executed. So the user must always ensure that the header is correct.
Vendor-Extensions
Vendor extensions have been encapsulated in a "cadence:extensions" container in order to check
it. Previously in iregGen vendor-extensions format was:
<vendorExtensions:hdl_path>dut</vendorExtensions:hdl_path>
In Register Verifier the format is changed to:
<cadence:hdlAccess>dut</cadence: hdlAccess>
Comparing vendor-extensions of Register Verifier to iregGen, one of the following scenarios might
happen:
iregGen had a vendor extension whereas there is native support in IP-XACT. For this
scenario, in Register Verifier, the vendor extension has been removed and user currently
needs to migrate to IP-XACT native. Such scenarios are:
Type Names
In iregGen, type names of the components were supported using "vendorExtensions:type".

But in Register Verifier, this is supported as "spirit:typeIdentifier" which is already a part of an

IP-XACT grammar, and it changes the type name of the component which contains this tag. It
is supported in spirit:register, spirit:registerFile ,spirit:addressBlock and memories containers
of the IP-XACT.
Arrays
In iregGen, the arrays were supported using "vendorExtensions:array". But in Register
Verifier, there is an equivalent to that in IP-XACT, which is "spirit:dim". Based on the numeric
value, it will create array for the IP-XACT component where used. It is supported in
spirit:register, spirit:registerFile containers of the IP-XACT. (See also Defining Single- and
Multi-Dimensional Arrays with IP-XACT“.)
For those iregGen vendor-extensions which have no native support in IP-XACT, those vendor-
extension are renamed and moved into new cadence.extensions container. The vendor-extensions
supported in Register Verifier and their comparison to iregGen vendor-extensions are shown in the
following table:
S.No. Vendor- reg_verifier iregGen Container IP-XACT

extensions/Features Element
1 HDL Information hdlAccess hdl_path spirit:register,

spirit:field,
spirit:addressBlock
2 Endianness endianess endianess spirit:addressBlock.

memoryMap
3 Coverage collectCoverage collect_coverage spirit:field,

spirit:register
memories
4 Reset Values resetValue resets spirit:register
For details on Register Verifier vendor-extensions, see Cadence IP-XACT Vendor Extensions for
Register Verifier.
There are other vendor-extensions which are not yet supported in Register Verifier but which were
supported in iregGen. They are rawConstraint, rawCode, is_fifo_with_depth, indirect_addr_reg,
indirect_areg_reg, constraint, attribute. These vendor-extensions will have a new name when
supported in Register Verifier.

Commmand-Line
Once the input XML is ready for Register Verifier, the next step is that user should identify the top
level component name in the input XML that is to be mentioned in command-line.
There are many options in Register Verifier for generating a register model (see Running Register
Verifier and the Register Verifier Demo).
Some options for generating are mandatory:
"-top" - Input XML file name.
"-dut_name" - Top level component name.
"-domain uvmreg" - For generating UVM register model.
Using these options, the user can generate a UVM register model.
For example:
reg_verifier -top my_env.xml -domain uvmreg -dut_name apb_system -quicktest
Generation is internally divided. First, the input XML is validated using XML schema. Then, the
XML data is parsed and the register model is generated in an output directory (default:
"reg_verifier_dir"), as follows: The "uvmreg" directory is automatically created within the output
directory, and the register model files are generated in the uvmreg directory.
Output
The generated output contains following files:
reg_verifier_dir/uvmreg/cdns_uvmreg_config.dat . Configuration file listing the configuration
of all Register Model components.
reg_verifier_dir/uvmreg/cdns_uvmreg_hdlpaths.dat . All hdl_path definitions of all Register
Model components.
reg_verifier_dir/uvmreg/cdns_uvmreg_rdb.sv . All classes of the Register model components
generated in Register Model file.
reg_verifier_dir/uvmreg/cdns_uvmreg_utils_pkg.sv. Package file containing all utilization
functions and structures.
To test the generated files, the user can generate the quicktest as follows:
1. Adding "-quicktest" option in the reg_verifier command-line option.

2. Go to the <output_directory>/uvmreg directory.

3. Use Makefile to execute the quicktest (in the command line, do, ‘make').

mltypemap Utility: Automatic Generation of Data Types
mltypemap Utility: Automatic Generation

of Data Types
This chapter describes a utility called mltypemap. This utility can be used to generate data types
in a target language based on data types in a source language. These data types can then be used
as data types in UVM-ML OA transactions using TLM1 and TLM2 ports.
Using mltypemap lets you avoid manually coding type definitions, which can be complex, tedious,
and error prone.
The supported source languages are SystemVerilog, e, and SystemC. The supported target
languages are SystemVerilog, e, and SystemC.
This chapter contains the following:
mltypemap Examples
Invoking mltypemap
Mapping Types with mltypemap
Configuring mltypemap
mltypemap Limitations for this Release
mltypemap Examples
The following sections contain simple, runnable examples for mltypemap. The examples are
divided into sections based on the three source languages (e, SystemVerilog, or SystemC) and
show how to convert to each of the other two:
Mapping from e
Mapping from e to SystemVerilog
Mapping from e to SystemC
Mapping from SystemVerilog
Mapping from SystemVerilog to e

Mapping from SystemVerilog to SystemC

Mapping from SystemC
Mapping SystemC to e
Mapping SystemC to SystemVerilog
Mapping from e
This section shows how to convert frome to either SystemVerilog or SystemC, using three files:
run_mltypemap.sh— Invokes xrun with the mltypemap option, and specifies a Tcl run file
and e input file
test.e — The e source file. Its types will be mapped to either SystemVerilog or SystemC.
do.tcl — The configuration file, specific for each output language.
Configures mltypemap using the configuration commands described in Configuring
mltypemap
Invokes the mapping process using the maptypes command described inInvoking
mltypemap
The mapped type is msg. It is mapped along with its two subtypes big_msg and small_msg.
File: run_mltypemap.sh
xrun \
-mltypemap_input do.tcl \
test.e

File: test.e
<'
package dt;
type kind_t : [GOOD, BAD];
struct msg {
kind : kind_t;
!top_unit : any_unit; // pointer to unit - do not map
};
struct big_msg like msg {
private counter : int; // note: private fields are not mapped by default
data : list of byte;
};
struct small_msg like msg {

data : int;
};
'>
Mapping from e to SystemVerilog
File: do.tcl
# This will generate UVM code

# to generate OVM code add the configuration command
# configure_code -ovm
# change the scope from dt to sv_dt

configure_scope -scope e:dt -to_scope sv_dt
# skip field top_unit since it cannot be mapped

configure_type -type e:dt::msg -skip_field top_unit
# change the enumerated items

configure_enum_item -type e:dt::kind_t -item GOOD -to_name MSG_GOOD;
configure_enum_item -type e:dt::kind_t -item BAD -to_name MSG_BAD;
# change all field names to be prefixed with m_

configure_field -type e:dt::* -field {/(.*)/} -to_name {m_$1}
# do the actual mapping
maptypes -from_type e:dt::msg -base_name sv_dt -to_lang sv

Output Files
The output of the xrun command for the SystemVerilog target language is three files, with base
name sv_dt:
sv_dt.svh—Contains the types definitions.

sv_dt_ser.sv—Contains serialization code for SV.
sv_dt_ser.e—Contains serialization configuration code for e.
Mapping from e to SystemC
File: do.tcl
# This will generate UVM code
# change the scope from dt to sc_dt

configure_scope -scope e:dt -to_scope sc_dt
# skip field top_unit since it cannot be mapped

configure_type -type e:dt::msg -skip_field top_unit
# change the enumerated items

configure_enum_item -type e:dt::kind_t -item GOOD -to_name MSG_GOOD;
configure_enum_item -type e:dt::kind_t -item BAD -to_name MSG_BAD;
# change all field names to be prefixed with m_
configure_field -type e:dt::* -field {/(.*)/} -to_name {m_$1}

maptypes -from_type e:dt::msg -base_name sc_dt -to_lang sc
Output Files
The output of the xrun command for the SystemC target language is three files, with base
name sc_dt:
sc_dt.h—Contains the types definitions in SC.
sc_dt.cpp—Contains implementation of UVM member functions for the mapped types.
sc_dt_ser.e—Contains serialization configuration code for e.

Mapping from SystemVerilog

This section shows how to convert from SystemVerilog toe or SystemC, using three files:
run_mltypemap.sh — Invokes xrun with the mltypemap option, and specifies a Tcl run file
and SV input file.
test.svh — The SystemVerilog source file.
do.tcl — The configuration file, specific for each output language.
Configures mltypemap using the configuration commands described in Configuring
mltypemap.
Invokes the mapping process using the maptypes command described in“Invoking
mltypemap” on page 2-10.
The mapped type is msg. It is mapped a long with the type data, which is used for one of its fields.
xrun \
-uvm \
test.svh

File: test.svh
ìfndef TEST_SVH
`define TEST_SVH
package dt;
import uvm_pkg::*;
class data extends uvm_object;
bit [63:0] addr;
byte bytes[];
int do_not_map_me;
ùvm_object_utils_begin(data)
ùvm_field_int(addr,UVM_ALL_ON)
ùvm_field_array_int(bytes,UVM_ALL_ON)
ùvm_field_int(do_not_map_me,UVM_ALL_ON)
ùvm_object_utils_end
function new (string name="data");
super.new(name);
endfunction
endclass : data
class msg extends uvm_object;

string name;
data d;
ùvm_object_utils_begin(msg)
ùvm_field_string(name,UVM_ALL_ON)
ùvm_field_object(d, UVM_ALL_ON)
function new (string name="msg");
super.new(name);
endfunction
endclass : msg
endpackage : dt
èndif

Mapping from SystemVerilog to e
File: do.tcl
# map the scope dt to sn_dt

configure_scope -scope sv:dt -to_scope sn_dt
# skip the field do_not_map_me
configure_type -type sv:dt::data -skip_field do_not_map_me
# map the field msg.d as generatable in Specman
configure_field -type sv:dt::msg -field d -rand
# map the types
maptypes -from_type sv:dt::msg -base_name sn_dt -to_lang e
Output Files
The output of the xrun command for the e target language is five files, with base name sn_dt:
sn_dt_top_file.e—Top file, imports all the e generated files.

sn_dt_vr_dt.e—Contains the mapped types of package vr_dt. Whene is the target
language, there is one file per package.
sn_dt.e—Imports all the mapped files (created per-package).
sn_dt_ser.e—Serialization configuration for e.
sn_dt_ser.sv—Contains serialization code for SV.
Mapping from SystemVerilog to SystemC
File: do.tcl
# map the scope dt to sc_dt
configure_scope -scope sv:dt -to_scope sc_dt
# skip the field do_not_map_me

configure_type -type sv:dt::data -skip_field do_not_map_me
# map the types

maptypes -from_type sv:dt::msg -base_name sc_dt -to_lang sc

Output Files
The output of the xrun command for the SystemC target language is three files, with base
name sc_dt:
sc_dt.h—Definitions of mapped types in SC.
sc_dt.cpp—Implemenation of UVM member methods in SC.
sc_dt_ser.sv—Contains serialization code for SV.
Mapping from SystemC

This section shows how to convert from SystemC to SystemVerilog ore, using four files:
run_mltypemap.sh — Invokes xrun with the mltypemap option, and specifies a Tcl run file
and SV input file.
test.cpp and test.h — The SystemC source files.
do.tcl — The configuration file, specific for each output language:
Configures mltypemap using the configuration commands described inConfiguring
mltypemap.
Invokes the mapping process using the maptypes command described in Invoking
mltypemap.
The mapped type is msg. It is mapped along with the type data, which is used for one of its fields.
In these examples, mltypemap maps the type packet defined in the two source
files: test.cpp and test.h.
xrun \
-uvm \
test.cpp \
-sysc \
-compile

File: test.cpp
#include "test.h"
namespace dt {
packet::packet() {}
packet::~packet() {}
void packet::do_print(ostream& os) const {
os << "packet = " << name << endl;
}
void packet::do_pack(uvm_packer& p) const {
p << addr << name << data;
}
void packet::do_unpack(uvm_packer& p) {
p >> addr;
p >> name;
p >> data;
}
void packet::do_copy(const uvm_object* rhs) {
const packet* drhs = DCAST<const packet*>(rhs);
if (!drhs) { cerr << "ERROR in do_copy" << endl; return; }
addr = drhs->addr;
name = drhs->name;
data = drhs->data;
}
bool packet::do_compare(const uvm_object* rhs) const {
const packet* drhs = DCAST<const packet*>(rhs);
if (!drhs) { cerr << "ERROR in do_compare" << endl; return true; }
return
addr == drhs->addr &&
name == drhs->name &&
data == drhs->data;
}
}

File: test.h
#ifndef PACKET_H
#define PACKET_H
#include "ml_uvm.h"
using namespace uvm;
namespace dt {
class packet : public uvm_object {
public:
// use macro to generate necessary methods that factory needs
UVM_OBJECT_UTILS(packet)
packet();
virtual ~packet();
// implement mandatory pure virtual methods
virtual void do_print(ostream& os) const;
virtual void do_pack(uvm_packer& p) const;
virtual void do_unpack(uvm_packer& p);
virtual void do_copy(const uvm_object* rhs);
virtual bool do_compare(const uvm_object* rhs) const;
public:
sc_int<64> addr;
std::string name;
std::vector<sc_int<8> > data;
};
// register the data object with the factory
UVM_OBJECT_REGISTER(packet)
}; // namespace dt
#endif
Mapping SystemC to e
File: do.tcl
# configure the scope
configure_scope -scope sc:dt -to_scope sn_dt

maptypes -from_type sc:dt::packet -base_name sn_dt -to_lang e
Output Files for e

The output of the xrun command for the e target language is four files, with base name sn_dt:

sn_dt_top_file.e—Top file, to import all the e generated files.

sn_dt_vr_dt.e—Contains the mapped types of package vr_dt. When e is the target
language, there is one file for package.
sn_dt.e—Import all the mapped files (created per-package).
sn_dt_ser.e—Serialization configuration for e.
Mapping SystemC to SystemVerilog
File: do.tcl
# configure the scope
configure_scope -scope sc:dt -to_scope sv_dt

maptypes -from_type sc:dt::packet -base_name sv_dt -to_lang sv
Output Files for SystemVerilog

The output of the xrun command for the SystemVerilog target language is two files, with base
name sv_dt:
sv_dt.svh—Contains definition of SV mapped types.
sv_dt_ser.sv—Serialization code for SV.
Invoking mltypemap
mltypemap is a TCL-based tool that is invoked from xrun. When you invoke mltypemap, you must
enter the appropriate mltypemap-related flags plus all the compilation flags necessary for xrun to
compile the files and elaborate the snapshot (in the case of SystemVerilog inputs).
When you invoke mltypemap, xrun performs the following steps:
1. Compile all the source files.
NOTE: When working with SystemC input, the input file must be a single CPP file and the
argument -sysc has to be given. More than one input file is currently not supported for

SystemC.
2. Elaborate the design (in case of SystemVerilog).
3. Invoke mltypemap and display its TCL prompt.
4. Abort.
This section contains the following information:
xrun Arguments for Invoking mltypemap
xrun Examples
xrun Arguments for Invoking mltypemap

Following are the xrun arguments for invoking mltypemap:
xrun -mltypemap_input input-file -mltypemap_tcl
xrun Arguments
Argument Description
-mltypemap_tcl Invokes mltypemap in interactive mode (displays its TCL prompt).
- Identifies the name of an input file that contains TCL commands for
mltypemap_input mltypemap. Typically this file contains mltypemap configuration
input-file commands and one or more mltypemap map commands.
xrun Examples
To invoke xrun with e files:
xrun -mltypemap_input do.tcl file.e
To invoke xrun with SV files:

xrun -mltypemap_input do.tcl test.svh
To invoke xrun with SystemC files:

xrun -mltypemap_input do.tcl types.cpp -sysc -compile

NOTE: Refer to the Xcelium Simulator Reference for information about xrun options such as -
compile and -sysc.
Mapping Types with mltypemap

You use the mltypemap TCL command maptypes to invoke the mapping process. In general, this
command should be called after the necessary configuration commands have been executed. The
configuration commands are described in Configuring mltypemap.
This section contains the following:
maptypes Command
Output Files Generated by maptypes
Output Files Generated for SystemVerilog
Output Files Generated for e
Output Files Generated for SystemC
Mapped Data Types
Mapping Scalar and Aggregate Data Types
Mapping Classes
Mapping a Field
Mapping e Structs and SystemVerilog Structs
SystemVerilog Adapter Configuration Generation
UVM Method Ports
Mapping SystemVerilog Structs to e Structs
Mapping e when Subtypes
Referencing when Subtypes in Configuration Commands
Mapping Enumerated Types
Example
Mapping Typedefs
Mapping SystemVerilog Queues, SystemC Vectors, and e Lists
Mapping SystemVerilog Queues to SystemC Vectors / e Lists

Mapping SystemC Vectors / e Lists to SystemVerilog Queues

Example
maptypes Command
Syntax
maptypes -to_lang lang -from_type type-name -base_name base-name
Syntax example
maptypes –to_lang sv –from_type e:ahb::ahb_packet –base_name ahb_datatypes

Parameters
Parameter Description
-to_lang The name of the target language. The accepted language names are:
lang
e (or sn)
sv
sc
The language names are case insensitive. This parameter is mandatory and can
be repeated.
NOTE: When types are mapped to two or more target languages, Cadence
recommends doing so in a single invocation.
-from_type The name of the source type. The type-name must be the full name (including
type-name package/namespace qualifiers) and must contain the language prefix (e, SV,
SC).
This parameter is mandatory and may repeat. Examples:
-from_type e:my_pkg::my_struct
-from_type sv:package1::my_data_item
- The base name for the output files. This parameter is mandatory.
base_name The base name can contain a directory path to a folder. For example:
base-name
-base_name my_types
-base_name my_dir/my_dt
Description
As described above, you use the mltypemap TCL command maptypes to invoke the mapping
process.
Note that the input to mltypemap must be a type defined inside a package, and, therefore, its name
must be qualified with the package name:
In e, all types that are not defined explicitly inside a package, are defined inside the package
“main”. To map such a type, the “main” qualifier has to be used (for example, -from_type
e:main::packet).

In SystemVerilog, only types defined inside a package are supported. Types defined inside a
module, or types defined inside the compilation scope are not supported.
In SystemC, types should be defined in namespace, or in the global namespace. Types
defined inside classes are currently not supported.
Example
The following command generates type definitions in SystemVerilog for the e type ahb_packet:
mltypemap> maptypes –from_type e:ahb::ahb_packet \

-to_lang sv \
-base_name ahb_datatypes
This command generates three

files: ahb_datatypes.svh , ahb_datatypes_ser.sv and ahb_datatypes_ser.sv. (see Output Files
Generated by maptypes).
Output Files Generated by maptypes

When the maptypes command is executed, mltypemap generates the following code:
Data type definition in the target language
Serialization code in the target language
Serialization code in the source language
Output Files Generated for SystemVerilog

If SystemVerilog is the target language, all type definitions are generated in a file calledbase-
name.svh.
In addition, serialization code is generated if SystemVerilog is the source or target language. The
serialization file name is base-name_ser.sv.
Output Files Generated for e

When e is the target language, a file is generated for each package (because, ine, each package
must be defined in a separate file). Therefore, the following files are generated:

base-name.e: a file importing all type definitions

base-name_package-name.e: a file containing the type definitions for each of the generated
packages.
base-name_top_file.e: created only when e is the target language, this file imports all other
files
In addition, serialization code is generated if e is the source or target language. The serialization
file name is base-name_ser.e.
Output Files Generated for SystemC

When SystemC is the target language, the following files are created:
base-name.h: definition of the generated files
base-name.cpp: implementation of the UVM methods of the generated classes
Limitation: No serialization code is generated to SystemC, because SystemC uses the default
UVM packing for ML serialization.
Mapped Data Types

By default, the scope of the target type is the same as the scope of the source type. Types defined
in global scope will be mapped to scope named global_scope . This can be configured using
the configure_scope and configure_type commands. See:
configure_scope Command
configure_type Command
Mapping Scalar and Aggregate Data Types

Table 2-1 describes how scalars are mapped. Table 2-2 describes how to map aggregate data
types.
Table 2-1 Mapping for Scalars
e SystemVerilog SystemC Comment
bit bit sc_uint<1>

uint(bits:1) bit sc_uint<1>
int(bits:1) bit signed sc_int<1>
byte byte unsigned sc_uint<8>
uint(bits:8) byte unsigned sc_int<8>
int(bits:8) byte sc_int<8>
uint(bits:16) shortint sc_int<16>

unsigned
int(bits:16) shortint sc_int<16>
int int int
uint int unsigned unsigned int
longint longint sc_int<64>
longuint longuint sc_uint<64>
uint(bits:64) longint sc_uint<64>

unsigned
int(bits:64) longint sc_int<64>
uint(bits:n) bit[n-1:0] sc_uint<n>

(for n <= 64)
sc_biguint<n>
(for n > 64)
sc_bv<n>
int(bits:n) bit signed [n- sc_int<n> (for

1:0] n <= 64)
sc_bigint<n>
(for n > 64)
bool bit bool

user-defined type user-defined user-defined e type is created only for scalars.

type type For compound types like classes,
Example:
e uses the original type because it
type Corresponding Corresponding
has no aliasing for structs.
bits8_t:int(bits:8); SV code: SC code:
typedef byte typedef
bit8_t; sc_int<8>
bit8_t
enumeration type enumeration enumeration See also Mapping Enumerated

type type Types.
Example:
type color:[RED, Corresponding Corresponding
GREEN,BLUE]; SV code: SC code:
typedef enum enum color
{RED = 0, {RED = 0,
GREEN = 1, GREEN = 1,
BLUE = 2} BLUE = 2};
color;
real real, shortreal, Not supported

realtime
NOTES:
Four-value scalars are not supported, and an error is given if a field on such a type is passed.
When the input language is SystemVerilog, mltypemap can be configured to map four-value
scalars as two-value scalars, the configuration can be done globally using configure_code -
lang sv -map_all_as_2value, or per field using configure_field option -map_as_2value . See
also configure_field Command and configure_code Command.
When mapping scalars of size 8,16,32, or 64 bits to SystemC, the mapping can be controlled
using configuration option -use_cpp_type or -use_sc_type . See also configure_field
Command.
Table 2-2 Mapping for Aggregate Data Types
e SystemVerilog SystemC

struct packed struct Not supported Supported only when mapping from
SV to e. When mapping from e to
struct unpacked struct Not supported
Not supported union Not supported
Not supported packed union Not supported
scalar modifier packed array sc scalar type

in the length of (sc_int<>,
Example:
$bits() sc_uint<>,
bit [31:0] [7:0]
sc_bigint<> etc')
Corresponding bytes;
in the length of
e code:
bytes:
$bits()
uint(bits:256); Corresponding
//32*8 SC code:
sc_biguint<256>
bytes;
Not supported unpacked array Not supported Mapping SC/SV static array is not
supported.
string string string
list of e type Dynamic arrays std::vector of sc

type
[size] list of e Static arrays std::vector of sc

type type[size]
Not supported Associative Not supported

arrays
Example:
int
assoc_int_wild
[*];

list of e type Queues std::vector of sc See also Mapping SystemVerilog

type Queues, SystemC Vectors, and e
Example:
Lists.
MyClass_c
q_class[$];
// queue of
MyClass_c,
unlimited size
struct class class See also Mapping Classes.
Not supported Semaphores Not supported

Example:
semaphore smphr
= new(1);
Not supported Mailboxes Not supported

Example:
mailbox hugebox
= new;
See comment See comment See comment Named events are ignored; no error
is generated.
Example:
event e;
Mapping Classes
A class is mapped by mapping all its fields. By default, the mapped fields are the public, non static
fields.
When a class is mapped, all its subtypes are mapped as well. Also, the parent classes of this class
are mapped. By default, the name of the mapped class is as the name of the source class.
You can change the default settings with the configure_type command (seeconfigure_type
Command).

Mapping a Field
A field is mapped into a corresponding field in the target language. The default name of the field is
its source name. The access level (private/local, protected or public) of the field is the same access
level as the source field.
By default, only public, non static fields are passed. The mapping of a field can be configured using
the configure_field command. (see configure_field Command).
When a non-public field is passed, you can specify the setter/getter methods for the source field, as
well as for the target field.
Limitation: Setters/getters are not supported in the current release.
Static Fields
By default, static fields are not mapped. Mapping of static fields is not supported, and a run-time
error is given if a static field is configured to be passed.
Randomization Modifier
“rand” or “randc” fields in SystemVerilog are mapped to a generated field ine. Generated fields
in e are mapped to “rand” field in SV.
UVM Field Properties (pack, print, and so on)

For each a class, a code is generated to support basic UVM functionality. In SystemVerilog this
code includes generating the appropriate UVM macro for each field, and in SystemC this code
includes generating the code for the UVM methods. By default, a field is part of each of the
operations. mltypemap lets you configure certain aspects of this by specifying if a field should be
packed, printed, or so on.
Mapping e Structs and SystemVerilog Structs

This section shows how to map e structs and SystemVerilog structs instantiated in UVM classes.
To use SystemVerilog structs that are not instantiated in UVM classes please refer toCalling
SystemVerilog Functions and Tasks with e Method Ports in the Specman Integrator's Guide.
NOTE: Only SystemVerilog types that are defined inside a package are supported. Therefore,

SystemVerilog types defined inside a module or defined inside the compilation scope are not
supported.
SystemVerilog Adapter Configuration Generation

When working with UVM Method Ports to pass structs, additional SystemVerilog adapter
configuration code should be written in e (see UVM Method Ports). You can use mltypemap to
generate this code by using the configure_code option, as follows:
mltypemap> configure_code -gen_adapter_config -lang e
This command causes mltypemap to generate a SystemVerilog adapter configuration file ine.
UVM Method Ports

With this implementation, you are able to pass UVM classes that have one or more struct fields,
including nested structs. Because e structs are mapped by default to SV classes, you have to use
the SystemVerilog adapter configuration mechanism to define for Specman that an e struct is
mapped to a SystemVerilog struct.
Mapping SystemVerilog Structs to e Structs

If you have a SystemVerilog struct that you want to map to ane struct, use
the associate_struct() SystemVerilog adapter configuration API. This API maps an e struct with
an existing SystemVerilog struct. It also declares which fields will be passed across languages. For
example:
pre_generate() is also {
associate_struct(“vr_ahb::my_struct”,”sv_vr_ahb::my_sv_struct”,{“opcode”;”addr”});
};
where:
The first parameter: vr_ahb::my_struct is the e type.
The second parameter: sv_vr_ahb::my_sv_struct is the SystemVerilog type.

The third parameter: {“opcode”;”addr”} is the list of fields to be passed.
As noted in SystemVerilog Adapter Configuration Generation, mltypemap can generate the adapter
configuration code as part of the type conversion process. In this case,
the associate_struct() code will be generated.

NOTE: You must instantiate the adapter configuration struct in youre environment.
Example: Mapping SystemVerilog struct to e

The following example illustrates converting a SystemVerilog class to ane struct using mltypemap.
The example also shows using the e struct within a UVM method port environment.
The following SystemVerilog source file contains a UVM class declaration sv_trans that has a
struct field, sv_data .
//sv_types.svh
package sv_types;
import uvm_pkg::*;
typedef struct {
bit [7:0] opcode;
bit [15:0] addr;
} sv_data;
class sv_trans extends uvm_sequence_item;

int trans_id;
sv_data trans;
ùvm_object_utils_begin(sv_trans)
ùvm_field_int(trans_id, UVM_ALL_ON)
endclass // sv_trans
endpackage // sv_types
Example Mapping Procedure

The following procedure converts the SystemVerilog struct to ane struct. The procedure generates
two files:
sn_dt_sv_types.e, which is the e type declaration file
sn_dt_adapter_config.e, which is the adapter configuration file.
The mltypemap utility is used to create the corresponding type ine:
% xrun –uvm sv_types.svh –mltypemap_tcl
The following Tcl commands are issued:

mltypemap> configure_code -lang e -gen_adapter_config

mltypemap> maptypes -from_type sv:sv_types::sv_trans -base_name sn_dt -to_lang e
The first Tcl command-line configures mltypemap to generate adapter configuration code that will
be used to configure the method port.
The second Tcl command performs the actual code generation.
The final step is to instantiate the adapter configuration under the unit that contains the UVM
method ports.
Example Output Files
The e Type Declaration Output File

As shown in the following sn_dt_sv_types.e file, the sv_trans class and sv_data struct from the
SystemVerilog source file are mapped to e structs:
//sn_dt_sv_types.e
<'
package sv_types;
//------------------------------------
//Source: SystemVerilog
//Source type: sv_types::sv_data
//Source Location: sv_types.svh:10
struct sv_data {
!%opcode : byte;
!%addr : uint(bits:16);
}; // end struct sv_data
//----------------------------------
//Source: SystemVerilog
//Source type: sv_types::sv_trans
//Source Location: sv_types.svh:12
struct sv_trans like any_sequence_item {
!%trans_id : int;
!%trans : sv_data;
}; // end struct sv_trans
'>
The Adapter Configuration Code Output File

As shown in the following sn_dt_adapter_config.e adapter configuration file, sv_trans is
associated with a SystemVerilog class using associate_class() , while sv_data is associated with a
SystemVerilog struct using associate_struct().

// sn_dt_adapter_config.e
<'
unit sn_dt_adapter_config like sv_adapter_unit {
associate_class("sv_types::sv_trans",
"sv_types::sv_trans",{"trans_id";"trans"});
associate_struct("sv_types::sv_data",
"sv_types::sv_data",{"opcode";"addr"});
};
};
'>
For more information see:

Mapping Between e and SV Parameter Types
Calling SystemVerilog Functions and Tasks with e Method Ports
Mapping e when Subtypes

The current version of mltypemap supports only flattening ofwhen subtypes. That is, when an e
struct is mapped and this struct has when subtypes, then all the when subtypes are flattened into the
target class. To avoid ambiguity in the field names, the field name is the C name of the field in e
(usually prefixed with the determinant value).
For example:
type packet_kind : [BIG,SMALL];

struct packet {
kind : packet_kind;
when BIG packet {
data: byte;
};
when SMALL packet {
data : int(bits:100);
};
};
In this case, the struct packet has two when subtypes, "BIG packet" and "SMALL packet". By
default, all fields defined under when will be flattened into the type packet, and their default names
will be "BIG__data" and "SMALL__data".
If a struct in e contains a field whose type is a when subtype, this field is mapped to a field whose
type is the base type of the when subtype. For example:

struct data {
rp : RED packet;
};
In this case, the mapped type of “data” will have a field whose type is the mapped type of “packet”,
not of “RED packet”. For example, if the target language is SV, then:
class data {
packet rp;
};
Referencing when Subtypes in Configuration

Commands
When you need to refer to a when subtype in any of the configuration commands, you need to
specify the when subtype name enclosed in double quotes. For example, suppose you are mapping
this class:
package user_pkg;
type packet_kind : [BIG,SMALL];
struct packet {
kind : packet_kind;
when BIG packet {
data: byte;
};
when SMALL packet {
data : int(bits:100);
};
};
Suppose further that you would like to skip the field "SMALL'packet.data". The proper command
would be:
configure_type -type "e:SMALL user_pkg::packet" -skip_field data
Mapping Enumerated Types

For a source enumerated type, a target enumerated type is created. You can control the name of
the target enumerated type and the mapping of literals names. The target enumerated type will
have the same bit width as the source type.

You can use the command configure_type to configure the mapping of the enum type and the
command configure_enum_item to configure the mapping of the enum items themselves. (See
configure_type Command and configure_enum_item Command.)
Example
Given the following enum in e:
type color : [RED = 10; GREEN = 20 ; BLUE = 30];
The following type definition is generated in SystemVerilog:

typedef enum { RED =10, GREEN = 20 ; BLUE = 30} color;
Mapping Typedefs
For a source typedef, a target typedef is created. You can use the commandconfigure_type to
configure the mapping of the typedef, specifically the target’s name. (See the configure_type
Command.)
Notes
Specman only supports numeric typedefs. If the output language ise, all non-numeric
typedefs (to classes or aliases for other types) are not created. The underlying types are
used instead.
Typedefs defined inside a class scope are created in the target language inside a namespace
with the class’s name, and not inside a class scope.
Example
Given the following typedef in SystemVerilog:
typedef bit signed[17:0] int18;
The following typedef will be generated in SystemC:

typedef sc_int<18> int18;
The following typedef will be generated in e:

type int18: int(bits:18);
Mapping SystemVerilog Queues, SystemC Vectors,

and e Lists
Mapping SystemVerilog Queues to SystemC Vectors / e Lists

The mltypemap utility automatically maps SystemVerilog queues to SystemC vectors ore lists.
You do not need to specify a configuration option to enable this mapping.
Mapping SystemC Vectors / e Lists to SystemVerilog Queues

To map a specific field of a SystemC vector or e list into a SystemVerilog queue:
Use the command configure_field -map_as_queue to specify the field of the SystemC vector
or e list. See configure_field Command.
To map all SystemC vectors and e lists to SystemVerilog queues:
Use the command configure_code -map_all_as_queue . See configure_code Command.
Example
Given the following queue in SystemVerilog:
rand byte unsigned f8[$];
The following vector will be generated in SystemC:

std::vector< sc_uint<8> > f8;
The following list will be generated in e:

f8 : list of byte;

Configuring mltypemap
This section describes the TCL API for mltypemap configuration. The configuration commands are
usually written before the maptypes command. When maptypes command is invoked, it will apply
all the configuration commands to the built types. If a configuration command was not applied to
any instance, a non-fatal error is given. Cadence recommends looking for these errors because
they might indicate typos in the configuration commands.
There are four configuration commands used to configure type-related entities: configure_scope,
configure_type, configure_field, and configure_enum. The configure_code command is used
for global configuration regarding the generated code. In addition, there is a print_type command
that can be used to get information about types and the configuration commands applied to them.
Using regular expressions

To describe the entity which the configuration command applies to (for example, scope, type, field,
enum-item), regular expressions can be used. The regular expression syntax is a POSIX regular
expression syntax, and the regular expression has to be written inside slashes.
For arguments that must include the language prefix (such as scopes and types), the regular
expression does not apply to the language prefix, and the language prefix has to be written outside
of the regular expression.
For example, to apply the configuration type command to all types of package vr_ahb that start
with the prefix my_, the following command has to be written:
configure_type -type e:/vr_ahb::my_/ …
For some configuration properties, sub-matches can be used to set the new value of the
configuration. This is done by using $0,..,$9 in the appropriate property, and by adding () to group
the sub-matches in the regular expression (where $0 refers to the full match).
For example, to map all fields of type packet starting with sv_ to start with sn_, the following
command can be given:
configure_field -type sv:sv_ahb::packet -field {/^sv_(.*)/} -to_name {sn_$1} …
For simple regular expressions containing only the expression for any number of characters (.*),
the regular expression can be written as a wildcard (*), and without slashes. That is, the following
are equal:
-type e:/vr_ahb::my.*bus/
-type e:vr_ahb::my*bus
When a given property is reconfigured multiple times, the last configuration command wins and no

warning is given.
To get more information about the configuration, use theprint_type command, which prints the
configuration commands that have been applied to a given type.
This section describes the following commands:
configure_field Command
configure_enum_item Command
print_type Command
configure_code Command
Syntax
configure_scope -scope scope-name-or-regex -to_name field-name
Syntax Example
configure_scope -scope e:vr_ahb -to_name cdn_ahb
Parameters
Argument Description
-scope scope- Name of source scope. This name should include the language prefix. For
name-or-regex example: -scope e:vr_ahb
-to_name field- The name of the target scope. This name can contain $0..$9 to refer to the
name sub-matches of the scope-name-or-regex.

Description
This command should be used to configure properties of a scope (only its target name).
Note that a scope of a type can be defined usingconfigure_scope or configure_type. If both
commands are relevant for a specific type, then the configure_type command takes effect,
because it is more specific.
Syntax
configure_type
-type source-type-name-or-regex
-skip_field field-name-or-regex
-pass_field field-name-or-regex
-to_name name
-to_scope scope-name
-use_existing
-skip_type
Syntax Example
configure_type –type e:vr_ahb::ahb_burst -skip_field driver \
-skip_field parent_unit -to_name AhbBusrt

Parameters
-type source- Name of the source type. This name should be qualified and must include the
type-name- language prefix. For example:
or-regex -type sv:cdn_ahb::ahb_burst
-skip_field Name of a field to be skipped. This parameter can be repeated for several
field-name- fields and a regular expression can be used. This should be used to tell
or-regex mltypemap to skip fields which are passed by default.
-pass_field Name of field to be passed. The parameter can be repeated for several fields
field-name- and a regular expression can be used. This should be used to tell mltypemap
or-regex to pass fields which are skipped by default.
-to_name Target name of the type. The target name should be the simple, non qualified
name name. For example, “-to_name packet”. Note that this name can contain $0..$9,
which refer to sub-matches in the source-type-name-or-regex.
-to_scope Name of the scope where the type has to be defined. By default, the target
scope-name scope is the same as the scope of the source type. Note that the scope can be
set also using the configure_scope command; in this case, the configure_type
command wins since it is more specific.
- Tells mltypemap to not generate a type definition for this type, but rather to use
use_existing the existing definition. mltypemap assumes that this type already exists with the
name as given with -to_name . This configuration should typically be used to
support consecutive invocations of mltypemap, for example, if part of the
hierarchy was already generated by previous invocation.
-skip_type Tells mltypemap to skip this type. Relevant only if this type has to be generated
as a subtype of a parent type. In this case, the type and all its subtypes will be
skipped. This configuration should be used if a sub-hierarchy of a mapped
class is not relevant for ML communication.
Description
Use this command to configure properties of an exported type. The-type argument should be used
to describe the source type. The other parameters are used for the configuration itself.

See Also
configure_field Command
Syntax
configure_field
-field field-name-or-regex
-to_name field-name
-norand | -rand | -randc
-public | -protected | -private
-pack | -nopack
-print | -noprint
-compare | -nocompare
-copy | -nocopy
-dec | -hex | -bin
-to_cpp_pointer
-use_cpp_type | -use_sc_type
-map_as_2value
-map_as_longint
-map_as_queue
Syntax Example
configure_field –type sv:vr_axi::axi_packet -field data \
-to_name AxiData -nopack -hex
Parameters

-type source- Name of source type. This name should be qualified and should include the
type-name-or- language prefix. The name can contain regular expressions. For example:
regex -type sv:cdn_axi::axi_packet
-field field-name- Name of the source field. This switch is mandatory.

or-regex
-to_name field- The target name of the field. This name can contain $0..$9 to refer to sub-
name matches in field-name-or-regex.
-norand | -rand | Controls the randomization type of the target field. Relevant only if target is
-randc e or SystemVerilog. The default is the same as the source field.
-public | Controls on the target access level of the field.

-protected | -
The default is the same access level as the source field.
private
-pack | -nopack Controls whether this field should be part of the packing.
Default is -pack.
-print | -noprint Controls whether this field is printed. Has no affect if the target language is
e.
Default is -print.
-compare | - Controls whether this field should be part of the comparing. Has no affect if
nocompare the target language is e.
Default is -compare.
-copy | -nocopy Controls whether this field should be part of the copying. Has no affect if
the target language is e.
Default is -copy.
-dec | -hex | -bin Sets the radix for this field. Has no effect if the target language ise.
-to_cpp_pointer Relevant when the target language is SystemC. Indicates that the field
should be mapped into pointer in C++.

-use_cpp_type | Integers of 8,16, and 64 bits are mapped by default to SC types:

-use_sc_type sc_(u)int<8>, sc_(u)int<16> and sc_(u)int<64> respectively. Integers of size
32 bits are mapped by default to C++ type int or unsigned int. This option
can be used to change the default of such mapping. The mapping is done
per field, and the field can be of the integer type of dynamic or static array
of this type.
-map_as2_value Instructs mltypemap to map a four-value scalar field as two-value. This is

relevant only for SystemVerilog fields whose type is four-value scalar or
array of four-value scalars.
Note that the mapping of four-value scalar as two-value scalars can be
done globally using the configure_code command. When the latter is used,
this option has no impact.
- Instructs mltypemap to map a SystemVerilog or SystemC 64-bit scalar field

map_as_longint as e longint. An unsigned 64-bit scalar field is mapped as e longuint.
Note that the mapping to 64-bit scalar fields can be done globally using the
configure_code -map_all_64bit_as_longint command. When -
map_all_64bit_as_longint is specified, this option has no impact.
-map_as_queue Instructs mltypemap to map the specified field from a SystemC vector or an
e list into a SystemVerilog queue. Relevant only when the-lang is SV.
(This flag does not affect fields that are not part of a SystemC vector or an
e list.)
Note that the mapping to SystemVerilog queues can be done globally using
the configure_code -map_all_as_queue command. When -
map_all_as_queue is specified, this option has no impact.
Description
Use this command to configure properties of an exported field. The-type and -field parameters
should be used to describe the source field. The other parameters are used for the configuration
itself.
See Also

configure_enum_item Command
Syntax
configure_enum_item
-item enum-item-name-or-regex
-to_name enum-item-name
Syntax Example
configure_enum_item –type sv:vr_ahb::color –item RED –to_name AHB_RED
Parameters
-type source- Name of source enumerated type. This name should be qualified and should
type-name-or- include the language prefix. The name can contain regular expressions.
regex
-item enum- Name of the source enumerated item. This name can contain regular
item-name-or- expressions.
regex
-to_name The target name of the enumerated item. The target name can contain
enum-item- $0..$9 refer to sub-matches in the enum-item-name-or-regex.
name
Description
Use this command to configure the target name of an enumerated type item. The-type and -item
parameters should be used to describe the source item.

print_type Command
Syntax
print_type -type source-type-name-or-regex
Syntax Example
print_type -type sv:vr_ahb::burst
Parameters
-type source-type- Name of type to be printed. The name can contain regular
name-or-regex expressions. This argument can be repeated.
Description
Print information about a specific type or types. The command prints basic information about the
type, plus its configuration properties (if any configuration has been applied to the type).
See Also

configure_code Command
Syntax
configure_code
-lang SV | SC | SN | e
-header_code code
-gen_adapter_config
-adapter_config_name adapter-config-unit-name
-ovm | -uvm
-unilang | -uvm_ml_oa
-map_all_64bit_as_longint
-map_all_as_2value
-map_all_as_queue
-only_physical_fields
-skip_unsupported_type
Syntax Example
configure_code -lang sv -header_code {ìnclude "my_kind_pkg.svh"}
Parameters
-lang SV | SC | SN | e Name of target language for which the configuration will be

applied. Define this parameter only if it is applicable to the target
language.
-header_code code Instructs mltypemap to add the code at top of the generated
header code.
-gen_adapter_config Instructs mltypemap to generate adapter configuration settings

when mapping types from SV to e.

-adapter_config_name Name of the adapter unit name. Relevant only when-

adapter-config-unit-name gen_adapter_config is specified.
Default: the base-name suffixed with _adapter_config.
-ovm | -uvm Instructs mltypemap to generate UVM or OVM compliant code.

Default: -uvm. The -ovm option is deprecated and should not be
used.
-unilang | -uvm_ml_oa Instructs mltypemap whether to generate code that is appropriate
for the standard Cadence UVM multi-language solution (UVM-ML
OA) or the deprecated UVM-ML solution.
Default: -uvm_ml_oa. The -unilang option is deprecated and
should not be used.
- Instructs mltypemap to map all SystemVerilog and SystemC 64-

map_all_64bit_as_longint bit scalars as e longint. Unsigned scalars are mapped to e
longuint.
-map_all_as_2value Instructs mltypemap to map all SystemVerilog four-value scalars

as two-value scalars. Relevant only when the -lang is SV.
-map_all_as_queue Instructs mltypemap to map all SystemC vectors and e lists to

SystemVerilog queues. Relevant only when the -lang is SV.
-only_physical_fields Instructs mltypemap to map only physical fields. Relevant only

when mapping from e.
-pass_field <field name> This field is mapped even if -only_physical_fields is used and
the field is not physical.
-skip_unsupported_type Causes mltypemap to continue its type mapping process and

recover from mapping errors encountered.
Description
Use this command for general configuration of the generated code.
The -header_code option is used to insert code into the generated header code. This is useful, for
example, when existing types are used and their header file has to be imported/included.
The -gen_adapter_config and -adapter_config_name options are used to instruct mltypemap to

generate adapter unit code for the e-over-SV flow. The generated adapter config code implements
the necessary logic to allow the mapped types to be passed between the source and target
languages through method ports.
The -unilang | -uvm_ml_oa option instructs mltypemap whether to generate code that is
appropriate for the standard Cadence UVM multi-language solution (UVM-ML OA) or the
deprecated UVM-ML solution. The -unilang option is deprecated and should not be used.
The -map_all_64bit_as_longint option instructs mltypemap to map all SystemVerilog and
SystemC 64-bit scalars as e longint. Unsigned scalars are mapped to e longuint. Note that this can
be configured also per-field using the configure_field -map_as_longint command. Note, however,
that when the global configuration is given, the per-field configuration has no impact.
The -map_all_as_2value option instructs mltypemap to map all four-value scalars as two-value
scalars. Note that this can be configured also per-field using the configure_field -map_as_2value
command. Note, however, that when the global configuration is given, the per-field configuration
has no impact.
The -map_all_as_queue option instructs mltypemap to map all SystemC vectors and e lists as
SystemVerilog queues. Note that this can be configured also per-field using the configure_field -
map_as_queue command. Note, however, that when the global configuration is given, the per-field
configuration has no impact.
The -only_physical_fields instructs mltypemap to map only physical fields from Specman to
SystemVerilog or SystemC. Consider the given example that -only_physical_fields maps only
physical fields, except the field f4 of inner struct:
configure_code -only_physical_fields
configure_type -from_type e:dt::inner -pass_field f4
The -skip_unsupported_type option causes mltypemap to continue its type mapping process and
recover from mapping errors encountered. Erroneous types and fields will be skipped. The user
can use the generated output to analyze and fix the errors.
mltypemap Limitations for this Release

The current version of mltypemap is the first phase of implementation, and has the following
limitations:
Parameterized types are not supported.
Setters/getters are not supported. Thus, if private/protected fields are mapped, the
serialization code may not be compiled.

Static fields cannot be mapped.

No serialization code is generated for SystemC. Thus, all fields in SystemC should be paced
(otherwise an error is given).
when subtypes are mapped as flattened classes. Mapping when subtypes into a hierarchy of
classes is not supported.
You cannot trim part of the when hierarchy. When a struct containing when subtypes is
flattened, all its when subtypes are passed.
SystemVerilog input limitation: Packed structs are not supported.

Mapping of units and sequencers (drivers in e) are not supported. These fields must be
configured as skipped.

Uvm Util

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Uvm Util

Uploaded by

Copyright:

Available Formats

UVM Related Utilities

Product Version XCELIUM AGILE

Restricted Rights: Use, duplication, or disclosure by the Government is subject to restrictions as

September 2022 4 Product Version XCELIUM AGILE

Optimization in Register Verifier 48

September 2022 5 Product Version XCELIUM AGILE

September 2022 6 Product Version XCELIUM AGILE

September 2022 7 Product Version XCELIUM AGILE

Running Register Verifier and the Register

Running Register Verifier

Syntax Usage Example

September 2022 8 Product Version XCELIUM AGILE

Value Global Option

-top <top-file> Top level IP-XACT file.

- Specifies whether the code is generated in e (vr_ad) or in

-dut_name <dut-name> Name of the top level DUT component.

Value Global Option

-h[elp] Display all supported options.

-nocopyright Disable the copyright message

- Comma separated list of alternate register groups to be selected. Where

September 2022 9 Product Version XCELIUM AGILE

Domain Options (vr_ad)

Value Domain Option (uvmreg)

-reg_prefix <prefix> Prefix to add to register name

<dir,...> Keep the case specified in the XML, ignore coding

Domain Options (uvmreg)

Value Domain Option (uvmreg)

-pov_intf <intf- Comma separated list of interface paths

-quicktest Generate a testbench (quicktest.sv ) and a makefile

- Generate a register model without using the UVM factory.

September 2022 10 Product Version XCELIUM AGILE

When the domain flag is vr_ad:

When the domain flag is uvmreg:

September 2022 11 Product Version XCELIUM AGILE

cdns_uvmreg_config.dat — Configuration file listing the configuration of all Register Model

Running the Register Verifier Demo

The following files are generated:

September 2022 12 Product Version XCELIUM AGILE

The following files are generated:

setenv REG_VERIFIER_EXAMPLE_DIR <install-dir>/tools/tti/examples/reg_verifier

September 2022 13 Product Version XCELIUM AGILE

Working with IP-XACT Files

Currently Supported IP-XACT Versions

IP-XACT File Format Structure

September 2022 14 Product Version XCELIUM AGILE

Defining Type Names with IP-XACT

Defining Single- and Multi-Dimensional Arrays with IP-

September 2022 15 Product Version XCELIUM AGILE

Generating HDL Paths with IP-XACT 1685-2014

IP-XACT Entities and Their Conversion to e

September 2022 16 Product Version XCELIUM AGILE

component elements & attributes

components unsupported attributes/elements

memoryMaps elements & attributes

September 2022 17 Product Version XCELIUM AGILE

memoryMaps unsupported attributes/elements

Result in the following e code:

extend vr_ad_map_kind : [AM0];

September 2022 18 Product Version XCELIUM AGILE

memoryMap unsupported attributes/elements

September 2022 19 Product Version XCELIUM AGILE

Result in the following e code:

extend vr_ad_map_kind : [AM0];