Typically thousands of registers are required for today’s complex designs, which are used to control the operations of the SOC. Registers are accessed by hardware, software, verification and embedded design teams and all better have the same information. Mismatch of implemented registers and their specification cause unwanted delay and quality problems.
Agnisys identified the need of having executable specification as a single source and generating 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 engineer’s 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, RALF and use these as single source file 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 thru a revision. The new version (2.0) will be coming out soon.
SystemRDL is designed to increase productivity, quality, and reuse during the design and development of complex digital systems. It can be used to share register IP within and between groups and companies. This is accomplished by specifying a single source for the register description from which all views can be automatically generated, which ensures consistency between multiple views. A view is any output generated from the SystemRDL description, e.g., 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
// User Defined Property declaration
property clock_edge {type = string; component = addrmap|reg; }
addrmap hier_block {
name = “block_name Address Map”;
clock_edge = “negedge” ; // Use of UDP
reg myReg { field {} data[31:0]; };
internal myReg extReg; // single internal register
myReg extArray[32]; // internal register array of size 32
};
On top of SystemRDL 1.0, IDS provides additional user defined properties for various design requirement. For SystemRDL 2.0 development, Agnisys RnD team actively engaged with Accellera and has contributed several problem statement 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 and 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 a number of 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 structure. 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 in order 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 numbers 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 the comprehensive flow to implement complex register in shortest time with ease of use.
IDesignSpec is available as s 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 for Evaluating IDesignSpec – 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 are the opinion of Agnisys. Please refer to Accellera site for latest updates on SystemRDL 2.0.
