Source-linked AI summary
Terracotta: Enabling the Adoption of New DRAM Techniques via a Flexible DRAM Interface and Memory Controller
Harsh Songara, Konstantinos Kanellopoulos, F. Nisa Bostancı, Konstantinos Marios Sgouras, Ataberk Olgun, İsmail Emir Yüksel, Andreas Kosmas Kakolyris, A. Giray Yağlıkçı, Onur Mutlu
TL;DR
DRAM techniques can improve computation, maintenance, parallelism, and access latency, but adopting them often requires repeated changes to rigid interfaces and controllers. Terracotta captures common command and controller structures in configurable primitives and evaluates them across four technique domains. Its implementations retain over 96% of custom implementations’ performance benefits, and a composition of two techniques outperforms either alone.
Problem
Method
Terracotta combines standardized custom command extensions with a programmable memory controller built around shared command and workflow primitives.
Source: §1 · p. 2Results
Terracotta retains over 96% of custom implementations’ performance benefits across four techniques and a ChargeCache–MASA composition, which outperforms either technique alone.
Source: §1 · p. 3Takeaways & Limitations
Terracotta reduces repeated interface and controller modifications while leaving vendors free to implement technique-specific DRAM functionality.
Source: §1 · p. 2, §9.2 · p. 15Terracotta does not provide technique-specific DRAM chip modifications; vendors must implement those, and supporting every technique in one architecture could add circuitry some products do not need.
Source: §9.2 · p. 15
Abstract
from arXiv · showhide
DRAM continues to limit the performance, energy efficiency, and robustness of modern systems. Many prior works propose DRAM techniques that support in-DRAM computation, improve memory access latency and parallelism, and enhance DRAM maintenance and reliability. However, adopting each new technique requires repeated modifications to the rigid DRAM interface and memory controller, hindering its deployment. Our goal is to reduce these repeated modifications. We observe that the DRAM commands and memory controller structures of many DRAM techniques are similar. Our key idea is to use these similarities to compose a set of primitives for implementing diverse DRAM techniques. We propose Terracotta, a new framework with two flexible components: (i) custom command extensions that let DRAM vendors define new commands within a single, standardized interface, and (ii) a programmable memory controller that system designers can program to support new DRAM techniques post-silicon. Together, these enable deployment by configuring the memory controller instead of modifying the interface and controller. We design Terracotta for a DDR5-based system and evaluate its performance, energy, and hardware complexity. For four DRAM techniques from four distinct domains (processing-using-DRAM, low-cost DRAM maintenance, subarray-level parallelism, and latency reduction), Terracotta retains almost all of the performance benefits (>96%) of custom implementations. A Terracotta-based composition of two techniques outperforms the Terracotta-based implementation of each technique alone, demonstrating the benefits of adding techniques without repeated interface and controller modifications. Terracotta incurs low DRAM energy (0.6-3.2%), area (0.03%), and power (0.56%) overheads in a high-end server-grade processor. Terracotta's source code is freely available at https://github.com/CMU-SAFARI/Terracotta.
1. Introduction
New DRAM techniques often require repeated interface and controller changes, slowing deployment. Terracotta captures shared command and controller structures in flexible primitives; its implementations retain over 96% of custom implementations’ performance benefits while adding low overhead.
Motivation
- New techniques can require non-standard DRAM commands and controller hardware, while standardization needs stakeholder agreement and already-deployed systems cannot easily adopt later techniques.The rigidity of interfaces and controllers can hinder adoption and deprive systems of performance, energy-efficiency, and security improvements.Source: §1 · pp. 1–2
Terracotta framework
- Custom command extensions standardize a command’s operation type, target DRAM locality, and payload in one interface extension, separating format from function so vendors can define commands without further interface changes.The extension requires a one-time change to the interface rather than repeated changes for each new command.Source: §1 · p. 2
- The programmable controller exposes state, triggers, updates, and actions, letting system designers implement new technique support after fabrication without modifying the controller.Actions can issue custom DRAM commands through Terracotta’s command extensions.Source: §1 · p. 2
Evaluation
- Terracotta implementations retain over 96% of custom implementations’ performance benefits across four techniques and a ChargeCache–MASA composition; the composition outperforms either technique alone.The four techniques span processing-using-DRAM, low-cost maintenance, subarray-level parallelism, and latency reduction.Source: §1 · pp. 2–3
- Terracotta adds 0.03% die area and 0.56% TDP overhead relative to a high-end server-grade CPU, plus 3.2% DRAM energy for PRADA and <1% for the other three techniques.The energy comparisons are relative to the respective custom implementations; the area and TDP comparisons use the high-end server-grade CPU.Source: §1 · p. 3
Availability
- Terracotta’s source code is freely available.Source: §1 · p. 3
2. Background
DRAM systems organize memory into channels, ranks, banks, and subarrays, while controllers translate requests into commands and schedule them onto the channel. The background describes how DRAM rows are operated and how controller scheduling proceeds.
2.1. DRAM Organization and Operation
- A DRAM channel connects a memory controller to ranks; chips contain banks and subarrays, where rows and columns are formed from DRAM cells.Subarrays share bank I/O circuitry, and a row buffer consists of the subarray’s sense amplifiers.Source: §2.1 · p. 3
- Opening a row requires ACT, after which RD or WR accesses row-buffer data; PRE closes the row, and timing constraints govern command spacing.The described constraints include tRCD, tCCD, tRP, and tRC.Source: §2.1 · p. 3
2.2. Memory Controller Organization
- The controller resolves each physical address to a DRAM address and queues the request before scheduling commands.Queues may be bank-partitioned or unified.Source: §2.2 · p. 4
- A two-level scheduler selects valid commands per bank, then chooses among them for the DRAM channel; the PHY converts scheduled digital commands into analog I/O signals.Source: §2.2 · p. 4
3. Motivation & Goal
DRAM techniques use DRAM’s internal structure to improve computation, maintenance, parallelism, or latency. Rigid interfaces and controllers make adoption difficult, motivating support for new commands and post-fabrication controller updates.
Motivation & Goal
- DRAM techniques target in-memory computation, lower maintenance overhead, exposed internal parallelism, or reduced memory access latency.Maintenance examples include refresh, read-disturbance mitigation, scrubbing, and online error profiling.Source: §3 · p. 4
- Techniques commonly need both interface support for new commands and controller hardware to decide when and how to invoke them.PRADA’s A* command drives a wordline without sense amplification; ChargeCache tracks recently precharged rows and applies lower timing constraints to them.Source: §3 · p. 4
- Rigid systems may need up to N interface changes and N controller redesigns to adopt N techniques; the goal is to support new commands without per-command interface changes and add controller support after fabrication.Standardization requires stakeholder agreement, and already-deployed systems cannot easily adopt new techniques.Source: §3 · p. 4
4. Terracotta
Terracotta uses configurable primitives based on similarities across DRAM techniques to support new techniques without repeated interface and controller modifications. Its command extensions and programmable controller cover shared command and workflow structures across diverse techniques.
4. Terracotta
- Terracotta combines standardized custom command extensions with a programmable memory controller that system designers can configure post-silicon.The design follows an analysis of 32 DRAM techniques across seven categories.Source: §4 · p. 4
4.1. Custom Command Extensions
- DRAM commands are decomposed into operation type, target DRAM locality, and payload, while vendors define their functional meanings within a common structure.For PRADA’s A∗ command, these specify activation without sense amplification, the target bank, and the row address.Source: §4.1 · p. 5
4.2. Programmable Memory Controller
- The controller primitives are state, triggers, updates, and actions, which designers configure to implement technique-specific workflows instead of fixed logic blocks.State can include metadata and timers; triggers test conditions, updates maintain state, and actions support custom commands.Source: §4.2 · p. 5
4.3. Applicability Across Techniques
- Across 32 techniques in seven categories, the mapping identifies shared underlying structures captured by Terracotta’s command extensions and controller primitives.The table maps techniques to required state, triggers, updates, actions, and custom commands.Source: §4.3 · pp. 5–6, Table 1 · p. 5
5. Terracotta: Design Overview
Terracotta routes requests through per-bank queues and scheduling, then evaluates technique triggers and updates controller state. It issues custom commands through the action unit and standard commands through the standard issue path.
5. Terracotta: Design Overview
- The per-bank scheduler selects a request and passes it to a trigger unit, which checks request attributes and, when needed, looks up metadata.A triggered request is marked with a technique ID and may have its command ID replaced with a custom command ID.Source: §5 · p. 6
- The channel scheduler forwards each selected request to update and action units, with updates maintaining state based on the technique and command IDs.State includes metadata and timers.Source: §5 · p. 6
- Custom commands are issued through the action unit to the DDR PHY, while standard commands use the standard command issue path.Source: §5 · p. 6
6. Terracotta: Implementation
Terracotta implements configurable DRAM support using DDR5 reserved command encodings and programmable controller tables, with state partitioned across techniques and banks to mitigate contention. Firmware configures the controller for each DIMM during early boot.
6. Terracotta: Implementation; 6.5. Hardware Complexity
- Terracotta supplies interface and controller support for all 32 surveyed techniques, but leaves DRAM-chip modifications to vendors; 15 techniques require such modifications.Its custom command decoder is confined to the DRAM center stripe and uses fewer than 24 gates for combinational control logic.Source: §6 · p. 6, §6.5 · p. 9
6.1. Custom Command Encoding
- Custom commands use DDR5’s reserved encoding space: a header signals the command, followed by one payload per operation operand.The header identifies the operation and DRAM locality; 4-bit command and payload-type identifiers allow up to 16 of each per design or command, respectively.Source: §6.1 · pp. 6–7
6.2.1. State: Metadata and Timers.
- Per-bank state uses 64-entry metadata tables and 16 programmable timers; state capacity can be scaled without changing Terracotta’s programmable logic or command encoding.Tables are 2-way set-associative and use configurable age-based invalidation; these sizes are design-time parameters.Source: §6.2.1 · p. 7
6.2.2. Trigger Unit.
- Triggers evaluate requests against configured techniques, filter multi-cycle commands using C/A-bus utilization thresholds, and select among eligible techniques by programmable priority.Metadata-dependent triggers look up and match metadata; metadata-independent triggers can become eligible on a trigger-table hit.Source: §6.2.2 · pp. 7–8
6.2.3. Update Unit.
- Updates use scheduled commands to modify technique metadata and load selected timers with technique-specific timing constraints.Metadata changes use configurable read-modify-write operations, while timer masks select which bank timers are loaded.Source: §6.2.3 · p. 8
6.2.4. Action Unit.
- On an action-table hit, the controller constructs a custom-command header and sequences typed payloads from scheduled-command fields to the DDR PHY.A programmable payload table maps fields such as row, column, and subarray to vendor-defined payload identifiers.Source: §6.2.4 · p. 8
6.3. System Support; 6.4. Security
- During PEI, firmware identifies each DIMM, loads its signed configuration into controller tables, and defaults to JEDEC-compliant operation when configuration is unrecognized or missing.After PEI, register lock bits prevent operating systems and user applications from changing the tables until reset.Source: §6.3 · p. 9, §6.4 · p. 9
6.5. Hardware Complexity
- The synthesized design occupies 0.083mm2 and consumes 324mW static power per DDR5 channel, about 0.04% of chip area and 0.67% of the power budget of a 10nm Intel Xeon processor.Triggers add two cycles to the critical path of a memory controller that supports no techniques. Updates remain off the critical path when minimum timing constraints exceed the two-cycle metadata read-modify-write latency; actions are off the critical path because custom and standard command issue paths operate in parallel.Source: §6.5 · p. 9
7. Evaluation Methodology
The evaluation compares Terracotta-based and custom implementations of four representative DRAM techniques using cycle-level performance and energy simulations. It evaluates single-core workloads and four-core mixes, measuring IPC and weighted speedup.
7. Evaluation Methodology
- Four techniques represent processing-using-DRAM, low-overhead maintenance, subarray-level parallelism, and access-latency reduction; simulations use Ramulator 2.0 integrated with DRAMPower.The techniques are PRADA, MoPAC-C, MASA, and ChargeCache.Source: §7 · p. 9
- Terracotta-based, custom-hardware, and applicable ideal implementations are modeled, with latency overheads included for fair comparison.Custom implementations use RTL-derived overheads and assume two cycles for non-standard commands; Terracotta models include two controller cycles and command latencies based on payload count.Source: §7 · pp. 9–10
- The workload set includes 57 single-core workloads and 60 four-core mixes; performance is measured with IPC for single-core and weighted speedup for multi-core.Workloads come from five benchmark suites; mixes span five memory-intensity categories.Source: §7 · p. 10
8. Evaluation
Terracotta is evaluated on four DRAM techniques, a ChargeCache–MASA composition, implementation overheads, controller-latency sensitivity, and a reconfigurable-logic variant. Across the reported evaluations, its implementations closely track custom implementations, and combining techniques improves performance over either Terracotta-based technique alone.
8.1. Processing-using-DRAM: PRADA
- 13.36× versus 13.79× is Terracotta-PRADA’s versus PRADA’s average speedup over the CPU baseline for one-bank in-DRAM operations; across 32 banks, their performance is nearly identical.Terracotta-PRADA retains 96.9% of PRADA’s average one-bank speedup; for COPY, NOT, and AND/OR across 32 banks, it outperforms PRADA by 0.2%–1.7%.Source: Figure 9 · p. 10, §8.1 · pp. 10–11
8.2. Lower-Overhead DRAM Maintenance Operations: MoPAC-C
- 0.3% (four-core) and 0.5% (single-core) separate Terracotta-MoPAC-C from custom MoPAC-C; at TRH 250, it improves performance over PRAC by 4.1% and 3.7%, respectively.Terracotta-MoPAC-C retains 96.0% and 88.2% of custom MoPAC-C’s improvement over PRAC for four-core and single-core workloads.Source: Figure 10 · p. 11, §8.2 · p. 11
8.3. DRAM Parallelism: MASA
- 0.22% (four-core) and 0.51% (single-core) lower geometric-mean performance than custom MASA still leave Terracotta-MASA with 96.72% and 92.66% of MASA’s improvement over baseline.Terracotta-MASA captures 68.3% and 74.6% of the ideal system’s geometric-mean improvement for four-core and single-core workloads.Source: Figure 11 · p. 12, §8.3 · p. 12
8.4. Reducing Memory Latency: ChargeCache
- 96.4% (four-core) and 87.7% (single-core) of custom ChargeCache’s benefits are retained, with geometric-mean speedups over baseline of 1.09% and 2.04%, respectively.The result is reported despite Terracotta’s memory-controller latency overhead.Source: Figure 12 · p. 12, §8.4 · pp. 12–13
8.5. Composing ChargeCache and MASA
- 6.4% and 1.4% (single-core), and 6.1% and 0.2% (four-core), are ChargeCacheMASA’s speedups over Terracotta-ChargeCache and Terracotta-MASA; the composition retains 95.8% and 95.9% of custom implementation gains.The retention figures correspond to single-core and four-core mixes, respectively.Source: Figure 13 · p. 13, §8.5 · p. 13
8.6.1. Energy.
- 3.2% more DRAM energy for one-bank Terracotta-PRADA contrasts with overheads below 0.64% (single-core) and 0.40% (four-core) for the remaining techniques and their composition; 99th-percentile access latency rises 0.17%.The 3.2% overhead applies to in-DRAM computation operations in one bank; across 32 banks, PRADA’s average DRAM energy is 0.17% lower than custom PRADA’s.Source: §8.6.1 · p. 13, §8.6.2 · p. 13
8.6.3. Area and Power.
- 0.03% of die area and 0.56% of thermal design power are Terracotta’s overheads relative to a high-end Intel Xeon processor; increased controller latency causes only marginal performance decreases for the other techniques and their composition.PRADA’s performance remains unchanged as controller-latency overhead rises from two to 10 cycles in the evaluated 32-bank workloads.Source: §8.6.3 · p. 13, §8.6.4 · p. 14
8.7. Terracotta with Reconfigurable Logic
- 0.37–0.66% lower performance than Terracotta-Tables is the CGRA-based implementation’s result for the remaining techniques and their composition, while PRADA preserves nearly all custom-implementation benefits.Terracotta-CGRA provides similar performance to custom implementations, with little or no performance loss relative to Terracotta-Tables.Source: Figure 16 · p. 14, §8.7 · p. 14
9. Discussion
Terracotta’s primitives may need extensions for techniques requiring coordination across banks or feedback from DRAM outcomes. Its stated limitations also include technique-specific chip or processor changes and fixed controller resources and timing constraints.
9.1. Extending Terracotta
- Cross-bank coordination and DRAM-outcome feedback are unsupported by the described primitives, so techniques requiring them may need extensions that the paper leaves to future work.Potential additions include channel- or bank-group-level triggers and a feedback path that records profiling results in state for later triggers and updates.Source: §9.1 · pp. 14–15
9.2. Limitations of Terracotta
- Fixed metadata and timer resources, technique-specific chip or processor changes, and timing constraints tighter than table read-modify-write latency bound what a Terracotta implementation can support without redesign.The paper leaves technique-specific DRAM modifications to vendors and processor or memory-hierarchy modifications to system designers.Source: §9.2 · p. 15
10. Related Work
Terracotta is presented as a framework for enabling DRAM techniques through custom command extensions and a programmable controller, unlike prior approaches focused on other forms of programmability or existing-command infrastructures.
Related work
- Terracotta is described as the first work to reduce repeated interface and controller modifications needed to enable DRAM techniques.The claim is made with respect to the cited range of DRAM techniques.Source: §10 · p. 15
- SMD targets autonomous DRAM maintenance, whereas Terracotta supports techniques needing controller-side changes; the paper describes the frameworks as complementary.The paper says they can be combined to enable further DRAM-system innovations.Source: §10 · p. 15
- Unlike FPGA-based infrastructures and systems exposing functionality through existing commands, Terracotta provides vendor-defined custom command extensions and post-silicon programmable controller support.PARDIS offers programmable address resolution, scheduling, and power management, but cannot implement techniques introducing new DRAM commands or controller metadata.Source: §10 · p. 15
11. Conclusion
Terracotta packages shared DRAM command and controller workflows into configurable primitives, with custom command extensions and a programmable controller. The conclusion also describes the analyzed modification categories and the artifact’s reproduction materials.
11. Conclusion
- Terracotta combines custom command extensions with a programmable memory controller to support four DRAM techniques across distinct domains.The conclusion reports almost all performance benefits of the respective custom implementations, with low DRAM energy, controller area, and power overheads.Source: §11 · p. 15
A. Modifications Required by the Analyzed DRAM Techniques
- The appendix classifies technique modifications as memory-controller, DRAM-interface, or DRAM-chip modifications.Controller modifications can involve state, triggers, updates, commands, or timing; interface modifications involve undefined commands or repurposed reserved or unused bits; chip modifications change the cell array or peripheral circuits.Source: A. Modifications Required by the… · p. 23
B.1. Abstract; B.1.1. Source code, scripts, and data.
- The artifact provides source code, scripts, and data to reproduce Terracotta’s results.It includes a cycle-level simulator, RTL sources, workload traces, and scripts for running experiments and generating plots.Source: §B.1 · p. 23, §B.1.1 · p. 23
B.1.2. Reproducible results.
The artifact supports reproduction of several Terracotta performance, energy, latency, and hardware-complexity results. Its checklist records the public archive and the resources and environment needed to run it.
B.1.2. Reproducible results.
- The artifact supports reproducing performance, DRAM energy, memory-access latency, and controller area and power results.The reproducible results include the performance and energy figures, latency results, and controller complexity results.Source: §B.1.2 · p. 23
B.2. Artifact check-list (meta-information)
- The checklist specifies software, hardware, benchmark, metric, storage, and runtime requirements for the experiments.It lists 57 workload traces from five benchmark suites, five PRADA microbenchmarks, approximately 80 GiB of disk space, and a recommended 1000-core cluster for a one-day full sweep.Source: §B.2 · p. 23
- The artifact is publicly available, with separate archived DOIs for its source and traces.The checklist also identifies Bash and Python automation.Source: §B.2 · p. 24
B.3.1. Key results (R).
The artifact documents the results it is designed to reproduce, the execution requirements, and the steps for building and running its experiments. Its workflows cover performance and DRAM energy as well as hardware complexity.
B.3.1. Key results (R); B.3.2. Experiment workflows (E)
- The listed key results cover performance, DRAM energy, 99th-percentile latency, controller-latency sensitivity, hardware overheads, and programmable-table versus reconfigurable-logic performance.The artifact divides the experiment workflows into performance and DRAM energy (E1) and hardware complexity (E2).Source: §B.3.1 · p. 24, §B.3.2 · p. 24
B.3.4. Hardware dependencies.
- The full sweep comprises approximately 5000 jobs, with up to 4 GiB of RAM and one core per simulation job.The artifact recommends an x86-64 system with at least 32 GiB of RAM and approximately 80 GiB of free disk space; a 1000-core cluster is recommended for completion in about one day.Source: §B.3.4 · p. 24
B.3.5. Software dependencies.
- The artifact requires Linux, CMake, a C++20 toolchain, Python packages, and Git-related utilities; containerized E2 runs require Podman or Docker.Slurm is needed for cluster runs, while containerization is optional for E1.Source: §B.3.5 · p. 24
B.3.6. Workload memory traces.
- Workload traces come from SPEC CPU2006, SPEC CPU2017, TPC, MediaBench, and YCSB; PRADA also uses five computation microbenchmarks.Those microbenchmarks cover COPY, NOT, AND/OR, NAND/NOR, and XOR/XNOR operations in one bank and across 32 banks.Source: §B.3.6 · p. 24
B.4. Installation; 1. Obtain the source code; 2. Install Python dependencies; 3. Download the traces; 4. Build the tools.
- Installation begins by cloning the repository, installing Python dependencies, and downloading traces.The instructions then distinguish building Ramulator 2.0 for E1 from building the OpenROAD and Yosys container image for E2.Source: §B.4 · p. 24, §1 · p. 24, §2 · p. 24
B.5. Experiment workflow; 1. Launch the sweep; 2. Track simulation progress.
- The E1 workflow launches the sweep on Slurm or a personal computer and provides scripts to track progress.The instructions recommend detached execution for the large sweep and include live-dashboard and completion-status scripts.Source: §B.5 · p. 24, §1 · p. 24, §2 · p. 24
3. Parse and plot.
- After simulations finish, scripts parse results and generate plots, CSV data, and text reports; the E2 workflow runs hardware synthesis.The reported output directories include figures/, results/csv/, and results/txt/.Source: §3 · pp. 24–25
B.6. Evaluation and expected results
The artifact’s expected results include performance, energy, latency, and controller-complexity measurements. It also documents experiment customization and identifies the artifact-review methodology.
B.6. Evaluation and expected results
- The expected results include near-retention of custom-implementation performance benefits, low DRAM energy overheads, and a 0.17% increase in 99th-percentile latency over custom implementations.The figures also report sensitivity to controller-latency overhead and compare programmable-table-based with CGRA-based implementations.Source: §B.6 · p. 25
- Controller overhead over custom implementations is 0.03% of die area and 0.56% of the reference Intel Xeon processor’s TDP.The hardware-complexity workflow reports these area and power results.Source: §B.6 · p. 25
B.7. Experiment customization
- The experiment scripts allow customization of techniques, simulation parameters, runtime environment, workloads and mixes, and containerization.The artifact README provides customization instructions.Source: §B.7 · p. 25
B.8. Methodology
- The artifact identifies ACM artifact-review and badging methodology and cTuning as its methodology references.Source: §B.8 · p. 25