( ESNUG 473 Item 2 ) -------------------------------------------- [05/29/08]
From: Ramon Macias <ramon=user domain=razamicro not calm>
Subject: The new make_ccs_noise let us dump CeltIC for a pure PT-SI flow
Hi John,
This is a follow-up to your back-end tools use survey and request for
inputs. We just switched to PrimeTime-SI to tape out a 2.5 million
instance design. We had been a long time user of CeltIC for SI,
crosstalk, delay and noise analysis.
Synopsys convinced us that switching to pure PT-SI only would improve
our flow by eliminating our PT-to-CeltIC-back-to-PT cycle. This would
also eliminate the overhead of file transfers back and forth.
We figured our current tape-out would make a good test case to verify a
flow before heading to the next process node. We set four criteria that
must be met to consider switching to PT-SI:
1. Noise library generation must be easy (including macros and I/Os)
2. Same or better accuracy
3. Much simpler flow with fewer file transfers
4. Fast runtimes in anticipation of larger designs
We used a 350 K instance block with a 2.8 nsec clock cycle for our eval.
We already had NLDM timing libraries for our standard cells, RAMS, regfiles
and I/O cells. We used a utility called make_ccs_noise that came with
PT-SI to create CCS noise models which were added to our existing NLDM
timing models.
Generating Noise Libs:
The noise lib creation didn't start off very well. The make_ccs_noise
utility crashed on a high fanout transistor cell. Synopsys provided a
work-around the next morning and a fix in the next release so it turned
out this was not a major issue. After that we were able to create new
cells within a few minutes and were able to run our entire 800-plus cell
library in about 8 hours, so we met our noise library criteria.
Same or Better Accuracy:
We next focused on crosstalk delay accuracy by taking a number of paths
that had large SI-induced delta delays and compared our PT-SI results to
CeltIC and HSPICE. For most of the paths we checked, both CeltIC and
PT-SI showed good correlation and both were within 5 psec of HSPICE.
We've had no complaints with CeltIC's accuracy. It provided good
results for all of the 90 nm designs we've taped out. We were confident
in CeltIC's numbers, and for the most part were OK when PT-SI provided
similar results. We did, however, want to check out PT-SI on a few paths.
The process we used for this extra analysis was to select a path and run
it in PT-SI. Then we wrote out a SPICE deck and used HSPICE to analyze
the same path with and without the aggressor stimuli. Here's a sample
of one path (U726/ZN -> n520 -> n520_ATrc_i339/I) from a PT-SI timing
report we analyzed that showed a suspiciously large delta delay.
The PT-SI timing report shows the 45 psec delta delay:
U726/I (TL_INVD1) 0.000 0.068 0.000 0.035 & 2.721 f
U726/ZN (TL_INVD1) 0.080 0.074 & 2.796 r
n520 (net) 1 0.015
n520_ATrc_i339/I (TL_BUFD2)
0.039 0.119 0.045 0.045 & 2.840 r
n520_ATrc_i339/Z (TL_BUFD2)
0.049 0.065 & 2.906 r
The HSPICE delay for the net with the delay is 113.46 psec as shown in the
net_n520.mt0:
delay_u726/i_n520_atrc_i339/i= 1.1346E-10 targ= 3.0113E-08 /
trig= 3.0000E-08
The HSPICE delay for the net after modifying the SPICE deck to remove the
aggressor stimuli is 67.717 psec as shown in the same net:
delay_u726/i_n520_atrc_i339/i= 6.7717E-11 targ= 3.0068E-08 /
trig= 3.0000E-08
So the delta is 113.46 psec - 67.717 psec = 45.743 psec which is very close
to the 0.045 nsec reported by PT-SI.
CeltIC reported 47 psec in the SDF file:
(INTERCONNECT U726/ZN n520_ATrc_i339/I (-23::47) (-23::20))
The noise analysis was a bit more challenging as the tools report noise in a
slightly different manner. We were satisfied with the results that PT-SI
provided which were pretty close to CeltIC.
As a sanity check, however, we ran HSPICE on a mixture of 18 inverting, non-
inverting and complex cells and measured the height of the noise bumps.
The results we saw when comparing PTSI to HSPICE for the 18 data points
looked like this (data points are in Volts):
PT-SI HSPICE % Dif
1.0723 1.0907 1.7%
0.4866 0.5034 3.3%
0.9001 0.8969 -0.4%
0.5637 0.5859 3.8%
0.9175 0.9799 6.4%
0.4916 0.4864 -1.1%
1.1349 1.1225 -1.1%
0.5777 0.5944 2.8%
0.9104 0.9041 -0.7%
0.6134 0.6313 2.8%
0.9698 0.9993 3.0%
0.5815 0.5699 -2.0%
0.4630 0.4782 3.2%
0.6655 0.6790 2.0%
0.7154 0.7729 7.4%
0.6732 0.6808 1.1%
0.7871 0.7972 1.3%
0.7438 0.7527 1.2%
The % differences ranged from -2.0% to 7.4%, but generally, most of the
points were less than 3%. We met our accuracy criteria.
Simpler Flow & Fast Run Times:
We had used a flow that included an initial PrimeTime run for timing
window generation and STA analysis, then a CeltIC run to create an SDF
file containing delta delay, followed by a second PrimeTime timing run
that utilized the CeltIC SDF information for xtalk delta delay to
complete the final STA analysis.
This new flow uses a single PT-SI run which provides about the same
accuracy, run times and reports for crosstalk delay analysis. We used
PrimeTime-SI 2006.12-SP3 and CeltIC CND61_V06_10_PO15_1 for comparison.
The run time for the PT/CeltIC/PT flow was 100 minutes, about the same
as the single PT-SI run.
So the bottom line is that we switched from CeltIC to PrimeTime-SI for
crosstalk delay and noise analysis because PT-SI provides a simple
efficient flow that runs fast and delivers high accuracy.
PT-SI's new make_ccs_noise function gave us noise libraries overnight
which was a key enabler in our decision to switch.
- Ramon Macias
RMI Corp. Cupertino, CA
Index
Next->Item
|
|
