There are two standards developed by Accellera for capturing artifacts of the IP/SoC – IP-XACT and SystemRDL. Both of these standards have their strengths and weaknesses and the question often arises about which to use and under what circumstances. 

This article compares IP-XACT and SystemRDL. It discusses the best practices on how to manage top-level designs, managing address-maps, and complex assembly of SoCs.

What Is IP-XACT?

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 is quite limited in this area, especially as new types of register designs are needed to meet new requirements of next-generation SoCs. 

What Is SystemRDL?

To address the limitations of IP-XACT, SystemRDL was created. SystemRDL is a description language specifically for describing registers to address the growing design complexity.

SystemRDL supports the full project cycle of registers from 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 that they use in their aspect of the chip development process.

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

The Comparison

The IP-XACT standard provides the 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 the 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.

IP-XACT not only provides a unified structure to work on IP level but also provides the flexibility to design a system over that IP. There are multiple constructs that describe the system connectivity and abstraction information. 

Below are the methods by which  SystemRDL and IP-XACT can be used to design the memory map of an IP, including the pros and cons of each language to describe a system.

A memory map is generally used to describe the memory structure of an IP. It includes the information of registers, memories, etc. Each register/memory is bound to some functionality.   

Element of a Memory Map

There are multiple constructs in both languages to describe a MemoryMap. These are:

  • Fields 
  • Registers
  • Reggroups/sections
  • addressBlock/addrmap

Each above construct can be described in textual language using the two standards. 

Fields

A field element of a register describes a smaller bit field of a register. It contains multiple elements such as bit length, bit offset, access types, and description. Each language has different  methods to describe the information of a field in a register. 

In IP-XACT, a field can be described as <ipxact:field> inside a register, as shown below:

<ipxact:field>
           <ipxact:name>fieldName</ipxact:name>
           <ipxact:bitOffset>0</ipxact:bitOffset>
           <ipxact:resets>
                <ipxact:reset>
                      <ipxact:value>'h00000000</ipxact:value>
                      <ipxact:mask>'h00000000</ipxact:mask>
                </ipxact:reset>
           </ipxact:resets>
      <ipxact:bitWidth>32</ipxact:bitWidth>
      <ipxact:volatile>true</spirit:volatile>
      <ipxact:access>write-only</spirit:access>
      <ipxact:modifiedWriteValue>oneToClear</spirit:modifiedWriteValue>
      <ipxact:vendorExtension>
      </ipxact:vendorExtension>
</ipxact:field>
  • Field name can be described in <ipxact:name> with any string type 
  • Start of the field is described in <ipxact:bitOffset> with any integer number or parameter name
  • Reset types can be described in <ipxact:resets> and can be either hard reset or soft reset with their default values
  • Field size is described in <ipxact:bitWidth> and can be described using any integer or a parameter
  • Volatility describes the accessibility of field other than the software bus
  • Access describes the software bus accessibility of the field
  • “Modified write/read values” is the special accessibility feature tied to the field, e.g., read to clear, write to set, etc.
  • vendorExtension is used to describe some user defined property/functionality that can be bound to the particular field

In SystemRDL, a field can be implemented as below:

field {
        hw = rw;
        sw = rw;
        fieldwidth = 1;
        resetsignal = pci_soft_reset;
      }  [7:7]=0;

 

  • Field name can be described as above with any string type or parameter
  • hw/sw element is used to describe the volatile access and the software access of a field in a register
  • “resetsignal” describes the soft reset of the field
    • Note: SystemRDL supports only a single soft reset signal on a field
  • Value in “<fieldName> = <value>” to describe the reset value/default value of the field

Registers

A register is defined as a set of one or more field instances that are automatically accessible by software at a given address. 

A register can be described in both languages as shown below.

In IP-XACT:

               < ipxact:name>regName</ ipxact:name>
               < ipxact:addressOffset>0x4</ ipxact:addressOffset>
               < ipxact:size>32</ ipxact:size>
               < ipxact:volatile>true</ ipxact:volatile>
               < ipxact:field>
                  ……..
               </ ipxact:field>
               
	         
                          …..
                     
                     …….
   
               < ipxact:vendorExtensions>
                  ………
               </ ipxact:vendorExtensions>
  </ ipxact:register>

 

  • Name of the register can be of any string type
  • addressOffset describes the relative offset of the register w.r.t. to the parent block or section
  • Size describes the register width, and it can be any integer value
  • Volatile describes the volatility of a register 
  • Multiple fields can be described as <ipxact:field>
  • IP-XACT also has the capability to define alternate register definitions: <ipxact:alternateRegsietrs> can contain multiple alternateRegister
  • User defined properties/functionality can be added in vendorExtension
  • IP-XACT does not provide any information about the register present outside (External Register) the IP block; it can only be done by vendorExtension
  • All other special registers and memory information can be provided in vendorExtension of register

 

In SystemRDL:

reg PCIE_REG_BIST { 
    regwidth = 8; 
      field {
       …….
      };
  };
  • Register is described as above with regwith 8
  • Multiple fields can be instanced or defined in the register

Alias Registers

reg some_intr { 
    field { 
     hw=w; 
     sw=rw;
     onwrite = woclr;
    } field2;
  };
addrmap foo { 
  some_intr  event1 @0x100; 
  alias event1 some_intr event1_for_dv;
};
    • SystemRDL has functionality to describe an “alias” of a register (alias register) using keyword “alias” at the instance of the register

External Register

reg reg1 { 
    field { 
     hw=w; 
     sw=rw;
    } field1;
  }; 
addrmap foo {
 external reg1 reg1;
};

 

  • External register can be described with “external” keyword at the time of creating the  register instance

Memory

mem fixed_mem #(longint unsigned word_size = 32, longint unsigned  memory_size = word_size * 4096) {
  mementries = memory_size/word_size ; 
  memwidth = word_size ;
} ;

 

  • A memory is an array of storage consisting of several entries of a given bit width 
    • Note: The physical memory implementation is technology dependent and memories shall be external
  • Memory has following properties:
    • Mementries: The number of mem entries
    • Memwidth: memory width
    • sw: sw access of the memory

Enums

In IP-XACT:

<ipxact:field>

                  …….

                  <ipxact:enumeratedValues>

                     <ipxact:enumeratedValue>

                        <ipxact:name>e1</ipxact:name>

                        <ipxact:value>2</ipxact:value>

                     </ipxact:enumeratedValue>

                     <ipxact:enumeratedValue>

                        <ipxact:name>e3</ipxact:name>

                        <ipxact:value>3</ipxact:value>

                     </ipxact:enumeratedValue>

                  </ipxact:enumeratedValues>

       …….

<ipxact:field>
    • Enums describes the name for each value in a field
    • Multiple enumerated values can be described in <ipxact:enumeratedValues>
    • In IP-XACT enums are supported at field level only

In SystemRDL: The enum constract encloses a set of constants named integral values into the enumeration’s scope. Its syntax is as shown below:

enum Enum1 {
 VAL1 = 3'h0 ;
 VAL2 = 3'h1 ;
} ;
enum Enum2 {
 VAL11 = 3'h0 ;
 VAL22 = 3'h1 ;
 VAL33 = 3'h2 ;
} ;
property MyUDP { component = addrmap ; type = Enum1 ; } ;
addrmap top {
  reg some_reg { field {} a[3] ; } ;
    addrmap {
      MyUDP = Enum1::VAL1 ; // Allowed
      some_reg regA ;
      regA.a -> reset = Enum1::VAL2 + Enum2::VAL33;
    } submap1 ;
    addrmap {
      reg { 
       field {
        hwclr=longint'(Enum1::VAL1) == longint'(Enum2::VAL11); 
       } b;                         
      } other_shared_reg ;
    } submap2 ;
};

Parameters

In IP-XACT:

IP-XACT supports parameters at the following constructs:

  • signals 
  • registers 
  • fields
  • blocks 

The syntax of a parameter is:

	 anystring
	value to parameter</ ipxact:value >
 
 
In systemRDL:
Parameters can be used as shown below:
 reg myReg #(longint unsigned SIZE =32){
  regwidth = SIZE; 
  field {
  } data[SIZE – 1]; 
}; 
addrmap myAmap {
  myReg reg32;
  myReg reg32_arr[8]; 
  myReg #(.SIZE(16)) reg16;
  myReg #(.SIZE(8)) reg8;
 };
Note: Parameter overriding is possible at the creation of an instance of an element.

Signals

In IP-XACT:

<ipxact:ports>

    <ipxact:port>

          <ipxact:name>signal name</ipxact:name>

     </ipxact:port>

     …….

</ipxact:ports>
  • IP-XACT support signal declaration as a port list
  • All bus signals and user defined signals can be declared in <ipxact:ports>
  • Multiple signals can be declared in the port list
  • Signals can also be parameterized
  • Extra properties can be added in <ipxact:vendorExtension>

In SystemRDL:

addrmap top {

       signal{activelow;async;field_reset;} pci_soft_reset;

       signal{async;activelow;cpuif_reset;} pci_hard_reset;

     

      …..

};

 

  • Signals can be declared using keyword “signal”
  • Multiple properties are supported for signals in SystemRDL
  • Signalwidth
  • Sync/async
  • Field_reset
  • Active low/high
  • Reset signal
  • cpuif_reset

 

Table 1: Comparison of Constructs

Properties IP-XACT 2014                                                                                                                                                                              SystemRDL
Interrupt Register IP-XACT does not have a built-in construct to describe an interrupt register. This can be implemented using the vendor extension.  In SystemRDL keyword “intr” is used to describe an interrupt register. Posedge, negedge, non sticky, enable, mask, etc. are keywords used to describe interrupts in SystemRDL.
Counter Register IP-XACT does not have any  built-in counter reg functionality. This can be implemented using the vendor extension. SystemRDL has built-in keywords to support counters such as counter, incrvalue, decvalue, saturation, etc. 
hdl path Hdl path is not supported in IP-XACT. There are many properties to support hdl paths, such as ashdl_path, hdl_path_gate, etc.
Constraints IP-XACT does not support constraints. SystemRDL has built-in properties for constraint enable and disable.

Conclusion

  • IP-XACT is an XML language used to describe memoryMap of IP as well as the connectivity of multiple IPs at higher level, which include system bridges with master and slave information, master memoryMap, connection of master with slave interface, etc. – basically all requirements to build an SOC
  • On the other hand, SystemRDL is extensively used to define only the slave component of the SOC, mainly the memoryMap 
  • Which one to use really depends on the context and purpose. If you want a reusable IP development and SoC assembly language, then IP-XACT is the answer as SystemRDL has no construct for that. However, if you want a text-based entry method for describing complex addressable registers, then SystemRDL is the answer. 

References

IP-XACT:

https://www.accellera.org/activities/working-groups/ip-xact

SystemRDL:

https://www.accellera.org/images/downloads/standards/systemrdl/SystemRDL_2.0_Jan2018.pdf

By Comments off March 27, 2022