DVCon Europe Special Edition – Agnisys Spotlight 2018
IDesignSpec incorporates SystemRDL functionalities
SystemRDL v2.0
SystemRDL is a language used for the design and delivery of intellectual property (IP) products in design systems. SystemRDL semantics supports an entire life-cycle of registers right from the specification, model generation, and design verification, to maintenance and documentation. Registers are not just limited to traditional configuration but can also refer to register arrays and memory.
IDesignSpec incorporates SystemRDL v2.0 functionalities
IDesignSpec now supports SystemRDL v2.0 functionalities by taking input SystemRDL v2.0 file and generating output SystemRDL v2.0 file from multiple inputs which IDesignSpec supports. Features such as:
- Constraints
- Structures
- Memory
- Software access
- Parameters
- Enum
- HDL Path
Are now supported in SystemRDL 2.0 format.
Listed below are the new features implemented in SystemRDL v2.0 with detailed examples:
Parameterized documentation can now be created. The parameters can be resolved at the documentation level.
For example:
reg myReg #(unsigned longint SIZE = 32, boolean REGISTERED = true) {
regwidth = SIZE;
registered = REGISTERED;
field {} data[SIZE];
};
addrmap myAmap {
myReg reg32;
myReg reg32_arr[8];
myReg #(.SIZE(16)) reg16;
myReg #(.SIZE(8), .REGISTERED(false)) reg8;
};
Various specifications of the register can be parameterized and overridden at the time of instantiation. To define Verilog-style parameters in SystemRDL, parameter definitions shall be specified after the component’s name. parameter_definition is defined as follows.
parameter_type parameter_name [= parameter_value]
Structures are supported at the documentation level:
For example:
struct my_struct {
string foo ;
string desc1;
} ;
addrmap top {
regfile some_regfile #( my_struct arg ) {
reg {
desc = arg.foo ;
field {
desc = arg.desc1;
} a ;
} regA ;
} ;
some_regfile #(.arg( my_struct'{ foo: “reg desc”, desc1:”field desc” })) regFA ;
some_regfile #(.arg( my_struct'{ foo: “reg2 desc”, desc1:”field2 desc” })) reggrp2 ;
Structs enable the creation of structured properties for more complex extension of component types.
Expressions are supported with arithmetic operations such as | |, &&, ! etc.
For example:
reg some_reg #(boolean BYTEENB = false) {
ext_byte_enb = !BYTEENB ; //expression
field {} b;
b -> ispresent = false ;
field { ispresent = false ; } d ;
} ;
some_reg #(.BYTEENB(true)) reserved_reg ;
some_reg partially_reserved_reg ;
some_reg not_reserved_reg ;
not_reserved_reg.b -> ext_byte_enb = true ;
not_reserved_reg.d -> ext_byte_enb = true ;
Values can be post assigned during declaration and can also be given in the form of an array:
For example:
addrmap block_def {
hdl_path = “int_block” ;
reg {
hdl_path = `{ “ext_hdl_path”, “externl_reg” } ;
field {
hdl_path_gate = `{ “field1” } ;
} f1 ;
} external_reg ;
reg {
hdl_path = “int_reg” ;
field {
hdl_path_gate = `{ “field1” } ;
} f1 ;
} internal_reg ;
} ;
addrmap top {
hdl_path = “TOP” ;
block_def int_block0 ;
int_block0 -> hdl_path = “int0” ;
block_def int_block1 ;
int_block1 -> hdl_path = “int1” ;
};
Memory can be defined using the keyword ‘mem’ as shown below:
For example:
mem fixed_mem #( unsigned longint word_size = 32, //mem keyword
unsigned longint memory_size = word_size * 4096) {
mementries = memory_size / word_size ; //complex expressions supported
memwidth = word_size ;
} ;
- Different data types are supported such as unsigned long int, Boolean, string etc.
- Constraints are now supported in systemRDL 2.0 format.
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. Constraints can be instantiated within all structural components.
addrmap Admap {
name = “Admap Address Map”;
reg Reg21 {
regwidth = 32;
field {
constraint { this <=10; } Reg21_F1_constraint;
hw = rw;
sw = rw;
} F1[16:0] = 17’h0;
};
reg Reg32 {
regwidth = 8;
field {
constraint { this == 8; } Reg32_F1_constraint;
hw = rw;
sw = rw;
onread=r;
onwrite=w;
} F1[6:0] = 7’h0;
};
};
Summary:
IDesignSpec enables IP/SoC design teams to create code files from the register specification, saving time and producing consistent, quality results. IDesignSpec (IDS) generates System RDL registers right from the user’s specification. Therefore, the user can create various IDesignSpec outputs from the standard input SystemRDL file.
RTL Wrapper in IDesignSpec
Complex hardware IP or SoC can have hundreds and thousands of configuration and status registers. An accurate memory map description and its interface to standard buses are needed by the design, verification, firmware, diagnostics, tech-pubs, and customers.
With the designs getting more and more complex, often additional manual steps are required by the users in an otherwise fully automated specification to code the process. Uncertainty in the development process leads to a lot of time waste and productivity loss.
IDesignSpec enables teams to describe the registers and sequence, in specification once and automatically generate signoff quality standard/custom code and documentation from it. This comes into view when the designer must add application logic outside the IDesignSpec generated RTL Block. With designs having thousands of I/O ports, this manual process is troublesome as it is fraught with danger of bugs creeping into the connections.
To reduce these manual steps, IDesignSpec can accomplish a step further in our new enhancement. With IDesignSpec, the user can not only generate RTL for a block or a chip but can also generate a Wrapper around it. IDS enables teams to describe pins- in specification once and automatically generate signoff quality standard/custom code from it, thus improving team productivity and quality of results. This Wrapper acts like a bridge between the user application logic and IDS generated block/chip level RTL. And the best part is that it is fully automated and has reduced the manual efforts.
Primary Goals of RTL Wrapper:
- Allow users to make the interaction between his/her app logic and IDS generated a block.
- Gives user the flexibility to specify additional pins along with registers.
- Provides more feasibility and reusability for the user.
- Provides time-saving, fully automated, error and bug-free solution to users.
RTL Wrapper in IDesignSpec:
IDesignSpec allows the user to generate an RTL wrapper in addition to the core IDS block and prompts the user to enter more details on the pin connections. IDS helps the user to specify where the pins are directed to and coming from on wrapper to the IDS block. This compelling capability in IDS is accomplished by two properties.
| Name | Possible Values | Purpose | Applies To |
| RTL_Wrapper | True | If set to true, IDS will generate the Wrapper Logic for IDS Core for connection with the user application logic. | Block |
| Wrapper_port | True/applogic | If set to “true” they go to the wrapper and ids block, when set to “applogic” they only appear on the wrapper, and not on the IDS block.
When applied to field it can only be set to “true”. | Field| Signals |
Logic Diagram
Note:
- S1 and S2 both remain inside the IDS generated block but if needed to be brought out, then property wrapper_port=true should be applied to them.
- By default, signals remain inside the block only.
- P1, P2, P3 remain in Wrapper only and not in the block as property wrapper_port=applogic is applied to it.
- If the wrapper_port property is added to a field, then all hardware ports for the field (which are created based on the hardware access specified), will be brought out to the wrapper
Representation of RTL Wrapper:
Non-encoding and broadcast in Indirect Index Register
IDesignSpec (IDS) enables users to create indirect registers. By default, an index register is decimal encoded. For instance, if the index register has value 101, then the 5+1=6th register in the memory or register array is written. But this does not serve the purpose. There is an urgent need for the non-encoded index registers with the capability to write and read multiple registers at the same time (multicast and broadcast).
For example, if the index register has the value 101, then the 0th and 2nd registers are written simultaneously. When reading, the value from all the selected registers are OR’ed together.
Implementation of non-encoding and broadcast in Indirect Register
The example below describes the behavior of simple indirect register where the index register behaves as select line, for which a property “decimal_encoding=false” has been implemented in IDS.
Unicast: For writing and reading from a single register, simply write a one-hot vector in the index register. This is Unicast.
Multicast: If more than one bits are high in the index reg, the corresponding registers are written or read from.
Broadcast: If all bits are set high, then all registers are written. This is called Broadcast.
The same broadcast functionality has also been implemented for decimal encoded index register. If “msb_broadcast”=true property is set, then writing a 1 to the MSB of the index reg’s field will result in a broadcast to all registers.
Note that the field size is 1 more than that required by the register array or memory that is being indirectly addressed.
For example, in the case of an array of 16 addresses, the index field is of size 5 instead of 4 usually required. Writing to the bit 5 will result in writing to all 16 registers.
The register shown below “Reg1” is the Address Register (for the data register Reg1) which contains the property “decimal_encoding=false”, due to which it behaves like a select line. Whenever 1 is written on any bit from 0 to 4 of field F1, the corresponding location in the table is written and the value is stored in the data register.
Reg1 in SystemRDL format:
reg Reg1 {
regwidth = 32;
field {
decimal_encoding = “false” ;
hw = rw;
sw = rw;
} F1[4:0] = 5’h0;
};
The register shown below Reg3 is the Address Register (for the data register Reg3), it contains the property “msb_broadcast=true”, due to which whenever MSB is set to 1 ( i.e 4th bit of the field F1), then all the address location of the indirect register will be written with the Data.
Reg3 in SystemRDL format:
reg Reg3 {
regwidth = 32;
field {
msb_broadcast = “true” ;
hw = rw;
sw = rw;
} F1[4:0] = 5’h0;
};
UVM Output Code:
logic unsigned [63:0] val; //in case of decimal encoding
int unsigned idx;
int unsigned field_size;
uvm_reg_field fields[$];
m_idx.get_fields(fields);
val = fields[0].get();
field_size = fields[0].get_n_bits();
for (int i=0;i < field_size;i++)
begin
if(val[i]==1) begin
m_tbl[i].do_predict(rw, kind, be);
begin //in case of msb_broadcast
logic unsigned [63:0] val;
int unsigned field_size;
int unsigned idx = m_idx.get();
uvm_reg_field fields[$];
m_idx.get_fields(fields);
val = fields[0].get();
field_size = fields[0].get_n_bits();
if(val[field_size-1]==1) begin
foreach(m_tbl[i])
begin
m_tbl[i].do_predict(rw, kind, be);
end
end
else begin
m_tbl[idx].do_predict(rw, kind, be);
end
end
IDesignSpec NextGen™ – The current state of the art in Hardware Software Interface
IDS NextGen™ (IDS-NG) has been created as a new Integrated Development Environment (IDE), which enables users to capture the specification of IP and SoC at an enterprise level. IDS-NG is a multi-platform product and it deals with multiple format specifications such as Register view, Spreadsheet View, Sequence View, and Param View. It is not only capable of handling individual IP and sub-system but can also handle SoC level. Along with this, it is compatible with Word, Excel, IP-XACT, RALF, CSV and System RDL as input and output both. IDS-NG reduces time by generating the entire UVM, SV, and SystemC verification code not only for registers but sequences as well, and that too in one integrated environment. It is an advanced technology based IDE tool which is supported on Windows, Linux, and Mac-based GUI application.
The IDS NextGen product attempts to “understand” the specification using Machine Learning Technology and guide users regarding issues with the register specification, thus helping in creating the standardized specification. Capturing issues in the specification are the extreme form of “Shift-Left” that the industry has been seeing. Agnisys motto is to stop the bug from germinating in the first place so that less time is spent on the debugging which is often very costly. Once the specification is entered, the user can create custom outputs using a template engine. IDS Nextgen now supports all the prevailing input and output formats supported by IDS.
Features: –
- IDS NextGen has its own editor on which user can create specs. As IDS-NG has multi-format support for specifications, the user can interchangeably create specs and switch between any of them. Another vital feature of IDS-NG is that any change in the specification in a particular format is reflected back in all the other formats.
- The user can create IDS Word like specs in Register View and IDS Excel like specs in Spreadsheet View. Additionally, the user can write sequences according to the specifications in Sequence View.
- Yaml file “.yml” based Param view, a human-readable data serialization language for configuration files could be used in many applications for debugging output and document headers.
Register View
Spreadsheet View
Param View
Sequences
- IDS NextGen supports editor System RDL 2.0, hence giving the ability to configure the user’s specification. The user can also generate the desired output from the System RDL 2.0 editor.
- Following features makes IDS-NG one-stop solution for all the problems:
- Faster Speed, with almost 10 times faster than the previous versions of IDesignSpec.
- Errors in the spec are easy to understand and highlighted.
- A single User Interface for capturing all information related to IP/SoC.
- Integrated with existing technologies from Agnisys – IDSWord, IDSExcel, ISequenceSpec, and DVinsight.
- IDS-NG inherits another reliable feature of IDS, that is, “Register Diff”. In Reg diff, the user can compare two IDS input files, differentiate between the specs and can save the results.
- Another feature of IDS-NG that makes it stand-out is “Git Integration”. IDS-NG provides user to integrate projects with their Git Server. With this feature, the user can clone their project into the Git Workspace. IDS-NG makes Git command easy to use with its graphical user interface. The user can run basic Git commands like commit, push, pull, switch/create a branch. Along with this, the user can also view git commit history and changes made in the specifications.
Summary: –
IDS NextGen is a multi-platform Integrated Development Environment tool in which user can create specification using multiple formats and can generate desired outputs. IDS NextGen is one solution for all problems. It is a time-saving tool that supports git integration thus makes it possible for more than one user to work on a single project.
