Skip to content
STIMSMITH

Co-Simulation Testbench

Concept WIKI v1 · 5/25/2026

A co-simulation testbench for cross-level processor verification coordinates an RTL core and an instruction-set simulator (ISS) under a shared, on-the-fly instruction stream. In the cited design, the testbench is implemented in SystemC, uses Transaction Level Modeling (TLM) for memory abstraction, includes a core adapter and test controller interaction, and relies on instruction-stream matching to keep RTL and ISS execution comparable despite pipeline prefetching, jumps, and traps.

Co-Simulation Testbench

A Co-Simulation Testbench is a verification setup that runs an RTL processor core together with an instruction-set simulator (ISS) and compares their behavior while feeding both from a generated instruction stream. In the cited cross-level processor-verification approach, the co-simulation testbench is used to feed an on-the-fly, endless instruction stream to both the ISS and the RTL core. [C1]

Implementation basis

The described testbench is implemented in SystemC and uses TLM (Transaction Level Modeling). TLM is used to provide a unified memory abstraction for the RTL core and the ISS, based on a common standard. [C2]

Communication in the environment may be implemented using signals for RTL models or abstracted through TLM transactions for higher-level algorithmic models. A TLM transaction object contains a command such as read or write, a data payload, and an address. [C3]

Architecture

The RTL core is driven by a clock signal and has separate interfaces for instruction memory and data memory. The memory interfaces translate between RTL core signals and TLM transactions. The ISS is also configured with two separate memory interfaces so that it matches the RTL-side organization. [C4]

The data memory is implemented lazily: it starts empty, stores data on writes, and on reads either returns existing data or generates new random data if the address has not been accessed before. The RTL and ISS data memories use the same random seed so they behave the same when the two sides perform the same data-memory access sequence in the same order. [C5]

Instruction fetching and matching

Instruction fetching is handled through the instruction-memory interface using the program counter (PC). When the RTL core fetches an instruction, the testbench generates a new instruction on the fly, even if the same PC has been fetched before. When the ISS fetches an instruction, it receives the corresponding instruction that was fetched by the RTL core. This correspondence is handled by an instruction stream placed between the instruction generator and the memory interfaces. [C6]

Instruction-stream matching is needed because an RTL pipeline may prefetch several instructions. Some prefetched instructions may not execute if a jump or trap occurs, causing the ISS to fetch a different sequence of PCs than the RTL core. Short jumps or traps can also cause the RTL core to issue a new fetch before the ISS has the opportunity to fetch the corresponding instruction. [C7]

The matching mechanism keeps a queue of pending instructions. If an ISS fetch matches an instruction pending from the RTL side, the instruction is returned; otherwise, the setup reports a mismatch between RTL core and ISS because the ISS attempted to fetch an instruction that was not delivered to the RTL core. [C8]

Core adapter and test controller

The testbench includes a Core Adapter to hide implementation details of the RTL core and expose a clean testing interface. The adapter observes internal signal changes, especially pipeline behavior, and notifies the Test Controller whenever the RTL core completes an instruction. It also preserves the correct order in cases involving illegal instructions. [C9]

The core adapter provides access to RTL register values so they can be compared against the ISS. [C10]

The design deliberately does not directly feed the completed instruction sequence from the core adapter into the ISS, because that would compromise the testing approach: it would rely on the RTL core’s instruction propagation being correct, even though the RTL core is the unit under test. [C11]

Instruction stream generator

The Instruction Stream Generator supports endless generation of unrestricted instructions. Its baseline algorithm fully randomizes generated instructions, forming the foundation of the testing process. The cited design also considers guided modifications to steer generation toward interesting cases. [C12]

One modification injects a random instruction opcode to create a valid instruction while keeping the instruction fields randomized. This is described as simple, generic, and effective, and it helps ensure that a large set of legal instructions is considered. [C13]

Role in verification

The overall goal of the co-simulation testbench is to support cross-level processor verification by comparing an RTL core and ISS under a shared instruction stream while accounting for pipeline effects, memory behavior, and instruction-fetch ordering. [C1] [C7] [C9]

LINKED ENTITIES

5 links
Instruction Stream Generator CONTAINS
SystemC IMPLEMENTED_IN
Transaction Level Modeling USES
Core Adapter CONTAINS
Test Controller CONTAINS

CITATIONS

13 sources
13 citations
[1] The co-simulation testbench feeds an on-the-fly endless instruction stream to both an ISS and an RTL core for cross-level processor verification.
[2] The co-simulation testbench is implemented in SystemC and uses TLM.
[3] TLM communication uses transaction objects that include a command, payload data, and an address.
[4] The RTL core has separate instruction and data memory interfaces, and the memory interfaces translate between RTL signals and TLM transactions; the ISS also uses two separate memory interfaces.
[5] The data memory is lazy and uses matching random seeds on RTL and ISS sides so both behave identically under the same data-memory access sequence.
[6] RTL instruction fetches generate new instructions on the fly, while ISS instruction fetches receive the corresponding RTL-fetched instruction through instruction-stream matching.
[7] Instruction-stream matching is necessary because RTL prefetching, jumps, and traps can cause fetched and executed instruction sequences to diverge between RTL and ISS.
[8] The instruction-stream matcher uses a pending-instruction queue and reports a mismatch if the ISS fetch does not match an instruction delivered to the RTL core.
[9] The core adapter hides RTL implementation details, observes pipeline-related signal changes, and notifies the test controller when the RTL core completes an instruction while preserving order for illegal instructions.
[10] The core adapter provides access to RTL register values for comparison with the ISS.
[11] The completed instruction sequence from the core adapter is not directly fed to the ISS because doing so would rely on correct instruction propagation in the RTL core under test.
[12] The instruction stream generator enables endless unrestricted instruction generation, with a baseline algorithm that fully randomizes generated instructions.
[13] One generator modification injects a random opcode to create a valid instruction while keeping instruction fields randomized, helping cover legal instructions.