Newsletter 2023 Q1 Details
Dynamic HTML
Introduction
New in IDesignSpec is a feature which allows users to create a single HTML file for all repeat instances of the same component. It can be applied to all descendent chips or blocks with the help of an IDS property named “doc_repeat_compact =<samplename>[%d]”. Users can apply this property on chip and block instances which are repeated more than once, thereby saving a lot of time and memory during generation. Additionally, only one file is generated for the same instance which has the repeat property. The user can see all the expanded instances via the repeated indices. When a user clicks on any of the indices it will redirect to the same file for all the repeated instances along with their respective name and address.
Use Case
Suppose there is a block that repeats 10 times. If users want to expand all indices of the same block instance, then they can apply the “display_name=<samplename>[%d]” property, which creates files equal to the repeat value. This process occupies unnecessary memory and increases generation time. To address these issues, a new property called “doc_repeat_compact =<samplename>[%d]” has been introduced which will expand all the indices into a single file for the block/chip, thereby optimizing the memory and reducing the generation time.
Benefits:
- Generates only one file for all repeat indices of the same instance.
- By creating a single file for all repeated indices of the same instance, lots of time and memory consumption are saved during generation.
- Users can visit any indices of all instances using the search feature and it will redirect to the same file.
Features:
- All indices of each repeated instance data is provided to the user in the search box as well.
- Users also get the hierarchical path for the instance on top of the file which indicates the hierarchy from the top.
- Users can backtrack the parent and ancestor instance upon clicking on the instance link from the hierarchy path.
- Users can see all expanded instances for each repeated instance of child component in the parent Table of Content along with their indices.
SystemRDL
property chip {type = boolean; component = addrmap;};
property doc_repeat_compact {type=string; component=addrmap;};
addrmap gpal{
chip = true;
addrmap pcie_complex{
addrmap ddr_top{
regfile dsu{
reg CNTR{
field {sw=rw;hw=rw;} f1;
};
CNTR CNTR;
};
dsu dsu;
};
ddr_top ddr_top;
};
pcie_complex pcie_complex [10];
};
addrmap cypress{
chip=true;
gpal gpal[5];
gpal->doc_repeat_compact=”gpal_%d”;
gpal.pcie_complex->doc_repeat_compact=”pcie_complex_%d”;
};
Conclusion
The new feature in IDS enables users to create a single HTML file for all repeated instances of the same component, which can be applied to descendant chips or blocks using the “doc_repeat_compact” property. By applying this property to instances that are repeated more than once, users can save time and memory during generation. Additionally, this feature generates only one file for the same instance with repeat property, and users can view all expanded instances with respect to their repeated indices. When clicking on any indices, users are redirected to the same file for all the repeated instances with their respective names and addresses.
Support for creating array of instances using repeat in IDS-Integrate API translating into genvar and generate in Verilog output
Introduction
A new feature in IDS-Integrate now allows users to add instances of a block in a parent block using an API soc_add. Users can add multiple instances of the same block in a parent block by using multiple soc_add API in the Tcl/Python script. The API soc_add is enhanced to support adding an array of instances of a block using a single soc_add API. To connect an array of added instances, simply use the soc_connect API. The user enhancement for this new capability is shown below in Figure A.
Figure A describes the possibility of parallel connection between parent and array of block instances. Each block instance of the array connects with the parent block. This
shows symmetrical instances and connections. The syntax of using this option is shown below.
Syntax:
soc_add [-type block] -parent <block_name> -name <block_name> -inst <instance_name> -repeat <number_of_instances>
Where,
-type can be port, parameter, bus and block, default value is block if the option is not specified.
-parent is the name of an item which acts as a container for the instance being created.
-name is the name of the module (if applicable) of this item in the memory but not an instance; this name can be used later in the flow to create instance(s) of this item.
-inst is the name of the instance being added.
-repeat this option allows users to specify the length of the array of instances.
Use Cases
TCL Input
…
…
soc_add -type block -parent top_blk -name blk -inst blk_inst -repeat 8
soc_connect -source {top_blk.x[7:0]} -dest_inst {blk_inst[7:0].a}
soc_connect -source {top_blk.y[7:0]} -dest_inst {blk_inst[7:0].b}
soc_connect -source_inst {blk_inst[7:0].c} -dest {top_blk.z[7:0]}
soc_generate -out {v} -dir ids
Generated RTL
blk.v
module blk(
input a,
input b,
output c
);
endmodule
top_blk.v
`include “blk.v”
module top_blk(
input [7:0] x,
input [7:0] y,
output [7:0] z
);
generate
genvar loop1;
for(loop1 = 0; loop1 < 8; loop1 = loop1+1)
begin : generate_block_identifier
blk blk_inst_loop1(
.a(x[loop1]),
.b(y[loop1]),
.c(z[loop1])
);
end
endgenerate
endmodule
Conclusion
IDS-Integrate is enhanced with an API soc_add which enables users to add an array of instances of the same block in a parent block, rather than connecting them with the parent in a more-time consuming symmetrical manner using Tcl/Python script. This enhancement saves time and effort, thereby improving the user’s experience.
Tunable Flow Addition in HTML
Introduction
This document captures the requirement of allowing users to specify tuned reset values to the fields in the RDL specification. Tunables are used by operational firmware (FW) as a means of communicating register default reset value changes defined by architecture or design. It allows alignment between design, verification, and FW without human interaction. Different registers can be tuned at different timestamps during the boot process. These timestamps are referred to as configuration phases in this document and they can be numbered as phase0, phase1, phase2, and so on.
In the example shown below, IDesignSpec supports capture of the desired tunability through three properties named treset, tdesc, and tphase to adjust the register default reset value without changing the hardware properties and functionality during post silicon validation.
- treset: Indicates the default value that should be applied on the field at boot time. Users can apply treset values either in binary, decimal, hexadecimal, or octal.
- tphase: Indicates the phase in which the treset shall be applied at boot time.
- tdesc: Indicates the description updated for the tunable fields.
Users have the option to include individual columns for these properties by specifying their names as arguments in the “doc_add_field_col” property.
IDS provides the tunable properties as part of the HTML output for users’ reference. A sample input specification in RDL and corresponding outputs in different supported formats are illustrated in the following section.
Use Cases: IDS-Word Example
IDS-NG Example:
SystemRDL Example:
reg my_reg {
doc_add_field_col = “treset,tphase,tdesc”;
regwidth = 64;
field {
fieldwidth = 8;
hw = r;
sw = rw;
}f1;
field {
fieldwidth = 8;
hw = r;
sw = rw;
tphase = “Phase-3”;
treset = 0x5;
reset = 0x3;
desc = “This is my field F2”;
tdesc = “This is tuned field F2”;
}f2;
field {
fieldwidth = 16;
hw = rw;
sw = r;
tphase = “Phase-8”;
treset = 0x6;
reset = 0x2;
desc = “This is my field F3”;
}f3;
field {
fieldwidth = 16;
hw = r;
sw = rw;
treset = 0x1;
reset = 0x4;
tdesc = “This is tuned field F4”;
}f4;
};
addrmap top {
name = “top”;
my_reg my_reg;
};
Generated HTML:
Generated Reduced HTML:
Conclusion:
IDesignSpec provides users with three properties: treset, tdesc, and tphase, to adjust the register default reset value without altering the hardware properties or functionality during post silicon validation. These tunable properties are included in the HTML output for user reference, as shown in a sample input specification and corresponding outputs in supported format.
Unaligned register decode for registers
RegGroups do not have this constraint since a decode signal is generated individually for each register.
Extra decoding logic, including comparators, is necessary if external RegGroups are not aligned to suitable address bounds. IDS supports external RegGroups that are appropriately aligned in order to encourage optimized designs.
Example of usage of decode_unaligned:
IDS-NG:
System RDL:
`ifndef IDS_UDP
property decode_unaligned{type = boolean; component = addrmap|regfile|reg;};
`endif
addrmap d_unalignd {
name = “d_unalignd Address Map”;
reg ext_rg0 {
decode_unaligned=true;
regwidth = 8;
field {
hw = rw;
sw = rw;
onread=r;
onwrite=w;
} et_f1[7:0] = 8’h0;
};
reg ext_rg1 {
decode_unaligned=true;
regwidth = 16;
field {
hw = rw;
sw = rw;
onread=r;
onwrite=w;
} f_ex[15:0] = 16’h0;
};
reg ext_ram {
decode_unaligned=true;
regwidth = 32;
field {
hw = rw;
sw = rw;
onread=r;
onwrite=w;
} ex_r1[31:0] = 32’h0;
};
external ext_rg0 ext_rg0 @0x0;
external ext_rg1 ext_rg1 @0x1;
external ext_ram ext_ram @0x3;
};
In the above example, there is a top component “d_unalignd” having three external registers, where all three external registers apply the property “decode_unaligned =true”.
RTL output impact:
.
.
.
assign ext_rg0_offset = block_offset +’h0;
assign ext_rg0_decode = (address[d_unalignd_address_width- 1: 0] == ext_rg0_offset[(d_unalignd_address_width) – 1 : 0]) ? 1’b1 : 1’b0;
.
.
assign ext_rg1_offset = block_offset +’h1;
assign ext_rg1_decode = (address[d_unalignd_address_width- 1: 1] == ext_rg1_offset[(d_unalignd_address_width) – 1 : 1]) ? 1’b1 : 1’b0;
.
.
assign ext_ram_offset = block_offset +’h3;
assign ext_ram_decode = (address[d_unalignd_address_width- 1: 2] == ext_ram_offset[(d_unalignd_address_width) – 1 : 2]) ? 1’b1 : 1’b0;
.
.
Conclusion
IDS includes support for unaligned register decode, enabling the generation of high-level address bits to decode unaligned registers. This feature is particularly valuable for HDL designers, as it allows them to decode register addresses using only the minimum LSB address bit, reducing their reliance on expensive comparators. By leveraging this functionality, designers can not only more efficiently and cost-effectively decode register addresses in their designs, but also ensure greater design optimization.
