Newsletter 2022 Q4 Details

Flopped Interrupt Support in RTL

IDesignSpecTM (IDS) supports the interrupts output without any delay which is a limitation for CDC usage. Sometimes as per the requirement, it is important to provide the delay in the interrupts for the design optimization.
To achieve this objective IDS supports a top property that creates a separate assigned block for each interrupt which causes a delay in the interrupt.

Use Cases

IDS-Word Input

IDS-Excel Input:

IDS-NG Input:

SystemRDL Input:

property intr_status {type=string; component=reg|field;};

property intr_enable {type=string; component=reg|field;};

addrmap block1{

   reg reg1{

       field{

           intr_status=”Channel1”;

           sw=rw;

           hw=rw;

           woclr=true;

       }f1;

   };

   reg reg2{

       field{intr_enable=”Channel1”;}f2;

   };
   reg1 reg1;

   reg2 reg2;

};

 

Generated RTL:

 

module block1_ids#(

   . . .

   . . .

   output reg irq,       // Output interrupt signal

   . . .

   . . .

   wire irq_wire;

   . . .

   . . .

   assign irq_wire = (reg1_f1_q & reg2_f2_q );

   . . .

   . . .

   always @(posedge clk) begin

   if (!reset_l)

       begin

           irq <= 1’b0 ;

       end

   else

       begin

           irq <= irq_wire;

       end

   end          //end always

   . . .

   . .

   .

The property: “intr_out_flopped=true”

 

To generate the flops for the interrupts we have to use +top_property ”intr_out_flopped=true” in the command line or we can apply this property on the top component in the configure window as {intr_out_flopped}.

Conclusion:

 

  • In GUI mode, IDesignSpec supports the intr_out_flopped=true property in the configure window and also at the top component by using any IDS-supported input formats like IDS-NG, IDS-Word, IDS-Excel, SystemRDL, etc.

In batch mode, IDS-Batch supports this property through the top_property command line option.

CDC from the sw side using “custom_sync”

Introduction

The 2-FF chain inside handshake widget module is used to synchronize required control and data signals on the HW interface. On synthesizing RTL it is possible that the place-and-route tool can place these flops far apart thus causing metastability on the signals being synchronised and thus eliminating their purpose.

To resolve this issue the 2-FF chain for register clock and hw clock is put into separate modules named “agni_sync_sw_block” and “agni_sync_hw_block” and the current 2-FF logic is replaced with these modules in required synchronizers. IDS does support custom synchronization (i.e replacing 2-FF chain with back2back sync flop modules) for cdc from the SW side which gives users the flexibility to replace 2-FF chain with back2back sync flop modules.

Figure 1.a. Representation of CDC from sw side

Using property “custom_sync” users can instantiate modules “agni_sync_hw_block” and   “agni_sync_sw_block” inside CDC handshake widget modules which helps users to add custom implementations for their FF chain.

SystemRDL Example

property custom_sync {type=string;component=addrmap;};

property reg_clk {type=string;component=addrmap;};

addrmap Block1 {

     custom_sync = “true”;

     reg_clk = “clk2”;

     reg Reg1 {

       field {

         hw = rw;

         sw = rw;

       }Field1[31:0] = 32’b0;

     };

     Reg1 Reg1 @0x0;

   };

Custom synchronizer widget:

 

module handshake_widget_custom_sync #( parameter bus_width = 32, addr_width = 32, parameter prot =3)

.     .     .

.     .     .

.     .     .

   // Custom 2-FF Synchronizer stage for transaction req cycle

      agni_sync_hw_block #(.data_width(1)) U_SYNC_WIDGET_TRANS_REQ (.clk(clk2),.reset_l(slave_reset_ff1),.data_in(widget_transaction_req_ff0),.data_out(widget_transaction_req_ff2));

      // Custom 2-FF Synchronizer stage for transaction req_rd cycle

      agni_sync_hw_block #(.data_width(1)) U_SYNC_WIDGET_TRANS_REQ_RD (.clk(clk2), .reset_l(slave_reset_ff1), .data_in(widget_transaction_wait_ff0),.data_out(widget_transaction_req_ff2_rd));

   assign clk2_data_en = widget_transaction_req_ff2 & ~widget_transaction_req_ff3;

     assign clk2_data_en_rd = widget_transaction_req_ff2_rd & ~widget_transaction_req_ff3_rd;

      // Custom 2-FF Synchronizer stage for transaction ack cycle

      agni_sync_sw_block #(.data_width(1)) U_SYNC_WIDGET_TRANS_ACK ( .clk(widget_clk), .reset_l(widget_reset_l), .data_in(widget_transaction_req_ff2), .data_out(widget_transaction_ack_ff1));

      // Custom 2-FF Synchronizer stage for transaction ack_rd cycle

      agni_sync_sw_block #(.data_width(1)) U_SYNC_WIDGET_TRANS_ACK_RD (.clk(widget_clk),.reset_l(widget_reset_l), .data_in(widget_transaction_req_ff2_rd), .data_out(widget_transaction_ack_ff1_rd));

.     .     .

.     .     .

.     .     .    

// Custom 2-FF Synchronizer stage for slave res ack cycle

      agni_sync_hw_block #(.data_width(1)) U_SYNC_SLAVE_RESP_ACK (.clk(clk2),.reset_l(slave_reset_ff1),.data_in(slave_response_req_ff2),.data_out(slave_response_ack_ff1) );

      assign slv_rsp_pos = slave_response_ack_ff1 & ~slave_response_ack_ff2;

.     .     .

.     .     .

.     .     .

endmodule

 Conclusion

Custom Synchronisation for cdc from the SW side inside the handshake widget which will replace 2-FF chain with back2back sync flop modules giving users the flexibility to add custom implementations for their FF chain.

Hierarchical Restructuring

IDS-Integrate is envisioned to be a very fast assembler for larger SoC development teams spread around the world. In fact, it’s not just an assembler, but also a generator of components (like bridges and muxes). IDS-Integrate supports hierarchical restructuring to provide a flexibility to rearrange the design by changing parent-child relationship between blocks retaining the connections or ignoring the connections as chosen by the user.

Currently IDS-Integrate is able to read or create complex designs. Hierarchical restructuring feature allows users to modify the hierarchy in the existing design to meet new requirements.

Use Cases

 

A new command, soc_move, is added to IDS-Integrate API to move a block from its parent block to a destination block that could be anywhere in the current hierarchy. This API has following options/switches:

  1. i) -source_inst: this option allows user to specify the block instance to be moved
  2. ii) -dest_inst/-dest: this option allows user to specify the new parent block or block instance where the source instance is to be moved
  • iii) -no_connect: this switch is optional, it indicates that the existing connections are not retained in the changed hierarchy. Absence of this switch indicates that the existing connections have to be retained.

Syntax:

soc_move -source_inst <inst-name> -dest_inst | -dest <inst-name> | <container-name> [-no_connect]

As shown in the below diagram. The first picture (figure A) shows the hierarchy structure with two blocks blockA and blockB are instantiated in a top_block where the block instances are connected with each other and blockA is connected to the top_block as below:

Three ports (output TP1, output TP2, input TP3) in Top_block are connected with three ports (output AP1, output AP2, input AP3) of blockA

Other three ports (output PP1, output PP2, input PP3) of BlockA are connected with three ports (input BP1, input BP2, output BP3) of BlockB

Figure A

Second picture (figure B) shows the blockB moved inside blockA by using below command

Tcl Command

soc_move -no_connect -source_inst “blockB_inst” -dest_inst “blockA_inst”

Python Command

soc_move(“no_connect”, source_inst=”blockB_inst”, dest_inst=”blockA_inst”)

After execution of the above command, the connection will be removed and the source block will be moved to the destination block.

Figure B

Third picture (figure C) describes the restructuring of blockB inside blockA with connection. The direction of ports inside the blockB is reversed as blockB is instantiated inside blockB and peer connection is replaced with hierarchical connection.

Conclusion:

 

Hierarchical Restructuring is a versatile feature which leads IDS-Integrate to the next level in the EDA industry. Hierarchical restructuring refers to the functionality by which a user can move various blocks across the hierarchy.

SystemRDL Editor in IDS-NG

IDS-NG supports a full-featured SystemRDL editor allowing users to work with RDL files in a convenient and effective manner.

SystemRDL is an open source text based descriptive language that focuses exclusively on registers. Apart from basic editing features like copy, paste, select all, find, find & replace, automatic indentation, keyword highlighting, etc, IDS-NG supports following key features that makes the RDL editing very efficient and intuitive:

  • RDL syntax highlights
  • Context sensitive RDL & IDS property hinting with usage description and documentation link wherever applicable
  • Template hinting according to applicable component
  • Template insertion with or without parameter
  • 0 all feature support like:- parameter overriding, dynamic assignment, stride syntax (+=) etc.
  • Code fold
  • Error while check/generate through IDS-NG, pointing to the line number along with some RDL standard messages

Fig 1: SystemRDL Editor View

Fig 2: Nodes hierarchy suggestion in SystemRDL Editor View

Fig 3: SystemRDL property suggestion with description

Fig 4: IDS property suggestion with description

Fig 5: Error Display in SystemRDL Editor View

IDS-NG Editor is built upon the Ace Editor which is a community project under BSD license. It is an embeddable code editor which matches the features and performance of the native editors. Its native features are available for other coding languages as well, for example, Markdown, Verilog, JSON, UVM, HTML, Tcl, etc.

Fig 6: Markdown Output in IDS-NG

Fig 7: Verilog Output in IDS-NG

Fig 8: JSON Output in IDS-NG

Conclusion

 

IDS-NG is enhanced with a SystemRDL editor which uses a text editor to open RDL files and it is designed to support context sensitive hinting, provide a wide range of features such as basic editing capabilities, indentation, keyword and syntax highlighting, RDL property hinting, template hinting and insertion, basic RDL syntax error highlighting, RDL2.0 feature support, code folding, error checking and generation, and support for IDS UDPs. Furthermore, most of the editing features and syntax highlighting is supported for many other languages that IDS deals with. These additions to IDS-NG are expected to enhance the developer’s experience by providing a powerful and advanced code editing feature.

Scroll to Top