[SI-LIST] Re: Article discussion on bad packages
- From: Scott McMorrow <scott@xxxxxxxxxxxxx>
- To: Chris.Cheng@xxxxxxxxxxxx
- Date: Wed, 29 Dec 2004 01:25:32 -0500
Chris and all,
I've gotta say, although I wouldn't quite use your tone in public,
(although those who've known me throughout the ages have seen quite the
opposite), I agree with you that for accurate simulations of I/O cells
some variant of Spice is the only way to go. I am a proponent of IBIS,
and I am encouraged by other theoretical approaches to accurate
behavorial modeling. But these approaches currently have extreme
limitations when it comes to the modeling of SSO, SSI, driver gate
modulation, amplifier feedback circuits, complex floating power grids,
and package models. I've seen way too many marginal packages and IO
drivers that would have been discovered with rigorous (and many times
not so rigorous) Spice analysis.
I find that behavorial modeling of interconnect can be extremely
fruitful (using Laplace pole zero and S-parameter modeling, or even
simply transforming lumped circuits to coupled transmission line
equivalents) when coupled with a Spice simulation. I would endorse
Touchstone and IBIS ICM models of packages, interconnect, and other
passive structures when coupled with an appropriate simulator which
handles general nodes for power and ground, rather then node zero
universal ground.
But, I have not found any behavorial simulator yet that has the
flexibility of any of the many variants of Spice. And I find it
interesting that each day more and more variants appear, usually with
better algorithms, better matrix and data structure management and with
nifty new features like support of: convolution co-simulation, pole
zero modeling, lossy line modeling, enhanced lossy line modeling ... ect.
I've also found that a mixture of Spice and behavorial Spice modeling,
especially with current mirroring, is very useful to accelerate the
simulation of large numbers of IO cells. When combined with some of the
other behavorial methods for simulating interconnect, there can be
tremendous speedups, with no loss (or marginal loss) in accuracy. Being
the old school engineer that I am, I always go back and compare any
such behavorial approximation to the original circuit simulations to be
sure of the accuracy. If the behavorial simulation ain't accurate
enough, it gets thrown out.
Ultimately, behavorial modeling of I/O busses can be useful for finding
the glaring SI, timing and crosstalk problems on boards, but not as
useful for the modeling of most modern day high speed busses where
margins are exceptionally tight. Lee may have just "discovered' the
package problems written about recently, but I've been living them for
the past 10 years, diagnosing them to root cause and affecting solutions
that are a win-win for customers and suppliers alike. There are some
packages that cannot be fixed. But as Chris says, the problems can sure
as hell be diagnosed way before an entire product line has been
brutalized or yet another startup closed down.
Trust me, I've been brutally honest with my customers and ASIC vendors
who have dared to gloss over a problem with a package that one of my
customers has used per their recommendations. I have helped to bridge
the gap to a working solution through extensive Spice simulation and
measurement correlation, and have helped to build good continuing
relationships with customers and their suppliers alike. My customers
pay us to find solutions to problems, like the engineers that we are.
Nearly four years ago I was about to write an article titled " It's The
Package, Stupid! ", about noise and timing margin lost inside of the
package. This was not to say that packages are "bad", but to say that
they should be included in a full system simulation, that designers
should be aware of their limitations, and that it is very easy to break
a system with an incorrect package selection or an incorrect analysis of
the I/O-package-PCB interface. FPGA's are just a cheep, general purpose
version of a series of design compromises. To expect FPGA packages and
designs to be flawless is pure foolishness. It is the responsibility of
design engineers to confirm that their designs will work and not push
the limits of operability.
Nothing has changed since 2001 when I was considering this article,
except that I/O drivers keep getting faster, packages keep getting
larger, boards keep getting more dense, timing and noise requirements
keep getting more stringent, and those of us who know how to design, who
know how to perform complex system simulations with die, packages,
connectors, vias, pad transitions and interconnect, who know how to
design experiments to measure what we want to measure, who know how the
real world works, still have the best track record of successful
designs in the industry.
best regards and Happy Festivus,
Scott
--
Scott McMorrow
Teraspeed Consulting Group LLC
121 North River Drive
Narragansett, RI 02882
(401) 284-1827 Business
(401) 284-1840 Fax
(503) 750-6481 Cellular
http://www.teraspeed.com
Teraspeed is the registered service mark of
Teraspeed Consulting Group LLC
Chris Cheng wrote:
>Istvan,
>I thought I understand enough of your company's design methodologies (I
>worked on quite a few of them). So I am surprised to hear your response. Can
>you honest tell me your company is not running SPICE on "sophisticated IO
>circuits" to analyze its performance nor using it to analyze core power
>distribution ? Are you relying only on IBIS nowadays ? Or you are preaching
>something you don't practice yourself ?
>
>
>-----Original Message-----
>From: Istvan NOVAK
>To: Chris.Cheng@xxxxxxxxxxxx
>Cc: si-list@xxxxxxxxxxxxx
>Sent: 12/28/2004 8:36 PM
>Subject: Re: [SI-LIST] Re: Article discussion on bad packages
>
>Chris,
>
>If you want to simulate PDN SSN, you can do either a
>transistor-level SPICE simulation together with the PDN
>model, or an approximate behavioral model simulation can
>be done. For smaller circuits, transistor level models may
>work in SPICE (if you have access to it). For large chunks
>of silicon, like CPU cores and sophisticated IO circuits, the
>SPICE model may be prohibitively large. Also, for many
>users of third-party silicons, transistor-level SPICE model
>may not be available. For the above reasons, behavioral
>simulations may still be better than doing no simulations at all
>
>Regards,
>
>Istvan Novak
>SUN Microsystems
>
>------------------------------------------------------------------
>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:
