CrosSym: Cross-Level SystemC Peripheral Verification

• CrosSym is a symbolic-execution framework designed for cross-level verification of SystemC peripherals, featuring a modified kernel and unmodified KLEE.
• It supports standalone TLM and RTL verification as well as cross-level equivalence checking by reusing testbenches compiled to LLVM IR.
• Evaluation demonstrates effective bug detection in peripherals like the PLIC and GCD, with runtime and memory performance competitive with alternative approaches.

Searching arXiv for “CrosSym” to verify the relevant paper and context. CrosSym is a symbolic-execution-based framework for the cross-level verification of SystemC peripherals. It is presented as one of two “opposing approaches” for versatile symbolic execution of peripherals, alongside SEFOS, in “Comparing Methods for the Cross-Level Verification of SystemC Peripherals with Symbolic Execution” (Rudkowski et al., 5 Sep 2025). In this framework, the SystemC kernel is modified or replaced, while the symbolic execution engine KLEE is used unmodified. CrosSym is designed to support standalone Transaction-Level Modeling (TLM) peripheral verification, standalone RTL-style SystemC peripheral verification, and cross-level equivalence checking between TLM and RTL implementations of the same peripheral (Rudkowski et al., 5 Sep 2025).

1. Problem setting and motivation

Virtual Prototypes are executable hardware models, typically built in C++ with SystemC and its TLM extension. A VP of a system-on-chip usually contains one or more processors, interconnects or buses, and peripherals. Such VPs are used for early software development, continuous verification across design refinements, and cross-level verification between higher-level and lower-level models (Rudkowski et al., 5 Sep 2025).

The specific focus of CrosSym is on peripherals rather than processors. The paper emphasizes that peripherals are diverse, with complex communication interfaces and environment interactions, and that processor-oriented techniques do not transfer easily to them (Rudkowski et al., 5 Sep 2025). The intended cross-level use case is to verify a TLM peripheral model against its RTL or RTL-style SystemC counterpart, reuse the same testbench across levels, and employ modern symbolic execution engines from the software domain, such as KLEE (Rudkowski et al., 5 Sep 2025).

The original SystemC kernel creates several obstacles for off-the-shelf symbolic execution. The paper identifies three principal issues: SC_THREAD processes are implemented via OS threads; the signal–port mechanism uses mutexes; and the SystemC kernel contains large and complex C++ objects whose symbolic treatment becomes expensive for SMT solving (Rudkowski et al., 5 Sep 2025). Existing approaches either target restricted subsets of SystemC, especially TLM-only subsets, or do not support cross-level scenarios for peripherals (Rudkowski et al., 5 Sep 2025).

This suggests that CrosSym is motivated by a gap in symbolic verification technology: the absence of a comprehensive cross-level symbolic execution workflow for SystemC peripherals that spans both TLM and RTL abstractions.

2. Design philosophy and system architecture

CrosSym implements what the paper calls “Approach I”: the SystemC kernel is modified or replaced, and the design-under-verification may be slightly rewritten, while KLEE is left unchanged (Rudkowski et al., 5 Sep 2025). Conceptually, CrosSym is described as a replacement SystemC kernel and associated tooling that re-implements key TLM and RTL features in a way that is friendly to classical symbolic execution (Rudkowski et al., 5 Sep 2025).

Its architecture consists of SystemC peripheral models, the CrosSym replacement kernel, a C++/SystemC testbench, compilation to LLVM IR, and symbolic execution with KLEE (Rudkowski et al., 5 Sep 2025). The workflow supports three scenario types: standalone TLM verification, standalone RTL verification, and cross-level TLM↔RTL equivalence checking (Rudkowski et al., 5 Sep 2025).

The central design choice is to remove multi-threading and mutexes from the kernel design rather than extend KLEE with thread-aware semantics. CrosSym therefore implements scheduling, events, time, signals, ports, and clocks inside a single-threaded environment (Rudkowski et al., 5 Sep 2025). The result is that KLEE sees a single-threaded LLVM program rather than a SystemC program mediated by OS threads and synchronization primitives (Rudkowski et al., 5 Sep 2025).

The framework’s stated design goals are cross-level verification, explicit support for the SystemC features relevant to peripherals, performance competitive with the TLM-only state of the art, and integration into VP-based flows through LLVM IR (Rudkowski et al., 5 Sep 2025).

3. Kernel replacement and supported SystemC semantics

CrosSym effectively replaces the SystemC kernel with a custom implementation that exposes the same API used by the device-under-verification code, including SC_METHOD and SC_THREAD macros, event APIs, and wait() (Rudkowski et al., 5 Sep 2025). This replacement extends earlier TLM-focused approaches by supporting RTL-style constructs that were previously unavailable in tools such as SymSysC (Rudkowski et al., 5 Sep 2025).

For process handling, SC_METHOD processes are represented as ordinary C++ functions that run to completion when scheduled. SC_THREAD processes are transformed into single-threaded control flow with explicit state encoding through labels and gotos, following the thread translation strategy also used in SymSysC (Rudkowski et al., 5 Sep 2025). This transformation is required for TLM models that rely on SC_THREAD (Rudkowski et al., 5 Sep 2025).

CrosSym implements event-driven scheduling using sensitivity lists established during elaboration. Processes register sensitivity with constructs such as sensitive << clk.pos(); or sensitive << signal;, and events, signals, and ports maintain lists of waiting or sensitive processes (Rudkowski et al., 5 Sep 2025). When an event is notified or a signal or port changes, the corresponding processes are added to the ready queue (Rudkowski et al., 5 Sep 2025).

Time and delta-cycle semantics are modeled through an evaluate–update–delta scheduler. The evaluate phase runs processes triggered in the current time step, the update phase commits pending signal value changes, and zero-time delta cycles repeat until no more pending updates remain; only then does time advance (Rudkowski et al., 5 Sep 2025). Signals maintain both current and pending values, writes schedule a value change rather than immediately modifying the current state, and reads return the committed value (Rudkowski et al., 5 Sep 2025). Ports delegate to bound signals, and clocks are realized as signals toggling periodically according to a duty cycle (Rudkowski et al., 5 Sep 2025).

The paper contrasts CrosSym with SymSysC and SEFOS along feature lines. SymSysC is restricted to TLM and has limited event semantics; CrosSym adds correct events with multiple waiting processes, proper timed notify(time) semantics, SC_METHODs, static sensitivity, signals, ports, clocks, and delta cycles; SEFOS uses the original SystemC kernel and therefore preserves a broader feature set without DUV modification (Rudkowski et al., 5 Sep 2025).

4. Verification scenarios and target bug classes

CrosSym supports three verification scenarios. In standalone TLM verification, the TLM model is checked against a reference algorithm in the testbench. In standalone RTL verification, the RTL-style SystemC model is checked against the same or an equivalent reference. In the cross-level equivalence scenario, TLM and RTL models are instantiated together, driven by the same symbolic inputs, and compared on outputs and internal register states (Rudkowski et al., 5 Sep 2025).

The framework is intended to detect functional correctness bugs in core algorithms, bugs in control logic, protocol and interface errors on RTL and TLM bus interfaces, and mismatches between abstraction levels (Rudkowski et al., 5 Sep 2025). It also inherits generic symbolic execution error detection from KLEE, including assertion violations, divide-by-zero, overshift, invalid memory access, and path-reachability corner cases (Rudkowski et al., 5 Sep 2025).

Properties are expressed directly as C++ assertions in the testbench. These may state that a GCD result equals a reference algorithm result, that a hash result matches a reference hash function, that a mapping peripheral produces the correct outputs, or that TLM and RTL states agree after the same sequence of operations (Rudkowski et al., 5 Sep 2025). The paper also discusses protocol-level properties involving symbolic MMIO address, length, and data fields, including validation of register updates and error signaling for invalid addresses or lengths (Rudkowski et al., 5 Sep 2025).

This suggests that CrosSym is not a property language or theorem-proving environment; it is a symbolic exploration framework whose specification interface is ordinary testbench code augmented with symbolic inputs and assertions.

5. Evaluation on SystemC peripherals

The evaluation applies CrosSym and SEFOS to four peripherals available at TLM and RTL levels: a Platform Level Interrupt Controller (PLIC), a GCD peripheral, a hash peripheral, and a map peripheral (Rudkowski et al., 5 Sep 2025). The experiments use STP as SMT solver, a 24-hour global timeout per run, a 4 GiB memory limit, a 120-second per-query timeout, and BFS search in KLEE (Rudkowski et al., 5 Sep 2025).

The PLIC case study is based on the SiFive FE310 specification and includes tests of basic interrupt firing, threshold behavior, priority ordering, and cross-level equivalence for priority-threshold logic (Rudkowski et al., 5 Sep 2025). CrosSym detects, in the RTL PLIC, a wrong comparison of priority versus threshold, where <= was used instead of >; the paper labels this as bug E1 (Rudkowski et al., 5 Sep 2025). In cross-level tests it also detects a mismatch in the treatment of priorities above the allowed maximum, labeled E2 (Rudkowski et al., 5 Sep 2025).

For the GCD peripheral, the paper reports a wrong unsigned-to-signed conversion in the TLM model, discovered by both standalone TLM and cross-level tests and labeled E3 (Rudkowski et al., 5 Sep 2025). The hash and map peripherals are used for both functionality and performance studies; the map peripheral in particular is used heavily in mutation testing (Rudkowski et al., 5 Sep 2025).

Bus-interface verification is treated separately. Symbolic address, length, and data are passed through TLM and RTL bus interfaces, and the tests check correct register updates and correct handling of invalid accesses. CrosSym is reported to efficiently explore this bus logic, with typical runtime under approximately ten minutes, while detecting interface errors such as unmapped addresses, out-of-bound behavior, illegal modes, or incorrect interrupt-flag updates (Rudkowski et al., 5 Sep 2025).

The mutation-testing campaign uses over 300 mutants generated by systematically mutating operators in DUV code. CrosSym detects a high proportion of mutants, often 70–100% for map and lower percentages for hash, GCD, and PLIC, depending on the test class and abstraction level (Rudkowski et al., 5 Sep 2025). The paper attributes surviving mutants to path explosion, complex symbolic expressions, and cross-level overhead (Rudkowski et al., 5 Sep 2025).

6. Comparative position: SEFOS, SymSysC, and prior work

The paper frames CrosSym and SEFOS as two opposing approaches to the same problem. CrosSym modifies the SystemC kernel and may require SC_THREAD translation in the DUV, while SEFOS keeps the original SystemC kernel and peripheral code unchanged but modifies KLEE to understand SystemC threading and to perform array minimisation (Rudkowski et al., 5 Sep 2025). In this comparison, SEFOS is described as advantageous in preserving the unmodified SystemC kernel and peripheral, while CrosSym offers slightly better runtime and memory usage (Rudkowski et al., 5 Sep 2025).

The most direct prior comparison is with SymSysC. SymSysC is the closest earlier SystemC symbolic execution approach, but it is restricted to TLM, lacks RTL features such as signals, ports, clocks, and delta cycles, and has limited event support (Rudkowski et al., 5 Sep 2025). CrosSym extends SymSysC by adding both RTL support and cross-level verification capability (Rudkowski et al., 5 Sep 2025). In the PLIC TLM case study reused from SymSysC, CrosSym shows runtime overhead below 10% and memory overhead below 30% relative to SymSysC while providing the broader feature set (Rudkowski et al., 5 Sep 2025).

The paper also contrasts CrosSym with RTL-only symbolic execution approaches based on Verilog-to-C++ translation, with model-checking and symbolic-simulation approaches for SystemC, and with SESC, which supports only a severely restricted subset of SystemC (Rudkowski et al., 5 Sep 2025). Within that landscape, CrosSym is positioned as the first comprehensive cross-level symbolic execution framework for SystemC peripherals covering both TLM and RTL and their equivalence (Rudkowski et al., 5 Sep 2025).

A plausible implication is that the paper’s notion of “cross-level” is not merely comparative testing across abstraction boundaries; it is treated as a first-class verification scenario whose feasibility depends on implementing both abstraction levels within a unified symbolic execution environment.

7. Workflow, practical constraints, and limitations

Applying CrosSym to a new peripheral involves preparing TLM and/or RTL SystemC models, translating SC_THREAD-based TLM models into single-function control flow using labels and gotos, linking against the CrosSym kernel rather than the original IEEE 1666 library, writing a symbolic testbench with KLEE interfaces such as klee_int, compiling the full setup to LLVM bitcode, and executing it with KLEE and STP (Rudkowski et al., 5 Sep 2025).

The paper recommends separating communication testing from functionality testing. Symbolic writes via RTL signals or TLM sockets can create path explosion because signal writes compare old and new values; accordingly, bus-interface tests should focus on symbolic addresses, lengths, and data with assertions on post-transaction state, while core functionality tests should often bypass bus logic and directly write symbolic values into registers (Rudkowski et al., 5 Sep 2025).

CrosSym is explicitly limited to a selected subset of SystemC features needed for peripheral verification. It supports the core TLM and RTL features summarized in the paper’s feature comparison, but does not support asynchronous waiting or multi-simulator communication (Rudkowski et al., 5 Sep 2025). The framework is optimized for single-peripheral verification and is not presented as a full SoC symbolic exploration environment (Rudkowski et al., 5 Sep 2025).

The paper also notes several general limitations: state-space explosion in control-heavy peripherals such as PLIC and GCD, long solver times caused by complex symbolic expressions such as hash computations, and the absence of a proof that the replacement kernel is formally equivalent to the original SystemC kernel (Rudkowski et al., 5 Sep 2025). Future work directions include improved search heuristics beyond BFS, expanded feature support, mitigation of state-space explosion through abstraction or reduction techniques, and combination with fuzzing or concolic testing (Rudkowski et al., 5 Sep 2025).

7. Summary

CrosSym is a replacement-kernel approach to symbolic execution for SystemC peripheral verification, designed to make both TLM and RTL models amenable to unmodified KLEE while enabling cross-level equivalence checking (Rudkowski et al., 5 Sep 2025). Its technical core is a lightweight single-threaded reimplementation of SystemC scheduling and synchronization semantics, including events, waits, signals, ports, clocks, and delta cycles, together with SC_THREAD translation for TLM code (Rudkowski et al., 5 Sep 2025).

Within the evaluation reported in (Rudkowski et al., 5 Sep 2025), CrosSym detects functional and interface bugs in realistic peripherals, supports standalone and cross-level scenarios, and achieves performance comparable to the TLM-only state of the art while extending coverage to RTL and TLM↔RTL verification (Rudkowski et al., 5 Sep 2025). Its principal trade-off is that it requires a verification-specific SystemC kernel and a restricted SystemC feature subset, in exchange for compatibility with an unmodified symbolic execution engine and slightly better runtime and memory usage than the alternative engine-modification approach SEFOS (Rudkowski et al., 5 Sep 2025).