[SI-LIST] Re: Timing Methodology
- From: Jonathan Dowling <jdowlin2@xxxxxxxxx>
- To: si-list@xxxxxxxxxxxxx
- Date: Tue, 14 Aug 2001 13:49:47 -0700 (PDT)
Chris,
Its coming back to me now....its been so long I almost forgot.
The simulation model *is* the spec. The datasheet is meaningless.
Applied to the DDR-II DRAM scenario, this forces an industry
standard circuit simulation model (not to mention tool-suite)
for driver/receiver that all DRAM vendors target.
I'm curious to know if that's possible. Anyone care to comment?
-jd
--- Chris Cheng <chris.cheng@xxxxxxxxxxxx> wrote:
>
> 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
>
>
=== message truncated ===
__________________________________________________
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
Other related posts:
