PaperlayerView exact revision on arXiv

Source-linked AI summary

TPCS: A Cycle-Level Simulation Paradigm with Native Execution Semantics for RTL Modeling and Generation

Chengzhen Meng, Xiaoyu Li, Chen Bai, Zhenyu Zhang, Hongjun Dai

arXiv:2610.13067v1cs.AR

TL;DR

Pre-RTL evaluation must balance fast exploration with fidelity to detailed hardware behavior. TPCS uses transaction-based native execution and structural RTL generation; evaluations report faster simulation, cycle-level waveform agreement, and RTL quality close to hand-written designs.

  • Problem

    High-level simulators offer exploration speed but limited hardware fidelity, while RTL simulation has substantial overhead, complicating efficient pre-RTL microarchitecture evaluation.

    Source: §I · p. 1

  • Method

    TPCS models cycle-synchronous hardware with transaction-level function invocations and native control flow that prunes inactive logic while supporting structurally corresponding RTL generation.

    Source: §I · p. 2

  • Results

    TPCS achieves 36×–42× speedups over parallel Verilator on SMP systems and 3.4×–7.2× over single-threaded Verilator on accelerators, with cycle-level waveform agreement and comparable generated-RTL timing and area.

    Source: §I · p. 2, §VI · p. 12

  • Takeaways & Limitations

    The evaluated results support a unified representation for fast pre-RTL exploration, validation, and hardware implementation.

    Source: §VI · p. 12, §V · p. 12

    TPCS usability depends on infrastructure that is not yet mature, including stronger modeling diagnostics, debugging support, and reusable libraries.

    Source: §V · p. 12

Abstract

from arXiv · show

The growing diversity of domain-specific architectures and microarchitectural designs demands fast and accurate evaluation methods during early design stages. However, existing approaches suffer from a fundamental trade-off: high-level simulators offer speed but lack fidelity, while RTL-based tools provide accuracy at the cost of significant simulation overhead. This gap limits efficient pre-RTL microarchitecture exploration. Therefore, we propose Transaction-Pruned Cycle Simulation (TPCS), a novel modeling and simulation framework. It serves as a unified intermediate abstraction spanning microarchitecture modeling, cycle-accurate simulation, and synthesizable RTL implementation. TPCS organizes combinational logic as transaction-based function invocations and leverages host CPU control flow to naturally prune inactive logic, eliminating the need for explicit event scheduling or signal tracking. This enables cycle-accurate simulation with significantly improved performance. TPCS preserves structural correspondence with RTL and supports automatic generation of synthesizable designs. TPCS achieves 36$\times$-42$\times$ speedups over parallel Verilator on SMP systems and 3.4$\times$-7.2$\times$ over single-threaded Verilator on accelerators, with cycle-level waveform agreement on the evaluated traces. The generated RTL demonstrates comparable timing and area to handcrafted implementations, with relative changes of -4.7\% to +2.6\% in clock period and -3.3\% to +4.0\% in standard-cell area. By bridging the abstraction gap between high-level modeling and RTL design, TPCS enables a unified and agile pre-RTL workflow, allowing efficient microarchitecture exploration with both high performance and implementation fidelity.

I. INTRODUCTION

TPCS targets the efficiency–fidelity trade-off in pre-RTL microarchitecture evaluation with a native-execution model that supports cycle-level agreement and RTL generation. Its related-work positioning is a unified representation spanning modeling, simulation, and implementation.

I. INTRODUCTION

  • High-level tools prioritize exploration agility while RTL tools prioritize fidelity but incur simulation overhead, leaving neither suited to efficient and accurate pre-RTL evaluation.Prior approaches either trade efficiency for fidelity or rely on complex multi-level workflows –.Source: §I · p. 1
  • TPCS reframes simulation around behavioral descriptions because control logic activates computation blocks, allowing inactive paths to be skipped without explicit activity tracking.Prior signal-activity tracking approaches remain at signal-level abstraction,.Source: §I · pp. 1–2
  • TPCS models deterministic cycle-synchronous hardware as transaction-level function invocations, using host control flow to prune inactive logic and structural correspondence to generate synthesizable RTL.The framework aims for cycle-level equivalence at module boundaries while supporting fast pre-RTL evaluation.Source: §I · p. 2
  • 36×–42× speedups on SMP systems and 3.4×–7.2× on accelerators are reported against parallel and single-threaded Verilator baselines, respectively, with waveform agreement and near-handwritten RTL timing and area.Reported RTL changes are -4.7% to +2.6% in clock period and -3.3% to +4.0% in standard-cell area.Source: §I · p. 2

II. RELATED WORK

  • Mixed frameworks such as SystemC TLM and GEM5+RTL combine abstractions but retain reimplementation across layers and interface overhead, whereas TPCS uses a unified intermediate representation,,, –.Source: §II · p. 2
  • Cycle-level synthesizable SystemC still relies on kernel scheduling and signal or event updates, while TPCS maps control flow to native calls without a runtime event scheduler.Source: §II · p. 2
  • High-level RTL generators often target specific domains and remain signal-level construction frameworks, including approaches for CPUs, accelerators, and SoCs –.Source: §II · pp. 2–3
  • Assassyn generates cycle-accurate simulation and synthesizable RTL but is limited to pipeline and FIFO structures and uses event-driven single-threaded simulation.TPCS is presented as broader in hardware generality and faster in simulation.Source: §II · p. 3

III. TRANSACTION-PRUNED CYCLE SIMULATION

TPCS represents hardware through module states, transactions, and behavioral procedures, then executes cycles with native host-language control flow and generates structurally corresponding RTL.

A. Overview of TPCS

  • A TPCS module combines cycle-boundary states, request/service transactions with readiness conditions, and per-cycle C++ procedures into deterministic state transitions and interactions.State writes take effect in the next cycle, matching synchronous RTL non-blocking assignment semantics.Source: A. Overview of TPCS · p. 3
  • Each cycle executes module behaviors using host-language semantics: state APIs and transaction function calls statically resolve control flow, naturally pruning inactive code without schedulers or event queues.The text attributes the pruning to transaction conditions and branches, with only minimal branch-prediction cost and no additional activity tracking.Source: A. Overview of TPCS · p. 3
  • TPCS separates module hierarchy, state, and transactions from behavioral procedures, mapping the former to an RTL skeleton and translating the latter into combinational logic.The dedicated compiler generates synthesizable RTL while preserving state-transition and interaction semantics.Source: A. Overview of TPCS · p. 3

B. TPCS Modeling Semantics with RTL Correspondence

TPCS models hardware with modules, transaction ports, and logic blocks, mapping its structure and behavior to RTL and C++ representations. Its semantics define cycle-boundary state, inter-module interactions, and deterministic combinational behavior.

1) Module-Centric Abstraction:

  • TPCS models modules and instances hierarchically, with parameters as local constants and structural correspondence to RTL modules and C++ template classes.Persistent state carries values across cycles and updates through deferred assignment; ephemeral state holds intra-cycle values and is cleared each cycle.Source: 1) Module-Centric Abstraction · p. 4
  • Persistent-state writes take effect next cycle, with the highest-priority write resolving conflicts and reads observing the current-cycle value.This corresponds to synchronous RTL non-blocking assignment with priority arbitration.Source: 1) Module-Centric Abstraction · p. 4

2) Transaction System:

  • A transaction is a single-cycle control and data interaction between modules; handshaked invocations take effect only when the callee is ready.Non-handshaked transactions are accepted once invoked; request and service ports initiate and respond to interactions, respectively.Source: 2) Transaction System · p. 4

3) Logic Blocks:

  • Logic blocks express intra-module combinational behavior as C++ functions triggered by service invocation or once-per-cycle tick.Blocks must terminate deterministically, resolve conflicting state updates, and invoke each transaction at most once per cycle; the scope excludes asynchronous logic, analog behavior, X/Z states, and unrestricted cross-clock interactions.Source: 3) Logic Blocks · pp. 4–5
  • Built-in components support common patterns, including configurable pipes, multi-port BRAM, and recursive stall propagation.A five-stage CPU example connects modularized stages with pipes, uses BRAM in the cache, and propagates stalls across Decode, Execute, and Memory.Source: 3) Logic Blocks · p. 5

4) Debugging and Extensions:

TPCS provides tracing and scalable arrayed instances, while native execution uses statically ordered calls to run transactions and avoid runtime scheduling. Generated wrappers bind transaction connections, with optional optimizations for frequently invoked child instances.

4) Debugging and Extensions:

  • Transaction and register tracing links transaction-level activity to signal-level waveforms, while statically sized arrays support indexed point-to-point and dimension-based bulk connections.Traces record transaction invocations, arguments, responses, and return status; register updates are captured after deferred assignments commit.Source: 4) Debugging and Extensions · p. 5

C. TPCS Native Execution Semantics

  • Fixed execution ordering lets native control flow invoke transactions through C++ calls without runtime dependency resolution or activity detection.Without devirtualization, indirect calls can limit inlining; optional wrapper duplication trades code size for execution efficiency.Source: C. TPCS Native Execution Semantics · p. 5

1) Transaction Calls and Connections:

  • Generated static wrapper functions bind request-side function pointers and dispatch calls to connected child services or bound logic blocks.Optional aggregation inlines arrayed child modules into their parent for direct sibling calls, preserving functional equivalence while trading code size for speed.Source: 1) Transaction Calls and Connections · p. 5

2) Dual-Stage Cycle-Driven Simulation:

TPCS executes each cycle in two stages: module ticks and dependent requests evaluate behavior, then deferred assignments update state for the next cycle. Hierarchical ordering preserves declared dependencies during execution.

2) Dual-Stage Cycle-Driven Simulation:

  • Each cycle executes module ticks and dependent combinational requests, then commits deferred assignments for the next cycle.The execute call structure follows host control flow and captures hardware control semantics.Source: 2) Dual-Stage Cycle-Driven Simulation · p. 6
  • Execution traverses the module hierarchy in constructed priority order, while commit is order-independent because state elements update individually.The top instance’s exec function starts the execute stage and invokes its tick and children’s exec functions.Source: 2) Dual-Stage Cycle-Driven Simulation · p. 6
  • Projecting dependencies to the lowest common ancestor preserves declared ordering across recursively composed local topological orders; dependencies within one Tick are conservatively rejected.Ordering construction assumes resolved, nonrecursive calls without repeated block invocation; unresolved calls, conflicting ownership, or cycles cause a design fatal.Source: 2) Dual-Stage Cycle-Driven Simulation · p. 6

3) Parallel Execution:

TPCS uses static component-level parallelism with deterministic synchronization, then translates its model into synthesizable RTL through a module decomposition and a dedicated combinational-logic compiler.

3) Parallel Execution:

  • Parallel execution assigns order-free instances to fixed threads with exclusive state ownership, while cross-thread side effects are restricted to pipes or read-only services.Pipe updates use thread-local buffers and deterministic commits separated by barriers, making transferred data visible in the following cycle.Source: 3) Parallel Execution · p. 6

D. Synthesizable RTL Generation from TPCS

  • TPCS separates RTL structure from logic: module hierarchy, state elements, and transaction ports form the RTL skeleton, while logic blocks and invocations are compiled into combinational logic.This preserves structural correspondence and execution semantics between the model and generated RTL.Source: D. Synthesizable RTL Generation from… · p. 6

1) RTL Generation Workflow:

  • Each module is decomposed into Register, Logic, and RTL-skeleton components, with only the Logic sub-module produced by the dedicated compiler.The decomposition separates sequential and combinational logic in line with TPCS dual-stage execution.Source: 1) RTL Generation Workflow · pp. 6–7

2) Dedicated Compiler for Combinational Logic Generation:

  • The compiler supports fixed-width and Boolean operations, aggregates, conditionals, unrollable loops, and static calls, but excludes dynamic allocation and runtime dispatch.Its six stages normalize and lower code through SSA construction and predication before optimized RTL emission, preserving evaluation order and width semantics without adding state.Source: 2) Dedicated Compiler for… · p. 7
  • Predication converts control flow into value selection, and SSA merges and guarded writes lower to mux-based logic while preserving valid uses and complete output coverage.For valid inputs, settled RTL outputs are equivalent to one C++ execution.Source: 2) Dedicated Compiler for… · p. 7

3) Predicate Sinking Optimization:

Demand-guided predicate sinking targets serial predicate chains created by nested control flow, simplifying guards when downstream uses already impose the needed condition.

3) Predicate Sinking Optimization:

  • Nested control flow can create serial predicate chains that increase control dependence and combinational depth, motivating demand-guided predicate sinking before the CIRCT backend.The optimization aims to recover a structure closer to handwritten combinational logic, where predicates are applied near observable boundaries.Source: 3) Predicate Sinking Optimization · p. 7
  • For each candidate mux, the compiler traces consumers to collect gating predicates and rejects candidates whose paths reach observable boundaries without gating.Condition uses and uses through both data arms are also treated as ungated.Source: 3) Predicate Sinking Optimization · pp. 7–8
  • A predicate-cone node that is constant whenever a value is demanded can be replaced by True or False in a cloned guard cone, followed by Boolean simplification.The original cone remains available for shared uses.Source: 3) Predicate Sinking Optimization · p. 8
  • One pass is bounded by O(V + E + M[(V + E) + KRCproof + Cclone]); candidates without a proof within the budget remain unchanged.AIG normalization and simplification reduce predicate-proof cost before sinking.Source: 3) Predicate Sinking Optimization · p. 8
  • If downstream uses already imply a temporary’s guard, predicate sinking removes the redundant condition and shortens the predicate chain without changing observable output.The example specializes a guard a∧b to b when every downstream use implies a.Source: 3) Predicate Sinking Optimization · p. 8

IV. EXPERIMENT AND VALIDATION

The evaluation combines four experiments to examine correctness, system-level simulation performance, HDL comparisons, and applicability to accelerator designs.

Cross-abstraction correctness

  • Cross-abstraction correctness compares waveforms and workload results between direct execution and generated RTL to check evaluated cycle behavior.The comparison is intended to verify that simulation gains preserve the tested behavior.Source: §IV · p. 8

System-level performance

  • System-level experiments measure SMP simulation speed, parallel scalability, and overheads on large-scale systems.Source: §IV · p. 8

Direct HDL comparison

  • Direct HDL comparisons hold the microarchitecture constant to compare simulation speed and RTL quality across workflows, with ablation assessing compiler optimization.Source: §IV · p. 8

Hardware applicability

  • Hardware-applicability experiments evaluate AES and systolic-array designs under different input activity and transaction granularity.These tests extend beyond CPU pipelines.Source: §IV · p. 8

A. Experiment Setup

The setup evaluates TPCS and Verilator on CPU and accelerator designs with matched workloads and inputs, while assessing generated RTL after routing.

1) Platforms and Toolchain:

  • Experiments use an Intel i9-14900K PC with 128 GB DDR5 on Ubuntu 22.04, Verilator 5.036, g++ 11.4 with C++20 and -O3, and LLVM/clang 18.0 for the TPCS frontend.Source: 1) Platforms and Toolchain · p. 8

2) Target Hardware Design:

  • Targets include a 5-stage in-order RISC-V SMP with predictors and a 32KB 4-way L1 cache, plus AES1/AES2 and 8x8/16x16 systolic-array designs.The RISC-V system runs preloaded workloads; accelerators use a shared test harness with transaction or signal interfaces.Source: 2) Target Hardware Design · p. 9

3) Workloads:

  • RISC-V workloads are CoreMark and RISC-V bmarks; accelerator tests use full input streams or bursts that pause after every 10 batches.Implementations receive identical input patterns.Source: 3) Workloads · p. 9

4) Simulation Configuration:

  • Correctness checks trace pipeline valid signals and PCs or accelerator top-level ports, while speed is measured in simulated cycles per second with waveform dumping disabled.Comparisons use identical workloads, inputs, and initial states; SMP timing uses checkpointed benchmark phases.Source: 4) Simulation Configuration · p. 9

5) RTL Backend Flow:

  • RTL quality is evaluated after routing with OpenROAD and ASAP7, using identical clock constraints per target and reporting the minimum achievable period.Only the isolated RISC-V pipeline is synthesized to avoid memory-dominated effects; Fig. 10 identifies simulated cycle counts for workloads on target RISC-V systems, with 4C meaning four workload copies on a four-core SMP.Source: 5) RTL Backend Flow · p. 9, Figure 10 · p. 9

B. Validation on Cross-Abstraction-Level Correctness

TPCS matches RTL simulation at the observed register and workload levels, then reports faster simulation on the RISC-V SMP target. Its parallel overhead grows as synchronization and commit costs rise relative to execution.

B. Validation on Cross-Abstraction-Level Correctness

  • All observed module-interface signals and selected registers match cycle by cycle between direct TPCS execution and Verilator simulation of generated RTL.The comparison covers CPU, AES, and systolic-array traces; workload cycle counts also match on single-core and four-core SMP systems.Source: B. Validation on… · p. 9

C. Validation on System-Level Simulation Performance

  • On the control-flow-dominated CPU target, TPCS achieves a 36×-42× speedup over the RTL simulation baseline; peak parallel performance occurs at 2 threads for 4-core and 3 threads for 8-core configurations.Source: C. Validation on System-Level… · p. 10
  • With more threads, commit costs rise as inter-thread pipes reduce data locality, while synchronization takes a larger share when per-cycle computation does not substantially exceed synchronization cost.The overhead breakdown distinguishes logic evaluation, transaction wrapper handling, commit, and half-cycle synchronization.Source: Figure 12 · p. 10, C. Validation on System-Level… · p. 10
  • CPU pipeline stalls and instructions activating only subsets of functional units create opportunities for TPCS to prune inactive logic, unlike more regularly utilized dataflow designs.The paper identifies this contrast as a reason for smaller speedups on dataflow-oriented ASICs.Source: C. Validation on System-Level… · p. 10

D. Direct Comparison with Existing Synthesizable HDLs

On the shared CoreMark pipeline, TPCS outpaces the compared synthesizable HDL simulation flows. Its generated RTL also has competitive timing and area, with predicate sinking contributing to timing quality.

1) On Simulation Speed:

2) On Generated RTL Quality:

  • TPCS achieves the shortest clock periods for the full pipeline and MDU, improving on handcrafted SV by 3.09% and 4.74%, with area changes of −3.31% and +1.68%, respectively.FPU timing and area overheads are 2.58% and 3.77%; relative to Chisel, TPCS has shorter clock periods but slightly larger MDU and FPU areas.Source: Table V · p. 11, 2) On Generated RTL Quality · p. 11
  • Without predicate sinking, the full-pipeline minimum clock period is 32.7% above the handcrafted reference; predicate sinking with subexpression simplification instead yields a 3.09% reduction.The ablation attributes degraded timing to serial Boolean dependencies from nested predicates; it isolates predicate sinking's timing benefit within TPCS.Source: 2) On Generated RTL Quality · p. 11

E. Validation on Dataflow-Oriented Accelerators

On accelerators, TPCS is faster than Verilator across Full and Burst input modes, while aggregation reduces transaction-wrapper overhead. Generated accelerator RTL remains close to handcrafted references; the paper also identifies tooling, coverage, and compiler limitations.

E. Validation on Dataflow-Oriented Accelerators

  • TPCS achieves 3.4×–4.4× speedups in Full mode and 4.6×–7.2× in Burst mode over Verilator simulation of generated RTL on AES and systolic-array accelerators.Continuous inputs limit pruning opportunities in regular datapaths, whereas input gaps increase the benefit of skipping inactive logic.Source: E. Validation on Dataflow-Oriented… · p. 11
  • Without array aggregation, frequent calls across small systolic-array instances add wrapper overhead; aggregation largely removes it, leaving logic evaluation and register commitment as dominant costs.The comparison is described in Fig. 14.Source: E. Validation on Dataflow-Oriented… · p. 11
  • Under the same OpenROAD/ASAP7 flow, TPCS-generated RTL timing is within approximately 2% of handcrafted references, with standard-cell area overheads of approximately 0%–4%.Together with the CPU results, these measurements cover control-oriented pipelines and dataflow-oriented accelerators.Source: E. Validation on Dataflow-Oriented… · p. 11, Figure 15 · p. 12

V. Discussion and Limitations

  • Usability depends on more mature modeling diagnostics, debugging support, and reusable libraries; reliable AI-assisted development also requires dedicated validation and debugging infrastructure.The paper describes these infrastructure needs as a limitation for large-scale development.Source: §V · p. 12
  • Coverage remains to be extended beyond evaluated cycle-synchronous designs, including standardized CDC components, explicitly defined asynchronous primitives, and gated clocks.Faithful physical metastability capture is described as impractical at this abstraction level; configurable-delay models may support equivalence analysis under explicit timing assumptions.Source: §V · p. 12
  • The compiler emphasizes combinational timing optimization and has limited support for automatic pipelining and systematic area–timing exploration.The paper identifies latency-aware pipelining and closer gate-level and physical-design integration as future extensions.Source: §V · p. 12

VI. Conclusion

  • TPCS supports fast pre-RTL exploration with cycle-level agreement on evaluated workloads and competitive RTL quality, while its speed gains depend on input activity, transaction granularity, and parallel synchronization costs.The conclusion reports up to 42× speedup over parallel Verilator on SMP systems and 3.4×–7.2× on accelerators.Source: §VI · p. 12, §V · p. 12
Loading 2610.13067v1…