Equal Memory Payloads Can Require Different DRAM Row Work

Separate row state from the read payload

A memory specification can describe capacity, a rated transfer rate and a nominal CAS component without describing which DRAM row is open when a read needs the bank. That state matters because selecting a row and reading from it are different work.

Altera's External Memory Interfaces Agilex 7 F-Series and I-Series FPGA IP User Guide, version 23.2, identifies a DDR4 memory page by its bank group, bank and row. An activate command, abbreviated ACT, opens that page. With an open-page policy, the page can remain available for further accesses. Reusing the already open target row is a row hit. A different target row in the same bank is a row conflict: the current row must close before the target opens. PRE denotes precharge, the closing operation.

These named FPGA DDR4 controller descriptions explain the mechanism. Intel's historical Broadwell Server reference for the Xeon E5 v4 family also describes ACT as opening a page for subsequent CAS access. Neither source identifies the controller policy of an offered GPU host or accelerator.

References: [AR][AP][IP]

ROW4: follow the same payload through two row sequences

ROW4 is an invented counting example for one conventional DRAM bank in one fixed bank group. The bank starts closed. Four requested payloads of 64 bytes each have already been mapped to this bank and to the rows stated below. Exactly one read operation per requested 64 bytes is a teaching premise, rather than a claim about an actual DDR burst geometry.

Fix the serialized issued order and retain each open row until a different row is required. Exclude auto-precharge, refresh, other work and policy-driven closures. Count only the operations needed through the fourth read; there is no final cleanup precharge. These premises define both traces.

Trace H targets rows A, A, A, A. Its first read needs ACT A, then read 1 from A. Reads 2, 3 and 4 also use A, which remains open. The sequence is ACT A, read 1, read 2, read 3, read 4. H therefore has four reads, one ACT and zero intervening PRE operations. The last three reads reuse the row opened for the first.

Trace C targets rows A, B, A, B. It begins with ACT A and read 1 from A. For read 2, A is still open, so the sequence continues PRE A, ACT B, read 2. Read 3 requires PRE B, ACT A, read 3. Read 4 requires PRE A, ACT B, read 4. C therefore has four reads, four ACT operations and three intervening PRE operations.

Returning to A for read 3 does not reuse its earlier open state: that state was closed to serve B. H finishes with A open and C finishes with B open. Neither trace closes its final row inside the counted interval.

Both cases deliver 4 x 64 = 256 payload bytes. C adds three activations and three intervening precharges relative to H because its issued row sequence changes three times. These counts follow from the stipulated state transitions; the symbolic sequences explain the accounting rather than provide a command-issuance procedure.

References: [AR][AP]

Use the counts without inventing a performance ratio

ROW4 establishes a concrete difference in bank-state command demand at equal useful payload. A description that reports only four reads or 256 bytes loses that difference. Equal installed capacity, rated MT/s and nominal CL would leave it unresolved too.

The example assigns no durations or issue times. Every real DRAM timing constraint still applies, but the counts alone supply no request latency, achieved bandwidth or speedup. Four activations compared with one is a count comparison, not a fourfold execution-time claim. Fewer counted transitions also do not prove that H must win in an actual application.

Keep the separate timing questions with their existing guides. The CAS article explains how a paired operating rate and CL describe a nominal read-command component. The refresh article explains target-bank availability and request arrival. ROW4 isolates row reuse and conflict by excluding refresh; it adds no replacement calculation for either of those components.

Connect row locality to the actual issued behavior

An application address list is not enough to reproduce ROW4. Adjacent software addresses do not establish that requests reach the same DRAM bank or row. The example supplies the mapping as a premise. It also supplies the fact that all four reads reach that bank; cache behavior is outside its model.

Issued order matters as well. Altera's documented controller can inspect pending work and reorder commands. A row pattern in application request order therefore does not establish the same pattern at the DRAM interface.

Open-page retention can preserve useful row locality, while auto-precharge can close a row as part of an access. If closure has already occurred, the next different-row access does not need the same intervening explicit PRE shown in C. That changes the accounting boundary, rather than making the earlier closure disappear.

Intel's historical reference likewise distinguishes page-miss precharges from other closure categories, including automatic closure. This supports stating exactly what a count includes; it is not a universal event mapping. The useful comparison is the applicable mapping, policy and issued behavior together. ROW4 offers no universal open-page or closed-page recommendation.

References: [AR][IP]

Compare two explanations of the same supported system

Suppose a supplier offers a supported complete system for AI-host preprocessing and attributes a claimed improvement to better DRAM row reuse. Compare two fictional responses about that same system and workload, so differences in product support do not decide the question.

Response A restates the installed capacity, rated MT/s, CL and useful bytes processed. Those fields can describe capacity, a transfer-rate rating and a nominal read component. They do not identify which rows the requests need, which row is retained or how the controller serves them. The row-reuse attribution remains open.

Response B identifies the offered server, processor and memory configuration, and connects its applicable mapping and controller policy to evidence of the issued behavior for the relevant workload. It explains what was counted, including how row closures were treated. That response can substantiate the specific row-work explanation to the extent its evidence covers the claim. This is already a useful result: the buyer can distinguish a supported mechanism from a claim resting only on specification labels.

A further claim that preprocessing or the complete AI pipeline runs faster needs workload results on the offered configuration. Retain the software and workload versions, input size, useful work completed and configuration alongside those results. Ask how the observations connect the reported outcome to row behavior and account for other differences. A faster completion result alone does not identify its cause.

The next decision follows the evidence. Accept a documented component explanation at its supported scope; use the workload result to assess the application claim. If mapping, policy or issued behavior is missing, keep the row-specific attribution unresolved with the appointed platform and application owners. The missing evidence does not establish that the hardware is incompatible.

Carry selected equipment into a separate physical project

If the customer-selected system also needs a physical receiving, preparation or rack-assembly project, Leviathan's related Rack Assembly & Preparation service is a route to discuss that package. Its scope connects supplied equipment and the approved build configuration to agreed physical tasks and handoff records.

Use the related project inquiry with a nonconfidential equipment brief, approved configuration revision, supplied equipment state, proposed location, receiving arrangements and requested physical work. Memory or FPGA engineering, firmware, software and application-performance validation remain with the appointed providers. The physical inquiry defines the preparation and assembly package around the selected equipment.