IP-XACT vs SystemRDL: Construct Comparison for Registers

1170x200-1 (1)

Since its first release in 2010 by the SPIRIT consortium (now Accellera), IP-XACT has become the de-facto format for structuring, packaging, integrating and reusing IPs within tool flows.  One of the key reasons for its wide-adoption is its XML-based vendor-neutral format favorable to IP suppliers. IP-XACT can also describe components for memory and register maps, but quite limited in this area, especially as new types of register designs are needed to meet new requirements of next-generation SoCs. To address these limitations, SystemRDL was also formulated by the same industry. SystemRDL is a description language specifically for describing registers to address the growing design complexity.

What is IP-XACT?

This standard provides the EDA vendors, IP providers, and SoC design communities with a well-defined and unified specification for the meta-data that represents the components and designs within an electronic system. This specification enables delivery of compatible IP descriptions to improve the importing and exporting of complex IP that bundles to, from, and between EDA tools for the SoC design environments.
As part of design-build, generators may be provided internally by a system design tool to achieve the required IP integration or configuration, or they may be provided externally and launched by the system design tool as and when desired.

What is SystemRDL?

SystemRDL supports the full project cycle of registers from the specification, model generation, and design verification to maintenance and documentation. SystemRDL minimizes the problems encountered in describing and managing registers. Typically, in a traditional environment, the system architect or hardware designer creates a functional specification of the registers in a design. This specification is then used by other members of the team including software, hardware, and design verification. Each of these parties uses the specification to create representations of data in the languages which they use in their aspect of the chip development process.

During these verification and validation processes, bugs are often encountered which require the original register specification to change. When these changes occur, all the downstream views of this data have to be updated accordingly. This process is typically repeated numerous times during chip development. In addition to the normal debug cycle, there are two additional aspects that can cause changes to the register specification. First, marketing requirements can change, which require changes to a register’s specification. Second, physical aspects, such as area and timing constraints can drive changes to the register’s specification.

These challenges often result in a low-quality product and waste of time due to incompatible register views. Through the application of SystemRDL and a SystemRDL compiler, users can save time and eliminate errors by using a single source of the specification and automatically generating any needed downstream views.

Comparison

Since registers can be described in the textual format using these two industry standards, we often get questions about the pros and cons of each. In this article, we compare and contrast both IP-XACT and SystemRDL

There are many constructs in SystemRDL and IP-XACT to describe the registers. Table 1 shows a basic comparison between them.

Table 1: Comparison of Basic Constructs

IP-XACT 2014 SystemRDL
<ipxact:memoryMap> addrmap
<ipxact:addressBlock> addrmap
<ipxact:addressOffset> <block name>

 

<block_instance> @offset
none(can be handled with the help of vendor extension) external
<ipxact:width> regwidth
<ipxact:registerFile> regfile
<ipxact:addressOffset> <regroup name> <regroup_instance>@offset
<ipxact:register> reg
<ipxact:name> reg <register_name>
<ipxact:addressOffset> <reg name> <reg_instance>@offset
<ipxact:volatile> hw=wo/rw
<ipxact:reset> default
<ipxact:description> desc
<ipxact:field> field
<ipxact:bitOffset> [Lsb]
<ipxact:bitWidth> [Msb : Lsb]
<ipxact:access> sw
<ipxact:dim> [<repeat_value>]
Vendor Extensions User Defined Properties
none Documentation artifacts

Table 2 shows an implementation of a Lock Register in IP-XACT and SystemRDL. A Lock Register is a register whose software read and write access functionality is locked on another register field or based on an expression consisting of different register fields or some external signal.

Table 2: Comparison of Implementation of Lock Register

Lock Register Description in IP-XACT Lock Register Description in SystemRDL
<spirit:register>

 

<spirit:name>lockRegisterWrite</spirit:name>

<spirit:addressOffset>0x8</spirit:addressOffset>

<spirit:size>32</spirit:size>

<spirit:volatile>true</spirit:volatile>

<spirit:reset>

<spirit:value>0x00000000</spirit:value>

<spirit:mask>0xFFFFFFFF</spirit:mask>

</spirit:reset>

<spirit:field>

<spirit:name>Fld3</spirit:name>

<spirit:bitOffset>0</spirit:bitOffset>

<spirit:bitWidth>32</spirit:bitWidth>

<spirit:access>read-write</spirit:access>

<spirit:vendorExtensions>

<ids:default_value>00000000000000000000000000000000</ids:default_value>

</spirit:vendorExtensions>

</spirit:field>

<spirit:vendorExtensions>

<ids_properties>

<lock>locker.Fld</lock>

<address>0x08</address>

</ids_properties>

</spirit:vendorExtensions>

</spirit:register>

 property lock { type=string; component = reg|field;};

 

addrmapblock_name {

 name = “block_name Address Map”;

   // Signals

   signal { activelow; sync; signalwidth = 1;

desc= ” This signal is sync and activelow with width 1″; } Sig1;

..

..

reg locker {

regwidth = 32;

   field {

hw = rw;

sw = rw;

   } Fld[31:0] = 32’h0;

 };

..

..

reglockRegisterReadWrite {

    lock = “locker.Fld, wr” ;

regwidth = 32;

   field {

hw = rw;

sw = rw;

   } Fld4[31:0] = 32’h0;

 };

reglockRegisterSignals {

    lock = “Sig1, wr” ;

regwidth = 32;

   field {

hw = rw;

sw = rw;

   } Fld2[31:0] = 32’h0;

 };

lockRegisterReadlockRegisterRead @0x00;

 locker locker @0x04;

lockRegisterWritelockRegisterWrite @0x08;

lockRegisterReadWritelockRegisterReadWrite @0x0C;

lockRegisterSignalslockRegisterSignals @0x10;

};

IDesignSpec supports both SystemRDL and IP-XACT. It can take both SystemRDL and IP-XACT as an input format and automatically generate various outputs from it such as RTL, UVM Register Model, C Headers, HTML and PDF Documentation. IDesignSpec can also generate SystemRDL and IP-XACT as outputs from various types of inputs for register specification.

This article showed a comparison between IP-XACT and SystemRDL for register descriptions. To capture the design intent at the IP level, IP-XACT can, of course, be used. If the specification contains different types of common and special registers with various features and properties, SystemRDL would be a better choice. Next time, we will look closely on the advantages of IP-XACT vis-a-vis’ SystemRDL.