I agree, the point I was making is that it is easy to build an IBIS
model with two very different TIME_to_VM numbers yet when you simulate
the converted QUAD model and add up the TCO + flightime and then subtract
out the TIME_to_VM number the timing result is the same. So using
TIME_to_VM as
an indication of the L>H or H>L Tco value, when only one TCO number is
given, may not always work.
Mark
At 12:49 PM 5/19/99 -0700, Mellitz, Richard wrote:
>Hi Mark,
>
>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:[email protected]]
> Sent: Wednesday, May 19, 1999 5:05 AM
> To: [email protected];
>'[email protected]'
> 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: [email protected]
>[mailto:[email protected]]
> >Sent: Wednesday, 19 May, 1999 2:51 AM
> >To: '[email protected]'
> >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:[email protected]
> ><mailto:[email protected]> ]
> >Sent: Wednesday, May 19, 1999 12:21 AM
> >
> >
> >
> >
> >**** To unsubscribe from si-list: send e-mail to
> [email protected]. 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
>[email protected]. 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
[email protected]. 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 [email protected]. 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 ****