Unordered Floating-Point Reductions

Concept

Unordered floating-point reductions are reduction operations in the RISC-V Vector Extension whose valid results can depend on the reduction algorithm and rounding behavior. In verification, this can make a simulator result differ from a device-under-test result even when the hardware is correct, so some flows use a reduction-specific reference model and then synchronize the simulator state.

First seen 5/27/2026

Last seen 5/28/2026

Evidence 1 chunks

Wiki v1

WIKI

Overview

Unordered floating-point reductions are discussed in the context of the RISC-V Vector Extension (RVV) as operations for which the RVV specification allows implementation-dependent behavior related to the reduction algorithm and rounding mode. Because floating-point addition is sensitive to operation ordering and rounding, a hardware implementation and a simulator can produce different results while still being considered correct under the allowed behavior described in the evidence.

Verification challenge

READ FULL ARTICLE →

NEIGHBORHOOD

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

explore full graph →

RELATIONSHIPS

3 connections

Functional Verification of a RISC-V Vector Accelerator ← uses 90% 1e

A custom reference model for unordered floating-point reductions was developed to handle Spike divergence.

spike ← uses 85% 1e

Spike's handling of unordered floating-point reductions required special workarounds.

RISC-V Vector extension (RVV) part of → 91% 1e

Unordered floating-point reductions are part of the RVV instruction set

LINKED ENTITIES

1 links

RISC-V Vector extension (RVV) PART_OF Extracted graph relationship

CITATIONS

3 sources

3 citations — click to collapse

[1] Unordered floating-point reductions can produce mismatches between Spike and a VPU because valid results may depend on the rounding mode and reduction algorithm allowed by the RVV specification. source

[2] A false-positive mismatch can leave an incorrect value in Spike vector registers, causing later instructions to diverge and produce additional mismatches. source

[3] The described verification flow used an independent C reference model for unordered reductions that implemented the same reduction algorithm as the DUT, compared the VPU result against it instead of Spike, and injected matching results back into Spike. source