[SI-LIST] Re: Timing Methodology
- From: Chris Cheng <chris.cheng@xxxxxxxxxxxx>
- To: si-list@xxxxxxxxxxxxx
- Date: Tue, 14 Aug 2001 14:09:08 -0700
not necessory. i've done it with spice, tools from
southern or northern cal. cad companies, whatever
the customer want. the importance is the accuracy
not the tool itself. it just happened that all my
customers believe spice is the best tool to do the
job but we have retro other tools to support the
methodology. if you check out the websites of most
big dram vendors, they all give out spice or ibis
model anyways.
-----Original Message-----
From: Jonathan Dowling [mailto:jdowlin2@xxxxxxxxx]
Sent: Tuesday, August 14, 2001 1:50 PM
To: si-list@xxxxxxxxxxxxx
Subject: [SI-LIST] Re: Timing Methodology
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
------------------------------------------------------------------
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:
