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

  • From: Jonathan Dowling <jdowlin2@xxxxxxxxx>
  • To: si-list@xxxxxxxxxxxxx
  • Date: Fri, 10 Aug 2001 18:13:02 -0700 (PDT)


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
  

Other related posts: