DRAM Array Organization: Tricky Q&A

[INT][DRAM][ARRAY-ORGANIZATION]

Q: Why does increasing bank count not automatically deliver proportional bandwidth scaling?

A:
Because bank-level concurrency is limited by shared activate current limits (tRRD/tFAW), command scheduling constraints, bank-group turnaround penalties, and workload locality. If requests alias to the same groups or rows, extra banks remain underutilized while power/timing guardrails cap issuance rate. Senior analysis therefore reports achieved BLP versus theoretical, with current and conflict bottlenecks called out explicitly.

FOLLOW-UP TRAP: Assuming bandwidth scales linearly with the number of banks listed in the device spec.

[INT][DRAM][ARRAY-ORGANIZATION]

Q: How would you decide between open-page and close-page behavior for a mixed CPU workload?

A:
Profile row-hit distribution, latency tail targets, and fairness requirements per traffic class. If locality dominates, open-page usually wins by amortizing ACTIVATE/PRECHARGE energy and latency; if conflict-heavy random traffic dominates, aggressive close-page or adaptive policy reduces row thrashing and tail blowups. The right answer is an adaptive scheduler policy tied to measured row-buffer usefulness, not a fixed ideology.

FOLLOW-UP TRAP: Choosing one page policy globally without workload-specific row-hit and QoS evidence.

[INT][DRAM][ARRAY-ORGANIZATION]

Q: What makes address mapping a reliability concern in addition to a performance concern?

A:
Mapping controls where high-activity streams land physically. Poor mapping can concentrate activates in adjacent rows/subarrays, increasing thermal stress, retention pressure, and row-hammer disturb probability even if average bandwidth looks acceptable. Reliability-aware mapping intentionally spreads aggressor activity while preserving enough locality for efficiency, then validates with disturb and thermal stress campaigns.

FOLLOW-UP TRAP: Treating address mapping only as a throughput optimization and ignoring physical hotspot formation.

[INT][DRAM][ARRAY-ORGANIZATION]

Q: When a workload shows high average bandwidth but poor p99 latency, which array-organization levers do you inspect first?

A:
Start with bank-group conflicts, row-miss bursts, and scheduler reorder limits under QoS constraints. Then inspect whether row size/subarray granularity and mapping choices are causing repeated ACTIVATE penalties or unfair queue buildup for latency-sensitive flows. Finally, correlate with refresh windows and power throttling events that can disproportionately impact tail latency despite healthy average throughput.

FOLLOW-UP TRAP: Debugging only the PHY data rate while ignoring bank conflicts, row-buffer behavior, and maintenance interference.

WORKLOAD -> DRAM SYMPTOM -> TIMING/QUEUE METRIC -> ROOT CAUSE -> FIX -> REGRESSION

ARRAY ORGANIZATION VIEW

rows x columns -> mats/subarrays -> local sense amps -> global I/O
physical distance shapes timing and energy