Typically thousands of registers are required for today’s complex designs, which are used to control the operations of the SOC. Hardware, software, verification, and embedded design teams all access registers, ensuring consistent information across the board. Mismatch of implemented registers and their specification cause unwanted delays and quality problems.
Agnisys identified the need to have executable specification as a single source and generate the required output files way back in 2006. Agnisys’ IDesignSpec is an award-winning engineering tool that allows an IP, chip, or system designer to create the register map specification once and automatically generate all possible views from it. Various outputs are possible, such as synthesizable RTL, UVM, c-header, RALF, SystemRDL, IP-XACT, etc. Also, User-defined outputs can be created using Tcl or XQUERY scripts. IDesignSpec’s patented technology improves engineers’ productivity and design quality. It helps designers to capture the specification in executable form in MS Word or MS Excel or any text format for example SystemRDL, and RALF, and use these as single source files to auto-generate the desired files. IDS offers flow for standard input files like – IP-XACT, XML, RALF, CVS, etc. In this article, we will discuss about the next generation SystemRDL 2.0 to capture the register specification.
SystemRDL 1.0 was adopted by the industry some time back. Now under the auspices of Accellera, the standard is going through a revision. The new version (2.0) will be coming out soon.
SystemRDL enhances productivity, quality, and reuse in designing and developing complex digital systems. It enables sharing register IP within and between groups and companies by specifying a single source for the register description. This source automatically generates all views, ensuring consistency between multiple views. A view encompasses any output generated from the SystemRDL description, such as RTL code or documentation.IDesignSpec can import register specification in SystemRDL format and generates correct-by-construction desired output files like – Synthesizable RTL, SystemC, UVM Register Model systemVerilog, RALF, c/c++ headers, IP-XACT, etc.
One of the important features of SystemRDL is that it is a natural and easy-to-understand format.
Sample SystemRDL code – Easy-to-understand format
On top of SystemRDL 1.0, IDS provides additional user-defined properties for various design requirements. For SystemRDL 2.0 development, the Agnisys RnD team actively engaged with Accellera and has contributed several problem statements and solutions e.g. hdl_path, constraint, coverage, etc.
Agnisys partnership with leading EDA companies gave birth to Automatic Register Verification (ARV) for creating simulation-based UVM Environment and sequences for register verification and formal assertions and SystemVerilog properties with just push button effort.
Some major features available in SystemRDL are preprocessor directive, multiple properties for different behaviors of spec, multiple bus domains (supported by Agnisys), etc. Many more features are coming in SystemRDL 2.0 like –
Memory: A memory is an array of storage consisting of several entries of a given width.
A memory component and its software view (virtual register) can be described in SystemRDL 2.0.
memory example {
mementries = 1024;
reg reg_type { field {} a; };
reg_type a[10]; // So these will consume 40 bytes
//Address 0,4,8,C.... some_reg b[10] @0x100 += 0x10;
//These will consume 160-12 bytes of space
//Address 0x100 to 0x103, 0x110 to 0x113,....
};
Field structs: A field struct is a logical grouping of one or more field and field struct instances. The field struct provides the ability to define reusable clusters of fields. Unlike register files, field structs do not add architectural structures. Like register files, field structs do not necessarily add RTL hierarchy.
fieldstruct subfs {
width=16;
field {} foo[8];
};
Alternate components: An alternate is defined as a set of one or more SystemRDL register instances that share a common space in memory. Software may access only one instance in an alternate at a given time (via the select property). Hardware may access all instances simultaneously, in the same way that register instances within a register file can be.
reg myReg32 {
field {} data[31:0];
};
reg myReg64 {
field {} data[63:0];
};
alternate myAlternate {
0: myReg32 alpha;
1: external myReg32 beta;
default: myReg64 gamma;
};
regfile myRegfile {
myAlternate myRegAlt;
};
Hdl_path: An HDL path specifies the hierarchical path of the design storage element corresponding to the addrmap, register, register field, or memory. By specifying an HDL path, the UVM register layer class can have direct access to registers in a Design Under Test (DUT). The complete HDL path of a component is the concatenation of all HDL paths from the top level down to the component
addrmap block_def {
parameter ext_hdl_path= "ext_block" ; // parameter for an hdl_path
hdl_path="int_block";
external register {
hdl_path= ext_hdl_path . "external_reg";
field { hdl_path_slice = {"field1"}} f1;
} extern_reg ;
register {
hdl_path="int_reg";
field { hdl_path_slice = {"field1"}} f1;
}internl_reg ;
};
Coverage: Coverage is defined as the percentage of verification objectives that have been met. It is used as a metric for evaluating the progress of a verification project to reduce the number of simulation cycles spent in verifying a design.
reg reg2 {
cover_bits; // set the bits coverage.
field { } a [31:0];
};
Constraint: A constraint is a value-based condition on one or more components; e.g., constraint-driven test generation allows users to automatically generate tests for functional verification.
reg register1 {
field { hw = rw; sw = rw; }limit[0:2]=0;
field { hw = rw; sw = rw;
max_value max1; // another instance.
} f1 [3:9]=3;
constraint { f1 > limit } min; //anonymous constraint
field {
hw = rw; sw = rw; encode=color;
constraint { this == red || this == green; } rg1;
constraint { this inside {red, green}; } rg2;
constraint { this inside color; } rgb; // full range of encode
} f2 [10:31];
};
Parameters: verilog -style parameters are now supported
reg myReg {
parameter SIZE = 32;
regwidth = SIZE;
field {} data[SIZE – 1];
}
Array: Arrays enable properties with an arbitrary number of values. Arrays can be numeric/sequential or they can be associative. Associative keys shall be ASCII-only. Arrays may be used within structs or in property declarations. Arrays may be assigned on an element-by-element basis or the entire array may be replaced.
field f1 {
theproperty = {aa=>10, bb=>20};
arrayedstructproperty = ();
} ff[10];
IP-XACT features mapping like – is Present & All type of access from IP-XACT are now supported in SystemRDL 2.0
reg foo {
desc = ?gold desc?h { ispresent = VER<=10 };
desc = ?gnew desc?h { ispresent = VER>10 };
}
The advantage of using SystemRDL with IDesignSpec provides a comprehensive flow to implement complex registers in the shortest time with ease of use.
IDesignSpec is available as a plug-in for popular editors that are commonly used to document registers (Microsoft Word, Microsoft Excel) and as a command line utility for Windows, Linux, and Solaris platforms.
Please feel free to contact Evaluating IDesignSpec – at sales@agnisys.com
Ref- http://www.accellera.org/downloads/standards/systemrdl
Note: SystemRDL version 2.0 is not released yet. Any description of features beyond SystemRDL 1.0 is the opinion of Agnisys. Please refer to the Accellera site for the latest updates on SystemRDL 2.0.
