Errors/Warning handling in IDS-NG
By Gitanjali Singh
Introduction
IDS-NG is designed for reliability and offers tools for managing errors and warnings, helping users quickly fix issues and keep the design process running smoothly. The tool alerts users about invalid property names, values, or incorrect applications, providing improved error messages with correction suggestions and documentation links. Additionally, cut, copy, paste, undo, and redo operations are now supported for both single and multiple row/cell selections.
If any property or its value is incorrect, or it is applied on a component where it is not supported, an error will be issued and further processing will stop.
- The default behavior in IDS-NG is that
- When a warning is issued, the tool will not stop and will continue generation of the outputs.
- When an error is issued, the tool will stop further processing.
- By default, if a property name or its value is incorrect/invalid, a warning is issued.
Fig 1 : Warning generated for specifying invalid property “is_rsv1”
Strict Mode / No GUI Warnings
Two new modes are being introduced in the IDS-NG GUI. These modes allow users to override the default behavior of the tool. Both the modes are mutually exclusive and only one of them can be selected. By default, none is turned on.
Fig 2 : Two new modes – Strict Mode & No GUI Warnings
Strict Mode: If any property or its value is incorrect, or it is applied on a component where it is not supported, an error will be issued and further processing will stop. Till all such errors are fixed, the tool will not proceed. Extra information is displayed during this mode to help the user correct the errors:
- If the property name is incorrect, the tool will suggest two closest matching properties. These suggested properties will be clickable, pointing to the documentation page of each.
Fig 3 : Closest matching suggestions for invalid property name
- If the property value is incorrect, the tool will display a list of accepted values (only if the property accepts a fixed set of discrete values).
Fig 4 : Tool displays list of acceptable values and property documentation link
- If the property is applied on a component where it is not applicable/supported, the tool will display the list of components where it is applicable, in the error message.
Fig 5 : Tool displays list of components where the property is applicable.
If a value of property is incorrect, then the tool will flag an error and further processing will stop.
- If Strict Mode is enabled, then additional info will be displayed along with the error. The info includes a list of acceptable values and a link to documentation for more details.
No GUI Warnings:
In this mode, all GUI warnings are skipped, which means IDS-NG GUI will not check for wrong property names, wrong property values or when applied on the wrong component.
Fig 6 : Annotation error when No GUI Warnings mode is selected
Summary
IDS-NG’s robust error and warning handling features ensure users can effectively manage issues in design specification. The tool’s improved error messages, with suggestions and documentation links, assist users in quickly correcting errors. The new modes, such as Strict Mode, and No GUI Warn Mode, provide additional support for error resolution and property management. This will greatly enhance the ease-of-use as well as robustness of the tool. This reduces many days from the end user deadline as the user can debug and fix the input quickly without going through the Agnisys support.
Handling invalid address error in IDesignSpec
By Tanya Jaiswal
Introduction
An invalid address error is an error condition that occurs when a bus transaction attempts to access a memory location or register address that is not defined or does not exist within the specified memory map or register map of the design.
In IDesignSpec(IDS), error assertion is based on the type of bus transaction (read or write) where we can provide the values “read”, “write” or “razwi” (read-as-zero-write-ignore) to our block (addrmap).
However, to support this property in case of assertion for all the component errors, we have introduced a new feature in IDS tools where we can provide the value “invalid_addr_err=all”(supported as a top property).
This property asserts the error for all the components of the addrmap
Available features of the Property:
Property Values:
- The property can take three possible values: ‘read’,’write’, or ‘razwi’.
Assertion Behavior:
Example: When ‘invalid_addr_err’ is set to ‘write’:
Errors will only be asserted for ‘write’ transactions on undefined addresses. Read transactions on undefined addresses will return zero without error assertion.
Generated RTL:
assign emptyaddress0_error_l = block_offset + 'h4; assign emptyaddress0_error_h = block_offset + 'h1F; assign emptyaddress0_error = ((address[addr_width - 1 : 0] >= emptyaddress0_error_l[addr_width - 1 : 0]) && (address[addr_width - 1 : 0] <= emptyaddress0_error_h[addr_width - 1 : 0])&& wr_stb) ? 1'b1 : 1'b0 ;
assign invalid_address_error = emptyaddress0_error ;
assign error = invalid_address_error;
endmodule
Example: When ‘invalid_addr_err’ is set to ‘read’:
Errors will only be asserted for read transactions on undefined addresses. Write transactions on undefined addresses will return zero without error assertion.
Generated RTL:
assign emptyaddress0_error_l = block_offset + 'h4; assign emptyaddress0_error_h = block_offset + 'h1F; assign emptyaddress0_error = ((address[addr_width - 1 : 0] >= emptyaddress0_error_l[addr_width - 1 : 0]) && (address[addr_width - 1 : 0] <= emptyaddress0_error_h[addr_width - 1 : 0])&& rd_stb) ? 1'b1 : 1'b0 ;
assign invalid_address_error = emptyaddress0_error ;
assign error = invalid_address_error | reg_2_write_error;
endmodule
Example: When ‘invalid_addr_err’ is set to ‘razwi’:
Invalid address error will not be asserted for both the write transaction and the read transaction of the bus.
Generated RTL:
wire emptyaddress0_error; wire invalid_address_error; assign invalid_address_error = emptyaddress0_error ; assign error = invalid_address_error; endmodule
Scope:
- The behavior is applied at the block level, ensuring consistency within the addrmap.
Addition of feature in the property :
Example:
In the systemRDL code given below, we have opted for the value of invalid address error to be “all”.
In this scenario, the error will be asserted for all the components within the addrmap, appending all bus transactions.
property invalid_addr_err {type = string;component = addrmap;};addrmap chip_1 {
addrmap Block_1 {
invalid_addr_err = “all”;
reg Reg1 {
field {}f1[15:0] = 16’h0;
field {}f2[31:16] = 16’h0;
};
Reg1 Reg1;
};
addrmap Block_2 {
reg Reg2 {
field {}f1[15:0] = 16’h0;
field {}f2[31:16] = 16’h0;
};
Reg2 Reg2;
};
Block_1 Block_1;
Block_2 Block_2;
};
Generated RTL:
assign Block2_Reg2_f2_r = Block2_Reg2_f2_q; // Field : F2 assign Block2_Reg2_rd_data = Block2_Reg2_rd_valid ? {Block2_Reg2_f2_q, Block2_Reg2_f1_q} : 32'd0; assign emptyaddress2_error_h = block_offset + block_size-1; assign emptyaddress2_error = (address[addr_width - 1 : 0] > emptyaddress2_error_h[addr_width - 1 : 0]) ? 1'b1 : 1'b0 ;assign rd_data_vld = rd_stb; assign rd_data = Block1_Reg1_rd_data | Block2_Reg2_rd_data ; assign request = 1'b1; assign rd_wait = 1'b1;
assign invalid_address_error = emptyaddress0_error | emptyaddress1_error | emptyaddress2_error ;
assign error = invalid_address_error;
Conclusion:
The addition of the “invalid_addr_err” property enriches the IDS tool’s capability to manage error assertions effectively within the hierarchy. By specifying “all” as its value, the property mandates error detection for all components, promoting robust verification and debug processes. This feature aligns with industry standards for ensuring memory and register map integrity in complex digital designs, thereby enhancing overall reliability and performance.
This systematic approach to error management underscores the importance of configurable properties in maintaining design integrity and aligns with best practices in digital system verification and validation.
IDS-Integrate feature for adding wirename in busInterface
By Chavi Rana
Introduction
IDS-Integrate provides a feature to connect multiple blocks/components through bus interfaces. This is achieved using soc_connect API. The ports of the source and destination bus interfaces are connected through system-generated names which sometimes become too long. In order to specify user-defined names for wires connecting each matching port of the bus interfaces in soc_connect API the wirelist is given in the -wire option.
Users can specify the wire names in soc_connect API in the following ways:
- Defining a port-to-wire mapping: Users can specify a port-to-wire mapping for bus ports using either a list (Tcl) or a dictionary (Python). This mapping contains bus port logical names and corresponding user-defined wire names. This list/dictionary is then used in the soc_connect command as shown in the examples below:
TCL Syntax:
soc_connect -source <parent-block-name|driver-inst-name> -dest <parent-block-name|receiver-inst-name> -source_bus_intf <busIntf-name> -dest_bus_intf <busIntf-name> -wire <list-of-logical-name-and-user-defined-name>
TCL Example:
set wireList {{haddr llbg_haddr}
{hsize llbg_hsize}
{hburst llbg_hburst}
{hprot llbg_hprot}
{hwdata llbg_hwdata}
{hwrite llbg_hwrite}
{htrans llbg_htrans}
{hresp tregahb32l_0_hresp}
{hrdata tregahb32l_0_prd}
{hsel llbg_tregahb32l_0_hsel_area0}
{hclk llbg_hclk}
{hresetn llbg_hresetn}
{hready llbg_hready}}
soc_connect -source inst1 -dest inst2
-source_bus_intf AHB_initiator_inst
-dest_bus_intf AHB_target_inst
-wire $wireList
Python Syntax:
soc_connect(source="parent-block-name|driver-inst-name", dest=”parent-block-name|receiver-inst-name”,
source_bus_intf=”busIntf-name”,
dest_bus_intf=”busIntf-name”,
wire=”dictionary-of-port-to-wire-name-mapping”)
Python Example:
wireMap = {"haddr" : "llbg_haddr",
“hsize” : “llbg_hsize”,
“hburst” : “llbg_hburst”,
“hprot” : “llbg_hprot”,
“hwdata” : “llbg_hwdata”,
“hwrite” : “llbg_hwrite”,
“htrans” : “llbg_htrans”,
“hresp” : “tregahb32l_0_hresp”,
“hrdata” : “tregahb32l_0_prd”,
“hsel” : “llbg_tregahb32l_0_hsel_area0”,
“hclk” : “llbg_hclk”,
“hresetn” : “llbg_hresetn”,
“hready” : “llbg_hready” }
soc_connect(source=”inst1″, dest=”inst2″,
source_bus_intf=”AHB_initiator_inst”,
dest_bus_intf=”AHB_target_inst”,
wire=wireMap)
- Defining a template for wire names: Users can specify the wire names in a formatted string and use “%s” for the logical name of the ports, e.g., some_text_%s_some_other_text. In this case, there is no need to provide individual wire names for each port separately.
TCL Syntax:
soc_connect -source <parent-block-name|driver-inst-name> -dest <parent-block-name|receiver-inst-name>
-source_bus_intf <busIntf-name>
-dest_bus_intf <busIntf-name>
-wire <wire-name-prefix>%s<wire-name-suffix>
TCL Example:
soc_connect -source inst1 -dest inst2 -source_bus_intf AHB_initiator_inst -dest_bus_intf AHB_target_inst -wire "init_%s_target"
Python Syntax:
soc_connect(source="parent-block-name|driver-inst-name", dest="parent-block-name|receiver-inst-name", source_bus_intf="busIntf-name", dest_bus_intf="busIntf-name", wire="<wire-name-prefix>%s<wire-name-suffix>")Python Example:
soc_connect(source="inst1",dest="inst2",source_bus_intf="AHB_initiator_inst",dest_bus_intf="AHB_target_inst", wire="init_%s_tar")
Use Case:
Bus interface connection using a bus port to wire name map
Input : IP-XACT components M1 & M2 with M1 having an initiator bus interface and M2 having a target bus interface
Connection : M1 to M2 using bus interfaces with a wire map of bus ports and wire names
Output : Verilog and IP-XACT
Python Script
soc_read(search_path="./ipread/Agnisys/mixed_signal/1.0", file=[“M1.xml”, “M2.xml”])
wireMap = {
“haddr” : “llbg_haddr”,
“hsize” : “llbg_hsize”,
“hburst” : “llbg_hburst”,
“hprot” : “llbg_hprot”,
“hwdata” : “llbg_hwdata”,
“hwrite” : “llbg_hwrite”,
“htrans” : “llbg_htrans”,
“hresp” : “tregahb32l_0_hresp”,
“hrdata” : “tregahb32l_0_prd”,
“hsel” : “llbg_tregahb32l_0_hsel_area0”,
“hclk” : “llbg_hclk”,
“hresetn” : “llbg_hresetn”,
“hready” : “llbg_hready”
}
soc_create(‘top’, name=”Top”, bus=”AHB”)
soc_add(parent=”Top”, name=”M1″, inst=”inst1″)
soc_add(parent=”Top”, name=”M2″, inst=”inst2″)
soc_connect(source=”inst1″, dest=”inst2″,
source_bus_intf=”AHB_initiator_inst”,
dest_bus_intf= “AHB_target_inst”,
wire=wireMap)
soc_generate(“compact”, out=[“v”, “IP-XACT2009″], dir=”ids”)
RTL Outputs
M1.v file
module M1 #( parameter addr_width = 32,
parameter bus_width = 32,
parameter M1_offset = ‘h0
)(
output hsel,
output hclk,
output [2:0] hsize,
input [1:0] hresp,
output [bus_width-1:0] hwdata,
output [2:0] hburst,
output hresetn,
input hready,
output [addr_width-1:0] haddr,
output [1:0] htrans,
output [3:0] hprot, output hwrite,
input [bus_width-1:0] hrdata,
output M1_initiator_hsel,
output M1_initiator_hclk,
output [2:0] M1_initiator_hsize,
input [1:0] M1_initiator_hresp,
output [bus_width-1:0] M1_initiator_hwdata,
output [2:0] M1_initiator_hburst,
output M1_initiator_hresetn,
input M1_initiator_hready,
output [addr_width-1:0] M1_initiator_haddr,
output [1:0] M1_initiator_htrans,
output [3:0] M1_initiator_hprot,
output M1_initiator_hwrite,
input [bus_width-1:0] M1_initiator_hrdata
);
endmodule
M2.v file
module M2 #(parameter addr_width = 32,
parameter bus_width = 32,
parameter M2_offset = ‘h0
)(
//
input hsel,
input hclk,
input [2:0] hsize,
output [1:0] hresp,
input [bus_width-1:0] hwdata,
input [2:0] hburst,
input hresetn,
output hready,
input [addr_width-1:0] haddr,
input [1:0] htrans,
input [3:0] hprot,
input hwrite,
output [bus_width-1:0] hrdata,
//
input M2_target_hsel,
input M2_target_hclk,
input [2:0] M2_target_hsize,
output [1:0] M2_target_hresp,
input [bus_width-1:0] M2_target_hwdata,
input [2:0] M2_target_hburst,
input M2_target_hresetn,
output M2_target_hready,
input [addr_width-1:0] M2_target_haddr,
input [1:0] M2_target_htrans,
input [3:0] M2_target_hprot,
input M2_target_hwrite,
output [bus_width-1:0] M2_target_hrdata
);
endmodule
Top.v file
`include "M2.v"`include “M1.v”
module Top #(
parameter addr_width = 32,
parameter bus_width = 32,
parameter Top_offset = ‘h0
)(
input hwrite,
output hready
);
// Wire names provided by user for bus interface connections
wire llbg_tregahb32l_0_hsel_area0;wire llbg_hclk;
wire [2:0] llbg_hsize;
wire [1:0] tregahb32l_0_hresp;
wire [bus_width-1:0] llbg_hwdata;
wire [2:0] llbg_hburst;
wire llbg_hresetn;
wire llbg_hready;
wire [addr_width-1:0] llbg_haddr;
wire [1:0] llbg_htrans;
wire [3:0] llbg_hprot;
wire llbg_hwrite;
wire [bus_width-1:0] tregahb32l_0_prd;
//wire name defined by IDS-Integrate tool; if output port is
//not connected then a wire will be declared of respective
//width and mapped with the port.
wire wire_inst1_hsel;
wire wire_inst1_hclk;
M1 inst1(
.hsel(wire_inst1_hsel),
.hrdata({bus_width{1’bx}}),
.M1_initiator_hsel(llbg_tregahb32l_0_hsel_area0),
.M1_initiator_hclk(llbg_hclk),
.M1_initiator_hsize(llbg_hsize),
.M1_initiator_hresp(tregahb32l_0_hresp),
.M1_initiator_hwdata(llbg_hwdata),
.M1_initiator_hburst(llbg_hburst),
.M1_initiator_hresetn(llbg_hresetn),
.M1_initiator_hready(llbg_hready),
.M1_initiator_haddr(llbg_haddr),
.M1_initiator_htrans(llbg_htrans),
.M1_initiator_hprot(llbg_hprot),
.M1_initiator_hwrite(llbg_hwrite),
.M1_initiator_hrdata(tregahb32l_0_prd)
);
M2 inst2(
.hsel(1’bx),
.hrdata(wire_inst2_hrdata),
.M2_target_hsel(llbg_tregahb32l_0_hsel_area0),
.M2_target_hclk(llbg_hclk),
.M2_target_hsize(llbg_hsize),
.M2_target_hresp(tregahb32l_0_hresp),
.M2_target_hwdata(llbg_hwdata),
.M2_target_hburst(llbg_hburst),
.M2_target_hresetn(llbg_hresetn),
.M2_target_hready(llbg_hready),
.M2_target_haddr(llbg_haddr),
.M2_target_htrans(llbg_htrans),
.M2_target_hprot(llbg_hprot),
.M2_target_hwrite(llbg_hwrite),
.M2_target_hrdata(tregahb32l_0_prd)
);
endmodule
IP-XACT Output:
Top_design.xml file
<spirit:design xmlns:spirit=”http://www.spiritconsortium.org/XMLSchema/SPIRIT/1685-2009″
xmlns:vendorExtensions=”http://www.agnisys.com/” xmlns:ids=”http://www.agnisys.com/”
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
xmlns:xs=”http://www.w3.org/2001/XMLSchema” xmlns:soce=”http://www.agnisys.com/”>
<spirit:vendor>Agnisys</spirit:vendor>
<spirit:library>mixed_signal</spirit:library>
<spirit:name>Top_design</spirit:name>
<spirit:version>1.0</spirit:version>
<spirit:componentInstances>
<spirit:componentInstance>
<spirit:instanceName>inst1</spirit:instanceName>
<spirit:vendorExtensions>
<spirit:vendorExtension>
<spirit:interconnectionRef>inst1_inst2</spirit:interconnectionRef>
<ids:wireMaps>
<ids:wireMap>
<spirit:logicalPort>
<spirit:name>haddr</spirit:name>
</spirit:logicalPort>
<ids:wireName>llbg_haddr</ids:wireName>
</ids:wireMap>
<ids:wireMap>
<spirit:logicalPort>
<spirit:name>hready</spirit:name>
</spirit:logicalPort>
<ids:wireName>llbg_hready</ids:wireName>
</ids:wireMap>
</ids:wireMaps>
</spirit:vendorExtension>
</spirit:vendorExtensions>
</spirit:design>
Conclusion:
To summarize, the ‘wire’ option in soc_connect API for bus interfaces is used to simplify and shorten the lengthy default names in connections for both RTL and IP-XACT. In IP-XACT, this functionality is supported through vendor extensions.
Hierarchical Sequences Support in UVM and Firmware
Introduction
By Sudhir Bisht
IDS-Validate is revolutionising the way users configure, program, and test devices. This innovative tool streamlines the creation of sequences for various stages of development, including early verification phases, firmware creation, and post-silicon validation. By generating outputs such as UVM sequences for verification, C code for firmware and driver development, SystemVerilog sequences for validation, and CSV formats for Automatic Test Equipment, IDS-Validate ensures a seamless transition from one development phase to the next. Furthermore, it supports the integration of SystemRDL with sequences, accommodating hierarchical sequences similar to hierarchical register models, thereby enabling block-level sequences to be utilised or called at the chip level.
Objective
The primary objective of IDS-Validate is to enhance sequence reusability. Traditionally, sequences are tied to a single register specification, limiting their reuse when integrating block-level sequences at the top level. IDS-Validate addresses this limitation by supporting hierarchical sequences. This approach allows users to create reusable sequences at the block level and seamlessly integrate them at the top level, significantly improving workflow efficiency.
Proposed Solution
IDS-Validate introduces the capability to write sequences at lower levels using register specifications in SystemRDL, which supports a hierarchical register model. This integration, facilitated by the “seq_refpath” property, provides users with the flexibility to write sequences at every level, enhancing the versatility of sequence creation and usage.
Example Implementation:
SystemRDL at IP level
This is RDL at IP Level where we ref a sequence from IDS-NG sequences .
property seq_refpath{type=string; component=addrmap;}; addrmap block1{ seq_refpath="ip1_seq.idsng"; regfile section1 { reg { regwidth=32; field { hw=rw; sw=rw; } f0[2:0]=0; field { hw=rw; sw=rw; } f1[20:3]=0; field { hw=rw; sw=rw; } f2[31:21]=0; } reg0 ; } section1 ; };
Sequence Spec at IP level
We have an in-house GUI tool called IDS-NG, which allows us to specify sequences according to the provided RDL files. Within this tool, we have written initialization sequences for IP-level RDL, which can then be used at the SOC level.
Code for uvm sequence :
These are UVM sequences generated based on the sequences written in IDS-NG.
task body; uvm_reg_data_t section11_reg0_f0 ; uvm_reg_data_t section11_reg0 ; if(!$cast(rm, model)) begin `uvm_error("RegModel : block2_block","cannot cast an object of type uvm_reg_sequence to rm"); end if (rm == null) begin `uvm_error("block2_block", "No register model specified to run sequence on, you should specify regmodel by using property 'uvm.regmodel' in the sequence") return; end rm.section1[1].reg0.f0.write(status, 'h1, .parent(this)); rm.section1[1].reg1[1].f1.write(status, 'h6, .parent(this)); // Call Sequence :: uvm_block2_reset_seq block2_reset_ref.model = model ; block2_reset_ref.init(1, 1, 9); block2_reset_ref.start(m_sequencer); rm.section1[1].reg0.f0.read(status, section11_reg0_f0 , .parent(this)); v1=section11_reg0_f0 ; rm.section1[1].reg0.read(status, section11_reg0 , .parent(this)); v2=section11_reg0 ; endtask: body
System RDL at Chip level
This is a System RDL at the chip level where we reference a sequence from the IDS-NG sequences written for this System RDL.
property chip {type=boolean;component=addrmap;}; property seq_refpath{type=string; component=addrmap;}; `include ip1.rdl; `include ip2.rdl; `include ip3.rdl; addrmap chip1{ chip=true; seq_refpath="ss1_seq.idsng"; block1 block1_1; block1 block1_2; block2 block2_2[9]; block3 block3_1; block3 block3_2[5]; };
Sequence at chip level
These sequences are written for chip level RDL to perform operation at chip level.
FIRMWARE OUTPUT
These are firmware sequences generated based on the sequences written in IDS-NG at chip level .
#include "chip2.h" #include "chip2_init1_iss.h" int chip2_init1(int baseAddress) { int i ; int block2_22_section12_reg10_f1; int block2_22_section11_reg11_f0; int v1; int dim_rd; block2_init(baseAddress + CHIP2_BLOCK2_2_OFFSET(2)); block2_reset(baseAddress + CHIP2_BLOCK2_1_OFFSET); for(i = 0; i < 3; i++){ block2_init(baseAddress + CHIP2_BLOCK2_2_OFFSET(0)); } dim_rd = baseAddress + (BLOCK2_SECTION1_REG1_OFFSET + (BLOCK2_SECTION1_REG1_PER_INSTANCE_SIZE * (0))) + (BLOCK2_SECTION1_OFFSET + (BLOCK2_SECTION1_PER_INSTANCE_SIZE * (2))) + (CHIP2_BLOCK2_2_OFFSET(2)); block2_22_section12_reg10_f1= FIELD_READ(dim_rd,BLOCK2_SECTION1_REG1_F1_MASK,BLOCK2_SECTION1_REG1_F1_OFFSET); if(block2_22_section12_reg10_f1 >){ dim_rd = baseAddress + (BLOCK2_SECTION1_REG1_OFFSET + (BLOCK2_SECTION1_REG1_PER_INSTANCE_SIZE * (1))) + (BLOCK2_SECTION1_OFFSET + (BLOCK2_SECTION1_PER_INSTANCE_SIZE * (1))) + (CHIP2_BLOCK2_2_OFFSET(2)); block2_22_section11_reg11_f0= FIELD_READ(dim_rd,BLOCK2_SECTION1_REG1_F0_MASK,BLOCK2_SECTION1_REG1_F0_OFFSET); REG_WRITE('',block2_22_section11_reg11_f0); } return 0; }
UVM SEQUENCE OUTPUT
These are UVM sequences generated based on the sequences written in IDS-NG at chip level
if(!$cast(rm, model)) begin `uvm_error("RegModel : chip2_block","cannot cast an object of type uvm_reg_sequence to rm"); end if (rm == null) begin `uvm_error("chip2_block", "No register model specified to run sequence on, you should specify regmodel by using property 'uvm.regmodel' in the sequence") return; end
// Call Sequence :: uvm_block2_init_seq
block2_init_ref.model = rm.block2_2[2];
block2_init_ref.start(m_sequencer);
// Call Sequence :: uvm_block2_reset_seq
block2_reset_ref.model = rm.block2_1;
block2_reset_ref.start(m_sequencer);
for ( int i = 0 ; i < 3;i++ )
begin
// Call Sequence :: uvm_block2_init_seq
block2_init_ref.model = rm.block2_2[0];
block2_init_ref.start(m_sequencer);
end
rm.block2_2[2].section1[2].reg1[0].f1.read(status, block2_22_section12_reg10_f1 , .parent(this));
if (block2_22_section12_reg10_f1 >) begin
rm.block2_2[2].section1[1].reg1[1].f0.read(status, block2_22_section11_reg11_f0 , .parent(this));
rm..write(status, block2_22_section11_reg11_f0 , .parent(this));
End
Conclusion
The hierarchical sequence support in IDS-Validate significantly enhances the flexibility and reusability of sequences. By allowing sequences to be written at lower levels and integrated seamlessly at higher levels, IDS-Validate provides a robust framework for efficient sequence management across different stages of development and validation. This innovation not only streamlines the verification and firmware development processes but also ensures consistency and reliability in post-silicon validation.
