1
\$\begingroup\$

When a dram module receives a read/write command (while a row is active) it needs to:

  1. decode the command along with bank and column.

  2. multiplex the bank and send command along.

  3. (when reading) move the data from the column's latches to the send buffer ready to shift out after the CL expires, barrel shifting along the way according to the column address.

    (when writing) associate the relevant places in the receive buffer to he correct bank and barrel shift.

All this together seems to take a consistent 10 ns on modern DDRx dram modules while there is a clock that goes 10 times faster.

What is the biggest bottleneck in this sequence and could it be improved significantly or is there something else I'm missing here?

\$\endgroup\$
  • \$\begingroup\$ Back in the not-so-old days there has been a model of DDR400 module made with spec of CL=0. Never heard anyone got a system to boot with CL=0 though. If you ask about it in SuperUser or RetroComputing someone might be able to dig out some details of it. \$\endgroup\$ – user3528438 Oct 6 '17 at 13:58
2
\$\begingroup\$

What is the biggest bottleneck in this sequence

My guess would be parasitics. The copper read line and the read ampilfier would look like a R/C low pass filter when reading from a DRAM cell.

And since there are limits on how wide the copper line and how thick isolations can be, the R/C time constant stayed roughly the same even when the silicon structures got smaller in newer processes.

Trying to improve this time constant woud probably lower the data density too much, which is also an important parameter in DRAM design.

\$\endgroup\$
  • \$\begingroup\$ +1 but I wouldn't call it parasitics - since a DRAM cell is a capacitor, that RC time constant is fundamental to its nature, not a side effect. And a process designed to maximise capacitance is probably not ideal for high speed logic... \$\endgroup\$ – Brian Drummond Oct 6 '17 at 15:41
  • \$\begingroup\$ Correct me if I'm wrong. In my understanding what you're referring to would be RAS latency, not CAS. \$\endgroup\$ – axk Sep 9 '18 at 15:45
1
\$\begingroup\$

DRAM is actually not all that fast. The only reason it supports a fast clock is because the internal row width is many times the external interface width, so after you pay the penalty of opening the row, it can be read out in pieces much faster as the actual DRAM array is sitting idle, waiting for the row to close. And then the next row by address is physically in a different bank, so it can be opened before the first one is closed and there won't be any additional delay in reading out multiple back to back rows. Basically, things are interleaved and paralleled to mask the slowness of the actual memory array as much a possible, but it's unavoidable on the first access in a burst.

\$\endgroup\$
  • \$\begingroup\$ I'm not talking about row selection at all. CAS latency is only about reading the currently selected row. Row selection must be completed prior to that. \$\endgroup\$ – ratchet freak Oct 6 '17 at 17:42
  • \$\begingroup\$ To be fully clear once a row is selected you are effectively reading from SRAM. \$\endgroup\$ – ratchet freak Oct 6 '17 at 17:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.