[SI-LIST] Re: package SSN model accuracy requirements
- From: Chris Cheng <Chris.Cheng@xxxxxxxxxxxx>
- To: "'SI List'" <si-list@xxxxxxxxxxxxx>
- Date: Tue, 8 Mar 2005 17:13:19 -0800
You can say what you want with IBIS, at the end of the day (today, not
tomorrow or some future spec), can you do an SSO analysis based on a pure
IBIS model ?
I am a complete N00b on FPGA so I am curious how many people really do SSO
analysis with just a standard IBIS description of a chip. I can't, so please
tell me how you did it.
Those who know me and my previous life somewhere should remember some of
those reference SPICE SSO models I generated, there is only a small number
of SPICE drivers, interconnect and receivers set that need to be included to
accurately model SSO, x-talk, package/interconnect loss. Remember, m=x is a
very powerful macro that doesn't even need to be an integer.
Another interesting side note, some of the so call speedy "IBIS engines" end
up barely faster or even slower in some cases when the same interconnect
complexity is added to get the accuracy close to acceptable level.
All of the above SSO modelling methodolgies are well documented and
correlated with actual characterization numbers. I am not talking about
vaporware analysis here.
-----Original Message-----
From: lgreen [mailto:lgreen22@xxxxxxxxxxxxxx]
Sent: Tuesday, March 08, 2005 3:48 PM
To: weirsi@xxxxxxxxxx; heyfitch@xxxxxxxx; billw@xxxxxxxxxxx; 'SI List'
Subject: [SI-LIST] Re: package SSN model accuracy requirements
I agree with Vadim that this has been a relatively quiet thread. So I'll
stir things up with my favorite "rules of thumb" for packages. Please feel
welcome to add/delete/comment.
* The IBIS lumped model (R_pkg, L_pkg, C_pkg) is useless. Unfortunately,
this is what many IBIS files contain, since the same chips could go in
different packages.
* RLC multi-stage models might simulate more slowly (or more quickly) than
transmission lines or S-parameters, depending on the number of stages and on
the simulator.
* RLC models are frequency-limited. If there are not enough poles and
zeroes, they could (for example) have the right delay but the wrong dv/dt or
other higher-order timing terms. Transmission line and wideband S-parameter
models avoid these limitations.
* S-parameter models need low-frequency data (as well as high-frequency
data) to get DC and slowly varying (envelope) voltages correct.
* As Steve noted, total coupling what is important. This includes coupling
from pwr/gnd to I/O signals. Coupling can easily involve 2-6 neighbors on
each side, but rarely the entire chip.
* Nearest neighbor coupling is not necessarily the worst, so modeling more
than the nearest neighbor is needed, particularly at higher speeds.
* Coupling on "slow" signal pins, such as Reset, also needs to be modeled.
* The package model should make it easy for the user to use a single pin in
a simulation, without sucking in all of the coupled pins every time the
model is used. The model should also make it easy for the user to model the
largest set of coupled pins. This means a hierarchical model structure
works best in some tool environments. (Not that I personally like that
approach.)
* Packages cam be modeled using the IBIS ICM (interconnect model) syntax.
However, not all tools support all of the keywords yet. For example,
support for S-parameters is improving rapidly, but is not universal. Model
makers (and model users) are encouraged to talk with their favorite tool
vendors to move this ahead.
Best regards,
Lynne
"IBIS training when you need it, where you need it."
Dr. Lynne Green
Green Streak Programs
http://www.greenstreakprograms.com
425-788-0412
lgreen22@xxxxxxxxxxxxxx
-----Original Message-----
From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx] On
Behalf Of steve weir
Sent: Tuesday, March 08, 2005 1:18 PM
To: heyfitch@xxxxxxxx; billw@xxxxxxxxxxx; SI List
Subject: [SI-LIST] Re: package SSN model accuracy requirements
Vadim,
I agree with Bill's sentiment of "just enough". This places some burden on
the IC vendors as they would then need to evaluate results to see that they
are providing "enough" information. How much is enough? Enough to me is
what will get us to within 10% noise level and 10% of the actual timing
changes that we will really see under live conditions versus a simple IBIS
model driving against nominal driver / package parasitic capacitance at
both ends and a stock 50 ohm Tx line. ( Although, given modern boards, I
think 43 ohms s/b what we move the packages towards. )
The basic idea is that a chip vendor would begin with a very complete (
sic massive model ) as the golden reference and then exercise simplified
models of increasing complexity until the simplified results correlate
adequately in simulation and with test vehicles. At that point, the
simplified model would be the one provided to customers.
Here are some suggestions:
Core power distribution
Enough of the package / IC PDN to be able to match the board design to the
device power requirements.
I don't think this will require more than the parameters of the first LPF
pole pair, because beyond that pair, there is likely very little that can
be done on the board to control care and feeding of the beast.
What we really lack though is an impedance versus frequency requirement
that ties to application code.
There may be special circumstances that are peculiar to a given die or die
/ package combination that require additional data. For example analog
Vcc's that power PLLs or SERDES elements can be quite sensitive to
transverse digital noise currents. I would really like to know the
sensitivity as a PSRR frequency plot, and again the first order model of
any in-package distribution / bypass network(s). This will make it easier
to determine the need for board level decoupling networks and their
performance requirements.
I/O Signal integrity
A multi-line model that includes both enough lines and enough of the return
path detail so that noise may be determined within 10-20% of actual levels,
and signal timing aberrations may also be determined to an accuracy of
10-20%. If the package has super returns this might only require a few
lines. If the package is a wire bond, it will likely require many. For
the time being, I think we are stuck with coupled multi-stage R-L-C SPICE
models.
Regards,
Steve.
At 11:33 AM 3/8/2005 -0800, Heyfitch wrote:
>Bill, thank you for sharing your thoughts on this issue. The first two
>points you made lend themselves more readily to modeling of an ASIC
>package rather than an FPGA one. In ASICs, you indeed assign signals in a
>self-repeating pattern that has translational symmetry in X and Y
>directions, at least within a single interface.
>
>Frankly, I expected that many more SI-list participants would speak up on
>this issue. It's easy to talk about this with wide brush strokes. But,
>apparently, it's not that simple to formulate a set of specific
>requirements for the SSN package simulation model you'd like to see from
>your IC vendor. With opening this thread, I am inviting all of you -
>those who have already given it a lot of thought and those who are just
>now beginning to delve into these issues - to voice there wishes and
>concerns. This is an opportunity to be heard by all IC vendors, who
>certainly will take cues from this thread. On a very basic level, this
>thread may be an opportunity for system designers to voice their
>"SSN-Simulation-wish-list" for their IC vendors.
>
>The lack of response to my original posting may indicate that: either 1)
>this is an issue of scarce interest and significance, or 2) I failed to
>frame well, or 3) everyone is gone fishing ... to the PCB-West, and next
>week we should see a flood of replies to this thread.
>
>Regards.
>-Vadim
>Altera Corp.
>
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
or to administer your membership from a web page, go to:
//www.freelists.org/webpage/si-list
For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
List FAQ wiki page is located at:
http://si-list.org/wiki/wiki.pl?Si-List_FAQ
List technical documents are available at:
http://www.si-list.org
List archives are viewable at:
//www.freelists.org/archives/si-list
or at our remote archives:
http://groups.yahoo.com/group/si-list/messages
Old (prior to June 6, 2001) list archives are viewable at:
http://www.qsl.net/wb6tpu
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
or to administer your membership from a web page, go to:
//www.freelists.org/webpage/si-list
For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
List FAQ wiki page is located at:
http://si-list.org/wiki/wiki.pl?Si-List_FAQ
List technical documents are available at:
http://www.si-list.org
List archives are viewable at:
//www.freelists.org/archives/si-list
or at our remote archives:
http://groups.yahoo.com/group/si-list/messages
Old (prior to June 6, 2001) list archives are viewable at:
http://www.qsl.net/wb6tpu
Other related posts:
