---
title: 'CrosSym: Cross-Level SystemC Peripheral Verification'
url: https://www.emergentmind.com/topics/crossym
type: topic
---

# CrosSym: Cross-Level SystemC Peripheral Verification

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” [2509.05504]. 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 [2509.05504].

## 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 [2509.05504].

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 [2509.05504]. 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 [2509.05504].

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 [2509.05504]. Existing approaches either target restricted subsets of SystemC, especially TLM-only subsets, or do not support cross-level scenarios for peripherals [2509.05504].

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 [2509.05504]. 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 [2509.05504].

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

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 [2509.05504]. The result is that KLEE sees a single-threaded LLVM program rather than a SystemC program mediated by OS threads and synchronization primitives [2509.05504].

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 [2509.05504].

## 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()` [2509.05504]. This replacement extends earlier TLM-focused approaches by supporting RTL-style constructs that were previously unavailable in tools such as SymSysC [2509.05504].

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 `goto`s, following the thread translation strategy also used in SymSysC [2509.05504]. This transformation is required for TLM models that rely on SC_THREAD [2509.05504].

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 [2509.05504]. When an event is notified or a signal or port changes, the corresponding processes are added to the ready queue [2509.05504].

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 [2509.05504]. 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 [2509.05504]. Ports delegate to bound signals, and clocks are realized as signals toggling periodically according to a duty cycle [2509.05504].

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 [2509.05504].

## 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 [2509.05504].

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 [2509.05504]. 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 [2509.05504].

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 [2509.05504]. 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 [2509.05504].

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 [2509.05504]. 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 [2509.05504].

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 [2509.05504]. 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 [2509.05504]. In cross-level tests it also detects a mismatch in the treatment of priorities above the allowed maximum, labeled E2 [2509.05504].

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 [2509.05504]. The hash and map peripherals are used for both functionality and performance studies; the map peripheral in particular is used heavily in mutation testing [2509.05504].

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 [2509.05504].

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 [2509.05504]. The paper attributes surviving mutants to path explosion, complex symbolic expressions, and cross-level overhead [2509.05504].

## 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 [2509.05504]. 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 [2509.05504].

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 [2509.05504]. CrosSym extends SymSysC by adding both RTL support and cross-level verification capability [2509.05504]. 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 [2509.05504].

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 [2509.05504]. 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 [2509.05504].

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 `goto`s, 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 [2509.05504].

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 [2509.05504].

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 [2509.05504]. The framework is optimized for single-peripheral verification and is not presented as a full SoC symbolic exploration environment [2509.05504].

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 [2509.05504]. 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 [2509.05504].

## 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 [2509.05504]. 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 [2509.05504].

Within the evaluation reported in [2509.05504], 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 [2509.05504]. 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 [2509.05504].

Source: https://www.emergentmind.com/topics/crossym