The architecture describes what implementations must do and constrains what they may do — and where it intentionally declines to constrain them, it says so out loud with one reserved word: UNSPECIFIED UNSPECIFIED A behavior or value the architecture intentionally leaves unconstrained; extensions, platform standards, or implementations may constrain it further. defined in ch. I·1 — open in glossary .
An UNSPECIFIED behavior or value is intentionally unconstrained. Its definition is left open to three parties, any of which may narrow it later:
- Extensions — a future (or optional) extension may give the behavior a normative definition; that’s different from reserved encoding space, which is being held for future standard instructions.
- Platform standards — a platform spec (server platform, embedded platform, the de-facto “what mainline Linux expects” contract) may pin down choices the base architecture leaves open.
- Implementations — you, the hardware designer, may simply pick a behavior and document it.
The same discipline is expected of extensions themselves: fully describe allowable behavior, and mark the deliberate gaps UNSPECIFIED rather than leaving them silent.
This page closes the Introduction. From here, Chapter 2 opens the actual instruction set with RV32I — where every architectural statement starts turning into datapath.
Hardware Designer Notes
Treat UNSPECIFIED as a verification contract, not just a spec curiosity. Lock-step comparison against a reference model (Spike, QEMU) must mask UNSPECIFIED values — the models may legally disagree with your RTL. Keep a living table of every UNSPECIFIED decision your core makes; Volume II multiplies these (WARL fields are the CSR-flavored cousin — ch. II·2).
Minimal Linux-boot hart MUST
- Pick one concrete behavior for every UNSPECIFIED case your design can reach, and write it down (your DV team and your successors need the list)
MAY simplify / trap-and-emulate
- Choose whatever is cheapest — UNSPECIFIED is explicit permission; no future spec revision will retroactively make a documented choice non-conformant on this spec version
Check yourself — UNSPECIFIED
1.The spec says a behavior is UNSPECIFIED. What does that mean for your RTL?
2.Why does the distinction matter for verification of a Linux-bootable core?