Thanks for the explanation Nitin.
Sparsh
On Aug 1, 2019, at 10:08 AM, Bhagwath, Nitin <Nitin_Bhagwath@xxxxxxxxxx>------------------------------------------------------------------
wrote:
Hi Sparsh,
Here's my take on it:
* WCK is input-only at the DRAM, so it cannot be used as a traditional strobe
during a read
* LPDDR5 is planning on supporting low frequencies, and so there seems to be
an implicit dichotomy of "low-speed mode" and "high-speed mode" (for support
of Single Ended strobe/clock, DFE, ODT, etc)
* JEDEC's unofficial job seems to be to keep our jobs more interesting, and
so things are sometimes not terribly clearly spelt out.
So, for the case when RDQS is not being used, I think that the assumption is
that the data rate is low enough for the channel length that the controller
is going to be able to internally clock in the data being sent out by the
DRAM. The controller somehow trains itself to know the
ReadLatency+FlightTime+DRAMOutputLatency, and clocks in the data after a
pre-set amount of time. For "slow" speeds, and short reaches, perhaps the
flight time variations would be negligible enough. At higher data rates,
this might not be a good method, and an explicit read strobe (RDQS) would be
needed.
Procedure:
Disable RDQS -> send read command -> wait <pre-trained-amount-of-time> ->
start latching in data at 1UI intervals.
(Close my eyes -> Toss 4 balls up high in the air at 1 sec intervals -> count
to 5 -> hold my hand out and expect the balls to fall in my hand at 1sec
intervals)
One place I see this inferred is in section 7.4.3.1 "Read Timing". Buried in
the lower-middle part of the paragraph, it says "The DQ-data is valid for tQW
(DQ output window) and the controller must periodically train *its internal
capture clock* to stay centered in the tQW window to compensate for timing
changes due to temperature and voltage variation." Of course, it's talking
about voltage and temperature variation here, but the implication is that
there's an internal capture clock rather than using an external
(DRAM-generated) strobe.
So the WCK is used to help the DRAM drive the data out, but not quite as a
traditional strobe. At higher data rates, I'd expect this method would be
too difficult to control, and so the explicit RDQS would be a better way to
time the read data.
Regards,
-Nitin
-----Original Message-----
From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx] On ;
Behalf Of Sparsh Patwa
Sent: Wednesday, July 24, 2019 10:42 AM
To: si-list@xxxxxxxxxxxxx
Subject: [SI-LIST] LPDDR5
Hello All,
I’m trying to understand the new clocking architecture for LPDDR5 and wanted
to see if someone can explain what is the need for a RDQS mode when the WCK
can clock data on both write and read cycles ?
The Feb 2019 spec from JEDEC introduces WCK clocking and explains that the CA
bus operates at a lower clock CK where as the DQ bus operates off this new
WCK clock which can be 4x the speed of CK; and it can be used to sample DQ
for wrote and read operations however there is also a RDQS mode where RDQS
can be sent along with DQ during read cycles to same read data.
Maybe I’m missing something here but why have WCK and RDQS if they are used
for the same purpose ?
Thanks,
Sparsh
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
or to administer your membership from a web page, go to:
//www.freelists.org/webpage/si-list
For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
List forum is accessible at:
http://tech.groups.yahoo.com/group/si-list
List archives are viewable at:
//www.freelists.org/archives/si-list
Old (prior to June 6, 2001) list archives are viewable at:
http://www.qsl.net/wb6tpu
