VERDICT: FAIL

ISSUES:

1. **RISC-V cryptography extension taxonomy is incorrect in several places.** The document states Zkb is the "scalar crypto bitmanip" namespace containing Zbkb, Zbkc, Zbkx. This is approximately correct, but the document then conflates things in the Open Questions: it lists "the cryptography sub-extensions under Zkn, Zks, and Zkb" as if Zkb is parallel to Zkn and Zks. In the RISC-V taxonomy, Zk is the *profile* = Zkn + Zks. Zkb is a *separate* scalar-crypto-bitmanip grouping. The document itself explains this correctly in the Background but then later uses the phrasing inconsistently (e.g., "Zkn, Zks, Zkb family") as if they are three parallel sub-groups, which muddles the hierarchy. The recommendation also refers to "Zkb family" — the actual sub-extensions under Zkb are Zbkb, Zbkc, Zbkx (just three), not a "family" in the same sense as Zkn/Zks.

2. **Vector extension categorization is inconsistent.** Background correctly states V is a "major unprivileged extension, not a single-letter general-purpose extension." But the Implementation Considerations section lists V alongside "M, A, C, F, D" as if it were comparable in scope for coverage purposes, and the Open Questions list conflates them. This is a minor terminology slip but appears in a key list.

3. **"Hypervisor (H) is a privileged extension" is correct, but coverage treatment conflates privilege.** The document repeatedly treats H as if it were an orthogonal extension to be added on top of an unprivileged base, but H requires a host/guest privilege-level framework (VS-mode, VU-mode) and fundamentally changes the MMU/virtual-memory coverage model. The coverage proposal (item for H) is too lightweight: it says H coverage is "paired with a separate virtual-memory coverage plan" but does not flag that the *base* coverage matrix must be restructured (two-stage translation, nested page walks, HS-mode CSRs) rather than merely extended.

4. **"Zihintpause" is misclassified as a "throughput-modulation hint, not a power-management extension per se but relevant to power-state verification."** Zihintpause is a pause hint, not specifically a power-state entry point, and its verification relevance is to pipeline back-pressure / power-virus characterization, not "power-state verification" in the retention/WFI sense. The categorization is misleading.

5. **The "Spike" attribution is partially incorrect.** Spike (riscv-isa-sim) is the Berkeley ISA simulator; it was originally developed at Berkeley and is now maintained within the RISC-V International software ecosystem with contributions from many parties including SiFive. The document's phrasing "Berkeley / RISC-V International, with significant SiFive contribution" is acceptable, but the Sources list says "Berkeley / RISC-V International (with SiFive contribution)" — fine. However, the document later (Existing Approaches, item 4) says "Spike (Berkeley / RISC-V International, with significant SiFive contribution)" — this is broadly defensible. No issue here, but flagging for cross-check.

6. **The recommendation's claim that formal proof of the ROB is "bounded" is presented as a PROPOSAL but is treated as a settled assumption in the bound selection.** The document says the bound is "project-owned" but recommends adding ROB to the formal scope. For an out-of-order core with renaming, the ROB plus rename map plus load-store queue plus memory-ordering logic is not a single "bounded sub-module" — the interactions are what create the unbounded state. The proposal to bound only the ROB in isolation is technically weak: ROB correctness depends on squash/recovery paths that span the load-store queue and rename map. This is not flagged.

7. **The "instance-independent collateral" PROPOSAL does not address the formal-tool bound for the whole core.** A formal proof that closes on one instance of a 128-core array does not, by itself, prove anything about the *array* — it proves the RTL is correct for a single instance, which is fine. But the document frames this as a *scaling* win without noting that the formal tool must be re-invoked per instance (or the formal proof must be structurally parameterized to instance index), and the coverage-merging logic must handle the formal-tool output. The PROPOSAL is fine but the scaling rationale is overstated.

8. **"riscv-arch-test" signing is per-signature, not per-core in the way the document implies.** The compliance signature attests to a configuration (XLEN, extension set, privilege modes, etc.), not to a physical core instance. The 128-instance question is therefore mostly a documentation/reproducibility question, not a verification-engineering question, and the document treats it as the latter without flagging the distinction.

9. **The document states "open-source model checkers… e.g., Yosys + SymbiYosys (SBY), and academic / open-source bounded-model-checking frameworks built on top of ABC."** The "built on top of ABC" framing is vague and the parenthetical caveat is dropped in the final recommendation. The recommendation cites Yosys + SymbiYosys as the open-source option without the ABC caveat, but both are presented in the same category. The reader could reasonably conclude ABC is part of the recommended open-source formal stack, which is not what the document intends.

10. **Numeric coverage thresholds are repeatedly flagged as "not fabricated" but the document gives no qualitative baseline either.** For a methodology document, it is reasonable to omit numbers when project inputs are missing. However, the document frames this as a strength ("INSUFFICIENT EVIDENCE… No numeric claim… has been fabricated") while simultaneously providing partial qualitative thresholds ("every supported instruction × representative operand values"). The mixture is defensible but the "no fabrication" claim is overstated — qualitative examples are still being asserted as binding methodology, and "representative operand values" is itself a non-trivial claim that the document does not justify.

11. **Cross-cutting concern: "debug scan-chain fan-out" terminology.** The document correctly distinguishes the *functional* JTAG/daisy-chain debug fabric from the *manufacturing* scan chain. However, the term "debug scan-chain fan-out" is ambiguous: it could refer to the functional debug daisy-chain (as the document intends) or to manufacturing scan stitching across instances (which is the ATPG concern). The document resolves this in the Cross-Cutting section, but the earlier Research Question and 128-Core Scalability sections use "debug scan-chain fan-out" without that disambiguation, which is internally inconsistent.

12. **Spike is described as an "architectural reference model" in some places and as an "ISA simulator" in others.** Both descriptions are technically defensible (Spike is a functional ISA simulator used as a reference for differential checking), but the document oscillates between "co-simulation against an architectural reference model (Spike-class)" and "Spike (Berkeley / RISC-V International, with significant SiFive contribution)" without settling on one. Minor.

13. **Imperas / riscvOVPsim is listed as an "open example" in Existing Approaches item 4 but is actually a commercial product.** The Sources list correctly identifies it as "Imperas, riscvOVPsim (commercial reference model)" but the body text groups it with Spike and SAIL as "principal open examples." This is a factual error: riscvOVPsim has open-source components but is primarily a commercial offering. SAIL is open-source; Spike is open-source. The grouping is wrong.

14. **The document does not address that constrained-random UVM with full coverage closure is not the standard term for "A1: Pure simulation-driven sign-off" — the standard term is "CDV" (coverage-driven verification) or just "constrained-random with coverage closure."** Minor terminology issue.

15. **"FPGA prototyping or emulation capacity for 128 cores" is flagged as an OPEN QUESTION but the document does not note that full-system 128-core emulation is generally not feasible on any current commercial emulator for a complex core** (Palladium/ZeBu capacities are in the low billions of gates, and a 128-core out-of-order RISC-V core with caches can be 50M+ gates per core, so 6.4B+ gates just for cores — at the edge of feasibility and dependent on core complexity). The OPEN QUESTION framing implies the answer might be yes; the document should flag that this is a hard capacity constraint for any specific microarchitecture, not just an open question.

16. **The document's RISC-V extension list in the Open Questions conflates unprivileged and privileged extensions.** The list reads "RV32/RV64, I/M/A/F/D/C, the major V extension, the Zb* bitmanipulation sub-extensions, the H privileged extension, the cryptography sub-extensions under Zkn/Zks/Zkb, supported privilege modes, hypervisor." H is the hypervisor extension and "hypervisor" appears as a separate item — this is redundant. Also, "supported privilege modes" is not an extension; it is a configuration choice. M-mode, S-mode, U-mode, VS-mode, VU-mode are privilege *modes* (M, S, U are required by the Privileged ISA at certain levels; VS/VU are gated by H). The list mixes categories.

17. **The "ABC-based bounded model checking" claim in the Alternative Designs F2 section is hedged with an implementation-detail caveat, but the Sources list does not include a primary source for the "ABC as a BMC backend" claim itself** — the source cited is ABC project documentation generically. The "academic / open-source bounded-model-checking frameworks built on top of ABC" is a vague claim without a specific framework named, and the recommendation later drops this nuance. The document should either name a specific framework or remove the claim.

18. **The "SAIL" attribution: SAIL is a specification language developed at Cambridge (and elsewhere) with RISC-V support in sail-riscv. The document's description as "Cambridge, SAIL RISC-V (architectural reference model)" is acceptable, but the document inconsistently says "SAIL-class" in one place and "SAIL-compatible" in another, with no commitment to whether SAIL is a candidate reference model or only an analogy.** Minor.

19. **The document repeatedly uses the term "UVM" without distinguishing UVM 1.1d, UVM 1.2, UVM IEEE 1800.2, etc.** UVM version pinning is a real verification-engineering concern and is unaddressed.

20. **The "Mutation-based verification tools" item lists Certitude but does not flag that mutation-based verification is not a standard sign-off methodology in the RISC-V ecosystem** and that commercial mutation tools are not commonly integrated with RISC-V compliance flows. The OPEN QUESTION framing (whether mutation is in the sign-off artifact) is appropriate, but the document presents Certitude as a category member without noting that mutation-based verification is a specialty methodology with limited adoption in core sign-off.

REQUIRED_FIXES:

- Fix the riscvOVPsim misclassification as "open" in Existing Approaches item 4; it is primarily commercial.
- Reconcile the cryptography-extension taxonomy between Background (correct) and the Open Questions / Recommendation / Implementation Considerations (where Zkb is treated as a parallel sibling of Zkn/Zks rather than the crypto-bitmanip grouping it actually is).
- Clarify that the ROB formal bound in isolation does not cover the full out-of-order recovery semantics; either expand the formal scope to include rename/LSQ interactions or explicitly flag the residual risk in the ROB-as-bounded-sub-module PROPOSAL.
- Disambiguate "debug scan-chain fan-out" at first use in the Research Question and 128-Core Scalability sections (it is the functional JTAG/daisy-chain fabric, not the manufacturing scan chain; the latter is addressed separately).
- Remove or properly qualify the "open-source model checkers built on top of ABC" claim; if retained, name a specific framework and source it, or restrict the F2 category to Yosys + SBY.
- Address the H (hypervisor) coverage treatment: the base coverage matrix must be restructured (two-stage translation, HS-mode CSRs, nested page walks) rather than merely extended, and document this.
- Fix the privilege-mode / extension conflation in the Open Questions extension list (remove "hypervisor" as a separate item, distinguish modes from extensions).
- Flag the 128-core emulation capacity question as a likely hard constraint dependent on per-core gate count, not just an open question.
- Add UVM version pinning to the open questions or remove the UVM-specific recommendation until pinned.
- Clarify whether Spike/SAIL/riscvOVPsim are reference models (co-simulation) or ISA simulators used for differential checking; the document uses both framings.
- Source the claim that "Modern commercial RISC-V cores (SiFive, Andes, OpenHW) typically combine constrained-random simulation with a defined coverage model and supplement with formal property checks" or downgrade to a weaker claim — it is currently an ASSUMPTION but is referenced in the Advantages section as if it were a FACT.
- The Spike attribution should specify "Berkeley-originated, now maintained under RISC-V International" or similar; the current phrasing mixes "RISC-V International" (the standards body, which does not maintain Spike) with "Berkeley" (which originated it) and "SiFive" (which contributes).

CONFIDENCE: HIGH
