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


Scott,
I was hoping that this discussion could continue to focus
on timing methodology and not diverge to the simulator engine.

In that vein, I would like to "up the ante" so to speak
and move from DDR-I, which is a frozen spec, to the DDR-II
spec which is still somewhat malleable.  After all, it doesn't
matter what we say about the DDR-I timing methodology anyway,
it's too late to change.

If applying a Flight Time Methodology to a 266MT/s DDR-I
interface sounds "dinosaurish", cover your eyes...

I am willing to wager that there is a 99% chance that the 
400-600MT/s DDR-II DRAM spec will define:
  
  a)  VIH/VIL, Tsu/Thold, etc. at the DRAM package pin
  b)  tAC, tDQSQ, tDQSCK, etc. into a reference load 

Even if the 30pF cap is removed from the reference load
we're implicitly talking about a Flight Time Methodology
here.  So, the questions I have posed regarding DDR-I in
yr2001 will be recurring in yr2003.

My question for you is:
Are you willing to wager that these "legacy" parameters
will be redefined in such a way that they are only valid
at the input of the driver and output of the receiver?
If not, how would the logic-to-logic timing methodology be
applied in conjunction with the DDR-II spec?



Regards,
-jd

 




--- Scott McMorrow <scott@xxxxxxxxxxxxxxxx> wrote:
> Jonathan,
> 
> In my experience, there is still the problem that the "standard methodology"
> for timing does not make the conditions under which timing is specified
> explicit.  Worst case timing specs assume and are characterized in
> a particular package with a particular switching environment.  This
> is never fully specified.  Then ... when we do system simulations we
> include (some) package and power effects.  In many cases, "standard
> methodology" duplicates jitter, noise and timing effects which are
> actually already incorporated in to the worst case timing numbers
> for a device.  Here, we double count these effects.   In other
> cases, many manufacturers do not perform a thorough device and
> package characterization.  Many "standard" behaviorial simulation
> environments do not correctly simulate package crosstalk, power
> and ground effects.  Again, we miss the mark in actual performance.

> 
> Jonathan Dowling wrote:
> 
> > 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.
> >

> > 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
> >


__________________________________________________
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:     
                http://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: