i believe for any spec to be meaningful for a high speed system design, it has to reflect the reality of the system. if you buy into that, there is no way any semiconductor vendor can predict or even measure the worst case tDQSCK or tDQSQ, not even using the so call 30pf with high precision. as everyone knows, DQS and DQ timing (even at the component pins) will be a function of the SSO or ISI and will vary even between an ideal 30pf load vs. the tester environment with a 50 ohm transmission line ending with a 30pf load. The only place any vendor can reasonably be sure the timing could be bounded by pure silicon effect has to be before the main driver where there is minimal system dependency (obviously excluding voltage or temp effects). i can make a case then, to truly reflect a measurable quantity (be that on a tester or system), one needs to have a spec given by the si vendor that purely reflect the si behavior and coupled that with an accurate model to plug into individual system environment. all of the above is to address the output aspect of i/o timing. to complicate things even more, take your favorite DDR II example where you have DQ,DQS,DQSb, my question is how do you interpret all the ringing, edge degradation at the input pins in the system environment. given the same input signal edge and ringbacks, the delay of the input receiver will be different if the -ve end of it is presented with a constant level (vref as in psuedo differential receivers like DQ's) or a complement of the +ve signal or worst with a complement of the +ve signal time shifted due to system environment. you simply can not interpret DQS and DQSb individually and certainly even DQ has exactly the same shape as DQS/DQSb (which I don't believe will happen), the output of the receiver will be different also. you will be lucky if your misinterpretation being too conservative and you just lost performance. you will be dead if your misinterpretation is too aggressive and you have a fail system. in the end, all specs are meaningless if you cannot correlate to real system environment. whether you define them internally or externally should be determined by how you can decouple the pure silicon environment from the system environment. in the external timing case, you are trying to correlate to an imaginery 30pf or the si vendors tester environment, neither of which can be duplicated in the system customers test. in the internal case you allow the customer to bound their constrain based on their own environments coupled with an accurate model that allow them to do so. i believe at highspeed, any spec that go through the drivers or stop at the input of the receivers have too many dependencies on the system environment (SSO,xtalk,ISI to name a few) to be accurate. that said, any internal spec has to be backed up by an accurate model that customers of the part has confident in it so as to plug into their test or system environment to generate correlations. as far as my own experience, i think i am lucky enough to have every one of my customers (in my previous carrier) buy into both the methodology and confident of my reference model. they are, however, mostly high performance system design houses, not your average mum's and pap's design companies trying to built a $10 motherboard. the resources require to do a good job is significant but doable (or at least i've never heard them complain about it). -----Original Message----- From: Jonathan Dowling [mailto:jdowlin2@xxxxxxxxx] Sent: Friday, August 10, 2001 6:13 PM To: si-list@xxxxxxxxxxxxx Subject: [SI-LIST] Re: Question about Simulation in Spectraquest All, This all sounds good until its time to design to the DDR-DRAM spec. The legacy flight time methodology applies well here to integrate the spec numbers into a timing budget. Issues which crop up without such a methodology are: o Must know tDQSCK parameter for READ cycle CK-DQS roundtrip loop calculation. Surely, no one has run a full interconnect model in Hspice with the actual DRAM circuitry across all the DRAM pins/pkgs to estimate this delay from every vendor's circuits, right? If not, then how would you propose to integrate into your timing analysis the tDQSCK parameter which is defined into the reference load (including 30pF cap)? o Must know tDQSQ parameter for READ cycle DQS/DQ skew calculation. Surely, no one has run a full interconnect model in Hspice with the actual DRAM circuitry across all the DRAM pins/pkgs to estimate this skew from every vendor's circuits, right? If not, then how would you propose to integrate into your timing analysis the tDQSQ parameter which is defined into the reference load (including 30pF cap)? It seems to me that for parallel interfaces involving separate strobes and data (no embedded clock), defining timing/voltage parameters at the pin boundary is inescapable for production components even if your company owns the entire network. The simulation-only methodology works great until something breaks. After that, diagnostic means are needed which do not require an E-BEAM. -jd --- Scott McMorrow <scott@xxxxxxxxxxxxxxxx> wrote: > Chris, > > I find myself agreeing with you more often than not. > I agree that it is time to rethink i/o timing methodology. > The days of specifying timing to the pins of devices > are over. > > For high performance busses, we measure all timing > from die-to-die, from the input of the output buffer to > the output of the input buffer. This is the only way to > insure that all effects have been included and not > double counted. > > best regards, > > scott > > -- > Scott McMorrow > Principal Engineer > SiQual, Signal Quality Engineering > 18735 SW Boones Ferry Road > Tualatin, OR 97062-3090 > (503) 885-1231 > http://www.siqual.com > > > Chris Cheng wrote: > > > 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. > > __________________________________________________ Do You Yahoo!? Send instant messages & get email alerts with Yahoo! Messenger. http://im.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