DRAM & Controller (2).

DRAM controller is typically coupled with a cache or at least a write buffer.

DRAM: high latency and write-back overhead dictate preference for large burst operations.

The best controllers will lookahead in a pool of pending requests to assist decisions on when to do write back (aka close or deactivate).

But a new request falling in a previously open line can arrive just after we closed it!

It is best if clients can tolerate responses out of order (hence use bus/NoC structure that supports this).

Controller must

• set up DRAM control register programming,
• set clock frequency and calibrate delay lines,
• implement specific RAS-to-CAS latencies and many other timing details,
• and ensure refresh happens.

Controller often contains a tiny CPU to interrogate serial device data.

DRAM refresh overhead has minimal impact on bus throughput. For example, if 512 refresh cycles are needed in 4 ms and the cycle rate is 200E6 the overhead is 0.1 percent.

In the memories folder there is a simple DRAM+Controller TLM model. In the dramsim2 folder there is a TLM wrapper around the Univ-Maryland DRAM simulator. (Not examinable for CST).