( ESNUG 421 Item 4 ) -------------------------------------------- [12/10/03]
Subject: ( ESNUG 420 #1 ) Synopsys Rebuffs CeltIC/PrimeTime-SI Benchmark
> Benchmark Results:
>
> CeltIC PrimeTime-SI
> -------- ------------
> Max Rise Mean Error: 4.9025 -23.2759
> Max Rise STD Dev: 11.0508 25.3116
> Max Fall Mean Error: 11.3949 -0.1695
> Max Fall STD Dev: 10.6221 30.7975
> Min Rise Mean Error: -6.4781 0.9596
> Min Rise STD Dev: 8.2935 15.5052
> Min Fall Mean Error: -6.0534 2.0522
> Min Fall STD Dev: 9.7295 18.2835
>
>
> Our results showed that CeltIC has better bounded accuracy than
> PrimeTime-SI for crosstalk induced delta delay calculation.
>
> - Jatan Shah
> Broadcom Irvine, CA
From: William Natter <wnatter=user domain=nortelnetworks spot calm>
What are the numbers Jatan gives expressed in? Are they in absolute
time (in nanoseconds?), relative time (in percentages?) or something else?
- William Natter
Nortel Networks Nepean, Canada
---- ---- ---- ---- ---- ---- ----
From: Srinivasa Kakumanu <kakumanu=user domain=time2mkt spot calm>
Hi, John,
Celtic also models virtual attackers. It's a provision to model tiny
little coupling caps that could be attached to the nets going perpendicular
to the victim net. If such nets have been well in excess of 100s, then
the resultant coupling cap would be significant. It could not be
ignored considering an unfortunate time stamp where all of them switch
at the same time (a theoretical possibility) which may make Celtic more
"correct" than Primetime-SI.
- Srinivasa Kakumanu
Time To Market, Inc. Secunderabad, India
---- ---- ---- ---- ---- ---- ----
From: Bernard Miller <bernard.miller=user domain=synopsys spot calm>
Hi, John,
I've worked with many customers who have evaluated signal integrity analysis
tools and I would like to point out some of the potential issues evaluating
PrimeTime-SI's accuracy using Jatan's system.
First of all, I would like to applaud Jatan for his efforts in building a
system to simplify the comparison of SI analysis tools vs. SPICE. SI
analysis on real designs can be very complex, especially with multiple
aggressors per victim net. His system is a good attempt to make the
comparison task easier. However, as Jatan indicated all the assumptions
and setup issues are not resolved between PrimeTime-SI and Celtic.
> The PrimeTime-SI development team told me there are several differences
> in the way their tool did alignment and the way I did alignment of
> aggressors; but they didn't go into detail.
As I will explain below, these inconsistencies can fundamentally affect the
collected data and lead to incorrect conclusions.
> Since I was running my benchmark with infinite windows, the correct
> comparison point would be to compare against PrimeTime-SI after one
> iteration. However, in my 1st iteration, PrimeTime-SI uses a less
> accurate Elmore delay model for delay calculation for timing windows
> as well as a less accurate method to compute the delta delay.
This is incorrect. PrimeTime-SI uses a highly-accurate delay calculation
engine with Adaptive Arnoldi model order reduction and uses a macro-
modeling technique to calculate the delta_delay in the 1st crosstalk
iteration.
Using the information available in Jatan's letter, I have identified the
following areas that need to be resolved before making valid comparisons:
1. In his comparison system, the algorithm used to get the worst case
delta delay may not necessarily model what happens in a real circuit.
Jatan's algorithm is designed to produce the theoretical near-worst
case crosstalk impact. However, if a coupling bump is placed and
aligned way after the victim waveform passed the victim receiver
input switching threshold, in theory you can get a very large delta
delay but in reality the victim signal has already triggered the
signal propagation in down stream logic before the bump can distort
the victim waveform.
In other words if you are looking at 2 stages of logic, coupling in
the 1st stage may produce a large delta delay in theory but in reality
it may not cause such a delay for the actual signal being propagated
to the 2nd stage. The induced bump in his case causes noise or glitch
rather than crosstalk delay and needs to be analyzed differently.
PrimeTime-SI understands the above scenario and properly accounts for
it in its integrated SI/STA calculation to avoid over pessimism.
Bumps induced in the above scenario are analyzed using the update_noise
command. But Jatan's system was built for comparison of crosstalk
delay impact only. There is no easy way to replicate this setup in
PrimeTime-SI in order to match the sweeping range of the simulator
used.
In order to properly do his comparison, Jatan's system needs to
properly distinguish between crosstalk delay and noise and run
PrimeTime-SI accordingly.
2. PrimeTime-SI uses the info in the .lib library to do the crosstalk
delay calculation. It's unclear whether Jatan's comparison system's
simulation conditions matched those under which Broadcom's libraries
were created.
For example, the Broadcom library may have been characterized with
realistic input waveforms using a pre-driver. If the circuit stage
under simulation does not have a pre-driver or any preceding logic
stages, the stimulus will be an ideal ramp instead of a more realistic
waveform. Such differences in Jatan's setup can cause noticeable
discrepancy between his Celtic and PrimeTime-SI results.
3. PrimeTime-SI accurately computes the worst-case alignment of aggressors
to the victim for EACH load pin on the victim net. Jatan's comparison
system must make sure to not assume a single alignment for the entire
net. It is unclear whether his system in this case properly analyzed
each load pin of the design.
There are many factors to consider when comparing our SI analysis tool to
SPICE or to Celtic. A large number of our customers have thoroughly
evaluated PrimeTime-SI's accuracy. One customer even compared 40,000
PrimeTime-SI data points and found the outer bound of the results to be
within 10-15% of SPICE. I am certain that upon working through these
issues, Jatan will converge on a similar assessment.
- Bernard Miller
Synopsys, Inc. Mesa, AZ
|
|
