RE: [SI-LIST] : Looking Inside IBIS Model

Mark Nass (markn@rccorp.com)
Wed, 19 May 1999 10:05:02 +0100

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 ****