# Core Verification

## Document Conventions

This document uses a fixed label taxonomy applied to every claim:

- **FACT** — A statement supported by a cited primary or authoritative source.
- **ASSUMPTION** — A working hypothesis taken by the author in the absence of confirmed project data; must be re-validated before sign-off.
- **PROPOSAL** — A concrete design or methodology recommendation that the document puts forward, conditioned on the stated assumptions.
- **RECOMMENDATION** — A binding choice that follows from the analysis in this document, after considering the stated alternatives.
- **OPEN QUESTION** — A question whose answer is required before the surrounding analysis can be finalized; explicitly not closed by this document.

Where evidence is not available, the document writes `INSUFFICIENT EVIDENCE` rather than fabricating data.

---

## Status

Substantive research draft. The XH-1 ISA profile, microarchitecture, EDA toolchain, and sign-off criteria are not yet captured in the project repository, so several sections below remain conditional on those inputs. Where the document cannot close an item without that input, the item is marked **OPEN QUESTION**.

---

## Abstract

XH-1 is a custom 128-core RISC-V design. The verification burden scales sub-linearly with core count only if the per-core verification collateral is instance-independent (a single testbench and coverage model reused for every replicated instance) and the cross-core interactions (coherence, inter-processor interrupts, debug scan-chain fan-out, trace aggregation) are explicitly delegated to a separate multicore verification document. This document proposes a hybrid per-core methodology: constrained-random SystemVerilog/UVM simulation as the workhorse, formal property verification on targeted bounded sub-modules (CSR file, MMU/TLB, exception priority encoders, ROB/scoreboard, FSMs), co-simulation against an architectural reference model (Spike-class), and riscv-arch-test signature generation. Coverage exit criteria are defined in terms of legal-bin functional coverage, CSR-bit and WARL coverage, exception/interrupt priority coverage, and targeted formal unbounded proofs on bounded sub-modules. The document also identifies verification concerns that the per-core scope must explicitly address or defer with stated reason: gate-level simulation, X-propagation, clock-domain crossing, manufacturing scan/MBIST interaction, and security verification. The document does not yet commit to specific numeric coverage thresholds, simulator selection, or tool licenses because the project's ISA profile, simulator stack, and tape-out schedule are OPEN QUESTIONS.

---

## Research Question

The specific research questions addressed are:

1. What is the minimum set of per-core verification techniques required to achieve a stated sign-off confidence target for a single XH-1 core, given that this core will be replicated to 128 instances?
2. How should directed, constrained-random, and formal methods be partitioned across the core's microarchitectural units (fetch, decode, rename, issue, execute, load-store, memory, retire, CSR, MMU, PMP, debug transport, trace)?
3. What coverage model is required at the core level versus deferred to multicore verification, and what are the numeric exit criteria for each?
4. How must the per-core verification collateral be structured so that it is reusable across 128 instances without per-instance redevelopment?
5. How are per-core verification concerns that span RTL and physical implementation (gate-level simulation, X-propagation, clock- and reset-domain crossing, manufacturing scan interaction) handled in the per-core scope, and which are deferred with stated reason?

The question of how cross-core coherence, inter-processor interrupts, and debug scan-chain fan-out are verified is explicitly **out of scope** and deferred to the multicore verification document.

---

## Background

**FACT** — The RISC-V ISA is defined by two principal specifications maintained by RISC-V International: the *Unprivileged ISA Specification* and the *Privileged ISA Specification*. Both are ratified, versioned, and publicly available. [Sources: RISC-V International, *Unprivileged ISA Specification*; *Privileged ISA Specification*.]

**FACT** — The RISC-V *Debug Specification* is at version 1.0.0 (ratified). [Source: RISC-V International, *RISC-V Debug Specification*, version 1.0.0, https://riscv.org/technical/specifications/ — verified at the URL above as of 2024; this document does not assert that 1.0.0 is the only version ever deployed, only that it is the current ratified version. The Debug 0.13 specification existed historically; whether 0.13 is observed in deployed cores is not stated as FACT in this document. See Open Questions for XH-1's specific Debug version.]

**FACT** — The RISC-V *Trace Specification* is at version 2.0.0 as of the most recent public release prior to this document. No specific release date is recorded here; pin to a version is an **OPEN QUESTION** for XH-1. [Source: RISC-V International, *RISC-V Trace Specification*, version 2.0.0, https://riscv.org/technical/specifications/.]

**FACT** — RISC-V International publishes the *Architecture Test* framework (riscv-arch-test) and an associated signing process. Compliance is established by producing a signature on a defined test set, not by formal certification. [Source: github.com/riscv-arch-test, RISC-V International *Compliance Policy*.]

**FACT** — OpenHW Group's CV32E40P is a 32-bit, in-order, RV32IMFC RISC-V core. CV32E40PX is a separate variant that adds PULP/XpulpV2 extensions and an FPU. The two are not interchangeable. [Source: OpenHW Group CV32E40P and CV32E40PX core documentation, https://github.com/openhwgroup/core-cv32e40p and https://github.com/openhwgroup/core-cv32e40px.] (Relevance to XH-1 is not asserted; this fact is included only to disambiguate a common citation error.)

**FACT** — The RISC-V extension taxonomy as ratified by RISC-V International separates unprivileged and privileged extensions:

- The unprivileged ISA general-purpose extensions are designated by single capital letters: I (base integer), M (integer multiply/divide), A (atomic), F (single-precision floating-point), D (double-precision floating-point), C (compressed). [Source: RISC-V International, *Unprivileged ISA Specification*, "Extension" naming conventions, https://riscv.org/technical/specifications/.]
- The V extension (RVV, vector) is a *major* unprivileged extension, not a single-letter general-purpose extension in the M/A/F/D/C sense; it has its own specification document. [Source: RISC-V International, *Vector Extension*, "V" specification, https://riscv.org/technical/specifications/.]
- B (bitmanip) is not a single extension in the current taxonomy. The bitmanipulation functionality is defined as a family of sub-extensions under the Zb* namespace, principally Zba, Zbb, Zbs, and (in some revisions) Zbc, Zbe, Zbf, Zbm, Zbp, Zbr, Zbt. The single-letter "B" was a pre-ratification umbrella that has been superseded by the Zb* sub-extension split. [Source: RISC-V International, *Unprivileged ISA Specification*, "B" / "Zb*" extension naming history, https://riscv.org/technical/specifications/.]
- H (hypervisor) is a *privileged* extension, not an unprivileged general-purpose extension. It appears in the *Privileged ISA Specification* and is orthogonal to the M/A/F/D/C unprivileged set. [Source: RISC-V International, *Privileged ISA Specification*, "H" extension, https://riscv.org/technical/specifications/.]
- The cryptography extensions comprise the Zk profile (Zk = Zkn + Zks, an umbrella profile for scalar cryptography) and a family of scalar and vector cryptography sub-extensions. The scalar bitmanipulation-for-cryptography extensions Zbkb, Zbkc, and Zbkx are grouped under the **Zkb** namespace (scalar crypto bitmanip), not under Zk. Zk itself bundles Zkn (NIST algorithm suite: Zknd, Zkne, Zknh) and Zks (ShangMi algorithm suite: Zksed, Zksh). The Zb* family of scalar bitmanip sub-extensions is distinct from the Zkb family of scalar-crypto-bitmanip sub-extensions. [Source: RISC-V International, *Cryptography Extensions* specification, https://riscv.org/technical/specifications/.]

**ASSUMPTION** — Modern commercial RISC-V cores (SiFive, Andes, OpenHW) typically combine constrained-random simulation with a defined coverage model and supplement with formal property checks on targeted blocks (CSR file, TLB, scoreboard/ROB). This is widely reported in industry but is not sourced to a single authoritative document in this draft; treated here as an **ASSUMPTION**, not a **FACT**, pending a citable source.

**FACT** — The baseline is not sufficient on its own: the *riscv-tests* / *riscv-arch-test* suites are necessary but are known to provide shallow coverage relative to the architectural state space and are not a substitute for a project-defined coverage closure plan. [Source: RISC-V International *Architecture Test* documentation, which explicitly states the suite is a compliance baseline.]

---

## Existing Approaches

**FACT** — The following categories of core-level verification flow are established in the EDA and RISC-V ecosystems:

1. Constrained-random SystemVerilog/UVM simulation with coverage-driven closure (functional, code, toggle, assertion, cross-coverage).
2. Formal property verification using model-checking tools on selected sub-modules. Correctly categorized tools in this space include: Siemens EDA JasperGold, Synopsys VC Formal, Synopsys 360 DV-Formal (formerly OneSpin 360 DV; OneSpin was acquired by Synopsys in 2022 and the product is now positioned as part of the Synopsys formal portfolio), and open-source flows such as Yosys + SymbiYosys (SBY). [Source: vendor product documentation; the corporate-ownership status of these tools is recorded here for procurement accuracy.]
3. FPGA prototyping and emulation acceleration (e.g., Synopsys ZeBu, Cadence Palladium, in-house FPGA boards).
4. Co-simulation against architectural reference models, of which the principal open examples are Spike (Berkeley / RISC-V International, with significant SiFive contribution), SAIL (Cambridge), and the Imperas/OVP reference models. [Sources: github.com/riscv/riscv-isa-sim (Spike); github.com/rems-project/sail-riscv; github.com/riscv-ovpsim.]
5. Compliance test suites: *riscv-tests* (legacy) and *riscv-arch-test* (current RISC-V International framework), together with the RISC-V International signing process. [Source: github.com/riscv-arch-test.]
6. Mutation-based verification tools (e.g., Certitude, proprietary in-house mutation frameworks).
7. Coverage merging across simulators and prototypes (e.g., Synopsys VCS + ZeBu, Cadence Xcelium + Palladium).
8. Gate-level simulation (GLS) against the post-synthesis or post-place-and-route netlist, with or without power-aware annotations, to catch synthesis-introduced functional regressions and X-optimism issues. [Source: general EDA methodology; tool-specific user documentation for Synopsys VCS, Cadence Xcelium, Siemens Questa GLS flows.]
9. X-propagation and X-init analysis: design-for-verification techniques that force and observe X-state to detect simulation-versus-synthesis mismatches (e.g., Synopsys X-Prop, Cadence X-Cell, Siemens Questa X-Prop). [Source: vendor methodology documentation.]
10. Clock-domain crossing (CDC) and reset-domain crossing (RDC) verification using structural analysis and formal property checking (e.g., Synopsys SpyGlass CDC / RDC, Cadence JasperGold CDC, Siemens Questa CDC). [Source: vendor methodology documentation.]

---

## Alternative Designs

The principal methodology alternatives considered are:

- **A1. Pure simulation-driven sign-off.** Constrained-random UVM with full coverage closure; no formal. Lowest tool-chain complexity but slowest closure on deep corner cases (CSR WARL semantics, TLB invariants, exception priority encoders).
- **A2. Hybrid simulation + formal (selected).** Constrained-random UVM as workhorse, formal model-checking on bounded sub-modules (CSR, TLB, scoreboard/ROB, FSMs, exception priority encoder). Higher engineering effort but materially faster closure on sub-modules where simulation reaches diminishing returns.
- **A3. Formal-first, simulation-supplemental.** Heavy formal front-end; simulation used only for integration and compliance. This document makes no claim about the absolute practicality of A3 for a specific XH-1 microarchitecture; the qualitative observation is that A3 has been applied to bounded in-order cores but is not commonly adopted for complex out-of-order cores because the unbounded state space of the memory subsystem is not tractable for current model checkers. The feasibility of A3 for XH-1 is conditioned on whether the core is in-order or out-of-order (OPEN QUESTION). **ASSUMPTION** — Within the bounded regime (CSR file, FSM, TLB, exception priority encoder, small ROB), formal model checking is tractable for current commercial and well-engineered open-source model checkers; the tractability assumption does not extend to the unbounded memory-ordering state space of a full out-of-order core.
- **A4. Emulation/FPGA-first.** Boots real software (Linux, distro, stress workloads) early. High infrastructure cost; visibility into microarchitectural state is limited relative to event-driven simulation; sign-off against the microarchitectural coverage model is still owed. The infrastructure cost is a function of the array size; for 128 cores, FPGA capacity and emulation licensing scale with capacity and may be a hard constraint. Capacity availability for XH-1 is an **OPEN QUESTION**.

Within the simulation domain:

- **B1. In-house UVM testbench.** Full control, no license cost, but high engineering effort.
- **B2. Commercial verification IP.** Faster start; recurring license cost; opaque to RTL changes.
- **B3. Generator-based flows (e.g., riscv-dv, originally developed at Google and now hosted under CHIPS Alliance).** riscv-dv is an ISA-aware constrained-random instruction-stream generator used as a stimulus source within a testbench; it is not a self-contained "random program generator" in the full-program sense. It produces instruction sequences that a surrounding testbench wraps, typically with a reference model for differential checking. [Source: github.com/chipsalliance/riscv-dv.]

Within the formal-tool domain:

- **F1. Commercial model checkers.** Examples: Siemens EDA JasperGold, Synopsys VC Formal, Synopsys 360 DV-Formal. Higher capacity, commercial support, license cost.
- **F2. Open-source model checkers.** Examples: Yosys + SymbiYosys (SBY), and academic / open-source bounded-model-checking frameworks built on top of ABC. Lower cost; smaller capacity; smaller ecosystem. The "ABC-based bounded model checking" claim refers to the use of ABC's `bmc` flow as a backend, typically wrapped by a higher-level driver; this is an implementation detail that varies by project and is recorded here without a single canonical source. [Source: https://github.com/YosysHQ/yosys; https://github.com/YosysHQ/sby; ABC project documentation, https://github.com/yosyshq/abc.]

Coverage-model alternatives:

- **C1. Structural only (line/branch/toggle).** Fast to collect; known to miss functional holes.
- **C2. Functional matrix indexed by ISA extension × privilege level × interrupt/exception path.** Necessary for sign-off; higher collection and debug cost.
- **C3. Functional + mutation score.** Mutation is a complementary measure of suite strength; not a substitute for functional coverage. Whether mutation is part of the XH-1 sign-off artifact is an **OPEN QUESTION** (see Verification Considerations).

---

## Comparison

**INSUFFICIENT EVIDENCE** for a quantitative comparison. The relative run time, license cost, engineering effort, coverage-closure time, and debug productivity of A1–A4, B1–B3, and F1–F2 depend on the chosen EDA stack, the ISA profile, and the in-house team's existing code base, none of which are captured in the project repository. A numeric trade-off table is not fabricated here. The qualitative direction is well established (see Advantages/Disadvantages below) and is sufficient to support the recommendation.

---

## Advantages

**Hybrid simulation + formal (A2):**

- Formal closes deep corner cases (CSR WARL, TLB invariants, exception priority encoder) faster than simulation, where simulation reaches diminishing returns. (Qualitative; consistent with published methodology guidance from the formal-tool vendors cited above.)
- Constrained-random UVM remains the workhorse for cross-block interactions and stress.
- The split allows formal to be scoped to bounded sub-modules, which is where model checking is tractable.

**Generator-based flow (B3, e.g., riscv-dv):**

- Open-source and ISA-aware; reduces hand-written sequence count.
- Integrates with the architectural reference model (Spike) for differential checking. [Source: github.com/chipsalliance/riscv-dv; github.com/riscv/riscv-isa-sim.]

**Open-source formal (F2):**

- No license cost; can be applied to small bounded sub-modules (single FSMs, small CSR files) without commercial procurement.
- Useful as a pre-screen or as a fallback for sub-modules where commercial formal capacity is not warranted.

**Compliance framework:**

- riscv-arch-test with the RISC-V International signing process produces a portable, vendor-neutral artifact that downstream software/OS teams can use. [Source: github.com/riscv-arch-test; RISC-V International *Compliance Policy*.]

---

## Disadvantages

**Hybrid simulation + formal (A2):**

- Two tool flows must be integrated, which adds engineering effort and requires a coverage-merging strategy across flows.
- Tool licensing for the formal path is non-trivial; a CapEx/OpEx line item is required.

**Generator-based flow (B3):**

- riscv-dv is RV32/RV64 ISA-focused; non-ISA RTL (custom accelerators, custom CSRs) is not generated and must be hand-written.

**Compliance framework:**

- The riscv-arch-test suite is shallow; producing a signature on it is necessary but not sufficient for sign-off. Treating it as sufficient is a known failure mode. (This is a usage guideline, not a property of the framework itself.)

**Open-source formal (F2):**

- Lower model-checking capacity than commercial tools; not all sub-modules will close.
- Smaller ecosystem of commercial support.

**General across alternatives:**

- None of the alternatives in isolation produces a tape-out-ready sign-off artifact; all require an explicit, project-owned coverage-closure plan with numeric exit criteria.

---

## XH-1 Considerations

**ASSUMPTION** — XH-1 is a custom 128-core RISC-V design. Core-level verification must produce a sign-off artifact reusable across all 128 replicated instances.

**OPEN QUESTION** — The 128 cores are assumed to be **homogeneous** (single RTL replicated). Whether this holds, or whether XH-1 includes variants (e.g., application cores plus a management/IoT core), is not stated in the project repository and must be confirmed before downstream documents can proceed.

**OPEN QUESTION** — The boundary between per-core and multicore verification is not yet defined. Candidates:

- Per-core: L1 I-cache, L1 D-cache, MMU/TLB, PMP, CSR, debug transport module, trace encoder, retire/ROB, exception/interrupt controller.
- Multicore: coherence directory and protocol, snoop/interconnect agent, inter-processor interrupts, debug scan-chain fan-out and DMI multiplexing, global trace aggregation, clock/reset distribution across tiles.

**OPEN QUESTION** — Debug and trace are partitioned as: debug transport module and trace encoder are per-core; DMI multiplexing, system bus master, and trace aggregation are multicore. This must be confirmed against the microarchitecture before the multicore verification document is written.

**OPEN QUESTION** — The RISC-V Debug Specification version that applies to XH-1 is not stated. The current ratified version is 1.0.0; the project's choice between 1.0.0 and any earlier revision (including 0.13, which was a pre-ratification draft) is not captured. Until this is fixed, the per-core debug/trace verification artifacts cannot be locked. The Trace Specification version is similarly unresolved (current ratified version is 2.0.0).

---

## 128-Core Scalability

**PROPOSAL** — Per-core verification collateral (testbench, sequences, assertions, coverage models) is constructed as a **single instance-independent artifact** that is run for each of the 128 replicated cores (or, equivalently, run once with a parameterizable instance handle). **ASSUMPTION** — The UVM environment, reference-model integration, and coverage infrastructure are themselves parameterized by instance handle and are re-entrant across instance runs. If the in-house infrastructure does not support re-entrant parameterization, the instance-independence must be re-validated as a project-specific constraint. Coverage, scoreboard state, and reference-model state are reset between instance runs unless a cross-instance scenario is explicitly constructed (and cross-instance scenarios are owned by the multicore document). This is the same artifact exercised 128 times, not 128 specialized artifacts.

**PROPOSAL** — The formal-tool bound (proof depth, state-space depth, number of register bits) is selected such that the same bound applies to all 128 instances; the bound is not a function of the instance index. The formal collateral is therefore also instance-independent.

**ASSUMPTION** — The 128-core design reuses a single verified core RTL. If the array is heterogeneous, the instance-independence collapses to one per variant, and the per-core effort is multiplied by the number of variants.

**OPEN QUESTION** — XH-1's physical organization (tiled replicated layout, mesh/NoC of heterogeneous tiles, or a mix) is not stated and is required to determine whether cross-tile interactions can be cleanly excluded from the per-core sign-off artifact or whether the per-core collateral must include tile-edge stub agents.

**PROPOSAL** — Cross-core interactions (coherence, inter-processor interrupts, debug scan-chain fan-out) are **out of scope** for the per-core document and are owned by the multicore verification document. (This is a PROPOSAL based on the verification-reasoning argument that mixing per-core and multicore concerns produces a fragile, instance-coupled artifact; it is not a "known anti-pattern" in the sense of an externally codified rule.)

**OPEN QUESTION** — How is the riscv-arch-test signing flow extended to 128 instances? The compliance flow is per-core; the project intent (one signature per instance, one signature from a representative instance, or a parameterized signature) is not stated.

**PROPOSAL** — Regression parallelism across 128 instances is achieved by distributing identical per-core runs across the host farm. **ASSUMPTION** — The regression harness supports per-instance pass/fail reporting so that a single failing seed in one instance blocks the regression for that instance but does not invalidate the other 127 instance runs; triage is per-instance. If the harness aggregates pass/fail across instances, the per-instance triage discipline must be re-engineered. Cross-instance coverage merging is performed by aggregating the per-instance coverage databases into a single per-core dashboard.

**OPEN QUESTION** — FPGA prototyping or emulation capacity for 128 cores is not stated. A4 (Emulation/FPGA-first) is feasible only if the platform can host the full array; the alternative is to emulate a single instance plus a representative tile-edge stub, which is a per-core artifact, not a multicore one.

---

## Performance Considerations

**OPEN QUESTION** — Core-level simulation throughput (instructions/second, coverage points/hour) depends on the chosen simulator (commercial event-driven, Verilator, cocotb, or custom), the workload, and the host farm, none of which are fixed. No numeric simulation throughput is fabricated here.

**ASSUMPTION** — The selected simulator will be one of the established options (Synopsys VCS, Cadence Xcelium, Siemens Questa, Verilator, cocotb). The choice is project-owned and is deferred to the verification strategy document.

**OPEN QUESTION** — The trade-off between open-source simulators (Verilator, cocotb) and commercial event-driven simulators at 128-core regression scale is not characterized here. The relevant axes are: per-instance throughput, license cost, UVM support, coverage-tool integration, and debug visibility. A quantitative trade-off depends on the chosen farm size and is not fabricated.

**PROPOSAL** — A regression-budget plan is required before any coverage-closure phase: a target number of seed-hours per day, an expected closure horizon, and a triage budget for failed seeds. The numeric values are an **OPEN QUESTION** pending the chosen simulator and farm size.

---

## Area Considerations

**INSUFFICIENT EVIDENCE** — Verification-influenced area decisions (adding observability or assertion logic, formal-friendly state encodings, scan/DFT hooks) are not characterized for XH-1.

**ASSUMPTION** — The core RTL is fixed for tape-out area budgeting and that verification-influenced changes are bounded to observability that does not appear in the synthesized netlist (e.g., `ifdef` guards). This must be confirmed against the synthesis/scan insertion flow.

**OPEN QUESTION** — What is the XH-1 target process node and per-core area budget? Both are required before area-influenced verification choices (e.g., one-hot vs. binary FSM encoding for formal tractability) can be evaluated.

---

## Power and Energy Considerations

**INSUFFICIENT EVIDENCE** — Per-core power and energy are not characterized for XH-1.

**ASSUMPTION** — Verification-influenced power decisions (e.g., additional clock-gating observability, retention-state assertions) are a sub-area of the per-core document and are conditioned on the power-management architecture being defined.

**OPEN QUESTION** — Does XH-1 implement RISC-V power-management mechanisms, and at what privilege level? The RISC-V mechanisms relevant to this question include:

- WFI (`wait-for-interrupt`) and the WFI-idle semantics defined in the *Privileged ISA Specification*; these are the standardized low-power entry points. [Source: RISC-V International, *Privileged ISA Specification*, "Wait for Interrupt", https://riscv.org/technical/specifications/.]
- `Zihintpause` (unprivileged pause hint), a throughput-modulation hint, not a power-management extension per se but relevant to power-state verification. [Source: RISC-V International, *Unprivileged ISA Specification*, "Zihintpause" extension, https://riscv.org/technical/specifications/.]
- Custom or vendor-defined retention / deep-sleep states, which are not standardized under a single RISC-V extension and must be enumerated against the XH-1 microarchitecture.

Sstc (Supervisor-mode Timer Interrupts) and Smstateen (State Enable) are *not* power-management extensions; they are interrupt-routing and state-visibility extensions, respectively, and are miscategorized if grouped under power management. [Source: RISC-V International, *Privileged ISA Specification*, Sstc and Smstateen extensions, https://riscv.org/technical/specifications/.] Until the XH-1 power-management architecture is defined, power-aware verification cannot be scoped.

**OPEN QUESTION** — How is energy-aware DV (e.g., power-state-transition coverage) partitioned across the per-core and multicore documents? An explicit ownership line is required.

---

## Implementation Considerations

**OPEN QUESTION** — XH-1 implements a defined subset of the RISC-V ISA (base integer I, and a selected set of M, A, C, F, D, the major V extension, the Zb* bitmanipulation sub-extensions, the H privileged extension, and cryptography sub-extensions under Zkn, Zks, and Zkb, plus platform extensions). The exact subset is an **OPEN QUESTION** and is required before any coverage matrix is locked.

**OPEN QUESTION** — Is the core in-order or out-of-order? This drives the verification surface:

- In-order: simpler scoreboard, no speculation-recovery paths.
- Out-of-order: ROB/scoreboard, load-store queue, register-renaming, speculation-recovery, and memory-ordering fences are all first-class verification targets. **ASSUMPTION** — A formal model of the ROB is typically bounded (small replay queue depth, fixed rename-map width) and tractable within that bound; a full out-of-order memory subsystem is generally beyond unbounded proof with current model checkers. This assumption is qualitative and is not sourced to a single authoritative document; it is recorded here as ASSUMPTION, not FACT.

**OPEN QUESTION** — The ROB formal bound (proof depth, replay-queue depth, rename-map width) is project-owned and is not fixed here. The bound is selected to make the model checker tractable while exercising the recovery paths the project considers in-scope for formal closure. The bounded proof covers the in-bound states; the unbounded remainder is covered by simulation. This division of labor is stated as a PROPOSAL, conditional on the in-order/out-of-order answer and on the project's risk posture.

**ASSUMPTION** — A reference model (Spike-class or SAIL-class) is available for differential checking, and the riscv-arch-test signing flow is adopted so that compliance is portable. Both are working assumptions until confirmed.

**PROPOSAL** — Where the project's extensions include V (vector), the Zb* bitmanipulation sub-extensions, H (hypervisor), or cryptography sub-extensions (Zkn, Zks, Zkb family), the per-core coverage matrix is extended with extension-specific cross-coverage, and formal proofs on the corresponding functional units are added to the formal scope. The conditional language here is the binding form: the coverage and formal scopes are conditioned on the confirmed ISA profile.

**PROPOSAL** — The riscv-dv generator is integrated as the primary random program source, with hand-written directed sequences retained for microarchitectural corner cases (cache aliasing, TLB refill, fence ordering, atomic RMW, debug-entry/exit, and CSR WARL). [Source: github.com/chipsalliance/riscv-dv.]

**OPEN QUESTION** — PMP is listed under per-core scope. PMP has a privileged-ISA definition with WARL semantics across its configuration registers and interacts with the MMU/TLB on access checks. The per-core split for PMP (simulation coverage on access-check behavior; formal bounded proofs on PMP-CSR WARL invariants and PMP-vs-MMU priority) is a project-owned decision and is not fixed here.

---

## Cross-Cutting Verification Concerns

The per-core scope must explicitly address or defer with stated reason the following cross-cutting concerns. Each item below is labeled IN-SCOPE (handled in the per-core document), DEFERRED (handled in another document), or OPEN (scope decision required).

- **Gate-level simulation (GLS).** **OPEN.** GLS against the post-synthesis or post-place-and-route netlist is mandatory for tape-out sign-off in industry practice. Whether GLS is owned by the per-core document, the multicore document, or a separate physical-implementation verification document is not stated in the project repository. **ASSUMPTION** — GLS uses the same constrained-random testbench as RTL simulation, with the netlist as a substitute for the RTL; this is the standard pattern, but the per-core-vs-multicore ownership is not fixed.

- **X-propagation and X-init analysis.** **OPEN.** X-optimism (where the simulator treats `X` as a known value and masks a real bug) is a well-known sign-off failure mode. Whether the X-Prop flow is applied to the per-core RTL before GLS is a project-owned decision. **ASSUMPTION** — An X-Prop pass is run on the per-core RTL prior to GLS so that GLS is meaningful; this is the conservative default.

- **Clock-domain crossing (CDC) and reset-domain crossing (RDC).** **OPEN.** A 128-core design with multiple clock and reset domains requires structural CDC/RDC analysis and formal CDC proofs on the crossing logic. The standard ownership split is per-block (per-core crossings) and top-level (multicore crossings), but the boundary is project-defined. **ASSUMPTION** — CDC/RDC for crossings *within* a single core (e.g., debug vs. functional clock) is a per-core concern; CDC/RDC for crossings *between* cores or between core and uncore is a multicore concern.

- **Manufacturing scan / MBIST / LBIST.** **OPEN.** Manufacturing scan compression, scan chain stitching across 128 instances, MBIST/LBIST controllers, and ATPG-vs-functional sign-off boundaries are not addressed by the per-core functional document. Functional verification must at minimum confirm that the scan/MBIST logic does not perturb functional state (e.g., that scan-shift does not corrupt architectural state, that MBIST isolation is correct, and that BIST completion does not stall the core). The per-core scope of this confirmation, versus a separate DFT-sign-off document, is project-defined. The document's "debug scan-chain fan-out" item refers to the *functional* JTAG/daisy-chain debug fabric, which is distinct from the *manufacturing* scan chain used for ATPG; both must be addressed and they are not the same concern.

- **Security verification.** **OPEN.** For a 128-core design with candidate cryptography extensions (Zkn, Zks, Zkb family), security verification includes (i) functional correctness of the crypto instructions, (ii) constant-time / side-channel resistance at the implementation level, (iii) fault-injection resistance, and (iv) secure-boot / attestation flows. Items (i) is in scope for per-core functional verification if the extensions are implemented; items (ii) and (iii) typically require specialized tooling and methodology (e.g., timing-fault simulation, statistical side-channel analysis) that are owned by a separate document. The one-line "side-channel considerations deferred to a separate document" in the prior version is insufficient; the ownership split for items (i)–(iv) must be defined.

- **FP corner cases (F/D extension).** **OPEN.** If F and/or D are implemented, the per-core coverage matrix must include FP-specific corner cases: subnormal handling, NaN propagation, NaN-boxing (where the wider register encoding is required for narrower FP values), all five IEEE 754 rounding modes, signed-zero behavior, infinity and signed-infinity handling, and exception-flag accumulation. The conditional scoping in this document covers inclusion; the specific FP coverage list is project-defined.

- **V (vector) extension coverage.** **OPEN.** If V is implemented, the per-core coverage matrix is non-trivial: VLEN × ELEN matrix, LMUL groupings, segment (segmented) vs. strided vs. indexed memory operations, fault-only-first (FOF) behavior, whole-register loads/stores, mask register semantics, and the relevant privilege / virtual-memory interaction. The conditional scoping in this document covers inclusion; the specific V coverage list is project-defined and is not fabricated here.

---

## Verification Considerations

**PROPOSAL** — A coverage closure plan is defined before any RTL is signed off. Exit criteria are stated in terms of:

- **Functional coverage.** Every supported instruction × representative operand values (0, 1, -1, max, min, sign-extension edges) × supported privilege mode.
- **Exception/interrupt coverage.** Every exception cause × every priority × MRET/SRET/URET paths × nested-trap sequences. [Source: RISC-V International, *Privileged ISA Specification*, trap-handling chapter.]
- **CSR coverage.** Every implemented CSR × every writable bit × reset value × WARL semantics. Formal proof of WARL invariants is a sub-goal.
- **Memory access coverage.** Misaligned accesses, PMP-denied accesses, MMU miss, page fault, AMO/RMW, fence ordering, I/O regions, and big-endian (if implemented).
- **Reset and debug.** Every reset reason (power-on, warm, retention, debug) and every debug state transition in the RISC-V Debug Specification version confirmed for XH-1.
- **Formal.** Targeted bounded proofs on bounded sub-modules: CSR file WARL invariants, TLB invariants, exception priority encoder, retire/ROB, debug-transport FSM, trace-encoder FSM. The bound for each sub-module is project-owned (see Implementation Considerations).

**OPEN QUESTION** — The numeric coverage thresholds (legal-bin closure percentage, toggle coverage, assertion coverage, mutation score) are project-owned and are not fabricated here. The selection of numeric thresholds is conditioned on the project's risk posture and is left as an explicit OPEN QUESTION.

**OPEN QUESTION** — Mutation / fault-injection (alternative C3) is a complementary measure of suite strength. Whether it is in or out of the XH-1 sign-off artifact is not decided in this document. Options: (i) include mutation score as an explicit exit criterion; (ii) use mutation as a development-time diagnostic without a numeric exit criterion; (iii) exclude mutation entirely. The decision is deferred to the verification strategy document.

**PROPOSAL** — Extension-specific items in the coverage list are conditioned on the confirmed ISA profile:

- F/D coverage (including NaN-boxing, subnormal handling, rounding modes) is included only if the F/D extension is implemented.
- V (vector) coverage is included only if V is implemented, and is scoped to the implemented VLEN/ELEN, the chosen vector subset, and the relevant mask/segment/strided/indexed coverage dimensions.
- Zb* bitmanip coverage is included only if the relevant Zb* sub-extensions are implemented.
- H (hypervisor) coverage is included only if H is implemented and is paired with a separate virtual-memory coverage plan.
- Cryptography coverage (Zkn, Zks, Zkb family) is included only for the implemented sub-extensions, with side-channel considerations deferred to a separate document.

This conditional scoping is the binding form: the coverage list is fixed at the granularity of *conditioned on the confirmed ISA profile*.

**PROPOSAL** — Coverage merging across flows (simulation, formal, emulation) is required: the formal-tool coverage reports and the simulator coverage reports must be merged into a single per-core dashboard so that the sign-off artifact is unambiguous. At 128-instance scale, the merge is performed per-instance and then aggregated.

**OPEN QUESTION** — Which verification sub-area (formal, fault injection, ISA compliance, multicore, regression, strategy, unit) consumes the artifacts produced at the core level? This ownership map is required before the multicore document is written.

---

## Software Considerations

**PROPOSAL** — The per-core verification artifacts are aligned with the downstream software flow:

- The riscv-arch-test signature is producible from the verified core and is delivered alongside the reference manual. At 128-instance scale, the signature-generation step is repeated per instance (or per representative instance, per the project-owned decision; see 128-Core Scalability).
- A linker script, boot ROM contract, and SBI interface contract are specified in parallel with the core's CSRs, to avoid post-silicon software surprises. [Source: RISC-V International, *SBI Specification*.]
- A pre-silicon architectural reference (Spike-compatible or SAIL) is published for software teams so that OS porting and toolchain work proceed in parallel with RTL. The specific version of Spike or SAIL is pinned to a commit or release tag as part of the verification strategy document; this document does not commit to a version.

**FACT** — The SBI interface is specified by RISC-V International; pinning to a specific SBI version is required and is an **OPEN QUESTION** for XH-1.

---

## Recommendation

The recommendation below states the binding methodological choices and is conditional on the homogeneous-128-core assumption and on the ISA profile being captured before the multicore document is written. Items that remain project-owned decisions (numeric thresholds, specific tool selection, reference-model version) are not bound by this recommendation and are listed in the Open Questions section.

**RECOMMENDATION** — Adopt the hybrid simulation + formal methodology (A2) for per-core verification, with the following binding choices:

1. **Simulation workhorse.** Constrained-random SystemVerilog/UVM, with riscv-dv as the primary random-program stimulus generator, integrated with an architectural reference model (Spike-class) for differential checking. The specific simulator and reference-model version are project-owned and are not bound by this document (see Open Questions).
2. **Formal scope.** Model-checking on bounded sub-modules: CSR file (WARL invariants), MMU/TLB, exception priority encoder, ROB/scoreboard (bounded), debug-transport FSM, trace-encoder FSM. Candidate tool categories are commercial model checkers (e.g., Siemens EDA JasperGold, Synopsys VC Formal, Synopsys 360 DV-Formal) and, for small bounded sub-modules, open-source model checkers (e.g., Yosys + SymbiYosys). Specific tool selection, license procurement, and per-sub-module tool assignment are not bound by this document.
3. **Compliance.** riscv-arch-test signature generation is part of the sign-off artifact. At 128-instance scale, the per-instance signature-generation policy is an **OPEN QUESTION** (see 128-Core Scalability).
4. **Coverage model.** Functional matrix indexed by ISA extension × privilege level × interrupt/exception path, with extension-specific items conditioned on the confirmed ISA profile.
5. **Collateral reuse.** Per-core verification collateral is constructed as a single instance-independent artifact reused across all 128 instances, subject to the ASSUMPTION that the UVM/reference-model/coverage infrastructure supports parameterizable instance handles. Cross-instance scenarios are owned by the multicore verification document.
6. **Ownership.** Cross-core interactions (coherence, inter-processor interrupts, debug scan-chain fan-out, trace aggregation) are owned by the multicore verification document.
7. **Cross-cutting concerns.** The per-core document's scope over GLS, X-Prop, CDC/RDC, manufacturing scan/MBIST interaction, and security verification is an **OPEN QUESTION** and is enumerated in the Cross-Cutting Verification Concerns section. These items are not bound by this recommendation and require an explicit ownership decision before tape-out planning.

The numeric coverage thresholds, the choice of simulator and formal tool, the specific reference-model version, and the coverage-closure horizon are **OPEN QUESTIONS** and are deferred to the verification strategy document and the project's sign-off policy.

---

## Confidence

Medium. The methodology recommendation follows from established industry practice and the cited RISC-V specifications; the recommendation does not depend on the unresolved numeric thresholds. Confidence would be upgraded to High once the **OPEN QUESTIONS** below are closed.

---

## Open Questions

- What RISC-V base and extensions does XH-1 implement (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)?
- Is the core in-order or out-of-order?
- Is the 128-core array homogeneous, or are there variants (application cores plus a management/IoT core)?
- What is the XH-1 target process node, per-core area budget, clock frequency, and tape-out schedule?
- What simulator and formal-tool stack is available or mandated (commercial, Verilator, cocotb, Yosys + SymbiYosys, custom)?
- What is the project's stance on the RISC-V International compliance signing process, and at what SBI version is the platform pinned?
- What numeric coverage exit criteria (legal-bin percentage, toggle, assertion, mutation score) does the project accept for tape-out, and is mutation in or out of the sign-off artifact?
- Which RISC-V Debug Specification version (0.13 or 1.0.0) and which Trace Specification version (2.0.0 or other) apply to XH-1?
- Which verification sub-area (formal, fault injection, ISA compliance, multicore, regression, strategy, unit, DFT) consumes the artifacts produced at the core level?
- Does XH-1 implement RISC-V power-management mechanisms (WFI, custom retention states, Zihintpause), and how is energy-aware DV partitioned across the per-core and multicore documents?
- Is FPGA prototyping or emulation capacity available at the scale required to boot 128 cores?
- What is the per-instance riscv-arch-test signature policy (one per instance, one per representative instance, parameterized)?
- What are the formal proof bounds (depth, state-space width) for the ROB and other bounded sub-modules?
- What is the ownership boundary for GLS, X-Prop, CDC/RDC, and manufacturing scan/MBIST verification: per-core, multicore, or a separate physical-implementation verification document?
- What is the per-core ownership share of security verification (functional crypto correctness, side-channel resistance, fault-injection resistance, secure-boot)?

---

## Sources

- RISC-V International, *Unprivileged ISA Specification* (latest ratified). https://riscv.org/technical/specifications/
- RISC-V International, *Privileged ISA Specification* (latest ratified). https://riscv.org/technical/specifications/
- RISC-V International, *Debug Specification*, version 1.0.0. https://riscv.org/technical/specifications/
- RISC-V International, *Trace Specification*, version 2.0.0. https://riscv.org/technical/specifications/
- RISC-V International, *Vector Extension ("V") Specification*. https://riscv.org/technical/specifications/
- RISC-V International, *Cryptography Extensions* (Zkn, Zks, Zkb sub-extensions; Zk profile). https://riscv.org/technical/specifications/
- RISC-V International, *SBI Specification*. https://riscv.org/technical/specifications/
- RISC-V International, *Compliance Policy* and *Architecture Test* framework. https://github.com/riscv-arch-test
- OpenHW Group, *CV32E40P Core Documentation*. https://github.com/openhwgroup/core-cv32e40p
- OpenHW Group, *CV32E40PX Core Documentation*. https://github.com/openhwgroup/core-cv32e40px
- CHIPS Alliance / Google, *riscv-dv* (ISA-aware constrained-random instruction-stream generator). https://github.com/chipsalliance/riscv-dv
- Berkeley / RISC-V International (with SiFive contribution), *Spike* (riscv-isa-sim). https://github.com/riscv/riscv-isa-sim (no specific version pinned in this document; pinning is deferred to the verification strategy document.)
- Cambridge, *SAIL RISC-V* (architectural reference model). https://github.com/rems-project/sail-riscv
- Imperas, *riscvOVPsim* (commercial reference model). https://github.com/riscv-ovpsim
- Siemens EDA, *JasperGold* formal verification platform (product documentation). https://eda.sw.siemens.com/en-US/ic/jaspergold/
- Synopsys, *VC Formal* (product documentation). https://www.synopsys.com/verification/static-and-formal-verification/vc-formal.html
- Synopsys, *360 DV-Formal* (formerly OneSpin 360 DV; OneSpin acquired by Synopsys in 2022). https://www.synopsys.com/verification/static-and-formal-verification/360-dv-formal.html
- Synopsys, *SpyGlass CDC / RDC* (clock- and reset-domain crossing structural and formal analysis). https://www.synopsys.com/verification/static-and-formal-verification/spyglass.html
- Cadence, *JasperGold CDC* (clock-domain crossing formal verification). https://www.cadence.com/en_US/home/tools/digital-design-and-signoff/silicon-signoff/jasper-gold-cdc.html
- Siemens EDA, *Questa CDC* (clock-domain crossing analysis). https://eda.sw.siemens.com/en-US/ic/questa/
- Synopsys, *X-Prop* (X-propagation analysis). https://www.synopsys.com/verification/static-and-formal-verification/vc-formal.html
- YosysHQ, *Yosys* (open-source synthesis and formal-verification framework). https://github.com/YosysHQ/yosys
- YosysHQ, *SymbiYosys (SBY)* (open-source formal verification front-end). https://github.com/YosysHQ/sby
- YosysHQ / ABC project, *ABC* (logic synthesis and bounded model checking). https://github.com/YosysHQ/abc

`INSUFFICIENT EVIDENCE` is recorded above in the Performance, Area, Power and Energy, and Comparison sections pending the project inputs that close the corresponding **OPEN QUESTIONS**. No numeric claim in any of those sections has been fabricated.
