The IC design ECO process can be summarized as follows: Initially, the RTL is synthesized into a netlist known as the pre-DFT netlist. This netlist undergoes processing by a DFT tool, which inserts DFT logic to generate the DFT netlist. The DFT netlist then proceeds to the backend stage, where a post-layout netlist is generated. If a bug is discovered, the post-layout netlist is compared to a new pre-DFT netlist, known as the Reference netlist, to identify and fix any differences. Since the Reference netlist (Pre-DFT netlist) has no test logic, the test logic within the post-layout netlist needs to be disabled. This is achieved by setting the test mode enable signals to constant values.
However, identifying the specific test mode signals can be challenging. If a SVF file is used in the logic equivalence checker, these DFT constraint signals may be buried within the large SVF file. So the SVF file maybe not a good reference to extract the test mode constraints. Furthermore, the DFT team and the implementation team responsible for ECO are typically separate groups within design companies, adding to the complexity.
To address this issue, GOF ECO provides a solution within the functional netlist ECO process. By utilizing the built-in GUI debug mode, it becomes easier to identify the test mode constraints. Improperly set test mode constraints can result in numerous non-equivalent points appearing in the analysis. To simplify the debugging process, it is advisable to select a non-equivalent point that involves clock or reset pins, as they generally have less complex logic and are easier to debug. Within the GOF shell, which appears after the completion of the ECO script without an 'exit' command, the command 'sch the_noneq_instance' can be executed to load the instance to a schematic for further analysis and debugging.
NONEQ: Instance pin tsp_reg/CK GOF > sch tsp_reg
The instance in the Implementation netlist is loaded into the schematic. By utilizing the 'Load peer gate in other tree' command through a right-click on the instance within the schematic, you can conveniently load the same instance from the Reference netlist as well.
Figure 1: Load both instances
To trace the clock pin on the schematic, utilize the 'Driver Until Non Buffer' fast tracing command. Apply this command to both instances of the Implementation and the Reference to perform clock tracing.
Figure 2: Tracing flop clock pin by fast tracing command
Upon examining the detailed schematic of the clock pins in both instances, it becomes evident that an additional clock MUX cell has been inserted by the DFT tool in the Implementation netlist. The purpose of this MUX cell is to introduce the dft_clock into the logic cone. Consequently, this addition results in a non-equivalence between the clock pins of the respective flops.
Figure 3: Pinpointed the MUX gate inserted by the DFT tool
To resolve the non-equivalent point, you can disable the driver of the selecting signal in the MUX cell. By incorporating the "set_pin_constant" command into the ECO script before executing the "fix_design" command, you can effectively address the issue. This command ensures that the selecting signal remains at a constant value, thereby eliminating the non-equivalent point.
set_pin_constant("test_mode_reg/Q", 0);
fix_design;
