Re: [SI-LIST] : Re: Question on DDR dram DQS handling.

About this list Date view Thread view Subject view Author view

From: D. C. Sessions ([email protected])
Date: Sat Apr 28 2001 - 07:46:11 PDT


On Friday 27 April 2001 14:44, Mike Saunders wrote:

> Regarding the DQS timing mentioned by Kevin, who defined this interface
> anyway?!?

A whole lot of people, both memory manufacturers and system (ASIC) builders.
Their objective was to make the whole combination work in a commodity
environment. In other words, the system vendors are very aware of the need
to have low-overhead and manufacturable (read: cheap) memory.

> The main problem with building anything that snoops or otherwise
> interacts with the DQS's is that they are edge aligned w/ the data when
> returned from the memory (on reads) but center-aligned when written from
> the MC. The entire concept of having two clock domains makes determining
> timing budgets a real bear.

Yup, but it puts the burden of doing all that work on the controller for both
reads and writes. It's easier to generate edge-aligned data, but easier to
sample center-aligned data. The DRAM gets the best of it both ways because
any other approach would involve replicating the extra circuitry 72 times per
system in parts built with processes that are oriented more towards low leakage
than high performance. The committee decided, not without stress, to place the
burden where it could best be borne.

> It's not too hard to sample the read data if you know that the edges are
> coincident with the data, especially since the memory chips are supposed to
> strobe the data on the nominal clock edge plus flight time. However,
> picking off only a subset of the DQS's and routing it/them to each memory
> chip on the dimm does tend to require additional buffering to the timing
> budget due to chip-to-chip skew on the dimm. I assume this is what Kevin
> meant when he stated that the dram chips only see a single DQS.
> The difficult challenge is to account for an independent "clock domain" on
> writes, since the DQS strobes on a write are allowed to occur anywhere from
> 75% to 125% of the nominal clock period. That translates to the question
> "by 125% of the clock period, have I already seen the first strobe go by,
> or is this one the first?", among many others. If any Standards-defining
> people are listening, keep a single clock domain on any future definitions
> (clocking on both edges or whatever).

You could, of course, join JEDEC and have a say yourself. In the meantime,
although I myself don't contribute to this part of JC-42.3 I can say that the people
defining these standards are Not Fools. The amount of intellectual horsepower in
the room is quite impressive, and they _do_ know their tradeoffs. It's just not an
easy problem once you consider how many billions of dollars per year are at
stake.

> As to the mumbling about a circuit solution, that's what I've been
> designing/simulating for the last two weeks and it's been a real pain! (In
> the Jedec standard for DDR SDRAM there is an optional QFC# signal, which is
> like a "DQS_VALID". I would challenge any reasonably capable designer to
> actually produce such a signal, without tons of overhead that adds
> exponentially to the timing uncertainty, of course. I suspect that the
> difficulty in going between two clock domains is exactly why it's optional.)

Nobody likes QFC# and for all practical purposes you can forget about it.
It's gone.

> At 11:37 AM 4/27/2001 -0700, you wrote:
> >
> >> One potential gotcha with either of these solutions could be "floating"
> >> inputs which are actually terminated to an intermediate voltage (as occurs
> >> in SSTL-II DDR SDRAM). In that case, you'll need to ensure that your input
> >> logic always determines the signal in a defined state (ie- when the term.
> >> voltage, after level shifting, is at or near the VBB of your input logic).
> >> --Mike
> >
> >
> >Mike's comment here reminded me of a nagging issue about DDR DQS signals.
> >
> >Forgive the detail level if you're not familar with DDR.
> >(double data rate sdram 133/266mhz)
> >
> >At the memory controller, there are many DQS signals (data strobes for
> read data)
> >coming in. (as opposed to at the dram chips, which only see one).
> >
> >So there is quite a lot of skew between early and late DQS strobe arrivals.
> >
> >
> >The problem is that these DQS signals are bidirectional. They are driven
> >by the memory control on writes, and by the dram on reads.
> >
> >The Jedec DDR spec specifies a "preamble", where they are driven to 0 for
> >a full dram cycle (roughly 7.5ns) before they start transitioning for
> >valid data transfers.
> >
> >So the clumsiness is that you can't just deal with DQS like an asynch
> interface.
> >
> >You have to only look at DQS when it's valid for returning read data, and
> >you have this preamble window defined by synchronous events like sending
> >a read command to the dram and counting cycles.
> >
> >But the large number of DQS's (for wide interfaces),
> >total skews, and dimm configuration dependencies, make the preamble window
> >seem pretty small....
> >
> >The whole problem ends up causing as much risk to margin, as the basic
> >DQS/DQ (strobe/data) sampling within a valid data window issue.
> >
> >
> >I throw this out, wondering if anyone out there is doing DDR and has
> >any words of wisdom. (The DDR is SSTL as mentioned above)
> >
> >Some people have mumbled that there could be a circuit solution, that
> >detects just when the DQS is valid. But I don't see that?
> >
> >-kevin
> >
> >
>
>
> **** To unsubscribe from si-list or si-list-digest: send e-mail to
> [email protected]. In the BODY of message put: UNSUBSCRIBE
> si-list or UNSUBSCRIBE si-list-digest, for more help, put HELP.
> si-list archives are accessible at http://www.qsl.net/wb6tpu
> ****
>
>

-- 
| The race is not always to the swift, nor the battle to the strong. |
| Because the slow, feeble old codgers like me cheat.                |
+--------------- D. C. Sessions <[email protected]> --------------+

**** To unsubscribe from si-list or si-list-digest: send e-mail to [email protected]. In the BODY of message put: UNSUBSCRIBE si-list or UNSUBSCRIBE si-list-digest, for more help, put HELP. si-list archives are accessible at http://www.qsl.net/wb6tpu ****


About this list Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Thu Jun 21 2001 - 10:11:45 PDT