Subject: Re: accuracy BIRD

From: [email-masked]
Date: Fri, 12 Mar 1999 17:00:39 -0600

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

[email-masked] 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
> [email-masked]

--
Fred Balistreri
[email-masked]

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

---

From: [email-masked]
Date: Fri, 12 Mar 1999 21:54:22 -0800

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