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.
Rich Mellitz
Sr. Staff Hw. Engineer, Intel
-----Original Message-----
From: Mark Nass [mailto:markn@rccorp.com]
Sent: Wednesday, May 19, 1999 5:05 AM
To: si-list@silab.eng.sun.com;
'si-list@silab.eng.sun.com'
Subject: RE: [SI-LIST] : Looking Inside IBIS Model
Here is my 2 cents worth on this subject. Sometimes the
TIME_to_VM
values are different because it depends on the point where
the data
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
shape at
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
Tco values
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
not contain
enough
of the Waveforms to generate a good QUAD model. I always get
the message,
REVERTING
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
pullup and
pulldown
is extremely important, at least for generating a QUAD
model.
Mark
At 09:23 AM 5/19/99 -0500, Beal, Weston wrote:
>Steve,
>
>Now I see your point. This is definitely correct
mathematically, but I
>still feel uneasy about it. I think that in reality, this
should not
>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.
>
>Regards,
>Weston
>
>
>-----Original Message-----
>From: TING.STEVE@inventec.com.tw
[mailto:TING.STEVE@inventec.com.tw]
>Sent: Wednesday, 19 May, 1999 2:51 AM
>To: 'si-list@silab.eng.sun.com'
>Subject: RE: [SI-LIST] : Looking Inside IBIS Model
>
>
>
>Weston,
>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
same test
>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
TIME_TO_VM).
>Then If I can have longer allowable flight time about 4nS
(7.5-1.5-2.0=4.0)
>purely for rising.
>If it is true, the Tflight_rise of 3.1nS(<4.0nS) won't
break my timing! Am I
>totally wrong?
>
>By the way, I assume zero skew and jitter in my formula
just for
>simplication, I didn't mean I can really do that in
practical.
>
>And I won't do the TIME_TO_VM correction manually in my
simulation, I'll
>enable the VM correction function in Quad if I have
>
>reliable TIME_TO_VM values in XTK models.
>
>RGS,
>
>Steve Ting
>
>-----Original Message-----
>From: Beal, Weston [ mailto:Weston.Beal@COMPAQ.com
><mailto:Weston.Beal@COMPAQ.com> ]
>Sent: Wednesday, May 19, 1999 12:21 AM
>
>
>
>
>**** To unsubscribe from si-list: send e-mail to
majordomo@silab.eng.sun.com. 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 ****
>
>
>
**** To unsubscribe from si-list: send e-mail to
majordomo@silab.eng.sun.com. 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 ****
**** To unsubscribe from si-list: send e-mail to majordomo@silab.eng.sun.com. 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 ****