Timing Check after functional netlist ECO
HEIDI ZHENG
Manager at NanDigits, Functional Netlist ECO, Functional Safety Fault Verification
Determining the extent of timing impact caused by a significant ECO in a large functional netlist is crucial. It is important to identify how the logic timing is affected and pinpoint the critical path. For example, when incorporating an arithmetic adder into combinational logic without any pipeline, it is highly likely that a setup timing violation may occur. In such cases involving substantial data paths, a swift timing report would be immensely beneficial.
The latest release, version V10.6, of GOF introduces a timing check feature specifically designed for ECO instances. This feature examines whether the functional modifications have any timing impact on the logic and identifies whether the ECO instances reside within the critical path.
If the timing report after applying the functional netlist ECO reveals violations, the basic timing ECO method can be immediately employed. There are several straightforward approaches to address timing issues, such as increasing the size of the cell driver, inserting a high-driving buffer, or adjusting the clock delay between the startpoint and endpoint. The most fundamental method to rectify timing is by sizing up the cell driver. If the timing check passes without violations, it is likely that timing will be met during the subsequent place and route stage. However, if all cells in the violated path have already been maximally sized and there are still timing violations, it becomes challenging to close timing during the back-end place and route stage. In such cases, it may be necessary to modify the architecture of the functional netlist ECO to prevent the occurrence of the violated long path.
The GOF API, report_timing, offers a rapid timing report mechanism for functional netlist ECOs. As an example, let's consider a functional ECO where timing violations arise due to the utilization of low driver cells. By employing the GOF report_timing API, the resulting report is presented below:
Startpoint: u_mbist/cycle_cnt_reg_0
? ? ? ? ? ? (rising edge-triggered flip-flop clocked by osc_ext)
Endpoint: u_mbist/rd_for_cmp_reg
? ? ? ? ? ? (rising edge-triggered flip-flop clocked by osc_ext)
Path Type: max
Point? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Incr? ? ? Path
-----------------------------------------------------------------
clock osc_ext (rise edge)? ? ? ? ? ? ? ? ? ? ? ? 0.0000? ? 0.0000
clock network delay (ideal)? ? ? ? ? ? ? ? ? ? ? 0.0000? ? 0.0000
u_mbist/cycle_cnt_reg_0_/CP (DFCN0Q)? ? ? ? ? ? ?0.0000? ? 0.0000 r
u_mbist/cycle_cnt_reg_0_/Q (DFCN0Q)? ? ? ? ? ? ? 0.3538? ? 0.3538 r
u_mbist/eco_23_09/ZN (IND2D0)? ? ? ? ? ? ? ? ? ? 0.1306? ? 0.4844 r
u_mbist/eco_23_10/ZN (ND2D0)? ? ? ? ? ? ? ? ? ? ?0.1084? ? 0.5929 f
u_mbist/rd_for_cmp_reg/D (DFCN0Q)? ? ? ? ? ? ? ? ? ? ? ? ? 0.5929 f
data arrival time? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0.5929
clock osc_ext (rise edge)? ? ? ? ? ? ? ? ? ? ? ? 0.7800? ? 0.7800
clock network delay (ideal)? ? ? ? ? ? ? ? ? ? ? 0.0000? ? 0.7800
clock uncertainty? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?-0.1000? ? 0.6800
u_mbist/rd_for_cmp_reg/CP (DFCN0Q)? ? ? ? ? ? ? ? ? ? ? ? ?0.6800 r
library setup time? ? ? ? ? ? ? ? ? ? ? ? ? ? ? -0.1528? ? 0.5272
data required time? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?0.5272
-----------------------------------------------------------------
data required time? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?0.5272
data arrival time? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?-0.5929
-----------------------------------------------------------------
slack (VIOLATED)? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? -0.0656
Following the initial timing report, the GOF API change_gate can be utilized. By applying the GOF sizing up script to enhance the weak driver cells within the violated path, the timing violation is eliminated.
Startpoint: u_mbist/cycle_cnt_reg_0
? ? ? ? ? ? (rising edge-triggered flip-flop clocked by osc_ext)
Endpoint: u_mbist/rd_for_cmp_reg
? ? ? ? ? ? (rising edge-triggered flip-flop clocked by osc_ext)
Path Type: max
Point? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Incr? ? ? Path
-----------------------------------------------------------------
clock osc_ext (rise edge)? ? ? ? ? ? ? ? ? ? ? ? 0.0000? ? 0.0000
clock network delay (ideal)? ? ? ? ? ? ? ? ? ? ? 0.0000? ? 0.0000
u_mbist/cycle_cnt_reg_0_/CP (DFCN2Q)? ? ? ? ? ? ?0.0000? ? 0.0000 r
u_mbist/cycle_cnt_reg_0_/Q (DFCN2Q)? ? ? ? ? ? ? 0.3280? ? 0.3280 r
u_mbist/eco_23_09/ZN (IND2D1)? ? ? ? ? ? ? ? ? ? 0.1477? ? 0.4757 r
u_mbist/eco_23_10/ZN (ND2D2)? ? ? ? ? ? ? ? ? ? ?0.0692? ? 0.5449 f
u_mbist/rd_for_cmp_reg/D (DFCN0Q)? ? ? ? ? ? ? ? ? ? ? ? ? 0.5449 f
data arrival time? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0.5449
clock osc_ext (rise edge)? ? ? ? ? ? ? ? ? ? ? ? 0.7800? ? 0.7800
clock network delay (ideal)? ? ? ? ? ? ? ? ? ? ? 0.0000? ? 0.7800
clock uncertainty? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?-0.1000? ? 0.6800
u_mbist/rd_for_cmp_reg/CP (DFCN0Q)? ? ? ? ? ? ? ? ? ? ? ? ?0.6800 r
library setup time? ? ? ? ? ? ? ? ? ? ? ? ? ? ? -0.1347? ? 0.5453
data required time? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?0.5453
-----------------------------------------------------------------
data required time? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?0.5453
data arrival time? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?-0.5449
-----------------------------------------------------------------
slack (MET)? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0.0004
To execute the report_timing command, it is essential to establish a basic setup of constraints. This includes defining crucial elements such as create_clock, set_input_delay, set_output_delay, and set_false_path. These constraints provide the necessary information for the tool to accurately analyze the timing behavior of the design and generate a basic timing report.
read_design("-ref",?"reference.gv");# Read in Reference Netlis
read_design("-imp",?"implementation.gv");# Read in Implementation
set_top("SOC_TOP");?# Set the top to?the most top module SOC_TOP
fix_design;
create_clock("soc_clock", 0.8);
set_input_delay("tx_in*", 0.5);
set_output_delay("tx_out*", 0.5);
set_false_path("-to", "ahb_read_reg*");
report_timing();
GOF's Timing Check API offers a rapid turnaround for timing fixes during functional ECO. It enables designers to promptly identify potential issues that may arise in the subsequent place and route stage due to the current ECO. This efficient approach significantly improves the effectiveness of ECO processes and reduces the number of iterations required. For more detailed information, please visit https://nandigits.com