pillar

The Next RTL Simulation Bottleneck Is the CPU Front End: When ARMOR Node Compression Reaches 2.7×

ARMOR packs repeated narrow RTL nodes into CPU words. We audit the mechanism, denominators, failure modes, and adoption gates.

Chase Na 나경채

2026.08.13 05:13 KST Updated 2026.10.24 09:35 KST · 12 min read ·

VLSI Korea original feature diagram

🆓 Free article · Anyone can read this article for free

Bottom line: the next bottleneck in large compiled RTL simulations is not only the amount of RTL work. It is the host CPU’s ability to deliver instructions from an enormous simulator binary. ARMOR, released on August 9, 2026, keeps full unrolling while packing repeated narrow nodes into separate bit slices of a CPU word. Its paper reports an average 2.69× speedup over Repcut for AI accelerators and 1.63× for CPUs.

Those numbers are not a universal ranking. Gains depend on module and subgraph reuse, node-width distribution, activity, the host ISA, and instruction-cache behavior. The public repository also says the core source will arrive after MICRO 2026, so independent reproduction is not yet open.

GSIM source figure comparing RTL simulator performance across processors and workloads — Source-backed context: simulator speedup changes sharply with design and workload. Chen et al., GSIM Figure 6, CC BY 4.0; cropped and watermarked by VLSI Korea.

The first reader job is for verification and simulation leads: decompose “the simulator is slow” across graph structure, activity, build, and host. The second is for accelerator and CPU architecture leads: decide which RTL-regularity and host counters to collect before scaling the model.

Two decisions follow. One is whether to invest engineering time in ARMOR-style packing, event-driven optimization, or a compact kernel/data representation. The other is whether to accept a single benchmark multiple or require an internal acceptance run covering correctness, compile cost, memory, and host conditions.

Where the consensus and VLSI Korea differ

The consensus treats compiled RTL-simulator performance as a problem of evaluating fewer nodes and generating better C++. Event-driven systems skip unnecessary evaluation when signal activity is low; cycle-based systems flatten the graph into straight-line code to reduce branching and scheduling overhead.

VLSI Korea takes the analysis one layer lower. Once the generated C++ becomes large enough, RTL optimization turns into a host-microarchitecture problem. The simulator IR’s objective moves beyond node count to useful RTL work per fetched instruction byte.

Three RTL-simulation representation strategies: supernodes, packed nodes, and tensor data — VLSI Korea representation spectrum. GSIM, ARMOR, and RTeAAL optimize different layers of the simulation problem.

The exact disagreement is not whether full unrolling must disappear. ARMOR argues that a simulator can retain the compiler benefits of full unrolling while compressing repeated narrow computations into word slices, cutting instruction footprint and bit underutilization together.

Why now? ARMOR, GSIM, and RTeAAL Sim attacked the same host-CPU bottleneck in 2025–2026 through different representations: packed nodes, supernodes, and sparse tensor algebra. The deeper signal is not one novel speedup; it is that three approaches redefine RTL simulation as an instruction-locality and representation-density problem.

The bottleneck moves from the RTL graph to the CPU front end

Verilator turns Verilog or SystemVerilog into a single- or multithreaded C++/SystemC model. CIRCT’s Arcilator likewise lowers Arc IR through LLVM into object code, flattening hierarchy and executing arcs as state-transfer functions.

This family benefits from aggressive constant propagation, inlining, and scheduling. Its tradeoff is that the instruction working set for one simulated cycle expands with the design. The host front end must keep supplying a huge code stream instead of repeatedly touching a small data structure.

RTeAAL Sim source figure showing top-down host CPU breakdown for Verilator and ESSENT — Source-backed evidence: RTeAAL Sim measured persistent frontend pressure as RocketChip and SmallBOOM configurations grew. Zhu et al., Figure 7, CC BY 4.0; cropped and watermarked by VLSI Korea.

In Intel’s Top-Down Microarchitecture Analysis, front-end bound is the share of pipeline slots left unused because fetch or decode cannot supply work. Latency covers stoppages such as I-cache misses, ITLB misses, and branch resteers; bandwidth covers underuse of fetch or decode width.

The ARMOR paper reports that more than 70% of unoccupied slots were associated with the front end in specific Verilator examples. It also places per-cycle working sets in the hundreds to thousands of kilobytes, above the experimental host’s 32 KB L1 instruction cache. These are not universal Verilator constants, but they support the diagnosis that faster RTL evaluation alone is insufficient.

RTeAAL Sim is a useful counterpoint. It moves circuit behavior out of a huge statically generated instruction stream and into sparse tensors evaluated by compact loop kernels. ARMOR raises the density of unrolled code; RTeAAL keeps code compact and carries circuit structure as data.

ARMOR’s mechanism: execute several nodes in one word

ARMOR begins with isomorphic narrow nodes. If nodes share an operation and dependency pattern and have small widths, their values can occupy fixed slices of a machine word. One bit-level instruction can then evaluate multiple RTL nodes at once.

Four-step node-compression mechanism from repeated subgraph discovery to host bit-level execution — VLSI Korea mechanism diagram. Compression changes value layout and generated instruction density, not the intended RTL semantics.

Step one is module-aware subgraph discovery. Repeated graphs inside instances of the same module narrow the comparison space, turning the regularity created by hardware generators into compression candidates.

Step two is alignment. Equal widths are not enough: operand positions, predecessor mappings, and operation semantics must match so the same instruction can operate without cross-slice interference.

Step three combines packing with data rearrangement. Node bits enter word slices and may need to move into layouts required by downstream operations. The paper reports that 57% of nodes were compressed on average, while a 22.7% rearrangement overhead reduced net RTL-graph reduction to 34.51%.

Step four is host-instruction selection. The public README requires x86-64 BMI2, Clang 12, and -mbmi2. The measured speedup is therefore a property of an algorithm, host ISA, and compiler contract—not the simulator algorithm alone.

Structural reuse—not design size—is the feedstock

ARMOR’s benchmark graphs range from about 21,000 to 2.86 million nodes, but module reuse does not scale monotonically with size. GEMM-16×16 and Conv2D-16×16 show 99% reuse and Gemmini-32×32 shows 97%, while BOOM-2C shows 58% and BOOM-8C 83%.

Bar chart of module reuse and graph node counts across ARMOR benchmarks — Original chart from ARMOR Table I facts. Reuse is a packing input, not a standalone speedup predictor.

This distinction matters for project triage. The right question is not “Is the design large?” but “How often does the generator repeat identical tiles, lanes, queues, or pipeline structures, and how many nodes inside them are narrow enough to align?”

The larger average gain for AI accelerators is consistent with this hypothesis. Systolic arrays and replicated processing elements can create regular structures at high activity, allowing cycle-based evaluation to amortize its fixed work across many useful operations.

CPU cores contain more irregular control, variable-width comparison, and cache, TLB, or predictor state. Their workload activity may also be low. An honest evaluation must compare event-driven skipping and packed instruction density on the same workload.

How to read 2.69× without mixing denominators

The paper used a dual-socket Intel Xeon Platinum 8338 host and Clang++ 12 at -O2. Each core had a 32 KB L1I, 48 KB L1D, and 1.25 MB L2; each socket had a 48 MB L3. Baselines included Verilator 5.036, Arcilator, Khronos, Repcut, RTeAAL, Dedup, and ESSENT.

Horizontal bars separating ARMOR speedup, IPC and bit utilization measurements — VLSI Korea denominator audit of ARMOR’s reported averages. These five values cannot be added or treated as the same metric.

Average speedup over Repcut was 2.69× for AI accelerators and 1.63× for CPUs. The peaks were 3.84× on Gemmini-32×32 and 1.95× on BOOM-8C. Average IPC under ARMOR was 2.32 and 1.75, versus 1.11 and 0.83 for Verilator.

Bit utilization rose from 25.57% in a single-node scheme to 45.61% in the multi-node scheme. The calculation 45.61 ÷ 25.57 = 1.78 is a packing-density lift, not an end-to-end speedup.

The paper also reports 47.6% front-end bound for ARMOR and 76.1% for Verilator. Because the simulators consume different total cycles, that percentage-point gap must not be converted directly into wall time saved.

VLSI Korea separates three measurement layers. Graph reduction describes generated work, IPC and front-end bound describe host delivery, and end-to-end speedup describes the complete compiled simulator. The mechanism is credible when all three move coherently.

Front-End Compression Fit: measure three axes before adoption

VLSI Korea’s analytical framework is Front-End Compression Fit. Axis R is the repeated or isomorphic structure ratio, W is the share of packable narrow nodes, and F is front-end pressure in the baseline host profile.

VLSI Korea experiment manifest. A reproducible profile precedes the optimization choice.

If R×W is low, packing has little material. If F is low, a smaller instruction footprint may not move wall time. Even when all three are high, rearrangement, equality handling, and compilation can consume the gain. The product is an experiment-priority heuristic, not a ranking formula.

Decision matrix for node regularity, simulation activity and host bottleneck — VLSI Korea decision matrix. Collect reuse, width, activity and host counters before selecting an optimization family.

A first-pass triage does not require every graph statistic. At FIRRTL or another IR layer, extract operation-width histograms, module-instance reuse, and isomorphic-subgraph coverage. On the baseline executable, collect IPC, front-end bound, I-cache MPKI, and branch misses.

Activity is separate. Linux boot, CoreMark, random tests, and directed accelerator kernels produce different switching and hot paths on the same design. Fix the trace, seed, cycle count, and waveform settings or representation benefits become entangled with workload differences.

The economic translation is (baseline wall time − new wall time) × daily regression count, less compile and preprocessing time, peak memory, integration effort, and debug-observability cost. Nightly throughput and engineer wait time matter more than one heroic run.

The hard part and failure modes: equality, width, rearrangement, correctness

Logical operations are slice independent and fit packing naturally. Equality consumes several bits and collapses the result to one bit, making cross-slice handling harder. ARMOR applies packing to equality at widths of four bits or less and uses a bounded lookup-table method for CPU equality.

Correctness coverage layers from short trace through integration and long software boot — VLSI Korea correctness scope. Performance is inadmissible until the full semantic envelope is closed.

Wide arithmetic, variable shifts, cross-slice carry, and irregular fan-in reduce the packable share. Frequent layout conversion increases rearrangement instructions and register pressure, potentially shifting pressure from the front end into the backend or data path.

Host portability is another failure mode. The public workflow assumes BMI2, so identical code generation and speedup cannot be presumed on Arm, x86 without BMI2, or another compiler version. A heterogeneous fleet needs architecture-specific baselines.

Correctness is the decisive gate. Matching a short waveform window is insufficient. The suite must cover reset, X/unknown behavior, multi-clock boundaries, DPI/PLI, random seeds, architectural state, and checkpoints in long software boots.

Source availability is a current operational constraint. The ARMOR repository is MIT licensed, but it mainly contains a README and build description; the core implementation is promised after MICRO 2026. Today’s recommendation is therefore “top of the reproducible evaluation queue,” not “replace the production simulator now.”

Node-compression failure map covering irregular nodes, cross-slice operations, rearrangement, and host portability — VLSI Korea failure map. A gain can disappear when cost moves into layout handling, registers, or a different host.

The strongest counterargument: a different representation may be better

The strongest counterargument is that teams should stop refining unrolled code and instead move circuit behavior into a compact data structure. RTeAAL Sim uses sparse tensor algebra; GSIM combines supernode, node, and bit-level optimizations.

That argument becomes stronger when binary size and compile memory already exceed operational limits, activity is low or irregular, and compact kernels manage data access, branching, or scheduling better than static code.

ARMOR’s thesis is strongest when full unrolling’s compiler optimizations remain valuable, regular narrow nodes are abundant, and the baseline really is instruction-delivery bound. The relevant competition is therefore a workload-specific representation portfolio, not a single simulator name.

Portfolio matrix matching simulation activity and structural regularity to optimization families — VLSI Korea portfolio view. Event-driven, packed-unrolled, and compact-kernel approaches fit different workloads.

Korean Lens: standardize the measurement contract first

Korean AI-accelerator and RISC-V teams often mix generator-based RTL, FPGA emulation, commercial simulators, and Verilator. In that environment, the useful unit of value is not an external paper’s peak speedup. It is which job blocks the pre-tape-out regression queue, and for how many engineer-hours.

The first choice is IR telemetry. Nightly width histograms, repeated-module coverage, and top subgraphs from Chisel/FIRRTL or an internal IR support not just ARMOR-style packing but partitioning and incremental-compilation investments.

The second is host standardization. CPU model, microcode, compiler, flags, NUMA binding, core pinning, and cache settings belong in the benchmark manifest before results inform procurement or capacity planning.

The third is a bilingual vendor question. Replace “How many times faster?” with requests for compile time, peak memory, front-end bound, IPC, waveform correctness, and unsupported features on the same design and trace. That contract lets domestic design services, IP vendors, and university projects exchange comparable results.

Practitioner checklist and thesis breakers

Six-rung validation ladder for RTL simulator speedup claims — VLSI Korea validation ladder. Correctness and denominator control precede procurement or migration.

1. Fix the RTL revision, elaboration parameters, trace, seed, and simulated cycles. 2. Close semantic equivalence first with waveforms or architectural checkpoints.

3. Separate compile and preprocessing wall time and peak memory from simulation time. 4. Record CPU ISA, BMI2, compiler, optimization flags, core pinning, and NUMA placement.

5. Collect IPC, front-end bound, I-cache MPKI, branch misses, and backend bound together. 6. Translate the result into nightly throughput, energy, license or cloud cost, and engineer waiting time.

The first thesis breaker is failure by independent teams to reproduce a material share of the paper’s gain after the core source appears, while preserving correctness. The second is low packable share and net graph reduction on wide or irregular designs, leaving rearrangement to erase the benefit.

A third breaker is a host profile dominated by memory or backend stalls rather than the front end. In that case ARMOR’s mechanism does not touch the real bottleneck.

Reproducible simulator-run contract covering frozen inputs, reported metrics, and acceptance gates — VLSI Korea team contract. Freeze, report, and accept against one reproducible manifest.

6–12 month watchpoints

By September 30, 2026: check whether commits, issues, and build artifacts move beyond the README. Within 30 days after MICRO 2026: verify that the promised core source, exact commits, benchmark scripts, and golden outputs actually appear.

By December 31, 2026: look for reproduction on another x86 host and compiler, including quantified BMI2 dependency and compile cost. By March 31, 2027: check multi-clock, waveform, DPI/PLI, and long-software-workload coverage, plus results outside the CPU/accelerator set.

By June 30, 2027: look for node compression as an independent Verilator or CIRCT-family pass or in a production-quality toolchain. If source, correctness, and portability remain open, lower the adoption scenario.

Final judgment

ARMOR’s most important contribution is not its 3.84× peak. It is the argument that RTL code generation must be co-designed with the host CPU’s instruction-delivery budget, and that regularity from a hardware generator can be reused as word-level parallelism in the simulator.

Our current judgment is promising but conditional. ARMOR is a strong candidate for accelerator regressions where regular narrow nodes, high activity, and a front-end-bound host coincide. It must sit beside alternative representations for low-activity CPU workloads, wide or irregular logic, non-BMI2 hosts, and as long as the public core source remains incomplete.

Roadmap from source release through reproduction, portability, and toolchain integration — VLSI Korea adoption roadmap. Source, correctness, portability, and total regression economics gate production use.

Sources

ARMOR: Accelerating RTL Simulation via Multi-Node Compression, primary paper, August 9, 2026.
ARMOR public repository, MIT license, requirements, and source-release status.
Verilator official repository, generated C++/SystemC model workflow.
CIRCT Arc dialect documentation, Arcilator compilation model.
GSIM, primary paper and CC BY 4.0 source for Figure 6.
RTeAAL Sim, primary paper and CC BY 4.0 source for Figure 7.
Intel Top-Down Microarchitecture Analysis Method.
Gemmini official repository and BOOM official repository, benchmark-design context.

AI assistance note: AI tools assisted source discovery, arithmetic checks, translation consistency, and visual layout. VLSI Korea verified the cited claims against the linked primary sources; no human expert review, private customer information, or first-person test experience is claimed.

Frequently Asked Questions

What does ARMOR do for compiled RTL simulation?

ARMOR, released on August 9, 2026, keeps full unrolling while packing repeated narrow nodes into separate bit slices of a CPU word. One bit-level instruction can then evaluate multiple RTL nodes at once, cutting instruction footprint and bit underutilization together.

What speedups does the ARMOR paper report?

The paper reports an average 2.69× speedup over Repcut for AI accelerators and 1.63× for CPUs. These are not a universal ranking: gains depend on module and subgraph reuse, node-width distribution, activity, the host ISA and instruction-cache behavior.

Why is the host CPU front end a bottleneck for RTL simulators?

Once generated C++ becomes large, the host front end must keep supplying a huge code stream. The ARMOR paper reports that more than 70% of unoccupied pipeline slots were associated with the front end in specific Verilator examples, with per-cycle working sets above the experimental host's 32 KB L1 instruction cache.

How much of the RTL graph did ARMOR compress?

The paper reports that 57% of nodes were compressed on average. A 22.7% rearrangement overhead reduced the net RTL-graph reduction to 34.51%.

Can ARMOR be independently reproduced yet?

Not yet. The public repository says the core source will arrive after MICRO 2026, and the public README requires x86-64 BMI2, Clang 12 and -mbmi2, so the measured speedup is a property of the algorithm, host ISA and compiler together.

Related reading