Re: FW: [SI-LIST] : IBIS datasheets for PCI and DDR

About this list Date view Thread view Subject view Author view

From: Jim Freeman ([email protected])
Date: Thu Nov 18 1999 - 15:21:55 PST


Hi Arpad,
    You've been reading A.S.Grove too much.
Jim Freeman

"Muranyi, Arpad" wrote:

> Jim,
>
> I just want to respond to the technical part of your EMAIL regarding
> bi-polar and constant
> current sources.
>
> Try plotting the IV curve of a constant current source. You will see a
> straight horizontal
> line (if your horizontal axis is voltage and the vertical axis is current).
> Compare that with
> an IV curve from an IBIS model of any buffer. Chances are that in most
> cases you will not see
> a horizontal line, but something that starts in the origin, and than
> saturates at a certain
> voltage becoming almost horizontal. Yes, in the saturation region it will
> be like a constant
> current source, but in the linear region it will be like a resistor. This
> is exactly the way
> a MOSFET transistor's IV curve look like.
>
> IBIS started with Intel's initiative. To my knowledge we do not manufacture
> anything else but
> (C)MOS parts. IBIS modeling started in the (C)MOS era. We use it for
> simulating our (C)MOS
> parts very successfully. In fact (in my opinion) IBIS is better at modeling
> (C)MOS, than bi-polar.
> What are you talking about bi-polar and constant current technology?
>
> By the way, we are working on the SSO limitations of IBIS at this very
> moment, so you should
> see that problem gone soon. On the other hand, a there are features in IBIS
> that would allow
> (limited) SSO simulations, but the reason you can't do it is because some
> tools do not use
> those features. So this is not entirely an IBIS spec issue.
>
> Arpad Muranyi
> Intel Corporation
> ============================================================================
> =====================
>
> -----Original Message-----
> From: Jim Freeman [mailto:[email protected]]
> Sent: Thursday, November 18, 1999 12:32 PM
> To: [email protected]
> Subject: Re: FW: [SI-LIST] : IBIS datasheets for PCI and DDR
>
> Hi Will,
> I have been performing Hspice simulations for board level analysis for
> 10 years and have had no trouble receiving or using a vendor's spice models.
> Your statement below basically says that we should be happy to get any
> models at all. In the past I have had to respond by not using Intel's parts.
> All of the simulators that use IBIS are designed to ensure signal integrity
> within the bounds of the capability of the models. The sso question goes
> largely unanswered by the use of IBIS and makes bypass calculations
> basically a swag. IBIS models do not project the variability of output
> impedance for the
> driver correctly. A transistor operates much differently than an ideal
> current source as is projected by IBIS usage. The IBIS builds on the
> industry formed using mainly bi-polar parts for drivers which can be more
> accurately
> portrayed as a constant current source over a wide variety of
> collector-emitter voltages. We are now in the CMOS era and this assumption
> is no longer true. Most of the board designers have grown up with the
> bipolar concept of
> constant output impedance and the IBIS feeds that mentality however
> misguided.
> There are now three major versions of IBIS models that have been
> proposed and most of the simulators are at least a major rev behind. This
> makes it difficult to really use the innovations that are coming out.
> To my mind, all that IBIS has done is muddy the waters sufficiently to
> satisfy the needs of semiconductor vendors and let the designers handle the
> board issues with inaccurate models that foster rampant overdesign while the
> semiconductor companies enter the board business with faster and better
> solutions and gain market share.
>
> Jim Freeman
>
> "Muranyi, Arpad" wrote:
>
> > On Will Hobb's (of Intel Corporation) request I am forwarding
> > his EMAIL to the list.
> >
> > Arpad Muranyi
> > Intel Corporation
> > ================================================================
> >
> > -----Original Message-----
> > From: Hobbs, Will
> > Sent: Thursday, November 18, 1999 11:42 AM
> > To: Peters, Stephen; Muranyi, Arpad
> > Subject: FW: [SI-LIST] : IBIS datasheets for PCI and DDR
> >
> > Stephen, Arpad,
> >
> > I've tried twice to post this to si-list, but it didn't get through. Could
> > you forward this for me? Thanks.
> >
> > Will
> >
> > -----Original Message-----
> > From: Hobbs, Will
> > Sent: Thursday, November 18, 1999 9:23 AM
> > To: '[email protected]'
> > Subject: Re: [SI-LIST] : IBIS datasheets for PCI and DDR
> >
> > Jim,
> >
> > It is true that one advantage from the semiconductor vendor's point of
> view
> > is IP protection. When we introduced IBIS, the reality was that very few
> > models existed at all, due largely to IP concerns. IBIS isn't ideal, but
> it
> > has lots of advantages that have been enumerated in the mail thread,
> > including speed and the potential to be accurate enough for most uses.
> >
> > To me, though, the largest benefit the industry has gained from IBIS is
> that
> > models are now widely available. Imagine trying to do your high speed
> > designs without them. IBIS removed the log jam that prevented engineers
> from
> > getting models at all. And it has evolved to attempt to keep up with
> > emerging needs. It trails, and will probably always trail, the leading
> edge
> > of our needs, but it sure beats the alternative (no models at all), and it
> > is still improving.
> >
> > Will
> >
> > -----Original Message-----
> > From: Jim Freeman [mailto:[email protected]]
> > Sent: Tuesday, November 16, 1999 4:51 PM
> > To: [email protected]
> > Subject: Re: [SI-LIST] : IBIS datasheets for PCI and DDR
> >
> > Hi All,
> > The discussion below seems to forget that the main reason IBIS models
> > were invented was to prevent Chip vendors from giving out the c"crown"
> > jewels of Spice parameters. The First vendor to do so was Intel because
> they
> > are the
> > most paranoid about secrecy.
> >
> > Jim Freeman
> >
> > Muranyi, Arpad" wrote:
> >
> > > Fred,
> > >
> > > Very good comments, and I would like to put an emphasis on the
> > > assumption you make, IF the models are correct (big IF). It is
> > > also true that SPICE models can or usually have a lot more detail
> > > so they can be more accurate (if done correctly). But detail does
> > > not equal accuracy. And, it is very true that they both have their
> > > appropriate places for use. A circuit designer will not get anything
> > > done with IBIS models, but a system designer will probably never get
> > > his/her work done with SPICE models either.
> > >
> > > I want to point out another thing that kind of hit a nerve. You
> > > mentioned the number of BIRDs (64 and counting) in the IBIS case.
> > > To be fair, you should have also mentioned the number of SPICE
> > > flavors that exist. These exist mostly because each vendor has some
> > > (unfortunately incompatible) "value added" feature. In addition, look
> > > at the number of "levels" each SPICE has for the various models, some
> > > of which are, again, incompatible. BSIM alone has at least three
> levels,
> > > and BSIM3 of one tool does not necessarily work with another tool
> > > supporting BSIM3. You don't even have to use different flavors of
> SPICE,
> > > just think about one of the comments someone made about the scaling
> > factors.
> > > You simply can't simulate with two SPICE models, if one of them uses
> > > certain scaling factors that another model doesn't need unless you
> rewrite
> > > the model (good luck). (Of course this is only a problem for those who
> do
> > > system level simulations where you must have more than just your own
> > > design's SPICE model).
> > >
> > > I don't claim that IBIS is perfect, it is an evolving standard, mostly
> > > done by volunteer efforts. I also wish that it would have a lot more
> > > badly needed features, that it would be more consistent and more
> general.
> > > We have serous talks now about these issues among the "IBIS officials".
> > > We want to fix the shortcomings. However, if we point these problems
> > > out for IBIS as negatives or drawbacks, we should also be honest and
> > > admit that SPICE DOES have similar problems, even if it may seems to be
> > > a more stable language...
> > >
> > > Arpad Muranyi
> > > Intel Corporation
> > > ======================================================================
> > >
> > > I agree strongly with most of the statements but disagree with the
> > > accuracy issue. Assuming that the SPICE model is correct and the IBIS
> > > model is correct, there is no way that an IBIS model can be more
> > > accurate than a SPICE model. This is regardless of where the IBIS
> > > model came from. Keep in mind that MOST IBIS models are produced from
> > > the SPICE model using s2ibis. That means by default MOST IBIS models
> > > cannot be more accurate than the source. For one thing SPICE is a
> > > different animal and contains much more information regarding both the
> > > topology and process of the design. Secondly there have been and
> > > continue to be accuracy as well as other issues with IBIS. If this were
> > > not the case there would not be 64 birds to date and counting.
> > >
> > > Both the IBIS and SPICE model are prone to incorrect data. Being not
> > > correct is NOT the same as model accuracy. In my view both SPICE and
> > > IBIS models have their application. There is some overlap in the SI
> > > community. You probably should not use SPICE models to simulate a
> > > whole board. But accuracy is a different issue. For most SI applications
> > > IBIS will do. But there are cases where one may need the SPICE model.
> > >
> > > Best Regards,
> > > --
> > > Fred Balistreri
> > > [email protected]
> > >
> > > http://www.apsimtech.com
> > >
> > > **** To unsubscribe from si-list: send e-mail to
> > > [email protected]. In the BODY of message put: UNSUBSCRIBE
> > > si-list, for more help, put HELP. si-list archives are accessible at
> > > http://www.qsl.net/wb6tpu/si-list ****
> > >
> > > **** To unsubscribe from si-list: send e-mail to
> > [email protected]. In the BODY of message put: UNSUBSCRIBE
> > si-list, for more help, put HELP. si-list archives are accessible at
> > http://www.qsl.net/wb6tpu/si-list ****
> >
> > **** To unsubscribe from si-list: send e-mail to
> > [email protected]. In the BODY of message put: UNSUBSCRIBE
> > si-list, for more help, put HELP. si-list archives are accessible at
> > http://www.qsl.net/wb6tpu/si-list ****
> >
> > **** To unsubscribe from si-list: send e-mail to
> [email protected]. In the BODY of message put: UNSUBSCRIBE
> si-list, for more help, put HELP. si-list archives are accessible at
> http://www.qsl.net/wb6tpu/si-list ****
>
> **** To unsubscribe from si-list: send e-mail to
> [email protected]. In the BODY of message put: UNSUBSCRIBE
> si-list, for more help, put HELP. si-list archives are accessible at
> http://www.qsl.net/wb6tpu/si-list ****
>
> **** To unsubscribe from si-list: send e-mail to [email protected]. In the BODY of message put: UNSUBSCRIBE si-list, for more help, put HELP. si-list archives are accessible at http://www.qsl.net/wb6tpu/si-list ****

**** To unsubscribe from si-list: send e-mail to [email protected]. In the BODY of message put: UNSUBSCRIBE si-list, for more help, put HELP. si-list archives are accessible at http://www.qsl.net/wb6tpu/si-list ****


About this list Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Tue Feb 29 2000 - 11:38:59 PST