instruction fetch matching algorithm

CodeArtifact

The instruction fetch matching algorithm is a co-simulation mechanism for feeding a consistent instruction stream to a pipelined RTL core and an instruction-set simulator (ISS). It handles RTL pre-fetching, jumps, traps, and on-the-fly instruction generation by keeping a fetch-order queue of pending instructions and matching ISS fetch requests against both program counter and expected instruction.

First seen 5/26/2026

Last seen 5/30/2026

Evidence 2 chunks

Wiki v1

WIKI

Overview

The instruction fetch matching algorithm addresses a co-simulation problem: an RTL core and an instruction-set simulator (ISS) must receive the same instruction stream, but a pipelined RTL core can pre-fetch instructions that the ISS has not yet requested. Because jumps and traps can invalidate or redirect pre-fetched instructions, direct program-counter-only matching is insufficient. [C1]

The algorithm keeps a queue of pending instructions fetched by the RTL core but not yet consumed by the ISS. Each queue entry stores both the instruction and its program counter (PC). When the ISS requests its next instruction, the algorithm searches the pending queue for an entry whose PC and instruction both match the ISS-side expectation. [C2]

READ FULL ARTICLE →

NEIGHBORHOOD

No graph connections found for this entity yet. It may appear in future ingestion runs.

explore full graph →

RELATIONSHIPS

2 connections

Instruction Fetch Matching implements → 100% 2e

The instruction fetch matching algorithm implements the instruction fetch matching concept to synchronize RTL core and ISS.

Efficient Cross-Level Testing for Processor Verification: A RISC-V Case-Study ← introduces 95% 2e

The paper introduces the instruction fetch matching algorithm to solve the synchronization challenge between RTL core and ISS.

CITATIONS

8 sources

8 citations — click to expand

[1] C1: RTL pre-fetching, jumps, and traps make it difficult to feed the same instruction sequence to RTL core and ISS, and PC-only matching is insufficient.

[2] C2: The algorithm stores RTL-fetched pending instructions with their PC in a fetch-order queue, searches the queue for a matching PC and expected instruction, returns the instruction on match, and reports mismatch otherwise.

[3] C3: The surrounding approach generates an endless unrestricted instruction stream, including memory accesses, jumps including self-loops, and special RISC-V CSR access instructions, while expecting identical observable architectural state between ISS and RTL core.

[4] C4: The implementation challenges are detecting completed RTL instructions and feeding the same instruction stream into the RTL core and ISS.

[5] C5: A one-instruction backward jump example shows why direct PC matching fails: the RTL core can pre-fetch from the target before the jump is fully completed and before the ISS has fetched and executed the jump.

[6] C6: Pipeline flushes, traps, stalled stages, multi-cycle operations, delays, and gaps must be considered when detecting completed instructions.

[7] C7: The core adapter observes internal pipeline signal changes, notifies the test controller when the RTL core completes an instruction, preserves order for illegal instructions, and provides RTL register values for ISS comparison.

[8] C8: On no match, a mismatch is reported because the ISS tried to fetch an instruction not delivered to the RTL core; the completed RTL instruction sequence is not directly fed to the ISS to avoid relying on the RTL core under test.