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

From: Bob Ross <bob_ross@mentorg.com>
Date: Tue Oct 24 2000 - 13:54:56 PDT

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 Tue Oct 24 13:58:08 2000

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