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