Subject: Re: IBIS IRD68 - Clarify that Rising and Falling Waveforms Should be Correlated

From: "Matthew Flora" <[email-masked]>
Date: Fri, 3 Nov 2000 13:06:04 -0800

All,

I'm concerned about using older models where the [Rising Waveform]'s within a
[Model] are time correlated to each other and the [Falling Waveform]'s within
that [Model] are time correlated to each other, but no time correlation exists
between the [Rising waveform]'s and the [Falling Waveform]'s.  How is the
simulator to recognize one of these models made prior to the clarification and
a model made after the clarification?  Would it be based upon the [IBIS_ver]
value?

Regards,
Matthew Flora
Innoveda

----- Original Message -----
From: "Bob Ross" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, October 24, 2000 12:54 PM
Subject: IBIS IRD68 - Clarify that Rising and Falling Waveforms Should be
Correlated

> To All:
>
> BIRD68 by David Lorang is issued for clarification.
>
> Bob Ross
> Mentor Graphics
>
>
******************************************************************************
******************************************************************************
>
>                        Buffer Issue Resolution Document  (BIRD)
>
>
> BIRD ID#:      68
> ISSUE TITLE:   Clarify that Rising and Falling Waveforms Should be
Correlated
> REQUESTOR:     David Lorang, Intel
> DATE SUBMITTED:                       October 24, 2000
> DATE ACCEPTED BY IBIS OPEN FORUM:     Pending
>
>
******************************************************************************
*
******************************************************************************
*
>
> STATEMENT OF THE ISSUE:
>
>       Rising waveform data should be correlated with falling waveform data
to
>       help simulators provide accurate duty cycles for their output
>       waveforms.
>
>
******************************************************************************
*
>
> STATEMENT OF THE RESOLVED SPECIFICATIONS:
>
> Add the following new paragraph to the [Rising Waveform], [Falling
> Waveform] Keywords in Section 6 before the paragraph that starts with, "A
> [Model] specification can contain more that one rising edge...":
>
> |               The data in all of the waveform tables should be time
> |               correlated.  In other words, the edge data in each of the
> |               tables (rising and falling) should be entered with respect
to
> |               a point in time when the input stimulus is assumed to have
> |               initiated a logic transition.   The first line in each
> |               waveform table should be assumed to be the reference point
in
> |               time corresponding to a logic transition.  For example,
> |               assume that some internal rising edge logic transition
starts
> |               at time = 0.  Then a rising edge voltage-time table might be
> |               created starting at time zero.  The first several table
> |               entries might be some "lead-in" time caused by some
undefined
> |               internal buffer delay before the voltage actually starts
> |               transitioning.  The falling edge stimulus--for the purpose
of
> |               setting reference time for the voltage-time curve--should
also
> |               start at time = 0.  And, the falling edge voltage-time table
> |               would be created starting at time zero with a possibly
> |               different amount of "lead-in" time caused by a possibly
> |               different--but corresponding--falling edge internal buffer
> |               delay.   Any actual device differences in internal buffer
> |               delay time between rising and falling edges should appear as
> |               differing lead-in times between the rising and the falling
> |               waveforms in the tables just as any differences in actual
> |               device rise and fall times appear as differing voltage-time
> |               entries in the tables.
>
>
>
>
******************************************************************************
*
>
> ANALYSIS PATH/DATA THAT LED TO SPECIFICATION:
>
> This change is necessary because errors in the relationship between rising
and
> falling edges cause duty cycle distortion in the simulated waveform.
> Preserving the timing relationship between rising and falling edge timing is
> important due to the effects of inter-symbol interference (ISI).
Intersymbol
> interference can be thought of as the effect of the previous edge (and in
fact
> edges before that) on the signal quality of the current edge of a signal.
If
> the timing between a previous and current edge is in error, then the ISI
effect
> will be inaccurate also.
>
> Note that an I/O buffer specification characterizes the shape of a buffers
> output waveform and does not and usually cannot, determine the internal
delay
> of that buffer.  It is the duty of a component data sheet to express the
> timing relationships between its various I/O pins.   But the timing
> relationship between an output buffer's own rising and falling edges is
> characterization of that output buffer and does fall within the realm of the
> buffer's specification, and thus that timingrelationship should be
preserved,
> if possible.
>
> The specification makes it clear that multiple waveforms for a given signal
> edge should be time correlated, but it does not specifically state that
> correlation should also be maintained between rising and falling edges.
>
>
> Consider the following example:
>
> A buffer has the following measured Tco (Time Clock-to-output) values.
>
>       Tco (rising edge):  2ns
>       Tco (falling edge): 3ns
>
> Suppose that we have measured waveforms as shown in the timing diagram
below.
>
>
>         0ns                 10ns                20ns
>
>         |                   |                   |
>
>          ___________________                     ____________________
>         |                   |                   |                    |
>         |                   |                   |                    |
>    CLK  |                   |___________________|                    |
>
>              ___________________                     _________________
>             /                   \                   /
>            /                     \                 /
>  OUTPUT __/                       \_______________/
>
>
>         |<->| TcoR = 2ns    |<-->| TcoR = 3ns
>
>
> Although  IBIS modeling does not deal with Tco directly, it does model the
> shapes of the waveforms.  For the measured information above, an IBIS model
> might be created to provide the following rising and falling waveforms:
>
>
>          Vfinal  ___         ___
>                             /
>                            /
>     Rising                /
>                          /
>                         /
>        Vinitial  ___   /
>
>        Vinitial  ___
>                        \
>                         \
>     Falling              \
>                           \
>                            \
>         Vfinal   ___        \___
>
>
>                        |    |  |
>
>                       T=0  T=2 T=3 (ns)
>
>
> And if so, although the waveforms are the correct shape, a time domain
> simulation would provide erroneous and misleading results:
>
>
>                0ns                 10ns                20ns
>
>                |                   |                   |
>
>                 ___________________                     ____________________
>                |                   |                   |
|
>                |                   |                   |
|
>           CLK  |                   |___________________|
|
>                     ___________________
_________________
>                    /                   \                   /
>  Original OUTPUT  /                     \                 /
>                __/                       \_______________/
>
>
>                |<->| TcoR = 2ns    |<-->| TcoF = 3ns
>
>                    ________________                       _________________
>                   /                \                     /
> Simulated OUTPUT /                  \                   /
>                 /                    \_________________/
>
>
>                 |-| TcoR = 1ns    |-| TcoF = 1ns
>
>
> The timing diagram shows that the delay from clock to output has
changed--and
> that is OK because IBIS is not intended to specify that.  The problem is
that
> the rising and falling edges have changed by different amounts causing duty
> cycle distortion of the simulated waveform.
>
> A better handling of this situation would have the rising and falling
> waveforms correlated so that for our example the IBIS V-T models would look
> like this:
>
>
>          Vfinal  ___         ___
>                             /
>                            /
>     Rising                /
>                          /
>                         /
>        Vinitial  ___   /
>
>        Vinitial  ___   ___
>                           \
>                            \
>     Falling                 \
>                              \
>                               \
>         Vfinal   ___           \___
>
>
>                        |  |  |  |
>
>                      T=0 T=1 T=2 T=3 (ns)
>
> With these waveforms when a time domain simulation is run, the waveform
would
> still have a different Tco than the original measurement, but because the
> rising and falling edges are correlated, the output signal shape is accurate
> (i.e. the simulated waveform no longer has the duty cycle distortion.)
>
>
>                0ns                 10ns                20ns
>
>                |                   |                   |
>
>                 ___________________                     ____________________
>                |                   |                   |
|
>                |                   |                   |
|
>           CLK  |                   |___________________|
|
>                     ___________________
_________________
>                    /                   \                   /
>  Original OUTPUT  /                     \                 /
>                __/                       \_______________/
>
>
>                |<->| TcoR = 2ns    |<-->| TcoF = 3ns
>
>                   ___________________                    _________________
>                  /                   \                  /
> Simulated OUTPUT/                     \                /
>                /                       \______________/
>
>
>                |-| TcoR = 1ns      |<->| TcoF = 2ns
>
>
> In summary, the IBIS specification should maintain correlation between all
> rising and falling waveforms to enable simulators that use the IBIS data to
> provide accurate results.
>
>
>
******************************************************************************
*
>
> ANY OTHER BACKGROUND INFORMATION:
>
>
>
******************************************************************************
*

---

From: Al Davis <[email-masked]>
Date: Fri, 3 Nov 2000 14:30:52 -0800

> a model made after the clarification?  Would it be based upon the [IBIS_ver]

It doesn't matter.

With IBIS as it has been, this correlation is undefined.  A simulator
must create its own correlation, because without it it would be
impossible to support diffrerential drivers or driver schedule, and
and it would be difficult to do periodic signals.  There is no basis
to say that any other method might be superior to this one.

Therefore, some of the existing simulators already do it this way, so
are already in conformance with no changes.  Others that used a
different method of establishing correlation would have a choice. 
They could key off [IBIS_ver], or they could apply the Bird68 method
everywhere.  Simulations will be more consistent vendor to vendor if
the Bird68 method is applied everywhere.  For simulators that did it
a different way, the method required here is usually a
simplification.  Models that assumed a different correlation have
always simulated different on different simulators, with some
matching what the creator hoped for, and some not.

This Bird does not cause anything to break that wasn't broken
already, and it makes an important clarification.  I am guessing
that the reason for proposing this is the author's frustration with
the arbitrary differences caused by the fact that this is not defined.
It is frustrating for simulator developers and modelers, too.  Bird68
should be approved.

Open question for simulator vendors:

1. Is yours already in conformance?

2. If not, how do you do it?

As a member of the IBIS futures subcommittee, I would appreciate
knowing this.  You can reply privately if you don't want the world to
know.