[SI-LIST] Re: Article discussion on bad packages

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:
>http://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:     
>               http://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:
http://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:     
                http://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: