RTeAAL Sim: Using Tensor Algebra to Represent and Accelerate RTL Simulation

Chip designers verify their circuits by simulating the register-transfer-level design in software, but the fastest simulators bake the whole circuit into the simulation program as code, so a big design takes ages to compile and, when it runs, its enormous instruction stream thrashes the CPU's instruction cache and starves the processor's front end; this paper (UC Berkeley — Yan Zhu, Boru Chen, Christopher W. Fletcher, Nandeeka Nayak) presents RTeAAL Sim, which recasts the circuit as a sparse tensor and the simulation as a cascade of tensor-algebra equations (Einsums), so the circuit becomes data fed to a small fixed kernel rather than sprawling code — decoupling simulation from binary size, slashing compile time and front-end pressure, and inheriting decades of tensor-algebra optimizations, all while matching the highly optimized Verilator across several CPUs and instruction sets.

The argument in one glance

Problem

Simulating a chip in software is slow, and the fastest way makes it worse in a new way

Before a chip is built, designers verify it by simulating its register-transfer-level (RTL) description — the Verilog that says what every register and gate does each clock cycle — on a CPU. This simulation is on the critical path of hardware development, run constantly during design and verification, and it is chronically slow, a persistent bottleneck. The fastest software simulators, like Verilator, get their speed by compiling the circuit directly into the simulation program: they turn the design into a dataflow graph and then generate C++ code that, when compiled and run, evaluates the circuit. That works, but it makes the circuit and the program one and the same, and as designs grow that identity creates its own problems — the program becomes as big and unwieldy as the circuit, which shows up as pain both before and during simulation.
What people did

Compile the circuit into a bespoke simulation binary

State-of-the-art CPU simulators embed the circuit into the binary: the RTL is lowered to a dataflow graph whose nodes are primitive operations, and that graph is translated into straight-line C++ that is compiled with heavy optimization. Each design becomes its own custom simulator executable, tuned by the C++ compiler for speed. This is the accepted, high-performance approach to software RTL simulation.
Why it fell short

The circuit becomes code, and code size becomes the bottleneck

Baking the circuit into the binary means the binary grows with the circuit, and two costs follow. First, compilation is slow: every new or changed design generates a large amount of C++ that must be recompiled, so the edit-simulate loop stalls on the compiler. Second, execution is fundamentally CPU front-end-bound: because the whole circuit is unrolled into straight-line code, the instruction stream is enormous and thrashes the processor's instruction cache, so the CPU spends its time fetching and decoding instructions rather than computing signal values. In other words, the circuit's size has been converted into code size, and code size has become the wall. Because simulation behavior is welded to the binary, there is no way to shrink the code without shrinking the circuit, and the usual tensor-algebra and data-layout optimizations that help data-heavy workloads do not apply to a workload framed as one giant program.
This paper's idea

Make the circuit data, not code, by casting simulation as tensor algebra

RTeAAL Sim reformulates RTL simulation as a sparse tensor algebra problem. The core idea is to express the RTL dataflow graph as a sparse tensor and its execution as a cascade of extended Einsums — a sequence of tensor-algebra equations over the dataflow-graph tensor and other tensors, augmented with user-defined operators for the primitive circuit operations. This flips the representation: the circuit is now data (tensors) processed by a small, fixed simulation kernel, rather than a huge program unique to the design. Decoupling simulation behavior from binary size in this way directly attacks both costs — a small generic kernel compiles quickly and does not blow up the instruction cache — and it makes RTL simulation amenable to the large body of well-studied sparse-tensor-algebra optimizations. To realize this, RTeAAL Sim uses TeAAL, a framework for analyzing, scheduling, and optimizing sparse tensor algebra kernels through a separation of concerns (mapping, format, binding), and the authors show that bespoke RTL-simulation optimizations map onto those abstractions (for example tensor compression as a format optimization and loop unrolling as a binding optimization). A proof-of-concept simulator, using only a subset of the available optimizations, already mitigates the compilation overhead and front-end pressure and is competitive with the highly optimized Verilator across multiple CPUs and instruction sets.

Why this problem is worth solving

RTL simulation is the workhorse of hardware development, so its speed shapes how fast chips can be designed.

Designing a chip means writing its behavior at the register-transfer level: a description, in a hardware language like Verilog, of the registers that hold state and the combinational logic that computes new values each clock cycle. You cannot fabricate silicon to try every change, so you verify the design by simulating it in software — applying test inputs, computing how signals propagate through the circuit, and checking the outputs, cycle by cycle. This simulation is run constantly throughout design and verification, on every change, so its speed directly limits how quickly designers can iterate. And it is slow: a modern chip has an enormous number of gates and registers, and faithfully computing all of their values every cycle is a huge amount of work. Faster alternatives exist in hardware — FPGA-based emulation and dedicated emulators — but they are expensive to acquire and often incur their own long compilation times for each new design. So CPU-based software simulation remains the default, and its performance is a persistent, widely felt bottleneck. Anything that makes RTL simulation meaningfully faster, or that removes the recompilation delay between changing a design and simulating it, saves time on the most repeated task in hardware development, which is why the problem attracts sustained effort.

The specific reason the fast approach hits a wall is that it conflates the circuit with the program.

The high-performance way to simulate on a CPU is to specialize: rather than run a generic interpreter over the circuit, compile the specific circuit into specific code, so the simulator for a given design is a custom program that does exactly that design’s work with no interpretive overhead. This is why Verilator is fast. But specialization by code generation has a hidden scaling problem. A large circuit becomes a large program — millions of operations turn into millions of lines of straight-line code — and CPUs are not built to run enormous, mostly-non-repeating instruction streams efficiently. The processor’s front end, which fetches and decodes instructions, and the instruction cache, which holds the code near the core, are sized for programs whose hot code is small and reused. A simulation binary that is essentially the whole circuit written out linearly overflows the instruction cache and keeps the front end busy just supplying instructions, so the CPU becomes front-end-bound: limited not by the arithmetic of computing signals but by the effort of streaming in the code that describes them. And before you can even run, you must compile all that generated code, which is slow. The root issue is that behavior is tied to binary size; if instead the circuit were represented as data consumed by a small, reused kernel, the code would stay small and cache-friendly while the circuit lived in data structures the memory system is good at streaming. That reframing is exactly what casting the problem as tensor algebra provides.

What people did before, and where it broke

Compiled, code-generating simulators (Verilator). Lower the RTL to a dataflow graph and generate specialized C++ that a compiler optimizes into a fast per-design binary. Where it broke. The binary grows with the circuit, so compilation is slow for each design and execution is front-end-bound with severe instruction-cache pressure.
Event-driven simulators. Dynamically schedule and evaluate only the graph nodes whose inputs changed, avoiding recomputing the whole circuit. Where it broke. The dynamic scheduling adds overhead and irregular control flow, and it still expresses the circuit as code, so it does not remove the fundamental code-size and front-end costs at scale.
Hardware-accelerated emulation (FPGAs, dedicated emulators). Run the design on reconfigurable or purpose-built hardware for speed. Where it broke. These are expensive to acquire and typically incur their own long compilation or mapping times for each new design, so they do not solve fast software iteration.
Bespoke per-simulator optimizations. Individual simulators add hand-crafted tricks (specialized layouts, unrolling) to relieve their bottlenecks. Where it broke. Each optimization is ad hoc and tied to one simulator, with no common framework to reason about, combine, or transfer them.
The gap. No approach represented the circuit as data processed by a small, fixed kernel — decoupling simulation behavior from binary size — so that compilation stayed cheap, execution stayed cache-friendly, and a mature body of optimizations could be applied uniformly.

How RTeAAL Sim works

Turning a circuit into a sparse tensor and simulation into a cascade of Einsums

↓ →
new
↓ →
new
↓ →
new
↓ →
new
↓ →
new

The idea

Turn the circuit from code into data. The pivotal move in RTeAAL Sim is to stop expressing the circuit as a program and start expressing it as data. Conventional fast simulators specialize by generating code, which makes each circuit its own giant binary; RTeAAL Sim represents the dataflow graph as a sparse tensor consumed by a small, reused simulation kernel, so the circuit lives in data structures rather than instructions. This single change decouples simulation behavior from binary size, which is the root of both the slow compile and the front-end bottleneck. Recasting a computation as sparse tensor algebra so that its structure becomes data amenable to a general engine, rather than bespoke code, is the same reframing the work on composable abstractions for sparse compilation covered elsewhere on this site is built on, treating an irregular problem as a sparse tensor kernel. RTeAAL Sim applies that reframing to RTL simulation, where the payoff is escaping the code-size wall.

Express the whole simulation as Einsums so a mature toolchain applies. Representing the circuit as a tensor is only useful if the computation over it is expressible in tensor algebra, and RTeAAL Sim shows it is: a cycle of simulation is a cascade of extended Einsums, tensor-algebra equations augmented with user-defined operators for the circuit’s primitives. Casting the work as Einsums means it can ride on the well-developed machinery for compiling and scheduling Einstein summations efficiently onto hardware. Compiling Einsum expressions into efficient, locality-aware execution is exactly the problem the work on compiling Einstein summations to locality-aware dataflow covered elsewhere on this site addresses, turning tensor-algebra equations into fast schedules. RTeAAL Sim benefits from that lineage by phrasing RTL simulation in the same language, so decades of tensor-algebra optimization become available to a domain that never had access to them.

Kill the recompile so iteration is fast. A large part of RTL simulation’s pain is not runtime but the wait to rebuild the simulator every time the design changes, because the code-generating approach must recompile the whole circuit-as-code. By making the circuit data fed to a fixed kernel, RTeAAL Sim shrinks what must be compiled to the small kernel, so changing a design mostly changes data, not code, and the edit-simulate loop stops stalling on the compiler. Attacking the long compilation delay that stands between changing a hardware design and testing it — so that reconfiguration becomes cheap enough not to dominate the workflow — is the same concern the work on fast FPGA compilation covered elsewhere on this site is built on, driving down the compile time that makes hardware iteration painful. RTeAAL Sim achieves it for software simulation by moving the circuit out of the binary and into data.

Following a design through RTeAAL Sim

Simulating one design without recompiling a giant binary

A trace, drawn from the paper, of how RTeAAL Sim simulates an RTL design as tensor algebra.

Step 1 of 5

Lower the RTL to a dataflow graph

As usual, the register-transfer-level design is lowered to a dataflow graph whose nodes are primitive operations and whose edges carry signals. This captures what the circuit computes each cycle.

The graph is the same starting point conventional simulators use.

Why it works

Data-sized circuits beat code-sized circuits on the CPU. A circuit compiled into code becomes a huge instruction stream that thrashes the instruction cache → but a circuit stored as tensor data is streamed through a small kernel → so the CPU stops being front-end-bound and spends time computing.
A fixed kernel compiles fast regardless of design size. Generating and compiling the whole circuit as C++ stalls every iteration → but only a small, generic kernel needs compiling while the circuit is data → so the edit-simulate loop no longer waits on the compiler.
Tensor algebra opens a mature optimization toolbox. Simulation framed as one giant program cannot use data-layout and scheduling optimizations → but framed as Einsums it can → so RTeAAL Sim inherits well-studied sparse-tensor-algebra optimizations for free.
A separation of concerns unifies bespoke tricks. Existing simulator optimizations are ad hoc and non-transferable → but TeAAL’s mapping, format, and binding abstractions express them uniformly → so tricks like compression and unrolling compose and generalize instead of being one-offs.
Even a partial implementation already competes. One might expect a new formulation to lag a mature tool → but even a subset of the optimizations relieves the compile and front-end costs → so the prototype already matches the highly optimized Verilator across CPUs and instruction sets.

What it costs (trade-offs and scope)

It is a proof-of-concept, competitive rather than dominant. The prototype matches Verilator with only a subset of the available optimizations; it demonstrates the reformulation works and relieves the key bottlenecks, but the paper positions it as competitive, not as a wholesale speedup over the state of the art yet, with the larger gains expected as more tensor-algebra optimizations are applied.
The pressure moves from code to data. Decoupling behavior from binary size shifts the circuit into tensor data, so while the instruction cache is relieved, the simulator now depends on efficiently streaming and caching that data; the benefit assumes the data path is more favorable than the code path, which holds for the evaluated designs but is a trade, not a free win.
It leans on the TeAAL framework and its abstractions. Realizing and optimizing the formulation uses TeAAL’s separation of concerns; the approach inherits whatever that framework can and cannot express, and mapping a given simulator optimization into it may take work.
The evaluation is on specific designs and machines. Competitiveness with Verilator (and ESSENT) is shown on particular RTL designs (RocketChip, BOOM, Gemmini sizes) across four machines and several instruction sets; other designs, corner cases of RTL semantics, and machines could shift the picture.
It targets cycle-based software RTL simulation. The reformulation addresses CPU-based simulation of synchronous RTL; other simulation styles, mixed-signal or asynchronous designs, and hardware-accelerated emulation are outside the scope of this work.

The evaluation

Simulating RTL on a CPU

Property	Compiled code-gen (Verilator)	Event-driven	RTeAAL Sim
Circuit representation
Binary grows with circuit
Compilation cost per design
Front-end / instruction-cache pressure
Reported outcome

A qualitative comparison of CPU RTL simulation approaches. RTeAAL Sim's proof-of-concept, with only a subset of tensor-algebra optimizations, mitigates compilation overhead and front-end pressure and is competitive with the highly optimized Verilator across multiple CPUs and instruction sets.Underlined values explain themselves when clicked.

Where this stops working

What to keep in mind

This explainer is based on the paper’s full text (arXiv:2601.18140, the extended version). The mechanism described is the paper’s: RTeAAL Sim reformulates RTL simulation as a sparse tensor algebra problem, expressing the RTL dataflow graph as a sparse tensor and its execution as a cascade of extended Einsums (tensor-algebra equations augmented with user-defined operators), which decouples simulation behavior from binary size and makes RTL simulation amenable to well-studied tensor-algebra optimizations; it uses the TeAAL framework (with its separation of concerns across mapping, format, and binding) to schedule and optimize the formulation, and taxonomizes bespoke RTL-simulation optimizations (for example tensor compression as a format optimization and loop unrolling as a binding optimization) in those terms. The headline result is the paper’s own: a proof-of-concept simulator, using only a subset of the possible optimizations, already mitigates the compilation overhead and front-end pressure and achieves performance competitive with the highly optimized Verilator across multiple CPUs and ISAs (the evaluation also compares against ESSENT on designs such as RocketChip, BOOM, and Gemmini). Exact kernel configurations, the tensor formulation details, and the full quantitative results should be read from the paper.

Background

Why so many problems are being recast as tensor algebra

It helps to see RTeAAL Sim as part of a broad and productive pattern: taking a computation that was traditionally expressed as bespoke code and re-expressing it as tensor algebra, so that a mature, general body of theory and tooling applies. Tensor algebra — especially in its sparse, Einsum-based form — has become a kind of lingua franca because an enormous amount of effort has gone into compiling and optimizing it well, driven by machine learning and scientific computing, and because its separation of what to compute from how to schedule it makes optimizations reusable across problems. When a domain reframes its core computation in this language, it suddenly inherits that toolbox and can express, combine, and transfer optimizations that were previously one-off. Graph processing, database queries, and deep learning have all benefited from this move, and RTL simulation is a striking new addition because it seems, on its face, like a control-heavy code-generation problem rather than a numerical one. The general lesson is that the representation you choose determines which optimizations are even thinkable, and that sparse tensor algebra is an unusually powerful representation to choose. That broader effort to build the abstractions and machinery that make sparse computation fast and general is the same enterprise the work on a stream ISA and processor specialization for sparse computation covered elsewhere on this site advances, treating sparse tensor work as a first-class target. RTeAAL Sim shows the reach of that enterprise by pulling hardware simulation into it.

If you remember only three things

1. RTL simulation — running a chip's register-transfer-level design in software to verify it — is a persistent bottleneck in hardware development. The fastest simulators, like Verilator, compile the circuit directly into the simulation binary as generated code, which has two escalating costs as designs grow: compilation is slow because every design becomes a large program to recompile, and execution is CPU front-end-bound with severe instruction-cache pressure because the circuit, unrolled into straight-line code, overwhelms the processor's instruction fetch. The circuit's size has become code size, and code size is the wall.
2. RTeAAL Sim reformulates RTL simulation as a sparse tensor algebra problem: it represents the RTL dataflow graph as a sparse tensor and expresses a cycle of simulation as a cascade of extended Einsums (tensor-algebra equations with user-defined operators for the circuit's primitives). This makes the circuit data processed by a small, fixed kernel rather than a giant per-design binary, decoupling simulation behavior from binary size — so compilation stays fast and the instruction cache is no longer thrashed — and it makes RTL simulation amenable to well-studied tensor-algebra optimizations, applied via the TeAAL framework's separation of concerns (mapping, format, binding), under which bespoke simulator tricks like tensor compression and loop unrolling are unified.
3. A proof-of-concept simulator, using only a subset of the available optimizations, already mitigates the compilation overhead and front-end pressure and is competitive with the highly optimized Verilator across multiple CPUs and instruction sets. It is positioned as competitive rather than dominant (with more gains expected as more optimizations are applied), it shifts pressure from code to data, it relies on the TeAAL framework, and it targets cycle-based software simulation of synchronous RTL.

Check yourself

Check your understanding

1. Why does the fastest style of CPU RTL simulation hit a scaling wall?
2. What is RTeAAL Sim's core idea?
3. How does casting RTL simulation as tensor algebra help beyond relieving the two bottlenecks?
4. What did RTeAAL Sim achieve, and what are its main caveats?

Sources

The paper is “RTeAAL Sim: Using Tensor Algebra to Represent and Accelerate RTL Simulation” by Yan Zhu, Boru Chen, Christopher W. Fletcher, and Nandeeka Nayak (University of California, Berkeley), published at ASPLOS 2026 (Volume 2), DOI 10.1145/3779212.3790214. It is licensed CC BY.

This explainer is written from the paper’s full text (arXiv:2601.18140, the extended version). The paper addresses the persistent bottleneck of CPU-based RTL simulation, where state-of-the-art simulators embed the circuit directly into the simulation binary, causing long compilation times and execution that is fundamentally CPU front-end-bound with severe instruction-cache pressure. RTeAAL Sim reformulates RTL simulation as a sparse tensor algebra problem: it expresses the RTL dataflow graph as a sparse tensor and its execution as a cascade of extended Einsums — tensor-algebra equations over the dataflow-graph tensor and other tensors, augmented with user-defined operators — which decouples simulation behavior from binary size and makes RTL simulation amenable to well-studied tensor-algebra optimizations. It uses TeAAL, a framework for analyzing, scheduling, and optimizing sparse tensor algebra kernels via a separation of concerns (mapping, format, binding), to optimize the formulation, and taxonomizes bespoke RTL-simulation optimizations (such as tensor compression as a format optimization and loop unrolling as a binding optimization) in those terms. The reported result is the paper’s own: a proof-of-concept simulator, even with a subset of these optimizations, already mitigates the compilation overhead and front-end pressure and achieves performance competitive with the highly optimized Verilator across multiple CPUs and ISAs, with comparisons also against ESSENT on designs including RocketChip, BOOM, and Gemmini. No numbers beyond the paper’s own have been introduced; exact kernel configurations, the tensor formulation, and the full evaluation should be confirmed in the paper.