GOF vs Conformal ECO

GOF ECO has proven to be superior to Conformal ECO in several ways based on 50 industry use cases provided by users. The cases involve netlists ranging in size from 100K to 2.5M instance count, and they all use a reference netlist to fix the netlist under ECO without external assistance or guidance files.

In terms of ECO patch size, stability, and effectiveness, GOF outperforms Conformal in most cases. Out of the 50 ECO use cases, GOF produced much smaller ECO patch sizes in six cases, while Conformal only achieved better patch sizes in two cases. However, in some cases, Conformal combined small logic gates into more complicated gates, such as combining four OR and AND gates into an AOI gate, which resulted in a smaller number of ECO patches but did not save actual area.

GOF proved to be more reliable than Conformal in obtaining equivalent ECO result netlists, achieving equivalent results in all three cases where Conformal failed to do so. In fact, Conformal even encountered a hang-up in one of these cases. However, both GOF and Conformal were unsuccessful in fixing one major ECO case. The remaining 38 cases yielded similar results between GOF and Conformal.

GOF has very good control of memory usage starting from Version 7, comparing with previous versions, and the above use cases all have similar memory usage between GOF and Conformal. Nevertheless, Conformal remains faster than GOF, with GOF being slower by an average of 50%. Conformal performs much faster than GOF when the netlist size is small, with a gate count of around 200K or less. However, Conformal loses its speed advantage when the netlist gate count exceeds 500K.

Conformal Performance Bugs

There are at least five known performance issues with Conformal ECO. Firstly, it does not perform well on netlists generated by Synopsys Design Compiler Topographical (DCT) or Design Compiler Graphical (DCG). Secondly, it has a bug in handling complex combinational logic for ECO. Thirdly, it struggles with mapping replicated flops. Fourthly, it doesn't do a good job when fixing ECOs that involve DFT scan chains. And fifthly, when dealing with Design Ware, Conformal adds too many redundant ECO gates if instance names change during synthesis.

DCT/DCG Boundary Optimized Netlist

Synopsys Design Compiler Topographical (DCT) and Design Compiler Graphical (DCG) are tools that optimize netlists for floorplanning, routing, and timing. However, they can make functional ECO more difficult. During synthesis, they can change hierarchical module boundaries to add clone ports or invert the original ports' phase and merge flops.

Conformal ECO has issues with ports mapping in functional ECO. As shown in Figure 1, Conformal ECO incorrectly maps the clone ports added by DCG/DCT, resulting in three times more gates being used than necessary to fix the logic.

Figure 1: Boundary mapping affects ECO quality

The synthesis tool adds cloned ports that do not have a one-to-one mapping between the Reference Netlist and the Implementation Netlist. When the ECO tool attempts to make these ports equal, it can result in redundant gates being added to the ECO patch or even make the final logic not equivalent.

Figure 2: DCG/DCT Boundary optimized netlist

However, GOF is able to map the clone ports correctly, ensuring that only the exact non-equivalent point is fixed.

Figure 3: GOF result, only the red spot is fixed

Complicated Combinational Logic ECO Bug

In RTL, combinational signals are often optimized after synthesis, making it difficult to locate the ECO point manually. To address this, a Logic ECO tool is used, which employs comprehensive algorithms to accurately locate and measure the size of the ECO patch, thus determining the quality of the ECO tool.

However, Conformal ECO has a bug in handling complicated combinational logic ECO. In some cases, it cannot determine the exact ECO location, resulting in a much larger ECO patch than necessary. In other cases, Conformal can pinpoint the ECO location, but produces redundant logic in fixing the ECO spot.

For instance, Figure 4 illustrates a single combinational signal ECO case, where a signal in the middle of a combination logic cone has been modified. The ECO tool should find the exact location in the Implementation Netlist and replace the original logic with the new logic in the Reference Netlist.

Figure 4: Single error, red spot is the failing logic

The following Verilog pseudo-code shows an example where an if-condition is changed in a big state machine, and a new combinational signal is added into the if-condition:

always @(*) begin
   case(current_state[7:0])
     IDLE: begin
             if(comb_sig0) next_state = START;
             else next_state = IDLE;
           end
     START: begin
             if(comb_sig1&comb_sig2|!comb_sig3) next_state = STATE1;
             else if(comb_sig4&comb_sig5&!comb_sig6|eco_comb_sig) next_state = STATE2;
             else if(comb_sig7|comb_sig8&!comb_sig9) next_state = STATE3;
             ...
end
assign eco_comb_sig = pcie_mode && beacon_status; // New combinational signal

It is highly probable that Conformal ECO is unable to accurately locate the exact location to fix the combination signal change, or it may find the location but use an excessive number of gates to fix the logic, thereby affecting the surrounding logic unnecessarily. This issue with Conformal ECO occurs in at least three out of the 50 cases.

Figure 5: Conformal ECO result, dark green spots are the redundant fixes

GOF excels at identifying the precise ECO location and producing an optimal ECO patch. Its advanced algorithms enable it to accurately pinpoint the exact location of the ECO fix, resulting in an ECO patch that is not only the most optimal but also ensures that the surrounding logic is minimally impacted.

Figure 6: GOF result, only the red spot is fixed

Replicated Flops Mapping Bug

Replicated flops are multiple flops in a circuit that have the same function, with equivalent data and set/reset pins. Replicated flops can be present in the original RTL code or generated by the synthesis tool during physical optimization runs to improve timing and area.

The ECO tool should map these replicated flops as the same key points. However, Conformal ECO seems to have difficulty in mapping these replicated flops in some cases.

For instance, in Figure 7, a flop named "reg1" can have an equivalent replicated flop "reg1_rep" after synthesis. At times, Conformal ECO fails to treat these as equivalent key points.

Figure 7: Flop replicated after synthesis

During ECO, RTL is modified and re-synthesized. The flop reg1 and its replicated flop reg1_rep have one fanout 'U2' swapped, as shown in Figure 8, and they are actually logically equivalent.

Figure 8: Flop reg1 and reg1_rep have fanout swapped

Since Conformal ECO treats reg1 and reg1_rep as different functional key points, it results in a redundant ECO fix logic.

One simplest use case to fail Conformal is like this:

  //IMP Implementation Netlist
  module top(a,b,c,d,clk,out);
   input a,b,c,d,clk;
   output out;
   AND2X1 u0(.A(a),.B(b),.Z(ab));
   DFFQX1 b_flop(.D(ab),.CK(clk),.Q(out0));
   XOR2X1 u1(.A(out0),.B(d),.Z(out));
   DFFQX1 a_flop(.D(c),.CK(clk),.Q(out_floating));
  endmodule
  //REF Reference Netlist
  module top(a,b,c,d,clk,out);
   input a,b,c,d,clk;
   output out;
   AND2X1 u0(.A(a),.B(b),.Z(ab));
   DFFQX1 a_flop(.D(ab),.CK(clk),.Q(out0));
   XOR2X1 u1(.A(out0),.B(d),.Z(out));
  endmodule

The two netlists are functionally equivalent, however, the default key point mapping used by Conformal is not able to handle this scenario effectively. GOF, on the other hand, is able to identify the floating flop a_flop in the Implementation Netlist and correctly map b_flop in the Implementation Netlist to a_flop in the Reference Netlist. This is a common occurrence in ECOs and can pose a problem for Conformal.

DFT Friendly ECO

An ECO is considered unfriendly to DFT if it impairs DFT functionality or diminishes DFT coverage. On the other hand, a DFT friendly ECO must ensure that DFT functionality remains unaffected, scan chain is intact, and clock and reset signals are manageable.

During functional ECO, the DFT logic should be set to inactive mode to prevent any functional changes from affecting it. However, in some cases, ECOs involving DFT paths may unintentionally impact the DFT logic.

ECO insertion in back-to-back flops

One example of this is when ECO insertion is performed on back-to-back flops in a partial scan chain, such as the one shown from A_REG to D_REG, with B_REG and C_REG forming a back-to-back path. In this scenario, it's acceptable for C_REG to be a non-scan flop prior ECO and DFT is good.

Figure 9: Scan Chain with back-to-back flops

If an ECO inserts combinational logic between B_REG and C_REG in a scan chain that goes from A_REG to D_REG, and C_REG is a non-scan flop, then the scan chain is broken, as shown in Figure 10. Conformal ECO breaks DFT by directly inserting logic in the back-to-back path in this type of ECO, without considering the need to keep the scan chain.

Figure 10: ECO inserts logic into back-to-back path

To address the scan chain breakage caused by the ECO, GOF's solution involves changing the type of C_REG from a non-scan flop to a scan flop, and connecting the scan chain properly as depicted in Figure 11.

Figure 11: GOF fixes the DFT logic by reconnecting up the Scan Chain

Pick the right signal for DFT

To ensure DFT logic remains inactive during functional ECO, the DFT_MODE signal is set to zero. However, some nets may be equivalent but not suitable for DFT, which can lead to DFT being broken. For instance, in Figure 12, an ECO must select either the mux_in or mux_out signal to drive a reset pin of a flop. Although the two signals are equivalent, Conformal ECO selects mux_in, which breaks DFT. In contrast, GOF can identify the MUX and chooses mux_out as the correct signal for the reset pin, thus maintaining the integrity of DFT logic.

Figure 12: Pick the right signal to maintain DFT logic

Settable resettable flop swapping

When performing functional netlist ECO, it is common to swap between resettable and settable flop types. This operation is assumed to be a simple and straightforward swapping of the same flop instance. However, in figure 13, Cadence Conformal introduces a redundant approach by using a new settable type flop reg1_1 instead of directly converting the original flop to a settable type. The new flip-flop reg1_1 drives the original functional circuit, while the old flip-flop reg1 drives the scan chain fanout reg2. This approach presents two major issues. Firstly, the new flip-flop reg1_1 is not included in the scan chain. In situations where there are many such reset/set flop swaps (around 0.2% of all flop count), there will be an approximately 0.2% loss in ATPG at-speed coverage. Secondly, Conformal LEC fails to consider the new flip-flop reg1_1 as an equal key point of reg1, resulting in numerous non-equivalent points in the equivalence report after the ECO.

Figure 13: Cadence Conformal causes DFT coverage loss in resettable/settable flop swapping ECO

While, in the ECO shown in Figure 14, GOF utilizes a direct approach of changing the flip-flop type from resettable to settable, resulting in the preservation of the scan chain and ensuring that DFT coverage remains unaffected.

Figure 14: Resettable flop swapped to settable type in ECO

One error is common in Cadence Conformal ECO, "Error: Duplicate fanout branch # for net 'IN#'"

The issue typically arises in a scenario where a flip-flop (REG1) has its Q output connected to the parent level, and the same output is also connected to the scan input (SI) pin of another flip-flop (REG2). When an ECO is performed on REG1, such as changing its type to a set-type flip-flop, this can cause an error to occur in Conformal ECO, potentially leading to the tool stopping its operation.

Figure 15: Cadence Conformal errors out in boundary wire changes

Design Ware Handling Bug

By default, Synopsys DC synthesis produces hierarchical modules when writing out Design Ware. However, when there are changes to the RTL, the instance names assigned to the Design Ware by DC may differ in a subsequent run. For example, suppose a design has three adder arithmetic elements named add_0, add_1, and add_2. After making RTL changes, a second synthesis may assign the three arithmetic elements with instance names add_1, add_3, and add_4. This means that the first adder takes the instance name of the third adder in the new synthesis.

In the Implementation Netlist, the first adder is referred to as add_0, and an ECO change has been made to it. However, during synthesis, the first adder has been renamed to add_1 in the Reference Netlist.

Figure 16: Design Ware instance names changed during synthesis

The optimal outcome of the ECO should be to insert a single inverter into the input of the add_0 module. However, Conformal exhibits poor performance in handling this type of ECO. When it meets the new instance (add_3), all gates are flattened and added as new ECO gates. Additionally, several new full adder cells are added as a result of the inverter gate.

On the other hand, GOF remaps the Design Ware instances if the two netlists don't have a full instance mapping of the combinational modules, including Design Wares. As a result, GOF's final outcome is an ECO with a single inverter inserted, which is optimal.

Conclusion

Based on the comparison between Conformal and GOF for ECO cases, it appears that GOF is a more efficient and reliable tool for ECO implementation. The issues with Conformal, such as poor performance in dealing with certain ECOs and bugs that affect its stability and performance, suggest that GOF is a better option for designers looking to achieve smaller patch sizes and more stable ECO runs. Overall, it seems that GOF is the more effective tool for implementing ECOs when compared to Conformal.


Follow us:
NanDigits.com US | NanDigits.cn China
© 2023 NanDigits Design Automation. All rights reserved.