data forwarding path testing

Data forwarding path testing

Concept

Data forwarding path testing is a pipeline-verification technique that exercises forwarding-path combinations during hazard-oriented instruction-sequence generation. In the cited PATARA framework, it is used to validate pipeline hazard detection mechanisms by building dependent instruction sequences, optionally inserting non-interfering filler instructions, and explicitly testing forwarding on both source operands.

First seen 5/28/2026

Last seen 6/1/2026

Evidence 2 chunks

Wiki v1

WIKI

Overview

Data forwarding path testing is a verification technique for pipelined processors that checks whether forwarding-path combinations are exercised correctly during hazard-oriented execution. In the cited PATARA framework, it is presented as an extension for validating pipeline hazard detection mechanisms by making full use of the data forwarding paths, including both source operands.

Test-sequence construction

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

PATARA ← uses 90% 1e

PATARA extends pipeline hazard testing to cover data forwarding paths to both source operands.

Pipeline Hazard Generation ← uses 90% 1e

Pipeline hazard generation includes data forwarding path testing to verify all forwarding combinations.

LINKED ENTITIES

2 links

PATARA USES Extracted graph relationship

Pipeline Hazard Generation USES Extracted graph relationship

CITATIONS

5 sources

5 citations — click to expand

[1] In PATARA, data forwarding path testing is used as an extension to validate pipeline hazard detection mechanisms by checking full use of forwarding paths on both source operands. A Self-Testing Framework for Verification and Validation of a RISC-V-Based System with a Co-processor | International Journal of Parallel Programming | Springer Nature Link

[2] The needed instruction-sequence length depends on pipeline depth; the cited example says a 6-stage implementation needs 4 consecutive instructions for full coverage. A Self-Testing Framework for Verification and Validation of a RISC-V-Based System with a Co-processor | International Journal of Parallel Programming | Springer Nature Link

[3] PATARA generates these sequences using a regular interleaving approach in which the initial data is forwarded from one test instruction to the next one. A Self-Testing Framework for Verification and Validation of a RISC-V-Based System with a Co-processor | International Journal of Parallel Programming | Springer Nature Link

[4] Random filler instructions may be inserted as long as they do not interfere with the test sequence's data dependency, enabling coverage of additional hazard state switches. A Self-Testing Framework for Verification and Validation of a RISC-V-Based System with a Co-processor | International Journal of Parallel Programming | Springer Nature Link

[5] Regular test cases emphasize the first source operand, so PATARA swaps the focus and random values to test forwarding on the second source operand as well; the swap probability is configurable. A Self-Testing Framework for Verification and Validation of a RISC-V-Based System with a Co-processor | International Journal of Parallel Programming | Springer Nature Link