<...> Chris, It depends on what is being designed, and what data there is to work with. Not everyone is doing the same stuff you're doing. If we're talking about common-clock design, with clock rates of 150 MHz or less (my rule-of-thumb), and timing specified to the device pin, the "dinosaur methodology" you refer to works just fine. Actually, it works better today than it ever did - because the tools are better. If you're doing source-synchronous, DDR, 250 MHz + designs, then sure, the methodology is totally different, and you need a whole different level of accuracy. You know the problem well - it isn't a flight time game, it's a skew game, and the timing slop that you can get away with at 100 MHz will break you at 250 MHz DDR. So, yeah, you need to be able to accurately account for the entire delay from the input of the driver's buffer to the output of the receiver's buffer. And one way to do that is to model the whole shebang - predriver, driver, package, PCB interconnect, package, receiver at the SPICE level. However, it's not the ONLY way. Modeling everything in SPICE gives you the ability to say you've modeled everything very accurately, but at the expense of vastly increased compute time. There are other ways to approach this problem, where the results are just about the same, but the compute times are significantly less. Okay everyone - here goes. My track record for generating good discussion in this forum has been dismal - but the whole "how accurate is accurate?" issue is a pet topic of mine. Questions for the group: a) how many of you actually have access to SPICE-level models for the I/O buffers, such that you could model the entire path, from the input of the driver to the output of the receiver? b) how many of you are doing it? c) if you need to model the whole path that accurately, how are you accounting for the crosstalk and skew induced at the package level? for that matter, how are you accounting for crosstalk and skew induced at the board level? d) if you need to model the whole path that accurately, how are you integrating the delays you get from SPICE with system-level timing analyses? Comments are welcome and appreciated. Todd. Todd Westerhoff SI Engineer Hammerhead Networks 5 Federal Street Billerica, MA 01821 twester@xxxxxxxxxxx ph: 978-671-5084 -----Original Message----- From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx]On Behalf Of Chris Cheng Sent: Tuesday, August 07, 2001 10:15 PM To: si-list@xxxxxxxxxxxxx Subject: [SI-LIST] Re: Question about Simulation in Spectraquest it seems like we are all victims of some poorly defined legacy i/o timing methodology that were used back in the days when dinosaurs rule the world. maybe its time to rethink the way we should define our i/o timing in the future. -----Original Message----- From: Venkataraman, Srinivas [mailto:srinivas.venkataraman@xxxxxxxxx] Sent: Tuesday, August 07, 2001 1:01 PM To: 'James Freeman'; Venkataraman, Srinivas; 'Todd Westerhoff' Cc: Coleman, Dave; 'we_r_frendz@xxxxxxxxx'; si-list@xxxxxxxxxxxxx Subject: [SI-LIST] Re: Question about Simulation in Spectraquest Importance: High Sure. The adjusted interconnect delay method is a good way to do it if you do not have a good receiver model. For high performance buses with very fast edge rates and smaller cycle times (a few nS), the need to do the whole path will become inevitable. The input to the receiver is always important as that is the only way to understand what the tline and the discontinuties along the path are doing to the signal. -----Original Message----- From: James Freeman [mailto:freeman@xxxxxxxxxxx] Sent: Tuesday, August 07, 2001 12:09 PM To: srinivas.venkataraman@xxxxxxxxx Cc: Coleman, Dave; 'we_r_frendz@xxxxxxxxx'; si-list@xxxxxxxxxxxxx Subject: Re: [SI-LIST] Re: Question about Simulation in Spectraquest Hi Srinivas, The signal at the receiver is always of interest for signal quality purposes and in the case of poorly documented receivers, the only way to quantify the delay. Thanks Jim Freeman "Venkataraman, Srinivas" wrote: > The flight time will always remain the same and has nothing to do with a > well or poorly behaved > t-line. Whether the flight time is fast or slow depends > only on the dielectric constant of the substrate. This confusion is caused > because you are trying > to bucket the driver delay, receiver delay and the interconnect delay in > different bins. The best > way would be to model the whole path, driver input->interconnect->receiver > o/p and then quantify the > impact of fast and slow skew corners of the devices. > > Srinivas > > -----Original Message----- > From: Coleman, Dave [mailto:dave.coleman@xxxxxxxxx] > Sent: Tuesday, August 07, 2001 7:44 AM > To: 'we_r_frendz@xxxxxxxxx'; si-list@xxxxxxxxxxxxx > Subject: [SI-LIST] Re: Question about Simulation in Spectraquest > > Rahul, > > For a well-behaved transmission line circuit, you are correct - the fast > corner conditions will yield the min flight time. If you have a > not-so-well-behaved circuit (i.e., have signal ringback across threshold), > the fast corner conditions may cause the signal to settle later than for the > slow corner conditions, so you CAN get a larger flight time with the fast > corner conditions. > > Dave > > -----Original Message----- > From: whiz kid [mailto:we_r_frendz@xxxxxxxxx] > Sent: Monday, August 06, 2001 8:14 PM > To: si-list@xxxxxxxxxxxxx > Subject: [SI-LIST] Question about Simulation in Spectraquest > > Hi Gurus, > I have a question about the usability of the values > that spectraquest spits when doing a flight time > simulation. When I am doing a simulation with a fast > driver, fast transmission line, and fast reciever I am > more concerned with the Min switch time (Min flight > time). Is the settle time (max flight time) that SQ > displays a use ful parameter here??. Because to find > the max flight time u make use of the slow driver, > slow line, slow reciever. Am I missing some thing in > how to interpret the values. > > Regards, > Rahul. > > __________________________________________________ > Do You Yahoo!? > Make international calls for as low as $.04/minute with Yahoo! Messenger > http://phonecard.yahoo.com/ > ------------------------------------------------------------------ > To unsubscribe from si-list: > si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field > 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 > > > ------------------------------------------------------------------ > To unsubscribe from si-list: > si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field > 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 > > > ------------------------------------------------------------------ > To unsubscribe from si-list: > si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field > 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 > ------------------------------------------------------------------ To unsubscribe from si-list: si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field 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 ------------------------------------------------------------------ To unsubscribe from si-list: si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field 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 ------------------------------------------------------------------ To unsubscribe from si-list: si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field 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