Re: BIRD #61 -- Characterization of Receivers

From what I have read so far, BIRD #61 specifies a timing *correction* table
mechanism, as opposed to a more sophisticated algorithm for dynamically
determining when a receiver has switched. The way I see it, a simulator would
have to:

1) Determine switch times at a receiver using good 'ol Vmeas.
2) Analyze the waveform around the Vmeas switch point and use the [Receiver
   Delay] info to determine a correction factor.
3) Offset the switch time by the correction factor and use this in timing
   measurements.

This seems OK for signal integrity style simulations, in which propagation of
a signal through interconnect is analyzed, but propagation through components
is not. However, a more functional style of simulation in which the received
signal propagates through a component and into another piece of interconnect
would not be served well by this BIRD. This limitation is OK for analysis of
common clock designs, in which the output buffer transition start times are
governed more by the system clock than anything else.

However, with source synchronous designs we may find ourselves wanting to
analyze some reasonable subset of the design, at least a few nets that
participate in a tight bus protocol, in a functional manner. At this time
the simulator would have to accurately model the propagation time(s) through
the component. The only reason I bring this up is because we seem to agree
that the seemingly endless stream of enhancements that IBIS needs to keep up
with technology, is causing us pain. We can at least try to make our changes
last a little longer. OK, now I can return to discussing what this BIRD *does*
address (steps down from soap box).

Are IBIS models limited to having only one [Receiver Delay] table? If so,
how do we specify separate corrections for rising and falling inputs? I would
expect that at least two tables would be required, one with Start_point less
than End_point (rise), and one with Start_point greater than End_point (fall).
It is not clear to me that this would be allowed, and I would expect the
specification to have an example showing both rise and fall. I would not expect
to use a single table "in reverse" to determine falling switch time corrections.

Mike

Stephen Peters wrote:
>
> Hello All:
>
> Following is the first in a series of BIRDS that aim to enhance
> IBIS's ability to specifying and characterizing receivers. Comments
> appreciated.
>
> Regards,
> Stephen Peters
> Intel Corp.
>
> ===================================
>
> Buffer Issue Resolution Document (BIRD)
>
> BIRD ID#: 61
> ISSUE TITLE: Enhanced Characterization of Receivers
> REQUESTOR: D.C Sessions (Philips), Richard Mellitz, Stephen Peters,
> Arpad Muranyi (Intel Corp)
> DATE SUBMITTED: August 9, 1999
> DATE ACCEPTED BY IBIS OPEN FORUM:
>
> *******************************************************************************
...
Received on Thu Aug 12 06:39:57 1999