[SI-LIST] Re: Article discussion on bad packages
- From: steve weir <weirsp@xxxxxxxxxx>
- To: Chris.Cheng@xxxxxxxxxxxx
- Date: Tue, 28 Dec 2004 16:35:35 -0800
Chris, that is an interesting story. Well at the end of the day if we
really want to see all of the effects in detail, SPICE with ACCURATE MODELS
still seems the best albeit slow way to get all the information. But we
know the objections, including mostly the open Kimono. I just don't see
people handing out detailed SPICE models to the general design
community. So as the man in black said to Fezzini: "If there can be no
negotiation, then we are at an impasse."
As convoluted and technically suboptimal as alternatives may be, unless the
attitudes on providing detailed SPICE models change, I think we have to
continue down this road. One idea that strikes me is for vendors to
convert the actual I/O models from SPICE to IBIS and then back to effect
the abstraction.
The other points that may send a chill up your spine is that the majority
of the design community is going to want to run on design rules, and not
detailed and complete analysis that is your custom. For them, 24 hour
H-SPICE runs are not going to be palatable. Piecing out aspects of the
models into different forms that can be individually run at much higher
speeds, I feel does serve a very useful purpose.
Regards,
Steve.
At 10:24 AM 12/28/2004 -0800, Chris Cheng wrote:
>Steve,
>Believe it or not, I actually have two of the largest SI EDA tool vendors
>sending me people to investigate what you descript below (on top of neat
>things like behavioral receiver modeling). They spent nearly a man year each
>to get to what I think is close enough (+/-10% of SPICE accuracy). At the
>end of the day with all those additional modeling, the run speed of the
>simulator is slow enough that the so call orders of magnitude faster than
>SPICE advantage is gone, in some cases it is slower. The time wasted to
>extract the additional parameters needed and the actually fitting of the
>models to a behavioral engine is longer than simply running the native SPICE
>model and go home and have fun. It's like the rice rockets kids in my
>neighborhood have. You can put more money and time and effort to make a
>Civic run fast, but I'll take a Corvette or Viper any day. I don't shoot
>from the hip, I've actually done it before I draw my own conclusion. And I
>have my customer's negative feedbacks on IBIS to back it up.
>You mind as well put in the requirement to model the modulation of the
>predriver voltage under SSO condition. Case where the pre-driver ground is
>isolated from the IO ground will be very different from when they are
>common. And I still want someone to give me a correct IBIS model on Bill
>Gunning's circa 89 GTL driver model with SSO effects. Let's see how you
>model the active feed back from the drain back to the gate while the pass
>gate is under SSO modulation in a behavioral model.
>
>-----Original Message-----
>From: steve weir
>To: Chris.Cheng@xxxxxxxxxxxx
>Cc: 'si-list@xxxxxxxxxxxxx '
>Sent: 12/28/2004 1:59 AM
>Subject: Re: [SI-LIST] Re: Article discussion on bad packages
>
>Chris, I think that there are multiple issues, some of which can be
>addressed more easily than others, but ultimately I do see some serious
>problems with IBIS. If we specified the following, I think we would be
>way
>better off than we are today:
>
>1) Signal return references. Easy to specify. If the package guy does
>his
>homework all he needs to do is tell the integrator:
>a. The signal reference plane
>b. S parameters as seen looking into an ideal launch at the package /
>PCB
>interface.
>
>2) Signal crosstalk due to coupled lines. I like the idea of mixed-mode
>S
>parameters here as well for the closest neighbor or two on each side.
>The
>idea is to avoid having to build up a big matrix of W elements.
>
>3) Signal crosstalk due to common power / ground impedance. This one is
>
>where I think things are tricky for IBIS. I don't see a good way around
>an
>equivalent circuit for the common impedance. I think from a practical
>standpoint this is going to require bolting the inductance/capacitance
>matrix onto the front of IBIS models converted to SPICE and dropping
>IBIS. In essence all IBIS is going to get us is a simplified SPICE
>model
>for the drivers.
>
>4) Current profile vs. frequency for core, and I/O. It would be up to
>the
>IC supplier to identify subgroups where each subgroup would be
>considered a
>lumped current source.
>
>5) Some means of feeding back noise voltage versus frequency at the
>package
>/ PCB interface resulting from 4) into 3). If we go the route of a
>SPICE
>model, this is straightforward, if a bit slow. In this case we bolt a
>SPICE model of the PCB attachment + planes + bypass caps at 3)
>
>I think this is enough to get us pretty close. Unless I have missed
>something ( comments welcome!!! ) we would be able to see:
>
>a) Most multiline crosstalk.
>b) Most common power impedance crosstalk / SSO, including analog if
>specified
>c) A good representation of power as measured at the device / PCB
>boundary
>d) Limited visibility of power at the internal distribution nodes (
>depends
>on the detail of models provided at 3) )
>
>What this proposal lacks is an evaluation of absolute voltages inside
>the
>package. My thinking is that the IC vendor could specify one of two
>ways:
>
>a) Absolute voltages at internal nodes where the matrix has been
>provided
>in 3) This is the most accurate, and ultimately I think preferred.
>b) Absolute voltages at the package / PCB interface. With software
>driven
>and/or programmable hardware, I don't think this has very good legs to
>it.
>
>
>I am interested in what stones folks can toss at this proposal.
>
>Regards,
>
>
>Steve.
>
>
>At 02:00 PM 12/27/2004 -0800, Chris Cheng wrote:
> >I am sorry but IBIS for SSO analysis is an oxymoron term for me. Can
>you
> >explain more ?
> >
> >Power and SSO analysis has been done on systems since the 70's. There
>was no
> >commmitte or industrial standard then and people who knows how to do it
>ask
> >the right question and get the right results. And every package I have
> >designed is unique and to say there is a generic or standard way to
>model it
> >is beyond my experience. But then again, what do I know ?
> >
> >-----Original Message-----
> >From: Istvan NOVAK
> >To: cgrassosprint1@xxxxxxxxxxxxx; Chris.Cheng@xxxxxxxxxxxx
> >Cc: si-list@xxxxxxxxxxxxx
> >Sent: 12/27/2004 7:50 AM
> >Subject: Re: [SI-LIST] Re: Article discussion on bad packages
> >
> >
> >
> >After the 2004 DesignCon panel discussion on PDN simulations,
> >this kind of standardization started in two independent tracks:
> >one of the IBIS committees and the IEEE TC-12 have been working
> >on proposals to address these issues. If anyone is interested in
> >contributing comments and proposals, please contact me offline
> >so that your effort can be channeled into these ongoing projects.
> >
> >HAPYY HOLIDAYS to everyone.
> >
> >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:
