Hi all, I agree with most of the guys who say they measure delays from a reference voltage at the output pin of the driver to a threshold voltage at the receiver's input pin. The reference voltage is the one the driver vendor specifies at his Tco specification. The threshold voltages are the Vinl and Vinh specified by the receiver vendor. But since the slew-rate of the signal on the PCB is generally different from the one defined in the data sheet I "normalize" data sheet specs in advance to making my simulations. What I mean by that is that, using the vendor's data sheet slew-rate definition, I calculate what the vendor's setup and hold specs would be if he had been using the threshold voltages as his reference point, instead of the (usually) 50% reference voltage. Then I can simulate delays up to this point and be sure nothing double counts and nothing is missed. This way I am even guaranteed against more severe problems, such as ringing. I use this method for maximum delay calculations as well as for dealing with hold time problems, using minimum delay measurements. The minimum measurement is done (using ICX) from the reference voltage at the driver's output up to the first time the input waveform at the receiver's pin crosses the first threshold (Vinl for rising, Vinh for falling waveforms). Again, I "normalize" beforehand the hold requirement of the receiver device vendor to the threshold voltage, to essentially get exact hold margins. I use the above method for bus signals only. For clock signals I measure the delay (for the purpose of substarcting them later and get the skew) from app. 50% to 50%. One reason for this different approach is that clock signals are "guaranteed by design" to be monotonic, thus eliminating "big" problems like ringing, but the main issue is that I am not sure how to use the min and max measurements, as described above, for clock signals. Should I really take worst-case measurements up to Vinl and Vinh? Since the vendor does not guarantee that clock inputs will switch at exactly a mid-point voltage, it would seem reasonable to take a broader definition for the term "skew" than usual: Take clock delay measurements both to Vinl and Vinh, and do the same for the other clock signals for the same bus. Then take the difference between all the delays you get. The largest of them all is your worst-case skew (taking account of traces only, of course, since one must consider also driver's skew and jitter). The result seems very conservative to me, since it actually gets you a "skew" for one and the same trace! While trying to use this broader definition I got unrealistically (to my opinion) skew results, so I dropped this approach. Nevertheless, theoretically it still bothers me, and my feeling is that this phenomenon should be taken into consideration somehow. Another issue which pops-up if one starts to look at the clock threshold definitions is that one must tweak, or "normalize" Tco also. Since vendors usually define this spec to be the delay from the clock pin to the output pin, both at the reference mid-VDD voltage, and since in reality the exact switching point may defer, one must caculate "normalized" Tco(max) numbers which reflect the fact that the for max Tco the switching point is at or near Vinh, and also calculate "normalized" Tco(min), which reflects the fact that for min. Tco the switching point is at or near Vinl! What do you think? Itzhak Hirshtal Todd Westerhoff wrote: > Question for the group: > > Most commercial SI tools seem to measure flight times to the receiver's > input thresholds. Thus, for a given transition, they report a "min" and > "max" flight time based on the threshold settings. > > However, there is a school of thought in SI that says measuring flight times > to Vil/Vih is too conservative. It's based on the observation that > setup/hold specs for a part are measured the same way Tco is - with > reference to a specific threshold. Therefore, the reasoning goes, you can > measure flight times to the point where the receiver crosses the reference > threshold, and, as long as the signal is within certain quality (i.e. > non-monotonic) and slew-rate limits, the flight time measurement is valid. > The required slew-rate is (or should be) part of the receiving device's > input spec. If the input signal does NOT meet the quality/slew rate > requirements, well, then you have to use Vil/Vih method, or in some cases, a > derating formula. > > My question is: what techniques are people predominantly using: the Vil/Vih > method, the reference voltage, or something in-between? > > For those who use the reference voltage method, I'm curious to know how > post-route analysis is performed. You can adapt any post-route SI tool to > measure at a single voltage by changing the models (if necessary), but - do > any of the tools report slew rate at the receiver inputs during post route > analysis? > > Your comments, both on and off the list, are greatly appreciated. > > Todd. > > Todd Westerhoff > SI Engineer - Hammerhead Networks > 5 Federal Street - Billerica, MA - 01821 > email:twester@xxxxxxxxxxx - ph: 978-671-5084 > ============================================ > > "Oh, but ain't that America, for you and me > Ain't that America, we're something to see > Ain't that America, Home of the Free > Little pink houses, for you and me" > > - John Mellencamp > > ------------------------------------------------------------------ > To unsubscribe from si-list: > si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field > > or to administer your membership from a web page, go to: > //www.freelists.org/webpage/si-list > > For help: > si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field > > List archives are viewable at: > //www.freelists.org/archives/si-list > or at our remote archives: > http://groups.yahoo.com/group/si-list/messages > Old (prior to June 6, 2001) list archives are viewable at: > http://www.qsl.net/wb6tpu -- Itzhak Hirshtal - Elta Electronics POB 330 Ashdod Israel 77102 Tel : 972-8-8572841 Mobile: 972-64-238631 Fax : 972-8-8572978 email: hirshtal@xxxxxxxxxxxxx ------------------------------------------------------------------ To unsubscribe from si-list: si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field or to administer your membership from a web page, go to: //www.freelists.org/webpage/si-list For help: si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field List archives are viewable at: //www.freelists.org/archives/si-list or at our remote archives: http://groups.yahoo.com/group/si-list/messages Old (prior to June 6, 2001) list archives are viewable at: http://www.qsl.net/wb6tpu