The last thing you want after detailed routing is to spend a lot of time finding and fixing signal integrity (SI) problems. You can minimize SI issues with good prevention techniques in design planning, but you also need an efficient back-end sub-flow for detecting and fixing the problems. As part of this sub-flow, you need the ability to perform incremental what-if modeling of fixes in static timing analysis (STA) to take advantage of an STA tool's fast run times. Sometimes you can also save time by making fixes manually.
These techniques can help minimize the number of iterations through the SI analysis/repair sub-flow. No matter how well integrated these steps are, the full sub-flow is required to ensure that SI problems are fixed. However, incremental what-if modeling of fixes (whether automatic or manual) in STA can save a great deal of time by showing that a fix will probably work. This article focuses on such analysis and repair techniques that help shorten this critical process.
Static SI Analysis
Only after detailed routing can the extraction tool provide accurate parasitics values with the cross-coupled effects that are required for a meaningful crosstalk delay analysis in an STA tool such as the Synopsys® PrimeTime® SI tool. Note that the ideal approach is to address timing violations without SI considerations first, then analyze SI effects. Otherwise, you can expect longer run times and more analysis effort to sort between structural non-SI effects versus route adjacency and SI effects. The prescription for a fix may be the same in some situations and entirely different in others depending on the magnitude of the violation, physical constraints and other circumstances.
In the real world, however, it is not always practical to insist on distinguishing between the two types of timing violations and focus on one without knowledge of the other. For example, a change that addresses a non-SI timing problem may affect cell placements in a way that creates a major SI issue or vice versa. Therefore, you often need to address both types of violations in parallel and balance the tradeoffs. Timing violations have to be fixed, whatever their source. The engineering change order (ECO) process goes back and forth with many handoffs, so you may end up taking more time if you insist on fixing "regular" and SI violations serially.
The PrimeTime SI tool analyzes both timing errors and noise due to crosstalk as well as IR drop. It calculates noise bumps based on the steady-state behavior of a victim driver rather than the victim's switching behavior. The primary set of parameters is the I/V curve data from the library model. Although switching behavior is not included in noise analysis, the tool uses methods such as arrival-window analysis and logical correlation to improve accuracy. You can also apply user-defined exclusion directives. Bear in mind that the height of a noise bump is only part of the equation. The bump's energy (determined by both height and width) actually determines the effect of the noise on logic cells.
As for crosstalk-induced timing-error detection, a critical aspect of this work is to apply the correct settings in both extraction and STA. The control of parasitics filtering and extraction accuracy in a sign-off extraction tool such as the Star-RCXT™ tool greatly affects the run time and timing accuracy in a sign-off-accurate analysis tool. The analysis tool generally provides additional controls such as electrical filter settings, net reselection parameters and iteration loop exit criteria to manage runtime and timing accuracy.
The filtering steps improve runtime performance by removing influences that have a negligible impact on timing, based on a set of threshold criteria. Electrical filtering removes some inconsequential noise bumps, and the settings are based on the process technology and standard cell library.
SI Analysis Methodology
In SI analysis, the STA tool must evaluate all of the possible timing relationships among all possible aggressors and victims. This evaluation is enormously complex for a number of reasons. Aggressor nets may be victims of other aggressors, for example. Because such an analysis would take far too long to cover every possible combination of nets in a large design, a practical analysis focuses on victims that show a substantial change due to crosstalk.
The simplest way to focus on these nets is to use an iterative process. The first iteration analyzes all nets without considering timing windows. This iteration is thus the most pessimistic. Subsequent iterations reduce the pessimism by considering the timing relationship between victims and aggressors. Net re-selection criteria determine which nets are analyzed in the next iteration. The exit criteria determine when the tool should stop refining victim/aggressor timing relationships and end the analysis.
Nets retain their crosstalk delta delays from the iteration in which they were last evaluated. Since re-selection reduces analysis pessimism by refining victim/aggressor timing relationships, nets that pass through more iterations have less pessimistic delay values. Analyzing more nets in more iterations can thus reduce the number of nets that you need to fix, but analysis runtimes can become prohibitive.
In the case of the PrimeTime SI tool, you can use several mechanisms for controlling net re-selection. If you specify paths with negative slack (slack_mode_reselection), you ensure that all nets on violating timing paths are reselected for further refinement in the next iteration. This choice does not cover unconstrained but relevant nets such as clock nets, but the latest version of this tool has a command to identify and re-select clock networks automatically by setting si_xtalk_reselect_clock_network true. This command is useful because re-selection based on a certain amount of change in stage delay (delta_delay_reselection) can cover clock nets but also reselects many non-critical nets.
You can also apply several mechanisms for controlling exit criteria. A simple approach is to specify a fixed number of iterations based on the following experiment. While analyzing one design block, track the net re-selection statistics to see when the number of re-selected nets no longer declines significantly. If that point is at the third iteration (which is usually the case), set the exit criteria to three iterations for the other blocks in the design.
Before accepting the STA results as the final word about which nets need to be fixed, note that multiple endpoints that violate in STA may be caused by the crosstalk delay on a single victim net. Using a script to identify such bottlenecks can greatly simplify and reduce the effort to close timing. For each violating endpoint, the script should identify all the nets whose crosstalk delta delays add up to the slack by which the endpoint violates. If you reduce the crosstalk delta delays for those nets to zero, you eliminate the violation of the endpoint. After processing all violating endpoints, the script must uniquify the identified nets and sort them by frequency of occurrence on paths and crosstalk delta delay. You can then easily see which nets you actually need to fix.
Post-Route SI Problem Fixing
As with all design methodologies, a primary goal of SI problem fixing is to minimize the number of iterations through the sub-flow. Three main steps are required for a complete iteration through this part of the flow: parasitics extraction, static timing analysis and design changes intended to fix problems.
The signal integrity ECO loop begins after detailed route, when specific crosstalk issues can be analyzed. Within the loop, the layout parasitics are extracted and the timing/noise effects are calculated by a static timing analyzer.
You can ensure that SI problems are fixed only by running the full sub-flow, but you can improve the likelihood of success by modeling fixes in STA. The what-if analysis provided by the STA tool allows you to try different fixes quickly. Once you have identified the probable fixes, you then model and evaluate the changes in the SI sub-flow to make sure that all of the complexities of SI interactions have been satisfied.
For automatic repair of SI problems at the sign-off stage, the PrimeTime SI tool drives the Astro™ router with a constraints file that identifies nets on which the STA tool has detected violations. The router can fix SI problems by spacing nets further apart to minimize cross-coupling among nets for the higher-ranked victim and aggressor pairs. (Net spacing is usually reserved for the last few and small violations and comes after other fixes.)
Additional sign-off fixing can be done using buffering solutions such as upsizing/downsizing drivers and/or inserting buffers. You may need to apply these techniques to a few nets manually, however, due to the different requirements of the sign-off and implementation tasks (more on this later). Spacing nets further apart is the least disturbing method, but it may not work in highly congested areas (exactly the areas where crosstalk tends to occur most).
Even without STA modeling, you can run some quick experiments with the target technology to discover how much delta delay you can fix with a particular net spacing. Double-spacing a net may correct 20 to 25 ps of delay at 130 nm, for example.
You can also manually upsize drivers without too much trouble if the upsizing does not greatly affect net topology. Buffer insertion usually has a greater impact on placement and is often needed. It may also be feasible to downsize the driver on the aggressor net. Although this last method may cause other problems, it does work well for fixing hold violations.
These types of manual fixes can prove handy because of inherent differences in the SI sign-off and implementation tasks. The router can share a common delay calculation with the STA tool for analysis, but the router requires a faster method for incremental optimization. An SI sign-off flow is therefore needed to address situations in which the STA tool detects violations that the router does not see.
Semi-automatic tcl scripts are used for running the following sign-off flow with the Prime Time SI tool and the Astro physical implementation tool. First, the STA tool provides incremental update capabilities for timing/SI issues to speed up the sign-off flow. Specifically, the tool's SI bottleneck analysis (report_si_bottleneck) closely resembles its regular timing bottleneck analysis. In the SI bottleneck analysis, the tool reports the most problematic nets with respect to both crosstalk delay and noise, thus simplifying the task of identifying which nets to fix.
Further, what-if analysis in this tool helps with problem resolution. Insert_buffer and size_cell provide the ability to change the netlist, and subsequent write_changes generates the change that was tried in the pt_shell. The additional command set_coupling_separation assumes the effect of net spacing.
After the use of these commands, the tool generates a timing report that reflects the changes. You can then take the results into the Astro physical implementation tool to perform ECO placement and routing. Finally, extraction provides the parasitic data for the final STA.
Bear in mind that each iteration of the back-end analysis/repair sub-flow takes a fair amount of time because it must be complete. That is, it must evaluate all possible SI interactions that could cause a failure in your design-an enormously complex analysis. You can save time with what-if modeling in STA. Further, remember that healthy timing margins allow you to ignore crosstalk-related delays that are well within your margins-an especially useful consideration at 90 nm and below, where many small SI delays cannot be fixed.
By Todd Beck and Richard Nouri. (Beck is a Senior Staff Consultant at Synopsys Professional Services specializing in SOC integration, chip-level STA, chip I/O timing, SI analysis and timing closure; Nouri has over 20 years of experience in the electronics industry, including high-speed board-level and ASIC design and has worked for Synopsys Professional Services developing and executing implementation methodologies for various customers since 2000.)
Go to the Synopsys, Inc. website to learn more.