Behavioral Semantics
Definition
In the context of hardware-accelerated processor co-simulation, behavioral semantics denotes the architectural behaviors that verification events convey, together with their mapping to specific microarchitectural components. Every event produced by the design under test (DUT) implicitly identifies a particular architectural action and the microarchitectural structure responsible for it.
Each verification event checks the architectural behavior of the corresponding instruction and locates errors to related micro-architectural components. Fusion (e.g., compressing N instruction commits into one N-commit event) loses the behavioral details of individual instructions, retaining only the overall behavioral results after compression, which makes it difficult to pinpoint error causes. Behavioral semantics is the property that makes it possible to recover those lost details without re-running the entire DUT.
Role in DiffTest-H
DiffTest-H is a semantic-aware, hardware-accelerated co-simulation framework built on top of the DiffTest co-simulation framework. DiffTest covers 32 types of verification events, and each cycle typically requires roughly 15 communications and 1.2 KB of transferred data. DiffTest-H identifies three key semantic properties that verification events carry — structural semantics, sequential semantics (also called order semantics), and behavioral semantics — and maps each property to a corresponding optimization:
| Semantic property | Optimization | Purpose |
|---|---|---|
| Structural semantics | Batch | Tightly pack structurally diverse events into a single transfer |
| Sequential / order semantics | Squash | Fuse events with a decoupled checking order |
| Behavioral semantics | Replay | Preserve instruction-level debuggability |
Prior optimizations (e.g., packing per-cycle events or fusing N same-type events such as N instruction commits into one N-commit event) reduce communication frequency and transmission volume, but fusing events across cycles discards per-instruction details and weakens instruction-level debuggability. By utilizing behavioral semantics, DiffTest-H can recheck only the verification events near the error location without re-simulating the entire DUT, providing instruction-level architectural behavior details and maintaining instruction-level error debugging capabilities.
How Behavioral Semantics Guides Debugging
Behavioral semantics guides debugging by localizing faults more precisely: each unfused verification event is tied to an architectural behavior and the microarchitectural component that produced it, so when a mismatch is detected, the relevant events point directly at the faulty instruction and the implicated component.
Instead of reverting to the full debug workflow of snapshotting the entire DUT and re-executing from the nearest checkpoint — a process that must be performed periodically because the root cause may precede the observed failure and that incurs substantial resource and time overhead — DiffTest-H reprocesses only the unfused verification events around the failure point. This restores instruction-level behavioral details and pinpoints the faulty instruction and the related microarchitectural component, enabling lightweight and effective debugging.
Realization via Replay
The Replay mechanism is the concrete implementation of behavioral semantics. It is a lightweight debugging mechanism that localizes bugs by reprocessing unfused events around the failure point, and it addresses two key challenges:
- Range determination — Optimizations and communication latency make it difficult to identify the range of unfused events that need to be replayed. Replay introduces a token-based management mechanism: tokens are assigned to buffered verification events before fusion, and are fused together during optimization. Upon detecting a mismatch, Replay uses these tokens to locate the exact range of events and notifies the hardware to retransmit only the necessary buffered events. The tokens also filter out irrelevant events that may arrive between the bug occurrence and the replay notification, ensuring consistent replay.
- Reference-model state recovery — Since mismatches may occur at any check, Replay must revert the reference model (REF) to the latest checkpoint before reprocessing events. Directly snapshotting the REF at each checkpoint would be prohibitively expensive, especially in memory usage. Instead, Replay adopts a compensation-based strategy: it records only the modifications between consecutive checkpoints (e.g., the original values of memory updates), and reverts by writing these logs back in reverse order to achieve lightweight state recovery.
The overall Replay workflow combines a hardware retransmission module and a software checking module. On the hardware side, verification events are buffered during fusion and retransmitted upon notification. On the software side, once a fused event mismatches, the REF reverts its state, requests retransmission, and reprocesses the unfused events for debugging. This token-driven, compensation-based design is what allows DiffTest-H to claim lightweight, instruction-level debugging rather than full-DUT re-execution.
Relationship to Other Semantic Properties
- Structural semantics concerns the data layout of events and is exploited by Batch to compute per-event offsets on hardware for tight packing while the software parses packed events by structure. The DiffTest framework covers 32 event types with length differences of up to 170x; existing fixed-space packaging yields over 60% invalid padding.
- Sequential (order) semantics concerns the check order of events and is exploited by Squash, which lets non-order-dependent events (NDEs) be transmitted ahead with sequence identifiers while other events continue to be compressed, after which the software reorders them by identifier.
- Behavioral semantics concerns the architectural meaning of events and the components they map to, and is exploited by Replay to keep per-instruction debuggability intact despite the lossy compression performed by Batch and Squash.
Together, the three properties form the semantic foundation of DiffTest-H's claim of significantly reducing communication overhead while preserving instruction-level debuggability. DiffTest-H achieves acceleration ratios of roughly 74–80x across different DUTs and hardware simulation platforms, reaches 7.8 MHz co-simulation speed on FPGA (a >7.8× improvement over prior SOTA), and has helped the Xiangshan processor identify and locate over 150 complex bugs in a six-month period.