Re: BIRD #61 -- Characterization of Receivers

Hello Nik:

   My comments are below, prefixed by >>>

     Regards,
     Stephen Peters
     Intel Corp.

>
> Hi All,
>
> Can't anyone clarify this new spec. about receivers for me
> and what the intention is?
>
> THanks
>
> Nik
> nikolai@avanticorp.com
>
>
> Qestions:
>
> *********
> * 1 *
> *********
>
> 1. What is a receiver? Is it
> a) A part of output buffer which receives controlloing
> signal (in other words, input of output type buffer).
> In this case it can be extended to enable node
> of 3-state and I/O buffers.
> b) That part of Input buffer, which is looking into
> a transmission line and receives signals from
> some output type buffer through the transmission line.
>

>>> it's b). A receiver can be connected to an input-only pin, or
       it can be the 'input' part of an I/O pin.
 
> I would expect the unswer should be b). However, the spec.
> says:
>
> ===begin===
>
> 1) The following new keyword is defined, and is placed in the
> specification just below the [Rising Waveform] and [Falling Waveform]
> keyword descriptions

>>> The above refers to where the keyword is placed textually within
        the specification document itself, not within a particular
        model.
>
> === end ===
>
> But Input buffer has no [Rising Waveform] or [Falling Waveform].
> I/O buffer does have, but Input buffer does not have and
> we have no place to place [Receiver Delay] keyword.
>
> If the answer is a), then, hey, how we can apply ramp
> signal to input of the output buffer, if we do not know
> its impedance, Capacitance, etc. ??

>>> Again, the [Receiver Delay] is used to build a receiver model-- it
        has nothing to do with an output or the output part of an I/O pin.
>
>
> *********
> * 2 *
> *********
>
> 2) Examples are confusing. The should give receiver delay.

>>> No. The intent was NOT to spec an absolute delay thru
        the buffer, but the *change* in delay due to differing overdrive
        and input waveform slope conditions. As I detail below, the
        intent is that by detailing the change in propagation delay
        thru the receiver for various controlled conditions, a simulation
        vendor can construct a model that predicts the receiver's behavior
        for any arbitrary waveform.

        You are correct that the delay columns in the second example are
        missing the "nS" suffix. This will be fixed.

> What we have in example 1:
>
> ===begin===
>
> [Receiver Delay]
> Start_point = 0.8v
> Slope = 1v/1ns
> End_point TABLE
> |variable typ min max
> 1.4 INF 7.0ns INF
> 1.5 INF 5.0ns INF
> 1.51 INF 3.0ns 10.0ns
> 1.53 7.0ns 0.0ns 7.0ns
> 1.55 2.0ns 0.0ns 1.0ns
> 1.6 0.0ns 0.0ns 0.0ns
> 1.7 0.0ns 0.0ns 0.0ns
> 2.0 0.0ns 0.0ns 0.0ns
> 2.1 0.1ns 0.1ns 0.1ns
> 2.5 -0.2ns -0.1ns -0.5ns
>
> === end ===
>
> delay is about 1ns, ok
>
> example 2:
>
> ===begin===
>
> [Receiver Delay]
> Start_point = 0.8v
> End_point = 2.0v
> Slope TABLE
> |variable typ min max
> 0.05/1ns -1.0 -3.5 -1.0
> 0.25/1ns -0.75 -2.0 -0.05
> 0.50/1ns -0.01 -0.5 -0.0
> 0.60/1ns 0.0 0.25 0.0
> 0.75/1ns 0.0 0.0 0.0
> 1.00/1ns 0.0 0.0 0.0
> 2.00/1ns +0.5 +0.2 +1.0
>
> === end ===
>
> is it a delay about 1s, or data are in Volts,
> or Nano is missing, or what is it?
>
>
>
> *********
> * 3 *
> *********
>
> 3) Some delays are negative. This is very very bad.
> Should be always positive. Just from stand point of
> causality. You apply a signal and then 1ns BEFORE that event
> your receiver tells you the signal has arrived.
> Simulators have to add some 'base' delay.
> Simulator_A will add 1ns, Simulator_B will add 10ns, etc.
> Why not IBIS spec add this 'base' delay and all have
> less headahe?
>

>>> As I pointed out above, the intent is to show the change in
         propagation delay, and a negative change is perfectly OK.
         Now, you do raise a good issue about 'base delay'. I do not know
         if base delay is an important variable in constructing a
         behavioral receiver model, of if different simulators will come
         up with different models because they assumed different base
         delays. I do assume base delay can be approximated by looking
         at the setup time specification for a particular pin. I hesitate,
         however, to have IBIS spec a 'base delay' -- at least not without
         a lot of simulator vendor input.
>
> *********
> * 4 *
> *********
>
> 4) Input buffer has Vinl, Vinh. If [Receiver Delay]-s
> are specified, then Vinl, Vinh should be discarded. Right?
> If ONLY 1 [Receiver Delay] is given, say for rising ramp,
> then we still use Vinl, Vinh, right ?
> Vinl, Vinh MUST be always given and BE CONSISTENT with
> [Receiver Delay] if the last is given. Right?
>

>>> I'm not sure I understand your comment. The Start_point and
        End_point parameters are not replacements for Vinh or Vinl.
        Start_point and End_point are in no way "specifications" of
        switching threshold. They (and Slope) simply describe a waveform
        applied to a receiver. Again, the idea is that with the right set of
        ideal waveforms, a simulator can construct a behavioral model
        of a receiver.
         

   I hope these responses help clarify the intent of the BIRD
>
> *********
> * end *
> *********
>
>
>
>
Received on Wed Aug 11 13:37:52 1999