[SI-LIST] Re: Question about Simulation in Spectraquest
- From: Jonathan Dowling <jdowlin2@xxxxxxxxx>
- To: si-list@xxxxxxxxxxxxx
- Date: Sat, 11 Aug 2001 11:33:28 -0700 (PDT)
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:
//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:
