Crosstalk Noise Analysis and Repair Methodology with PrimeTime-SI

Asia Pacific RegionWireless & Mobile System GroupMotorola Semiconductor Products SectorSu-Fen.Wei@motorola.com

Abstract

The challenge of Signal Integrity Closure is becoming the key issue for Deep Sub-Micron design, especially at 0.13m and below. A proper and complete methodology is very important to avoid, analyze, and resolve this issue in a tight project schedule.

This paper discusses how to avoid, analyze, and repair the Crosstalk noise (functional & delay) in our latest Dragonball design flow. It concentrates on our practical experience in how to use PrimeTime-SI to analyze the noise-induced delay. Then the repair (ECO) process is discussed, which also includes: the issues we met, the results we got, and the lessons and experiences we learned.

1 Introduction

In Webster’s Dictionary, “integrity” is defined as “The state of being unimpaired”. In IC design, signal integrity means the electronic signal is unimpaired with regard to the functionality. It has very a broad of effects, such as: Crosstalk, IR drop, EMI (electromagnetic interface) resulted from Antenna Effect, Hot Electron Device Degradation, … etc. Among them, Crosstalk is particularly critical, since Crosstalk induced noise can generate glitch, which may disturb the signals, and cause the functional failure. On the other hand, Crosstalk noise can affect the path delay and transition time on nets, and finally cause the timing violations.

Under this situation, the traditional design flow only with basic STA (static timing analysis) will leave many Crosstalk induced failures undetected before chips are taped out, and it may cause catastrophes ultimately. So we are highly motivated to establish a really feasible and reliable methodology, which includes Crosstalk avoidance, analysis, and repair.

Motorola’s Dragonball chips are a serials of embedded microprocessor used in PDA and Smart-Phone. In this project, which uses 0.13m process, we do Crosstalk avoidance floorplan, placement and routing. After that, we incorporate Synopsys’ PrimeTime-SI (PTSI version 2002.09) into post-layout STA flow to analyze the Crosstalk induced delay, and then feed all useful PTSI information back into Silicon Ensemble to do repairs. Moreover, we go back even

further to adjust floorplan and placement to mitigate this problem, when the routing tool alone cannot solve it.

This paper covers all the above topics, and stresses on the PTSI timing analysis repair flow.

1.1 Introduction of Crosstalk induced noise

Crosstalk is the undesirable electrical interaction between the physical adjacent nets due to capacitive cross coupling. The effect of Crosstalk on an ASIC depends on both logic and physical design. As dimensions continue to scale down, and more layers of metal routing are used, the physical structure of routing becomes high packing density, thus the cross-coupling capacitances between nets increase significantly. At the same time, the interconnecting wires get scaled and become narrower, so the parasitic capacitances to the substrate become less dominant, and the coupling capacitances become a larger fraction of total wire capacitance. Meanwhile, the clock speeds increase over 100MHz, the fast rise time causes unintentional switching, slowdown or speedup among the very close neighboring nets, so the Crosstalk effect is more severe.

Two terms are used when analyzing a net for Crosstalk noise: aggressor and victim. A victim is a net that receives undesirable cross-coupling effect from nearby ones. The nets that are cross-coupled to a victim are called aggressors.

There are two types of Crosstalk noise: Functional Noise and Delay Noise. A functional noise occurs when the noise is injected to a victim net and causes it to glitch. Not every glitch in a design can lead to chip failure because the build-in noise immunity of digital circuit comes to rescue. Only if the glitch propagates through the circuit and finally gets latched on to a register element (flip-flop or latch), the circuit alters, and a functional failure happens.

The second type of Crosstalk noise is Delay Noise. This occurs when the victim nets and aggressor nets are switching simultaneously, causes the transition delay of the victim net to be altered. The altered transition delay will cause noise induced delay problem, which will influence the path delay and the transition times on nets, and then lead to a timing failure (Setup/Hold).

In above Figure 1-2, Net B is the victim. Net A, and C are aggressors. Because of capacitive cross-coupling, the transitions on net A and net C can affect the time when the transition occurs on net B. A rising-edge transition on net A can cause the transition to occur later on net B, possibly contributing to a setup violation for a path containing B. Similarly, a falling-edge transition on net C can cause the transition to occur earlier on net B, possibly contributing to a hold violation for a path containing B.

There are five electrical parameters that determine the magnitude of these Crosstalk effects:

(1) Coupling capacitance between interconnects.

(2) Driver strength of the victim and aggressor net.

(3) Relative switching interval.

(4) Total capacitance of the interconnect.

(5) Total resistance of the interconnect.

1.2 Introduction of Dragonball chip

The chip introduced in this paper is the newest generation of Dragonball family. It is a very powerful design with the features of the advanced and power-efficient ARM926EJ-S™ core operating at speed up to 400MHz. It integrates WLAN, Bluetooth feature, USBOTG, PCMCIA/CF, MPEG4 Codec, smart LCD controller (maximum resolution is 800*600), SDRAM controller, flash memory controller, MMC/SD host controller, CMOS sensor interface and other rich suit of peripherals (such as four UARTs), so it can support a rich multimedia experience. It also provides high level of security through security controller, secure RAM and security algorithm accelerator, and digital rights managements.

As a typical SOC design, the chip uses both hard and soft IPs. The gate account is about 400 Million. The process is 5-mental-layer 0.13m .

The physical integration team in Suzhou design center is responsible for the two hard-block’s release, which contains all back-end work, including SI analysis and repair. One module is enhanced Multimedia Accelerator (eMMA). It has 191751 nets, and 217869 cells. The other module is Symmetric/Asymmetric Hashing And Random Accelerators (Sahara), which implements private key encryption algorithm for whole chip’s security purpose. Sahara has 95231 nets, and 103454 cells. Both these two modules have memories blocks, and the fastest AHB Bus Clocks run up to 133MHz.

2 Crosstalk Avoidance

For this project, the whole design cycle is composed of floorplan, placement/optimization, and routing. Crosstalk avoidance is performed from the beginning of the floorplan stage, as well as in placement/optimization, and routing stages.

2.1 The Crosstalk Preventive FloorPlan

Both the eMMA and Sahara modules have more than one memory blocks, and the data bus nets connecting between memories and corresponding BIST logic are often highly Crosstalk-affected because of the high area congestion rate. So proper collocation of memory blocks can alleviate the Crosstalk problem. For Sahara module, it has 10 memory blocks, and all of them share a single BIST controller. Quite a few nets have SI problems.

So we re-adjust positions of the memory blocks, this will be presented in detail in section 4.3.

2.2 The Avoidance Strategy in Placement and Optimization using Physical Compiler

We use the following strategies for the Crosstalk avoidance during the placement and optimization in PC:

(1) Tighter slew constraints to control transition time. Slow transition on victim nets leads to Crosstalk problem on them. In order to avoid this, during Physical Synthesis in PC, the max_transition is set to 0.5ns. The idea behind it is to limit Crosstalk problem by reducing the sensitive timing windows of nets. But it has the side effect, since achieving faster slew rate may increase layout area and the power consumption. The 0.5ns has already been a tradeoff between the area/power and the Crosstalk/timing by taking all factors into the consideration. Table 2-1 shows the influence of the max_transition value changes on delay, functional Crosstalk, and Area for the eMMA module, in which max_fanout is restricted to 60.

(2) Do not use the “weak” cells from the library. Each weak cell is a potential source of delay uncertainty. So in our methodology, all “weak cells” are not used at the synthesis stage.

(3) Limit maximum fanout number on regular nodes. We set max_fanout threshold to 60 except clock, scan_enable, and top-level reset, and create buffer trees on high-fanout nodes.

(4) Upsize the driver of most likely victim nets (e.g., the driver cell of the data bus nets in memory BIST).

In addition, there are some other good ideas from related papers for reducing the influence of Crosstalk:

(1) Use uniform strength drivers at the pre-route stage.

(2) Limit and control the placement of strong drivers, because each strong driver is a potential aggressor.

(3) Define maximum capacitance rule fore each library cell, and it has to take into account that coupling capacitance could increase interconnect capacitance and cause delay uncertainty.

2.3 The SI driven routing

We use the guidelines to do a SI driven routing:

(1) Use SI preventive option in WROUTE to perform a Crosstalk aware routing.

(2) Limit the distance of neighboring wires in parallel. SE is used for routing, and we limit the parallel wire length to 150mm. This is proven to be an efficient and proper setting to reduce the coupling capacitance in our design.

(3) Rule_driven routing. From the experience we learnt, the clock nets and data bus/address bus nets are critical nets from the perspective of Crosstalk effect. But it seems to be a contradiction that we cannot set double (2X) spacing rule to all these net since the congestion has already been worse in the space around those nets. So we set the double space constraints only to those victim nets whose delta delay is over 0.06ns from the first PTSI timing analysis.

3 Crosstalk Analysis

3.1 Crosstalk Analysis Flow

The whole Crosstalk analysis flow is showed as figure 3-1.

3.2 Full Coupling Capacitance Extraction using StarRC-XT

To prepare for Crosstalk analysis, we need to ensure that all coupling capacitances are extracted. StarRC-XT is used to perform 2.5D parasitic extraction. StarRC-XT is faster and more accurate

than STAR-RC. It consumes less memory, and can provide more accurate parasitic in RSPF/DSPF/SPEF format. And the latest released version (2003.03) of StarRC-XT can directly export the SBPF format file for faster timing analysis. In our project, the extraction format is SPEF. We set proper extraction threshold when extracting coupling capacitance. The parameters in StarRC-XT are as below:

COUPLING_ABS_THRESHOLD: 1e-16

COUPLING_REL_THRESHOLD: 1e-02

3.3 Crosstalk Induced Functional Glitch Analysis

The first step in our Signal Integrity flow is achieving traditional PrimeTime timing clean before Crosstalk-included analysis. Then we analyze the functional noise, and fix functional failed net first.

From version 2003.03, PrimeTime SI has the ability to analyze Crosstalk induced functional failure too. But our project is launched earlier than the release of this new feature. So we use Motorola’s in-house tool: ClariNet to analyze the functional glitch. It

has been used extensively within several design groups in Motorola for identifying noise issue. After analysis, it can generate repair directives for SE.

By default, ClariNet makes the most conservative assumption that all aggressors drivers switch to create perfectly aligned noise pulse. In reality, timing constraint can prevent this over conservation from occurring. ClariNet allows the user to specify an active window for each net to restrict the timing when a net can switch. A TCL script is used to transform the PrimeTime SI timing window to Text format, and then import to ClariNet.

3.4 PTSI Crosstalk Delay Analysis

After the functional noise repair is done, we use PrimeTime SI to analyze the delay noise. PrimeTime SI performs Crosstalk analysis in conjunction with regular PrimeTime analysis flow. With Crosstalk analysis enabled, it performs a timing manageable Crosstalk delay analysis.

3.4.1 Read in analysis data and do parasitic annotation

The inputs to PrimeTime SI are post-routed Verilog netlist, coupled SPEF, and Synopsys constraints. PrimeTime SI is also able to convert Standard Parasitic Exchange Format (SPEF) format parasitic data to Synopsys Binary Parasitic Format (SBPF). Data in SBPF format occupies less disk space and can be read much faster than the same data stored in SPEF format. Moreover, for the very large design whose SPEF file size is even over 2G, such as our whole chip’s SPEF file, PrimeTime SI can directly read in compressed SPEF in gzip format.

Check parasitic back-annotation report to ensure there are no annotation errors, which will affect the analysis accuracy. In our design, after some ECO iterations, we get DES-002 errors when

executing read_parasitics. These errors are the results of nets that do not drive anything. By default, the PTSI netlist reader discards such NC nets when reading in verilog netlist. But after ECO steps, the SPEF file may still contain the capacitance information of these nets, so DES-002 annotation errors come forth. In this case, after a detailed check and assured that all these errors are back-annotation failures of NC nets, we set the variable svr_keep_unconnected_nets to true before reading the netlist to depress this kind of error messages.

In our back-annotation report, there are only RC-009 warning messages left, the warning message is something as below:

Warning: The drive-resistance for the timing arc (hivtFhip7aPbcs30V165Tm40/inv_hivt_32) emma_encoder/hclk_encode_L3_I1/a–>x (max rising & falling neg_unate) is much less than the network impedance to ground; PrimeTime has adjusted the drive-resistance to improve accuracy.

(RC-009)

PTSI high lights a RC-009 warning when it finds the driver’s drive resistance is weaker than the net impedance (it is often the case on clock tree as clock tree buffers are strong), this may cause the transition computation potentially inaccurate. PTSI not only indicates the issue, but also solves it by adjusting the drive resistance. It is one of PTSI’s tactics to prevent loss of accuracy, and maintain a more conservative timing analysis.

3.4.2 PTSI Crosstalk Analysis Operation

Operating Crosstalk analysis in PrimeTime SI is an iterative process, taking multiple passes through the delay calculations, to obtain accurate results. In first iteration run, PTSI uses a conservative model that does not consider transition timing windows, and assumes that each aggressor net can have a worst-type transition (rising or falling) at the worst possible time, causing the worst possible slowdown or speedup of transitions on the victim net. In the second and subsequent delay calculation iterations, PrimeTime SI considers the actual arrival times and transitions, and removes any Crosstalk delays that can never occur based on the separation in time between the aggressor and victim. The result is a more accurate, less pessimistic.

And no matter what analysis type you set explicitly (Single, best case/worst case), PTSI will automatically switch to on-chip variation mode, so it can figure out the correct timing window relationship between victims and aggressors. It finds the earliest and the latest arrival times for each victim net and aggressor net. The range of switching times, from the earliest to the latest arrival, defines a timing window for the victim net, and defines another timing window for the aggressor net. Crosstalk timing effects can occur only when the victim and aggressor timing windows overlap. And such timing window is in originally internal data format of PTSI. To take the advantage of the timing window to aid ClariNet to perform a more factual functional noise analysis, we use a TCL script to export the PTSI timing window to a TEXT file.

And once on-chip-variation (OCV) is enabled, paths that are shared by both the launching and receiving registers may have different delays due to slew propagate and other factors involved in OCV analysis. But in reality, the common path should have only one propagated delay for both

registers at a given time. The over pessimism can be removed simply by turning on the Clock Reconvergence Pessimism Removal variable to true (off by default).

3.4.3 Set up Proper PTSI Parameters to Get an Accurate Result in a Reasonable Time

PTSI allows users to set parameter values to get an accurate result in a timing manageable run.

● Run Iteration Control: By default, PTSI will run analysis in two iterations, and can already obtain sufficient accuracy. In our design, we use the default iteration setting.

● Reselection Criteria: As mentioned above, in the first iteration, PTSI ignores timing window. In further iterations, it takes timing window into consideration, but requires more processing time. By default, only the nets in critical paths are reselected for the second (and further) iteration. A more complete criterion is to re-select nets based on slack (for example the nets with slack = 0), and also based on delta_delay reselection parameters. The later parameters measure absolute timing delta caused by Crosstalk, and/or a relative delta normalized by total stage delay (cell + net), which indicate enough Crosstalk effect to benefit the further analysis iteration. In our design, we set the reselection criteria as:

set si_xtalk_reselect_critical_path false

set si_xtalk_reselect_max_mode_slack 0

set si_xtalk_reselect_min_mode_slack 0

● Filter Parameter: The purpose of filter is to eliminate the considerations of cross-caps and Crosstalk voltage bumps that have very little influence on Crosstalk, in order to achieve a faster analysis time. PTSI has two kinds of filtering: Parasitic filter and Electrical filter. Both are user-control and we use a specific set of filter parameters for the 0.13mm process.

In Table 3-1, the run times are showed for different PTSI analysis stage for eMMA module. And the machine we used is Blade1000 with 8G memories.

3.4.4 Improve the Accuracy of Timing Analysis by Setting Proper STA Constraints

Transition time is a very critical parameter for delay uncertainty. Setting transition times of input signals to be unrealistically fast will cause over pessimism in delay calculation. So proper constraints should be used to control the transition time. Below is the setting we use:

(1) Set drivers for each input port. Definition of driver cell for each input port increases quality of timing analysis and prevents pessimism in delta delay analysis.

(2) Do not use set_drive or set_input_transition to 0. For a fast slope creates a strong aggressor for each input signal.

(3) Exactly define the clock transition time for clock network, because clock wires are strong aggressors.

The related constraints we used in best case timing analysis are listed as below:

set_driving_cell -cell inv_hivt_4 -pin “x” $inputs

set_max_capacitance 0.00466 $inputs

set_load 0.05 [all_outputs]

set_max_transition 0.5 $MODNAME

set_max_transition 0.5 [all_outputs]

set_max_transition 0.5 [all_inputs]

set_clock_transition 0.4 [ get_clocks hclk ]

3.4.5 Get Specific Timing Report

When Crosstalk analysis is enabled, -crosstalk_delta option is used in report_timing command to show the path delays, including Crosstalk effects. Crosstalk information shows up as “delta” delay values for stages (cell + net). Moreover, in order to summary Crosstalk victim nets in timing paths, we use the TCL script published in SNUG website (Doc Id 002163). The specific report lists each victim net and the associated delta delay. In repair process, we perform the double space rule to these victim nets whose delta delay is over 0.06ns.

A sample script file for running PTSI could be found as the appendix.

4 Crosstalk Repair

Crosstalk problem can be fixed in the below ways:

● Driver sizing.

● Buffer insertion.

● Double spacing.

● Shielding.

4.1 Repair the Functional Failed Nets

In whole analysis & repair flow, the first step is to analyze the function noise, and fix the failures first. And as showed in Figure 3-1, we should re-check the function noise after the final operation of delay noise fix.

From our experience, double space is the most efficient way to fix both functional and delay noise, and it is much easier to implement than shielding, and will bring less side effect than driver sizing and buffer insertion. So for repair functional failed nets, we choose the double space as the first choice solution. And since we have included the timing window from PTSI when doing functional noise analysis, the result is closer to the reality, and there are less than 15 nets with problems in each of the two modules in the later design phase. So it is possible to repair them all by double space. As we mentioned above, ClariNet can generate repair directives for SE.

4.2 Repair the Delay Noise by PTSI -> SE ECO

Frankly speaking, our Crosstalk Delay repair is an onerous and painful process, because it is mainly performed by manual effort, with little automation. Astro is the physical layout tool provided by Synopsys. It has the Crosstalk Preventive option too, and can directly read in the information produced by PTSI to do repair. However, our methodology chooses Silicon Ensemble to do APR. In this condition, we have to manually extract useful information from PTSI report, and provide the repair approach based on our experience.

We repair Crosstalk induced setup violations first, and then solve the hold time problems. And from our experience, comparatively, upsizing the driver of the victim nets is more efficient to repair setup time problems, and buffer insertion is more efficient to fix hold time violations. And double space has the power to alleviate both delay effects.

While at the same time, all these repair prescriptions have their limitations. In our design, upsizing driver reaches its red line after reducing 0.2ns path delay from the setup perspective, since stronger driver can make a week victim net turn out to become a aggressor too. Double space has its limitation too, as Crosstalk always comes up in the place where the congestion has already been so severe, that double spacing cannot even be feasible in some situation! On the other hand, we have already restricted the parallel net length to be less than 150mm, it will decrease the productivity of double space on such short parallel nets.

4.2.1 Prototype of Setup Fixes & Setup Repair Results

Crosstalk induced setup violations are mainly caused by the accumulation of Crosstalk deltas along the violation paths. And upsizing the drivers of the victim nets are effective for fixing setup problems. PTSI provides commands for cell sizing (such as size_cell ) to perform the virtual driver upsizing (what-if) analysis with old SPEF file. Of course, upsizing will typically cause localized placement disturbance, and the related route’s RC network will change a little bit. So after the real ECO cell sizing and routing in SE, the results will have small difference. The successful driver size directives after PTSI are summarized by manual work, and exported for SE. The example of upsizing repair directives is as below:

resize emma_decoder/emma_decoder_mem_bist/ U41 -macro mux2_hivt_8

Double space is also used to fix setup violations. Double space repair directives are generated by extracting repair nets from PTSI’s xtalk_net report. Figure 4-1 shows the most serious victim net in worst case xtalk_net_report in eMMA module, with itsdelta, and corresponding aggressors information.

The selection criteria for double space are the nets whose delta delays are over 0.06ns. The example of double space directive:

CHANGE NET “emma_pp/ram4_5_d_15_” “RULE.NAME” “double_space” ; DELETE WIRE NOKEEPGLOBAL NET “emma_pp/ram4_5_d_15_” ;

After each incremental ECO repair done in SE, we perform a new round of PTSI timing analysis using new SPEF. It usually needs 3~4 rounds to fix most of the setup violations. Take eMMA

module as an example. In the final phase, 3 iterations are used to analyze and repair the Crosstalk induced setup violations. Totally 34 sizing operations are performed, and 40 nets are doubly spaced. The upsized cells are mainly those that are in long paths with more stages, drive big cells, and have comparatively smaller fanout numbers. After applying all these repairs, there are still 12 setup violations remained, and 10 of them are new violations that arise after the ECO routing (This result is based on the constraint, in which the clock period is set tightly to 7.3ns. If clock period is relaxed to 7.5ns, timing is clean after the repair). The detailed numbers before/after fixing are listed in below Table 4-1.

4.2.2 Prototype of Hold Fixes & Hold Repair Results

The Crosstalk induced hold violations are mainly the paths with a few logic stages. The Crosstalk hold time fixing is similar to the traditional hold time fixing in SE. We insert buffer (normally buffer_8, or buffer_6) in the nets one stage before the most serious victim net, or in the nets in the last stage of all combinational paths. The inserted buffer has the effect of mitigating the speed-up effect caused by Crosstalk.

The example of buffer insertion directive is:

ReduceNetC emma_decoder/ ram1_d_6_-value 0.5 -macro buf_hivt_8

We have very few hold violations in both these two modules, and only need 1~2 iterations to fix hold. Table 4-2 lists hold repair result in the eMMA module. All 4 hold violations are fixed by successfully inserting 4 buffers in one round.

4.3 Repair the Delay Noise by PTSI -> Floorplan + PC ECO

In early design phase, when Crosstalk effect concentrating in some area is so execrable, many nets failed in both Crosstalk functional and delay analysis, that leaving all these nets to SE seems a mission impossible. So we have to re-fine-tune our floorplan in PC.

Take Sahara module as an example. There are 10 memory blocks in it, and they all share a single BIST test unit. According to the top-level requirement, all memory cells should be located in the top line of Sahara module. The original Sahara floorplan is showed as figure 4-2.

In this floorplan, 10 memories are separated in two groups, the high lighted standard cells are BIST logic, the state-machine part is mainly centralized between the two memory groups, but nearer to the left part. Long parallel lines have to be routed, and high congestion rate makes them very close to one another, so the coupling capacitances increased among them. There are totally 63 functional Crosstalk failed nets at that time, and most of them are the data bus nets connected from the inner BIST to the right-most memory cell. And double space cannot be performed in SE because no enough space left.

To resolve this problem, we have to balance the relative position of all memory blocks to the BIST logic to reduce the long parallel nets. The new tuned floorplan is showed as figure 4-3. Now it is comparatively more balanceable among all memory cells to the single BIST. The numbers of unreasonable long nets are reduced, and only 15 functional failed nets remained.

Besides the adjustment in floorplan, PC has to perform placement ECO step too. After tracing the Crosstalk failure concentrating area, PC is used to resolve this local congestion by creating some placement obstruction arrays to cut down the placement utilization and to add more routing channels in these areas. In our design, the regions nearby memory data bus ports are the most Crosstalk susceptible, so in the new round ECO in PC, the utilizations of these places are cut a little down to mitigate routing congestion.

4.4 The Summary Diagram of Whole Crosstalk Repair Flow

The whole crosstalk repair procedures are shown as figure 4-4 as a summary.

5 Conclusions and Recommendations

For our chip, with high-speed clock frequency and designed using 0.13mm technology, Crosstalk analysis and repair is a must-do task. PrimeTime SI does help us greatly in both analysis and repair procedures. PTSI can generate the timing windows for victim nets and aggressor nets. The real timing windows will also be helpful to pruning out the Crosstalk function noise.

However eliminating Crosstalk issue is not a push button process. After tediously repair iterations, which are mainly directed by human instruction, we finally achieve the timing clean in 133MHz clock frequency without functional Crosstalk failure. But the repair flow is not so smooth, for many times we have to do over and over again through all repair tries. Such manual fix solution is extraordinarily dangerous in a tight schedule. To get a faster Crosstalk Closure, following are our learnt lessons, recommendations, and suggestions.

1) A more scientific and practical design methodology is very important. Our methodology is quite good, because it runs the Crosstalk avoidance from very early design phase, and throughout whole design cycle. And it includes PrimeTime SI and ClariNet to ensure the Crosstalk closure. However, our methodology chooses Silicon Ensemble as APR tool. Since they do not come out from the same company, there are some interface conflicting problems. Silicon Ensemble itself has SI-aware option, and we have used it in routing. But it cannot understand the timing analysis result from PTSI, and of course, no ways to perform an automatic PTSI -> SE ECO flow. So for future project, we will consider to change the design methodology to choose Crosstalk analysis tool and APR tool with same analysis engine. I suggest to use PTSI + Astro-Xtalk flow, which forms a smoother ECO repair flow.

2) As mentioned many times, Crosstalk avoidance is vital too. So Crosstalk-constrained physical synthesis is highly expected. If Crosstalk analysis engine can be integrated into physical synthesis tool to prevent the Crosstalk effect in physical placement and optimization, we can speed up the procedure to get Crosstalk closure.

3) Qualify all Crosstalk related parameters and their settings for design process, and defined them in methodology. Because Crosstalk effect is physical dependent, for different processes and libraries, all Crosstalk related parameter settings should be qualified correctly before launching out the project. These include a Crosstalk ready library; the extraction threshold of coupling capacitance; the settings of filter and exit criterion for PTSI.

4) In our design flow, two Crosstalk analysis tools are used (ClariNet and PTSI) for function and delay issue individually. The latest release of PTSI has the ability to sign off the Crosstalk induced functional glitch too. So we need to do a further evaluation to decide which analysis engine is more accurate, and more manageable from the point of view of run time and memory requirement.

5) In our project, analyzing the whole chip with PTSI is real pain due to huge runtime. So it has been decided in new methodology to explore the hierarchical noise analysis for subsequent product. The 2003.03 version of Synopsys PrimeTime Modeling can generate ILM (Interface Logic Model) for hard-macro, which supports the hierarchical SI analysis.

6 Reference

[1] “PrimeTime SI User Guide” Version U-2003.03, March 2003

[2] Ravi Vaidyanthan, Deryi Sheu, Brian Millar, “Delay Noise Analysis & SI Management with Primetime-SI”, SNUG San Jose 2003

[3] Devaloy Muniz, John Pedicone, Greg Guiher, “PTSI Methodology and Results for Hierarchical 2M gate ASIC”, SNUG Europe 2003

[4] Chih-Tung Chen, Wilson Chan, Ying Gao, Xin Bao, Geoff Suzuki, “Noise analysis flow and methodology with PrimeTime SI”, SNUG San Jose 2003

[5] Kwamina Ewusie, Richard Nouri, “Identifying Prototyping and Fixing Crosstalk Induced Timing Violations with PT-SI and PC”, SNUG San Jose 2003

[6] Oleg Milter, Avinoam Kolodny, “Crosstalk Delay Analysis and Prevention Using Primetime SI and Design Compiler in High Frequency CPU Design” SNUG Israel 2003

7 Appendix

The following is a sample script file for running PTSI:

set PROC wcs

source .synopsys_pt_wcs.setup

# let PTSI don’t discard the NC nets in verilog netlist#

set svr_keep_unconnected_nets true

# read and link design #

read_verilog emma.vg

current_design emma

link

set_operating_conditions -analysis_type on_chip_variation

current_design emma

#source constraint#

read_sdc –version 1.3 emma_constraint.sdc

set_clock_gating_check -setup 0 -hold 0 [current_design]

set enable_recovery_removal_arcs {true}

#enable SI analysis#

set si_enable_analysis TRUE

#back annotation#

read_parasitics -keep_capacitive_coupling emma_wcs.spef

write_parasitics -format sbpf emma_wcs.sbpf

#read_parasitics -format sbpf -keep_capacitive_coupling emma_wcs.sbpf

# filter settings for 0.13u Process, they are recommended by Synopsys #

#victim filtering

set si_filter_total_aggr_xcap 0.01

set si_filter_total_aggr_xcap_to_gcap_ratio 0.05

#aggressor filtering

set si_filter_per_aggr_xcap 0.003

set si_filter_per_aggr_xcap_to_gcap_ratio 0.01

set si_filter_per_aggr_to_average_aggr_xcap_ratio 0.15

#RC filtering

set si_filter_single_xcap 0.0005

set si_filter_single_xcap_to_gcap_ratio 0.01

set si_filter_single_to_average_all_xcap_ratio 0.25

#bump filtering

set si_filter_per_aggr_noise_peak_ratio 0.01

set si_filter_total_aggr_noise_peak_ratio 10.0

#timing analysis#

set si_xtalk_reselect_critical_path false

set si_xtalk_reselect_max_mode_slack 0

set si_xtalk_reselect_min_mode_slack 0

#generate TEXT format timing window for ClariNet functional noise analysis#

set timing_save_pin_arrival_and_slack true

source timing_window.tcl

update_timing

activity_windows timing_window_from_PTSI 15

#15ns is the common clock period for two clocks whose periods are 7.5ns & 15ns respectively.

report_timing -crosstalk_delta -max_paths 100 -slack_lesser_than 0 -npaths_per_startpoint 1 \

-cap -trans –nets > emma_wcs.rpt

report_constraint -all_violators > emma_violator_wcs.rpt

report_clock_timing -type summary > clock_insertion_delay_wcs.rpt

# report xtalk nets in timing paths#

source xtalk_nets_in_timing_paths.tcl

report_path_xtalk -max_path 100 -min_max max -verbose > xtalk_net_wcs.rpt

#quit