HTML Component Search Feature in IDS

Introduction

IDS supports a feature in HTML that enables users to conveniently search for components based on their respective addresses. This feature significantly improves the user experience by facilitating fast access to specific components within the HTML output.

Searchable Components

The enhanced functionality allows users to search for various components, including, Chip, Block, Section, & Register.

Advantages of Address-Based Searching

Searching components by address in HTML offers several advantages over the traditional search by component name:

Efficient Navigation:

Utilizing the address to navigate to specific locations within the document enables users to make direct jumps to the desired component.

There could be multiple instances of a component so search by name may have many results while search by address provides a unique result.

Time-Saving Process:

Direct access to components via their addresses significantly reduces the time spent searching for and locating specific components, enhancing overall efficiency.

By incorporating this feature into HTML outputs, we aim to optimize component navigation and enhance the overall usability of our platform. Users can now leverage address-based searching for a more efficient and productive workflow.

Use Case 

SystemRDL Example:

property chip {type=boolean;component=addrmap;};
addrmap chip5{
 chip=true;
 addrmap {
   regfile {
      regfile {
        reg {
         field {}f1;
        }regA[3];
      }file_2[4];
      reg {
         field {}f1;
      }regB;
   }file_1[2];
 }block1[10];
};
addrmap chip4{
 chip=true;
 chip5 chip5;
};
addrmap chip3{
 chip=true;
 chip4 chip4;
};
addrmap chip2{
 chip=true;
 chip3 chip3;
};
addrmap chip1{
 chip=true;
 chip2 chip2;
};

Command Line: 

idsbatch test.rdl -out htmlalt2 -if -if_html -if_html_section -preserve -dir check -top_property "doc_repeat_compact=true;" -top "chip:top" 

Generated HTML:

 

Overview of HTML generation When generating HTML output, you’ll notice a convenient feature situated in the top left corner: the “Search by Address” mode checkbox. To initiate the address-based search capability, simply click on this checkbox. Follow these steps to activate address-based search: locate the checkbox in the top left corner of the generated HTML interface, click on “Search by Address,” and patiently wait for the indicator to turn green, signalling that the address-based search mode is active and ready for use. Once activated, you can start searching for existing components within the HTML output using their respective addresses. 

 

Conclusion:
Address-based component searching in HTML enhances user experience by streamlining access to specific elements, saving time and optimising workflow efficiency. This feature allows users to efficiently navigate and find components using their respective addresses, providing a direct and productive approach. We’re committed to continuously improving usability and refining this functionality to meet evolving user needs, ensuring an enhanced platform experience.

Glue logic in IDS-Integrate 

Introduction

Glue logic refers to the digital circuit/components used for interconnection between ports of different blocks or IP’s. The glue logic can be basic digital logic gates/operations (AND, OR, XOR and NOT) & MUX or some other combinational/sequential digital logic. Multiplexers are supported to be used as glue logic in IDS-Integrate connection API.

The goal of glue logic connection is to allow users to connect ports of blocks/IP’s using MUX. Connections with glue logic operations are made in a single command by enhancing soc_connect API.

Multiplexer:

Users can connect ports of two blocks through a multiplexer in soc_connect API by specifying a list of ports in the source option, a single port in the destination option and a port/signal name in condition option. The ports specified in source can be scalar or vector but the width of source ports must be the same as the width of destination port and the input/output ports of the mux.

Syntax:

soc_connect -source {<source-name_1> <source-name_2> …. <source-name_N>} -dest <dest-name> -condition <condition-signal-name>

Example:

soc_connect –source {input.p1 input.p2 input.p3 input.p4} –dest output.q –condition sel
soc_connect –source {input.p1[0] input.p1[1] input.p2[2] input.p3[3]} –dest output.q[0] –condition sel

soc_connect –source {input.p1[0:3] input.p2[0:3] input.p3[0:3] input.p4[0:3]} –dest output.q[0:3] –condition sel

where,

-source-name_x specifies list of “block-name.port-name” of the source blocks or instances of blocks that are either initiator or driver
-condition-signal-name specifies the signal name to be used as a select line for the mux. Its width depends on the number of inputs using the formula “sel-width=log2(num_inputs).

Block Diagram of Logic operation

Considering a basic use case, there is one top block with the name of Top, and other three blocks of the names Initiator_1, Initiator_2 & Target. Block Initiator_1 has output ports, of the names X and Y of which X is unconnected. Block Initiator_2 has an output port, of the name P and Q of which Q is unconnected. Block Target has an input port, of the name M and N of which N is unconnected. So, as per requirement output port Y of Initiator_1 and output port P of Initiator_2 are connected to M port of Target using Glue logic(AND gate). Users can use different logic operations like AND, OR and XOR.

So, as per block diagram, the connections can be specified with glue logic (AND) as shown below:

soc_connect -source “Initiator_1.Y & Initiator_2.P” -dest Target.M

 

Use Case   

TCL Input

soc_create -name Top -top

soc_create -name Initiator1 -port {output X, output Y}
soc_create -name Initiator2 -port {output P, output Q}
soc_create -name Target -port {input M, input N}

soc_add -parent Top -name Initiator1 -inst I1_inst
soc_add -parent Top -name Initiator2 -inst I2_inst
soc_add -parent Top -name Target -inst T_inst
soc_connect -source {I1_inst.Y I2_inst.P} -dest T1_inst.M -condition sel
soc_generate -out v -dir ids

Generated RTL

module Initiator1(
  output X,
  output
);
endmodule

module Initiator2(
  output P,
  output Q
  );
endmodule

module Target(
  input M,
  input N
  );
endmodule

module Top(
  input sel
  );
  wire wire_T_M_pins;
  wire wire_T_N_pins;
  wire wire_I1_inst_X;
  wire wire_I1_inst_Y;
  wire wire_I2_inst_P;
  wire wire_I2_inst_Q;
assign wire_T_M_pins = sel ? wire_I1_inst_Y : wire_I2_inst_P;
Initiator1 I1_inst(
  .X(wire_I1_inst_X),
  .Y(wire_I1_inst_Y)
);
Initiator2 I2_inst(
  .P(wire_I2_inst_P),
  .Q(wire_I2_inst_Q)
);
Target T_inst(
  .M(wire_T_M_pins),
  .N(wire_T_N_pins)
);
endmodule     

Conclusion

IDS-Integrate is enhanced in which users can connect ports of two blocks through a multiplexer using soc_connect API by specifying a list of ports in the source option and a port/signal name in condition option.

Datasheet name format

Introduction

The datasheet contains only the registers’ names and access information, along with the bus information. If there are no specific details for any other hierarchy, this causes the duplication issue in case of the same register name.

In the RTL and Cheader outputs, there is a feature with the help of “rtl_name_format” and “cheader_name_format” property which can remove the duplicacy of register name, in case two same registers appear under different blocks, now in datasheet output as well this feature has been supported property name is datasheet.name_format .

Since the register name in the resulting datasheet output only contains the basic register name, it creates no issues, when the register names are all different, but if two or more such registers are of the same name, i.e., duplicacy at any level of hierarchy, then it causes issues.

For this case of the name duplication, the top property datasheet.name_format can be used 

Usage

IDS provides an easy way to generate datasheet output. To use this feature, the datasheet keyword is used in the output command. 

Syntax: 

idsbatch <filename> -out “worddatasheet” -dir <output dir_name/path>

Example: 

idsbatch test.xlsx -out worddatasheet -dir ids -top_property "datasheet.name_format=%c%b%s%r"

Users can use this property in the command line as well. 

On executing the above command a .docx file with input file name will be generated in the ids folder in the current directory. 

Functionality

Here, upon using the property datasheet.name_format, the values for chip level and block level will be, %c%b%s%r and %b%s%r respectively.

Example 

 

Generated Output

Output file will represent chip and block level data with its hierarchical definition in a rectangular box. Each component is mentioned with a box and this box contains component details (i.e., type, name, size, address, offset, end address and bus). Each box is linked with its child component and the child component can collapse and expand on a single click on the parent component.

Conclusion 

Using this property, the actual hierarchy information is achieved for the register name.

To overcome the issue of the duplicate name, a new property datasheet.name_format top property has been used. It  will display the register names in the format specified in the property. Using this property, users can include hierarchical names (i.e., parent-name and block-name) to differentiate registers with the same names.

Byte access errors for external registers or Unregistered Fields

Introduction

Byte access is the ability to write individual bytes of data within a large data word. It is the logic that controls which bytes on a data bus are enabled for writing during a transfer operation. It determines which specific bytes of a data word should be transferred or modified.

The byte enable signals typically consist of a set of control lines that correspond to each byte in the write data bus. When a byte enable line is asserted, the corresponding byte in the data bus is enabled for writing.

IDesignSpec™ supports a property ‘external_byte_acc_err’ that generates an error signal while accessing the external register when any of the ‘byte_enable’ control lines is equal to zero. Further, this error signal goes to the bus.

Sometimes designers require hardware status bits to be accessed by software without being registered inside the IDS generated block. This functionality can be achieved by adding the property ‘registered=false’ to the field.

Or designers can implement a register manually outside the IDesignSpec™ generated RTL. To indicate such a register, the ‘external’ property in the template is set to ‘true’. As a result, IDesignSpec™ creates ports to interface with the external register. 

The property ‘external_byte_acc_err’ can be applied to the external register or to the unregistered fields with the property ‘registered=false’.

Sometimes, the size of the bus transfer is not partial while completing the write transaction. Therefore, there must be a way to notify the DV engineer regarding the partial access to the bus transfer. IDesignSpec™ provides bus error acknowledgements such as external logic response error (ext_error), which creates a port for error from external. The property ‘ext_error’ can also be used with the property ‘external_byte_acc_err’.

In the case of unaligned memory access, when N bytes of data start from an address that is not evenly divisible by N, the property ‘decode_unaligned’ is used to align unaligned memory access. Further, the generated decode signal will ensure that the correct peripheral device is selected for the transaction, and the byte enable signals specify which bytes within the data word are being accessed or modified. Hence,  property ‘external_byte_acc_err’ can be combined with property ‘decode_unaligned’.

 

Figure A:  Wave-diagram of byte access error transmission

Example:

IDS-NG:

 

Output Verilog :

 . . .
  . . .
   wire reg1_rd_valid;        // Read Valid
   wire [bus_width-1 : 0] reg1_rd_data;        // Read Data
    wire reg1_error;
    wire external_byte_err;
   output reg1_enb; // REGISTER ENABLE
  . . .
// REGISTER(EXTERNAL) : REG2 SIGNALS
  . . .

    wire reg2_error;
 .   .   .
   assign reg1_error = (reg1_wr_valid && (byte_enb != 4’hf))?’h1:’h0;
  .   .   .

   assign reg2_error = (reg2_wr_valid && (byte_enb != 4’hf))?’h1:’h0;
 .   .   .
   assign rd_data = int_rd_data | ext_rd_data;
     assign external_byte_err = reg1_error | reg2_error ;
  . . .
    assign error = external_byte_err;
  . . .

Conclusion:

Adding an error signal when a valid write signal is asserted and any of the “byte_enable” control lines equals zero while accessing an external register or unregistered fields This signal is finally assigned to the “error” signal, which further goes to the bus.

 

Scroll to Top