Re: accuracy BIRD

Actually,
I feel that any waveforms that completely describe the test conditions are
valid QA applicable "Golden" Waveforms. The important thing is being able to
test the simulation back to the original IBIS data. Thus, even the model
generation VT curves do supply a certain valuable form of test and QA
criterion. Of course, Any additional waveforms with more complex packaging add
additional test and sanity.

see, I agreed with everyone.

jon

gedlund@us.ibm.com wrote:

> Hi Fred and Chris,
>
> Thanks for taking the time to provide some input.
>
> Yes, Fred, what we had in mind was additional VT tables that contain
> waveforms you would measure at the pin of a DUT, including the package. We
> have defined some new test loads in section 3 of the IBIS Accuracy Spec,
> and we would like to describe these test loads as well.
>
> Chris, the Accuracy Subcommittee felt it was important to define some more
> complex loads. We added the open-ended transmission line and the
> transmission line + receiver loads to facility checking of reflection
> coefficients and clamp diodes. I think it is necessary to have waveforms
> that include the package because the package is there when you make the
> measurements to do the correlation. But we don't need to describe the
> package since it's already a part of the IBIS datasheet.
>
> On the question of "golden waveforms" vs. "regular old VT tables," Stephen
> Peters mentioned that there is a difference between the two. Golden
> waveforms have the package while regular old VT tables do not. Is there
> any syntactical construct within IBIS to differentiate between the two?
> Care to embellish here, Stephen?
>
> Thanks all.
>
> Greg
>
> gedlund@us.ibm.com wrote:
> >
> > The IBIS Accuracy Subcommittee has been considering submitting a new BIRD
> > that would allow for a wider variety of golden waveforms to be included
> in
> > an IBIS datasheet (model). Right now these new golden waveforms would
> > correspond to the additional test loads described in section 3 of the
> IBIS
> > Accuracy Specification, but we will certainly be adding more test loads
> to
> > the list as we examine different kinds of I/O buffers and their
> associated
> > electrical behavior. At the 2/26 IBIS Users Group conference call, Bob
> > Ross suggested we run this by the IBIS reflector to solicit your input,
> so
> > here it is. The two main questions are:
> >
> > 1) Is it necessary to describe the test loads in a machine-readable
> > fashion, similar to the distributed package model and EBD options already
> > present in IBIS? Or should we opt for the more simple approach of adding
> a
> > waveform with comments describing the test load?
>
> I presume you mean another v/t curve in text fashion and the load
> description along
> with which package parasitics you are using. IBIS allows up to 100 v/t
> curves so the
> bird may be only to add parasitic package information.
> >
> > 2) How does one distinguish between a golden waveform (w/ package) and a
> > regular old VT table (w/o package) in IBIS?
>
> This presumably is where you may need an additional key work in the v/t
> data. Not
> so hard to do.
> >
> > For those of you who were not at the DesignCon99 Summit, the IBIS
> Accuracy
> > Subcommittee presented a two-stage approach to documenting the
> correlation
> > results of an IBIS datasheet. Both stages involve embedding a golden
> > waveform, derived from SPICE, into the IBIS datasheet. The semiconductor
> > vendor can correlate the lab data to these golden waveforms and report
> the
> > correlation results in the "accuracy trailer," a comment section appended
> > to the IBIS datasheet. Using these same golden waveforms, the user can
> > correlate behavioral simulations and take up any significant
> discrepancies
> > with the simulator vendor. Question 1 above refers to automating the
> > second step of the correlation process. Of course, the user can always
> > capture the test load manually using the simulator's schematic capture
> > tool.
> >
> > Greg Edlund
> > Advisory Engineer, Critical Net Analysis
> > IBM
> > 3650 Hwy. 52 N, Dept. HDC
> > Rochester, MN 55901
> > gedlund@us.ibm.com
>
> --
> Fred Balistreri
> fred@apsimtech.com
>
> http://www.apsimtech.com
>
> Greg,
>
> Golden Waveforms are a great idea!
>
> >1) Is it necessary to describe the test loads in a machine-readable
> >fashion, similar to the distributed package model and EBD options already
> >present in IBIS? Or should we opt for the more simple approach of adding
> a
> >waveform with comments describing the test load?
>
> A "machine readable" format is prefered in order to facilitate automated
> validation.
>
> You mention using SPICE as the waveform creator so are transmission lines
> and package info really needed?
>
> If you're going to standardize the golden waveform loads, I suggest:
>
> 1) No Transmission lines (we're not testing the accuracy of T-Line
> modeling or
> T-line extraction parameters are we?).
>
> 2) No package parasitics (or they are spelled out explicity within the
> waveform).
>
> 3) A Shunt R to the Positive Rail, the Negative Rail and halfway in
> between. R should be
> near the impedence of the Transmission line the driver expects to see.
>
> 4) A Shunt C=50pF may prove informative also.
>
> >2) How does one distinguish between a golden waveform (w/ package) and a
> >regular old VT table (w/o package) in IBIS?
>
> I claim that a regular old VT table **IS** a golden waveform.
>
> It doesn't seem appropriate to place waveforms that use a particular
> package
> "within the [Model] block" using IBIS since a particular [Model] block may
> be used in with different packages. The [Model] block is meant to
> represent
> the output stage w/o (independent of) the package parasitics.
>
> If waveforms with particular package parameters are generated then they
> would have to be spelled out in some parseable format at the location of
> the
> waveform. Otherwise, there is the danger that someone will edit the
> package
> information at the top of the .ibs file and not re-generate the waveforms.
>
> Regards,
>
> Chris Rokusek
> Viewlogic Systems
Received on Fri Mar 12 20:00:24 1999