Tco is a spec. TIME_to_VM is a trick so that we don't double count the
simulator edge delay. The TIME_to_VM may have very little to do with real
circuit delays. To determine TIME_to_VM, you need accurate package and load
models for the conditions at which Tco is spec'ed and tested.
Sr. Staff Hw. Engineer, Intel
From: Mark Nass [mailto:email@example.com]
Sent: Wednesday, May 19, 1999 5:05 AM
Subject: RE: [SI-LIST] : Looking Inside IBIS Model
Here is my 2 cents worth on this subject. Sometimes the
values are different because it depends on the point where
for the IBIS model is taken. I have found that I can build
two IBIS models
for the same buffer that will generate a near Identical wave
the receiver and the TIME_to_VM value in one is 1.25ns and
in the other
it is 2.47ns. When I drive the load(4 DIMMs in this case)
and add up the
flightime using (Tco - Time_to_VM + Tflight) both numbers
are within 20ps.
The point is that TIME_to_VM is not a perfect indicator of
for Rise and Fall. I have started giving people the Tco
values, at the buffer
outputs, for both L>H & H>L transitions for the buffer
models I develop.
I also do the IBIS2XTK conversion and test the model to
make sure the
TIME_to_VM numbers are generated and that the numbers add up
to what I
see in spice.
One thing I have always hated about IBIS models, at least
the ones I have
received, that nobody has mentioned is that they usually do
of the Waveforms to generate a good QUAD model. I always get
TO RAMPS. This gives a terrible QUAD model, and of no use.
For me having the
appropriate number of RISING and FALLING Waveforms into the
is extremely important, at least for generating a QUAD
At 09:23 AM 5/19/99 -0500, Beal, Weston wrote:
>Now I see your point. This is definitely correct
mathematically, but I
>still feel uneasy about it. I think that in reality, this
>happen. If your TIME_TO_VM falling is much longer than
rising, then your
>simulation time to the receiver should also be much longer.
The pulldown is
>just not as strong.
>So, your example is correct, but if you actually got these
numbers from a
>simulation, then I would look closely at all the parameters
and test loads.
>I won't say that it's wrong, but I would double check it.
>Sent: Wednesday, 19 May, 1999 2:51 AM
>Subject: RE: [SI-LIST] : Looking Inside IBIS Model
>Thank you for your comment.
>In my example, I try to express the idea:
>The Tco_max was 2.5nS in my example, which was based on the
>loading used to generate TIME_TO_VM.
>And after Quad's mtest's calculation, I'll have TWO
different values for
>TIME_TO_VM: 0.8nS for rising and 1.8nS for falling.
>I'll then think that the Tco_max must came from falling and
the real Tco for
>rising should be smaller than 2.5nS, maybe
>around 1.5nS (I guess, because 1nS difference on
>Then If I can have longer allowable flight time about 4nS
>purely for rising.
>If it is true, the Tflight_rise of 3.1nS(<4.0nS) won't
break my timing! Am I
>By the way, I assume zero skew and jitter in my formula
>simplication, I didn't mean I can really do that in
>And I won't do the TIME_TO_VM correction manually in my
>enable the VM correction function in Quad if I have
>reliable TIME_TO_VM values in XTK models.
>From: Beal, Weston [ mailto:Weston.Beal@COMPAQ.com
>Sent: Wednesday, May 19, 1999 12:21 AM
>**** To unsubscribe from si-list: send e-mail to
firstname.lastname@example.org. In the BODY of message put:
si-list, for more help, put HELP. si-list archives are
**** To unsubscribe from si-list: send e-mail to
email@example.com. In the BODY of message put: UNSUBSCRIBE
si-list, for more help, put HELP. si-list archives are accessible at
**** To unsubscribe from si-list: send e-mail to firstname.lastname@example.org. In the BODY of message put: UNSUBSCRIBE si-list, for more help, put HELP. si-list archives are accessible at http://www.qsl.net/wb6tpu/si-list ****