Skip to content
STIMSMITH

Architectural Unit

Concept WIKI v1 · 5/29/2026

An Architectural Unit (AU) is a processor architecture component or domain that can be verified independently, such as privileged or unprivileged parts of a RISC-V processor. ProcessorFuzz uses AUs to group CSR-transition coverage events so fuzzing can target individual units before exercising the processor as a whole.

Definition

An Architectural Unit (AU) is a processor architecture domain that can be treated as a separately verifiable unit during processor verification. In the ProcessorFuzz context, AUs are used to organize control-and-status-register (CSR) transition coverage so that transitions belonging to different units can be explored independently.

Role in ProcessorFuzz

ProcessorFuzz allows designers to customize its CSR-transition coverage metric for verifying different AUs individually. It does this by grouping CSR transitions associated with AUs and treating each group as an independent event space. The stated purpose is to reduce the state space while improving exploration of CSR transitions within each group.

This grouping enables the fuzzer to generate tests targeted toward individual AUs, allowing verification engineers to check units as an initial verification step. The paper gives privileged and unprivileged architectures in a RISC-V processor as examples of units that can be verified separately by grouping transitions. The authors note that identifying and fixing bugs in each AU before fuzzing the whole processor can reduce overall verification effort.

Relationship to CSR-transition coverage

ProcessorFuzz monitors selected CSRs and records transitions caused by instruction execution. For AU-level verification, these transitions can be grouped by architectural unit. The same evidence describes a transition map entry as a tuple (Im, S0, S1), where Im is the instruction mnemonic and S0 and S1 are CSR values before and after the transition. AU grouping is applied to these CSR-transition events to make coverage more suitable for targeted verification.

Examples

In the cited RISC-V example, ProcessorFuzz can group transitions to verify:

  • privileged architecture behavior; and
  • unprivileged architecture behavior.

These examples illustrate that an AU is not necessarily a physical hardware block in the cited usage; it is an architectural verification scope used to structure coverage and testing.

LINKED ENTITIES

1 links

CITATIONS

5 sources
5 citations
[1] ProcessorFuzz uses Architectural Units as individually verifiable processor architecture scopes for CSR-transition coverage. ProcessorFuzz: Processor Fuzzing with Control and
[2] ProcessorFuzz groups CSR transitions of AUs and treats the groups as independent events to reduce the state space and improve exploration within each group. ProcessorFuzz: Processor Fuzzing with Control and
[3] AU-level grouping lets ProcessorFuzz generate tests targeted at individual AUs and supports verifying units before fuzzing the processor as a whole. ProcessorFuzz: Processor Fuzzing with Control and
[4] Privileged and unprivileged architectures in a RISC-V processor are cited as examples of AUs that can be verified individually by grouping transitions. ProcessorFuzz: Processor Fuzzing with Control and
[5] ProcessorFuzz stores CSR transitions in a transition map as tuples containing the instruction mnemonic and the CSR values before and after the transition. ProcessorFuzz: Processor Fuzzing with Control and