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

From: Matthew Flora <mbflora@mail.hyperlynx.com>
Date: Fri Nov 03 2000 - 13:06:04 PST

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" <bob_ross@mentorg.com>
To: <ibis@eda.org>
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:
>
>
>
******************************************************************************
*
>

 
Received on Fri Nov 3 13:08:51 2000

This archive was generated by hypermail 2.1.8 : Fri Jun 03 2011 - 09:52:30 PDT