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