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

About this list Date view Thread view Subject view Author view

From: Mike Saunders (mikesa@ia.nsc.com)
Date: Fri Apr 27 2001 - 14:44:38 PDT


I was specifically referring to sampling a single-ended signal into a diff.
lvpecl input, where the unused leg is either tied directly to VBB or to
some external VREF. However, this could also be a problem when both legs
of a sampled diff. input are "floating", ie- pulled to VTT. Vinu sent me a
comment stating that "the level shifter or the DC bias voltage divider can
be made asymmetric so that the true and complementary inputs 'float' to the
minimum swing level required at the input with respect to VBB." The main
issue in that case would be a reduction of the perceived duty cycle, if
"floated" to a voltage lower than VBB, or an increase in duty cycle if higher.

Regarding the DQS timing mentioned by Kevin, who defined this interface
anyway?!? 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.
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).

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

Good insight, Kevin.

--Mike

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
majordomo@silab.eng.sun.com. 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