[SI-LIST] Re: Question about Simulation in Spectraquest

  • From: Chris Cheng <chris.cheng@xxxxxxxxxxxx>
  • To: si-list@xxxxxxxxxxxxx
  • Date: Tue, 14 Aug 2001 10:50:49 -0700

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
  

Other related posts: