
         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         
{"id":"gen-1787739706-5JRlijYpTUyCneJp1Cyv","object":"chat.completion","created":1787739706,"model":"minimax/minimax-m3:free","provider":"GMICloud","system_fingerprint":null,"service_tier":null,"choices":[{"index":0,"logprobs":null,"finish_reason":"stop","native_finish_reason":"stop","message":{"role":"assistant","content":"# Core Verification\n\n## Status\n\nDRAFT — Research framework established; all claims are explicitly classified by epistemic status (FACT with citation, ASSUMPTION, PROPOSAL, RECOMMENDATION, OPEN QUESTION, or INSUFFICIENT EVIDENCE). Concrete sign-off criteria, tool selection, and quantitative thresholds are deferred until the OPEN QUESTION inputs are resolved. Example numeric thresholds in the Sign-Off section are starting points for the verification plan and are not validated targets.\n\n## Abstract\n\nThis document investigates verification strategies for the XH-1 core, defined here as a single processing core instance within a custom 128-core RISC-V processor. Core verification is the layer of the verification methodology stack concerned with demonstrating that one core conforms to its architectural specification, microarchitectural contract, and integration assumptions prior to and independent of multi-core interactions. For a 128-core design, the core is the unit of replication; defects undetected at this layer replicate 128-fold across the die, amplifying area, power, yield, and debug cost. This document frames the research questions, surveys existing approaches (simulation, formal verification, hardware-assisted verification, FPGA prototyping, emulation), analyzes their applicability to a custom RISC-V core, and identifies the gaps that the XH-1 project must close given that the existing related documents in `research/10-verification/` are placeholders (\"SOON\").\n\n## Research Question\n\nWhat verification methodology, toolchain, environment abstraction, coverage model, and sign-off criteria are appropriate for verifying a single XH-1 core such that the methodology:\n\n1. Provides evidence that the core implements the RISC-V ISA subset selected for XH-1 (see `research/10-verification/isa-compliance.md`).\n2. Provides evidence that the core's microarchitecture meets timing, area, and power targets for a design that will be replicated 128 times.\n3. Scales economically — verification effort, compute cost, and human review time must not grow linearly with the 128-core replication factor.\n4. Produces artifacts (testbenches, coverage models, formal proofs, regression suites) that compose cleanly with the surrounding verification layers (unit, multicore, system, post-silicon).\n5. Is implementable given that the related XH-1 documents in area 10 are not yet populated, indicating a greenfield verification program.\n\n## Background\n\nVerification of a processor core is conventionally decomposed into:\n\n- **Unit verification** — verification of individual blocks (ALU, FPU, register file, branch predictor, fetch/decode structures, load-store unit, replay logic, CSR file, MMU/TLB, caches). See `research/10-verification/unit-verification.md`.\n- **Core verification** — verification of the integrated core as a single design under test (DUT), exercising instruction-stream and exception behavior at the architectural interface, plus internal microarchitectural invariants.\n- **Multicore verification** — coherence, consistency, interconnect, and shared-resource correctness across multiple core instances. See `research/10-verification/multicore-verification.md`.\n\nFor XH-1, the core is the replication unit. The cost model is asymmetric under the replication-homogeneity assumption below: the marginal cost of catching a defect at the core level is lower than the marginal cost of catching it after tape-out, in silicon debug, or in the field. The phrase \"every bug caught at the core layer is caught 128 times\" is shorthand for: every defect that escapes core verification is replicated 128-fold in silicon, multiplying area, power, yield, and debug impact. The verification effort itself is paid once; the fix is paid once; the unfixed-defect cost is multiplied by the replication count.\n\n**ASSUMPTION (replication homogeneity):** The 128 XH-1 cores are architecturally identical instances of a single RTL core produced by elaboration of the same source. Heterogeneous cores, per-core configuration, or runtime variants invalidate the replication-leverage argument and require per-variant verification. This is treated as an assumption because no repository evidence contradicts it; OPEN QUESTION 6 below revisits it. Note that the formal \"per-instance cost of zero\" claim for proven properties holds for bit-identical replicated RTL; if the source is parameterized and elaborated with per-instance parameters, the proof must be re-established for any parameter set that differs, and the cost is not strictly zero.\n\n**ASSUMPTION (target implementation class):** XH-1 targets ASIC tape-out. FPGA-only deployment would change the methodology (no DFT/ATPG, different sign-off criteria, no post-silicon bring-up in the same sense). This assumption is conditional and is revisited in OPEN QUESTION 12.\n\n**ASSUMPTION (verification language availability):** The verification language of the testbench is the same as or interoperable with the design language. This is revisited in OPEN QUESTION 11.\n\nCore verification draws on several formal and semi-formal techniques:\n\n- **Dynamic simulation** with constrained-random or directed tests, against an ISA reference model, with functional coverage.\n- **Static (formal) verification** — model checking (bounded model checking, k-induction, IC3/PDR), equivalence checking (combinational and sequential), and property proving against the RTL.\n- **Hardware-assisted verification** — FPGA prototyping and emulation (commercial emulators, open-source flows such as FireSim on Amazon EC2 F1), trading compile time for runtime speed.\n- **Co-simulation** — two simulation engines running in lockstep (e.g., an RTL simulator and an architectural reference-model engine such as Spike) synchronized at defined events.\n- **Waveform and assertion-based methodologies** — SystemVerilog Assertions (SVA), PSL, custom monitors, end-of-test checkers.\n\nCoverage is a central concern. Functional coverage, code coverage (line, branch, expression, toggle, FSM), and cross-coverage of architectural state are the standard dimensions. For a custom ISA implementation, the relationship between ISA compliance coverage and microarchitectural coverage must be defined explicitly.\n\nStandard core-verification concerns that must be addressed in addition to instruction-stream behavior:\n\n- **Lint** — static analysis of RTL style, common bug patterns, and synthesizability (e.g., Verilator lint, commercial lint tools). A prerequisite to dynamic and formal work.\n- **Clock-domain crossing (CDC) and reset-domain crossing (RDC)** — analysis of signals crossing asynchronous clock or reset domains. Typically owned by a separate methodology but the core must be CDC/RDC-clean for integration.\n- **X-propagation** — controlled handling of unknown ('X) propagation in simulation, using X-pessimism removal or X-init optimization, to avoid false coverage from masked X's.\n- **Reset verification** — power-on reset, software reset, debug reset, partial reset, and reset-domain interaction.\n- **Power intent** — if power features are present (see OPEN QUESTION 7), UPF/CPF power intent formats integrate with simulation to model power-gated, retention, and isolation behavior.\n- **DFT/ATPG interaction** — scan, BIST, and MBIST structures must not alter mission-mode behavior; their interaction with the core testbench is a coordination point.\n\nThese are not optional; their absence in a verification plan is a known gap in pre-silicon methodology.\n\n## Existing Approaches\n\nThe following approaches are established in industry and academic practice. Their applicability to XH-1 is analyzed; none is recommended in isolation.\n\n### A. Constrained-Random Simulation with UVM\n\n**FACT:** Universal Verification Methodology (UVM) is standardized as IEEE 1800.2-2020, *Standard for Universal Verification Methodology Based on Accellera SystemVerilog 3.1* [IEEE 1800.2-2020], and is widely used in industrial block- and core-level processor verification for constrained-random stimulus generation, reference model integration, self-checking scoreboards, functional coverage, and phasing.\n\n**ASSUMPTION (conditional on design language):** UVM is applicable only if the XH-1 design language supports SystemVerilog class constructs — either the source is SystemVerilog, or the verification environment targets SystemVerilog regardless of source language. If the design language is Verilog-2001 only, or if the project commits to a Chisel/Spinal HDL or Bluespec-only flow, UVM is not directly applicable at the HDL-source level and an alternative testbench harness is required. This assumption is revisited in OPEN QUESTION 11.\n\n**PROPOSAL (applicability to XH-1):** Apply UVM as the primary dynamic verification environment for XH-1 core-level testing, paired with a chosen ISA reference (Spike or Sail). Sequence generation over the RISC-V ISA state space; reference model in co-simulation; scoreboard for architectural state comparison per committed instruction; explicit cover points for instruction × operand-mode × privilege × exception interactions.\n\n### B. Directed and Hand-Written Tests\n\n**FACT:** Constrained-random alone does not reach corner-case coverage of complex pipelines, corner-case CSR interactions, or rare exception sequences. Industry practice supplements with directed tests written by architects and designers.\n\n**PROPOSAL (applicability to XH-1):** A XH-1-specific directed test suite for pipeline hazard combinations specific to the XH-1 microarchitecture, corner cases in the chosen RVA profile subset, reset, wake, low-power entry/exit, and debug transport (if present at core level).\n\n### C. Formal Property Verification\n\n**FACT:** Bounded model checking, k-induction, and IC3/PDR are applied to control-dominated blocks: fetch, decode, CSR, MMU/TLB, branch predictor, retirement, and exception delivery. Commercial model checkers include Cadence JasperGold, Synopsys VC Formal, and Siemens FormalPro. Open-source flows include SymbiYosys (SBY), based on the Yosys synthesis and formal toolchain. Equivalence checking is a distinct formal category: tools include Synopsys Formality and Cadence Conformal, used to verify that two RTL representations (e.g., pre- and post-synthesis, or pre- and post-retiming) are functionally equivalent. Equivalence checkers are not model checkers and are not used for property proving.\n\n**PROPOSAL (applicability to XH-1):** Per-block formal sign-off for the control-dominated blocks listed above, end-to-end pipeline flushing, exception priority, and CSR read/write semantics. Formal proofs of privileged ISA semantics (e.g., `mstatus`, `sstatus`, `satp`, `mip`/`sip` behavior) provide a high-confidence anchor that random tests cannot match in isolation. Sequential equivalence checking between major RTL revisions is a separate, complementary activity.\n\n**ASSUMPTION (RISC-V privileged-ISA versioning):** The CSR semantics used as formal-proof targets correspond to the specific RISC-V Privileged ISA version adopted by XH-1. The unprivileged ISA, privileged ISA, and Debug specification each have versioned releases tracked by RISC-V International; the verification plan must be pinned to those versions [RISC-V International, *Unprivileged Specification*, *Privileged Specification*, *Debug Specification*].\n\n**PROPOSAL (applicability to XH-1):** Coordinate with `research/10-verification/formal-verification.md` for tool selection (commercial model checkers vs. SymbiYosys / SBY) and with `research/10-verification/isa-compliance.md` for the privileged-ISA version.\n\n### D. Co-Simulation with an ISA Reference\n\n**FACT:** Comparing DUT architectural state against Spike (the official RISC-V ISA simulator, C++ implementation) or Sail (a first-order imperative language designed for ISA specification, with a RISC-V model generated from the RISC-V ISA formal definition) per instruction is a widely deployed pattern. Spike + RTL constitutes co-simulation in the strict sense: two simulation engines synchronized at defined events. The DUT may run ahead of the reference using a deferred-check queue, with results compared at synchronization points. A single simulator that incorporates the reference model as a transactor is more accurately described as reference-model checking rather than co-simulation.\n\n**PROPOSAL (applicability to XH-1):** Required for ISA-compliance evidence. See `research/10-verification/isa-compliance.md`. Reference model parallelism is a 128-core scaling concern: Spike and Sail are single-threaded by default; running 128 reference models in lockstep with 128 RTL instances is itself a significant engineering problem. The pattern of choice is a single shared reference model servicing all DUT instances through a deferred-check queue, or sampling (multicore-layer decision) with the core testbench supporting the interface.\n\n### E. FPGA Prototyping and Emulation\n\n**FACT:** FPGA-based prototyping runs the RTL at higher throughput than software simulation, and emulation platforms (commercial: Palladium, Veloce, ZeBu; open-source: FireSim on Amazon EC2 F1) provide a middle ground. The throughput multiplier is workload- and instrumentation-dependent; published numbers for FPGA prototyping vs. software simulation range roughly from 10× to over 1000× depending on workload, Fmax, and observability overhead. Quoted multipliers are approximate and are not asserted here as specific numbers for XH-1.\n\n**PROPOSAL (applicability to XH-1):** Use FPGA prototyping to speed up core testbench bring-up by running entire test programs end-to-end, to enable fault-injection campaigns that are infeasible in simulation (see `research/10-verification/fault-injection.md`), and as the natural place to begin validating the multicore layer; core verification is the upstream prerequisite. Commercial emulation is a viable alternative for very large workloads or when observability requirements are relaxed; the decision depends on licensing posture (OPEN QUESTION 3) and workload characteristics.\n\n### F. Regression Infrastructure\n\n**FACT:** Regression management — version control of testbenches, seeds, baselines, coverage databases — is a load-bearing component of any non-trivial core verification program. See `research/10-verification/regression.md`.\n\n**PROPOSAL (applicability to XH-1):** The XH-1 regression infrastructure must support a single-core nightly run, a multicore run, and a system run with shared seeds where appropriate.\n\n### G. Coverage Closure Methodology\n\n**FACT:** Coverage closure combines functional coverage (defined by the verification plan), code coverage (uncovered RTL), and assertion coverage. Industry practice treats coverage closure as a managed funnel: cover points → cross coverage → corner case identification → directed/random test addition → formal where possible. Coverage baselines drift as RTL changes; a baseline-management policy is required.\n\n**PROPOSAL (applicability to XH-1):** Codify the funnel explicitly in the verification plan with tracked stages, baseline-management policy, and exit criteria per stage.\n\n### H. Assertion-Based Verification\n\n**FACT:** SystemVerilog Assertions (IEEE 1800-2017, *Standard for SystemVerilog*) and immediate assertions encode design intent and serve both as live checkers and as inputs to formal tools.\n\n**PROPOSAL (applicability to XH-1):** Define an SVA library for XH-1 invariants (e.g., \"no retired instruction has a privileged side effect inconsistent with its mode\", \"no speculative architectural state is observable at the architectural interface\").\n\n### I. Open-Source ISA-Level Formal Verification\n\n**FACT:** The `riscv-formal` framework (YosysHQ / Symbiotic EDA, Verilog, BSD-licensed) provides a directly applicable open-source ISA-level formal verification flow for RISC-V cores, consisting of a checkable RISC-V ISA specification encoded as a set of formal properties that are conjoined with a wrapper around the DUT and discharged by an SMT solver. The Kami project (Cambridge) provides an alternative formal RISC-V ISA specification in Coq with a Bluespec front-end; the project documentation and the publication by the Kami team should be cited from the project's own canonical sources rather than from a secondary attribution.\n\n**PROPOSAL (applicability to XH-1):** Evaluate `riscv-formal` as a complement to block-level formal. It directly targets ISA-compliance evidence with open-source tooling and is particularly relevant given the greenfield status of the XH-1 verification program.\n\n### J. Open-Source Constrained-Random Generator\n\n**FACT:** Google's `riscv-dv` is an open-source UVM-based constrained-random instruction-stream generator for RISC-V, widely used in industrial and academic flows. The license should be confirmed against the current repository state at the time of toolchain selection; this document does not assert a specific license version.\n\n**PROPOSAL (applicability to XH-1):** Evaluate `riscv-dv` as a generator either within a UVM environment or as a stimulus source for a lightweight harness.\n\n## Alternative Designs\n\nThe following alternative *strategies* for the core verification methodology itself are candidates for XH-1. They are not mutually exclusive; the project must select a composition.\n\n### Alternative 1: UVM-Centric with Formal Supplements\n\n- **Approach:** UVM as the workhorse for dynamic verification, with formal applied to control-dominated blocks.\n- **Strengths:** Industry-standard tooling, well-understood coverage and sign-off conventions, mature ecosystem; integrates with `riscv-dv` as a generator and `riscv-formal` as an ISA-level formal layer.\n- **Weaknesses:** UVM has a steep learning curve and high setup cost. For a 128-core design, the UVM environment must be designed for reuse to avoid 128× rewrite cost. Requires SystemVerilog (OPEN QUESTION 11).\n\n### Alternative 2: Lightweight Python/C++ Test Harness with Spike Co-Simulation\n\n- **Approach:** A generator produces instruction streams and a C++ testbench (e.g., based on cocotb, Verilator, or a custom framework) compares architectural state against Spike.\n- **Strengths:** Lower setup cost than UVM. Excellent generator productivity. Easy integration with regression infrastructure. Open-source-friendly. `riscv-dv` can serve as the generator. Verilator-based flows are not bound to SystemVerilog UVM at the source level.\n- **Weaknesses:** Less mature scoreboard/reuse infrastructure than UVM. Coverage closure tooling is less standardized.\n- **Application to XH-1:** Reasonable choice if XH-1 has a small team, an open-source toolchain preference, or a constraint on commercial EDA licensing.\n\n### Alternative 3: Formal-First\n\n- **Approach:** Formal proofs form the primary verification evidence; dynamic simulation is used for reach and to validate properties that formal cannot discharge.\n- **Strengths:** Highest assurance per proven property. Strong fit for control logic and CSR behavior. `riscv-formal` provides a directly applicable open-source ISA-level formal layer. Under the replication-homogeneity assumption, proven properties hold for all 128 instances at near-zero marginal cost (modulo parameter-set caveats in the Background assumption).\n- **Weaknesses:** Pipeline formalization is hard. State-space complexity grows combinatorially for large cores. May not reach proof closure on timing-agnostic models without abstraction. Inconclusive results are not equivalent to failure; risk-acceptance must be tracked.\n\n### Alternative 4: Emulation-Centric\n\n- **Approach:** Skip large-scale software simulation; use FPGA/emulation throughput as the primary engine.\n- **Strengths:** Excellent long-workload capability; native fault-injection support.\n- **Weaknesses:** Poor waveform/observability; slow compile/turnaround; harder to drive corner-case stimulus; debug cycle is slow.\n\n### Alternative 5: Hybrid (PROPOSAL — See Proposed Direction)\n\nA combination of a dynamic framework (Alternative 1 or Alternative 2) for stimulus and reach, formal supplements (Alternative 3, including `riscv-formal` where applicable) for control logic, and FPGA prototyping/emulation for throughput and multicore bring-up.\n\n## Comparison\n\nThe comparison is qualitative and is intended to make the trade-offs explicit, not to produce a numeric ranking. INSUFFICIENT EVIDENCE exists to rank absolute quality without XH-1-specific RTL data, tool licensing posture, and team size. The Hybrid column is a composition of the others and is not an independent point of comparison; the table is structured to show how each pure strategy performs on the dimensions, with the Hybrid column indicating how the strengths compose.\n\n| Dimension | UVM-Centric | Lightweight Harness | Formal-First | Emulation-Centric | Hybrid |\n|---|---|---|---|---|---|\n| Setup cost | High | Low | High | Medium | High |\n| Per-test runtime | Slow | Slow–Medium | N/A (proof time) | Fast | Mixed |\n| Corner-case reach | Strong (with seeds) | Strong (with fuzzing) | Strong (when discharged) | Weak–Medium | Strong |\n| Assurance on control logic | Medium | Medium | High | Low–Medium | High |\n| Debug ergonomics | Good (waveform, logs) | Good | Strong counterexamples | Weak | Mixed |\n| Open-source viability | Medium (UVM IEEE 1800.2 is open; simulators are usually commercial) | Strong | Medium | Medium | Medium |\n| Fit for 128-core reuse | High (if designed so) | High (if designed so) | High (under replication homogeneity) | High | High |\n| Pre-tape-out risk reduction | Strong | Medium–Strong | Strong (partial; inconclusive ≠ proven) | Medium | Strong |\n\n## Advantages\n\nThe advantages of investing in a robust core verification methodology for XH-1:\n\n- **Replication leverage.** Under the replication-homogeneity assumption, an unfixed defect in the core RTL is replicated 128-fold in silicon. The cost-leverage argument is about the cost of escaping defects, not about replicated verification effort: verification is performed once, the defect (if found) is fixed once, and the fixed RTL is then replicated. The benefit of core-level detection is the avoidance of multiplied post-silicon cost.\n- **Cleaner multicore verification.** A well-verified core reduces the multicore verification problem to coherence, consistency, interconnect, and shared resources. See `research/10-verification/multicore-verification.md`.\n- **Foundation for post-silicon.** First-stage silicon bring-up is dramatically simpler when the core is well-understood and the debug interfaces (assertions, traces, scan) are well-designed. Post-silicon validation feeds back into pre-silicon coverage targets; this feedback loop is not detailed in this document and is left to the post-silicon layer.\n- **Reusable testbench assets.** Generator, scoreboard, coverage model, and SVA library can be reused across cores if XH-1 has core variants, or across revisions of the same core.\n- **Formal evidence on critical control.** Privileged ISA semantics are hard to verify by random simulation; formal proofs on these blocks provide a high-confidence floor.\n\n## Disadvantages\n\nCosts and risks of a robust core verification program:\n\n- **Engineering cost.** A UVM-class environment plus formal plus emulation is a substantial program. The claim that it \"can easily exceed the RTL design cost for a single core\" is folkloric and is presented here as a planning consideration, not as a measured fact.\n- **Tooling lock-in.** Heavy UVM usage often implies commercial simulator licensing; this may not match XH-1's tool posture. Formal tool lock-in is similar: commercial model checkers differ in property language and run scripts.\n- **Slow turnaround.** Constrained-random simulation with full coverage at the core level is slow; coverage closure can take many cycles of \"add test, rerun, close hole\". Coverage baselines drift with RTL changes, requiring re-establishment.\n- **Reference model dependence.** Spike, Sail, or any reference may diverge from the RISC-V specification in interpretation of ambiguous or profile-specific corners; the verification program must track the chosen RVA profile carefully and pin the spec version of the reference.\n- **Coverage false confidence.** Hitting a cover point is not the same as proving correctness; the verification plan must distinguish cover and check.\n- **128-core replication pressure.** If the core testbench is not designed to compose with the multicore testbench, redundant effort emerges.\n- **Inconclusive formal ≠ proven.** Formal results of \"inconclusive\" must be risk-accepted, not treated as success.\n- **Equivalent mutants.** Mutation-kill rates are affected by equivalent mutants (mutations that produce behaviorally identical RTL); kill-rate targets are therefore noisy and must be interpreted with caution.\n\n## XH-1 Considerations\n\nXH-1-specific factors that constrain the methodology choice:\n\n- **128-core replication.** The verification plan must be replication-aware: the *testbench* should be agnostic to whether one or 128 cores are instantiated. This implies strong separation of (a) the core DUT, (b) the core testbench, and (c) the multicore wrapper.\n- **Custom design.** No third-party core is being verified; there is no vendor's pre-built verification IP. All environments must be built or assembled.\n- **Repository context.** The related verification documents are all placeholders (\"SOON\"). This is a greenfield verification program; the XH-1 project has the opportunity — and the burden — to define the methodology from first principles.\n- **RISC-V ISA.** The RISC-V ecosystem provides mature reference models (Spike, Sail), compliance / architectural test frameworks (`riscv-tests`, `riscv-arch-test`), and open-source verification tooling (`riscv-formal`, `riscv-dv`). These are the natural anchors.\n- **Tool posture (OPEN QUESTION 3).** Without evidence in the repository, the project's tool posture (open-source only, commercial EDA, mixed) is OPEN. The methodology composition must remain valid across posture choices.\n- **Design language (OPEN QUESTION 11).** The choice of design language — SystemVerilog, traditional Verilog, Chisel/Spinal HDL, Bluespec — has direct implications for verification methodology (e.g., formal property availability on generated RTL, simulation throughput, the place of unit-level testing at the HDL-source level vs. the generated-RTL level, and the applicability of UVM at the source level). This is OPEN pending XH-1 design-language disclosure. Section A's UVM assumption is conditional on this resolution.\n- **Microarchitectural class (OPEN QUESTION 2).** The pipeline class — in-order vs. out-of-order, superscalar width, depth of speculation, branch-prediction aggressiveness — materially changes the cost-benefit of formal vs. dynamic and the complexity of pipeline flush / replay verification. The methodology composition must accommodate both extremes.\n- **Power architecture (OPEN QUESTION 7).** Whether the core supports clock gating, power gating, retention, and/or DVFS is OPEN. The verification methodology must accommodate each combination. Assuming any specific power feature is invalid without evidence. Power intent (UPF/CPF) integration is conditional on this.\n- **Target implementation class (OPEN QUESTION 12).** Whether XH-1 targets ASIC tape-out or FPGA-only deployment fundamentally changes the verification methodology (DFT/ATPG scope, post-silicon layer, sign-off criteria). Treated here as an assumption (ASIC) pending resolution.\n\n## 128-Core Scalability\n\nReplication does not change which verification techniques apply to a single core, but it changes their cost-benefit and their composition.\n\n- **Core testbench scalability.** A core testbench written for a single instance must be instantiable inside a multicore wrapper without modification. This implies the testbench interfaces to the core through a standard transaction-level interface (or at least a clearly defined boundary), not through global signals.\n- **Cost-benefit of formal at replication.** Per-block formal verification has high fixed cost but, under bit-identical replication, a per-instance marginal cost of zero for the proven properties: once a control property is proven, it holds for every replicated instance of the same RTL. If the source is parameterized and elaborated with per-instance parameters, the proof must be re-established for any parameter set that differs. Under the replication-homogeneity assumption, formal's per-die marginal cost decreases as the replication count increases. The opposite is true for dynamic simulation at full coverage: a per-instance simulation cost must be paid for each replicated instance if all instances are to be exercised at full coverage, though the wall-clock growth is not strictly linear (the simulator elaborates and runs them in the same run, and the per-instance cost is amortized across the simulation kernel). The trade-off is a primary argument for the hybrid approach at 128-core scale, and the practical mitigation is sampling, not full per-instance coverage.\n- **Workload scaling.** Running the full core testbench in a 128-core environment is generally unnecessary; sampling (verify a subset of cores under full stimulus, sweep register state across all 128) is a more efficient pattern. The sampling strategy is a multicore concern but must be supported by the core testbench's reset/configuration interface. The statistical argument for the chosen sampling fraction (defect-escape probability vs. simulation cost) is a multicore-layer deliverable; the core testbench must support the interface.\n- **Coverage aggregation.** Per-core coverage data must be aggregated across the 128 instances. The core testbench should emit coverage in a form that is identifiable by instance index.\n- **Debug bandwidth.** 128 cores each generating waveform/log data is impractical. The core testbench must distinguish between detailed-trace mode (one core, full visibility) and lightweight-trace mode (128 cores, summary only).\n- **Compile and elaboration cost.** Elaboration of a 128-core testbench can dominate runtime. The core testbench should be elaborable standalone and in a multicore wrapper without recompiling the core RTL. Elaboration-time behavior (reset, clock tree, memory subsystem) can differ between 1-core and 128-core contexts; the core testbench must be valid in both.\n- **Testbench memory footprint.** 128 instances of a complex scoreboard and 128 reference models can dominate host memory. Memory-aware testbench design (shared reference models, deferred-check queues, summary-only trace mode) is required. This is acknowledged here and detailed in the multicore layer.\n- **Reference-model parallelism.** Spike and Sail are single-threaded by default. Running 128 reference models in lockstep with 128 RTL instances is a significant engineering problem. The recommended pattern is a single shared reference model servicing all DUT instances through a deferred-check queue, or sampling. This is a multicore-layer design constraint that the core testbench interface must support.\n- **Symmetry assumption revisit.** The replication-homogeneity assumption is load-bearing throughout this section. Heterogeneous cores (e.g., big/little, mixed application/accelerator, per-core ISA-subset configuration) invalidate the per-die marginal-cost argument and require per-variant verification, including per-variant testbenches, per-variant coverage, and per-variant formal. The methodology should be designed so that the additional cost of a variant is linear in the number of variants, not linear in 128 × variants.\n\n## Performance Considerations\n\nThe following are framework-level considerations. INSUFFICIENT EVIDENCE exists to provide numerical throughput estimates without XH-1-specific RTL data, simulator choice, and toolchain selection; any specific number is unsourced and is therefore not asserted here.\n\n- **Testbench throughput.** Dynamic simulation throughput determines how many random seeds can be run per unit wall-clock. Constrained-random at the core level is sensitive to simulator choice, RTL abstraction level, and coverage instrumentation; representative numbers are available in vendor documentation (commercial simulators) and in the open-source Verilator and cocotb benchmark literature, but are workload-dependent and cannot be quoted as typical without measurement on the XH-1 DUT.\n- **Compiler/optimizer.** Coverage instrumentation slows simulation. Production coverage runs and fast-turnaround debug runs should be separable.\n- **Co-simulation overhead.** Spike co-simulation overhead per committed instruction is non-trivial. Synchronization strategy (per-instruction vs. batched) is a tradeoff between debug granularity and throughput. At 128 instances, the cost of a per-instruction synchronization across all instances is prohibitive; batched or sampled synchronization is the practical pattern.\n- **FPGA prototype throughput.** FPGA prototype throughput is set by Fmax, which is determined by LUT count, routing, and the memory subsystem. Quoted MHz figures for an XH-1 core on a specific FPGA platform are not asserted here.\n- **Regression wall-clock budget.** A nightly regression that runs N seeds on a single core must fit within the available compute budget. Cloud burst capacity is typical.\n\nINSUFFICIENT EVIDENCE to provide numerical throughput estimates without XH-1-specific RTL data and toolchain selection.\n\n## Area Considerations\n\n- **On-die verification infrastructure.** XH-1 is described as a 128-core design. The verification *methodology* does not directly consume die area, but decisions made during verification (e.g., embedding assertions in RTL, adding observability muxes for trace, adding per-core DFT structures) do.\n- **Trace and debug infrastructure.** Core-level verification informs the design of trace, performance counters, and debug-transport blocks. Larger trace infrastructure costs area; the verification program must justify the cost in terms of debug productivity and post-silicon coverage.\n- **DFT (Design-for-Test) compatibility.** Scan chains, BIST, and MBIST are typically owned by a separate DFT program. Core verification should ensure that the core's DFT structures do not alter functional behavior in mission mode. If XH-1 is FPGA-only (OPEN QUESTION 12), DFT is out of scope.\n- **Replication-driven area optimization.** If the core's area is a major constraint (which is likely at 128 cores on a single die), the verification plan must protect against defects that would force a re-spin with re-spinned core area.\n\nINSUFFICIENT EVIDENCE to quantify area without access to XH-1's core area budget or process node.\n\n## Power and Energy Considerations\n\nThe following considerations apply **if and only if** XH-1 implements the corresponding power features. Each is OPEN QUESTION 7-conditional.\n\n- **Power-aware verification (conditional).** If the core supports power gating or retention, the core testbench must be able to drive representative switching activity to enable power estimation, and the testbench must verify that power-gated domains behave correctly (controlled wake, retention restore, ordering with respect to coherence traffic). UPF/CPF power intent integration with the simulator is the standard mechanism.\n- **Energy proportionality (conditional).** If the core supports clock gating at the instruction or block level, the testbench should verify that idle and active transitions behave correctly at the architectural interface (no observable state loss in idle, correct wake on interrupt).\n- **Thermal and DVFS interactions (conditional).** If XH-1 supports DVFS at the core level, voltage/frequency transitions and their effects on memory coherence, pipeline flush behavior, and CSR access must be verified. This is a cross-cutting concern between core and system verification.\n- **Power estimation accuracy.** Pre-silicon power estimation depends on workload realism. A core testbench that only runs synthetic random code will produce misleading power numbers.\n\nNo power feature is assumed. Verification provisions for any power feature must be activated only when OPEN QUESTION 7 is resolved.\n\n## Implementation Considerations\n\n- **Methodology composition.** The project must select one of the alternative strategies (or a hybrid) and codify it in the verification plan.\n- **Toolchain selection.** Open-source (Verilator, cocotb, SymbiYosys, `riscv-formal`, `riscv-dv`, Spike, RISCV-ISAC, GTKWave) vs. commercial (Synopsys VCS, Cadence Xcelium, Siemens Questa, JasperGold, VC Formal, FormalPro, Formality, Conformal, Palladium, Veloce, ZeBu) is a strategic decision. The choice cascades through licensing, hiring, training, and CI. These categories are not equivalent in role: Verilator and cocotb are simulation/cosim frameworks; SymbiYosys is a formal-verification flow; `riscv-formal` is an ISA-level formal property set; `riscv-dv` is a stimulus generator; RISCV-ISAC is a coverage tool; commercial emulators are hardware-assisted verification platforms distinct from FPGA prototyping. The choice within each role is independent.\n- **Reference model choice.** Spike (C++, instruction-accurate) vs. Sail (first-order imperative ISA-specification language with a RISC-V model) vs. a custom golden model. Spike is the most common reference; the project must document any corner-case behaviors of the chosen reference against the RISC-V specification.\n- **Coverage database.** Coverage data are stored in vendor-specific formats (e.g., Synopsys UCDB / DDC, Cadence IMC, Siemens UCDB) and may be aggregated into a custom backend (e.g., SQLite) for CI. The format is a tool-vendor concern; the aggregation backend is a CI concern. These are distinct choices.\n- **Test categorization.** Tests must be tagged by domain (base integer, M-ext, A-ext, F/D-ext, privileged, vector, …), by intent (sanity, corner, regression, performance), and by status (passing, known-fail, expected-fail).\n- **Seed management.** Random seeds should be reproducible. Seed pools should be partitioned into \"core regressions\", \"block regressions\", and \"fuzzing\".\n- **Bring-up sequencing.** Block-level → core-level → multicore → system. The core testbench is the transition point between block-level and system-level work.\n\n## Sign-Off Criteria\n\nA core verification sign-off is the point at which the methodology exits the coverage-closure funnel. The following are candidate criteria; numeric thresholds are starting examples to be refined in the verification plan and are not validated targets. The relationship to DRAFT status is explicit: the numbers below are illustrative starting points, not sign-off-ready thresholds.\n\n- **Functional coverage.** All defined cover points hit, with cross-coverage exercised. Threshold starting example: ≥ 95% cover-point hit, ≥ 90% cross-coverage hit; remaining items must be justified as unreachable or formally proven. Final threshold to be set in the verification plan.\n- **Code coverage.** Statement, branch, expression, toggle, and FSM coverage reported; excluded regions justified. Threshold starting example: ≥ 95% statement, ≥ 90% branch, with manual exclusion of reset/DFT/clock-gating logic. Final threshold to be set in the verification plan.\n- **Assertion coverage.** All SVA / immediate assertions vacuously satisfied or actively proven; assertion cover points hit. Open assertions must be reviewed and dispositioned.\n- **Formal closure.** Per-block formal sign-off, with proof closure recorded for each property. Inconclusive results must be either strengthened (via abstraction / decomposition) or accepted with risk justification; \"inconclusive\" is not equivalent to \"proven\".\n- **ISA compliance evidence.** All applicable tests in `riscv-arch-test` (the architectural test framework) and `riscv-tests` (the legacy compliance suite) pass. Signed certificate or equivalent record retained.\n- **Mutation testing.** Periodic injection of known-defect mutations into a frozen RTL revision; mutation-kill rate as a starting example: ≥ 80% of injected mutations detected by the testbench + assertions + formal. This number is a starting point and requires empirical validation on the XH-1 DUT. Equivalent-mutant handling (mutations that produce behaviorally identical RTL) must be defined; kill-rate targets are noisy and must be interpreted with caution. Final threshold and operator set to be set in the verification plan.\n- **Reference model validation.** Spike or Sail validated against the chosen RISC-V compliance tests before being used as a checker; validation evidence archived.\n- **Testbench self-check verification.** Every scoreboard check has at least one negative test that is expected to fail.\n- **Reproducibility.** Every sign-off run is reproducible from committed source, seed, and tool version.\n- **CDC/RDC closure.** CDC and RDC analysis clean for all core-level crossing structures.\n- **Lint clean.** Lint clean at the policy-defined severity level.\n- **Reset verification.** All reset domains and reset sequences verified; reset recovery verified.\n\n## Verification Considerations\n\nCore verification is itself subject to verification — the verification of the verification environment:\n\n- **Testbench self-checking.** All scoreboard checks must be end-of-test verifiable; every check should be paired with at least one negative test that is expected to fail.\n- **Reference model validation.** The reference model (Spike, Sail) must be validated against the chosen RISC-V compliance tests before being used as a checker.\n- **Coverage sanity.** Cover points must be reviewed to ensure they are not trivially self-firing.\n- **Mutation testing.** A subset of RTL defects should be intentionally injected to confirm the testbench catches them. See `research/10-verification/fault-injection.md`. Equivalent-mutant handling must be defined.\n- **Coverage baseline stability.** Coverage baselines drift as RTL changes; a baseline-management policy (when a baseline is re-established, by whom, with what approval) is required.\n- **Tool qualification.** If the verification tools are used in any safety-relevant context, tool qualification (per ISO 26262, IEC 61508, DO-254, or similar) is required. The applicability of these standards to XH-1 is OPEN QUESTION 8. Tool qualification is a verification-of-verification concern, not only a sign-off checkbox.\n- **Version control and baselines.** Every test run must be reproducible from committed source. Coverage baselines must be versioned.\n- **Testbench verification at 128-instance scale.** The testbench itself has bugs. Verification of the testbench (negative tests, mutation of the testbench, equivalence of testbench revisions) is part of the methodology. At 128 instances, the testbench's own correctness becomes a non-trivial verification problem and is acknowledged here as a multicore-layer concern that the core testbench interface must support.\n\n## Software Considerations\n\n- **Toolchain integration.** The core verification environment must integrate with the software toolchain (compiler, assembler, linker, Spike, debug server) to enable co-simulation and to run real programs.\n- **Firmware.** Firmware that runs on the core (boot code, exception handlers, interrupt dispatchers) is itself verification target; the core testbench should support loading and running firmware images.\n- **Operating system implications.** A core that supports an OS (Linux, RTOS) must be verified with syscall-heavy workloads. The core testbench should provide OS-aware run modes.\n- **Debug and trace protocols.** The core's debug-transport module (per the RISC-V Debug specification) must be exercised. JTAG or cJTAG interactions with the core's debug module are typically a core-level concern.\n- **Performance analysis tools.** Tools that analyze trace data, performance counters, and profile information should be able to consume the artifacts the core testbench produces.\n- **Software developer ergonomics.** The verification team's interfaces (test writers, coverage reviewers) should be ergonomic. A \"developer can run a single test and see results in under a minute\" goal is a useful operational target.\n\n## Security Considerations (Out of Scope, but Flagged)\n\n**ASSUMPTION (out-of-scope for this revision):** Transient-execution / side-channel verification (e.g., Spectre-class, Meltdown-class, and constant-time verification) is treated as out of scope for the XH-1 core verification layer for this revision. For a 128-core design with privilege boundaries, this is a real and high-risk concern. This is flagged as a high-risk gap and as a candidate for a follow-up document. The current methodology is sufficient for functional and microarchitectural correctness but does not, by itself, provide security assurance.\n\n## Proposed Direction\n\nPROPOSAL — A **hybrid methodology** for XH-1 core verification, with the following structure:\n\n1. **Dynamic simulation** as the primary verification engine, with the framework (UVM vs. lightweight) gated on OPEN QUESTION 3 (tool posture), OPEN QUESTION 4 (team size and timeline), and the design-language choice (OPEN QUESTION 11).\n   - If UVM: pair with `riscv-dv` as the instruction-stream generator and Spike or Sail as the reference model.\n   - If lightweight: pair `riscv-dv` (or a custom generator) with cocotb / Verilator and Spike.\n2. **Formal verification** applied to control-dominated blocks: fetch, decode, CSR file, MMU/TLB, exception/interrupt delivery, and the debug module. Coordinate with `research/10-verification/formal-verification.md` for tool selection. Apply `riscv-formal` as an ISA-level formal layer where the open-source flow is in scope. Sequential equivalence checking between major RTL revisions is a complementary activity.\n3. **Co-simulation against a RISC-V reference model** (Spike or Sail) for ISA-compliance evidence. Coordinate with `research/10-verification/isa-compliance.md`. Pin the RISC-V ISA, Privileged ISA, and Debug spec versions. At 128 instances, use a shared reference model with a deferred-check queue or sampled synchronization.\n4. **Directed tests** for XH-1 microarchitectural corner cases that random cannot reach economically. The corner cases to target are conditional on the in-order / out-of-order answer in OPEN QUESTION 2.\n5. **FPGA prototyping** for throughput-driven verification and as a substrate for fault injection and multicore bring-up. Commercial emulation is a conditional alternative based on licensing posture (OPEN QUESTION 3) and workload.\n6. **Regression infrastructure** with version-controlled seeds, baselines, and coverage data. Coordinate with `research/10-verification/regression.md`.\n7. **Coverage closure** as an explicit, tracked funnel with the sign-off criteria in the Sign-Off Criteria section, including baseline-management policy. Numeric thresholds are deferred to the verification plan and the numbers in the Sign-Off section are starting examples, not validated targets.\n8. **Reusable testbench architecture** so the core testbench composes inside the multicore testbench without modification, supporting both the per-die cost argument and the sampling strategy. The interface must support shared reference models, summary-only trace mode, and per-instance coverage identification.\n9. **Mutation testing** as a periodic check that the testbench is still doing useful work, with explicit equivalent-mutant handling. Coordinate with `research/10-verification/fault-injection.md`.\n10. **Standard core-verification adjuncts:** lint, CDC/RDC analysis, X-propagation handling, reset verification, and (conditional on OPEN QUESTION 7) UPF/CPF power-intent integration.\n\nThe hybrid is proposed; the specific framework within the hybrid (UVM vs. lightweight) is gated on OPEN QUESTION 3, OPEN QUESTION 4, and OPEN QUESTION 11, and the power-feature sub-portion is gated on OPEN QUESTION 7. The implementation-class sub-portion (DFT/ATPG scope, post-silicon layer) is gated on OPEN QUESTION 12. The document does not pick between alternatives that the OPEN QUESTIONS do not yet support.\n\n## Confidence\n\n- **High confidence:** The general methodology composition (dynamic + formal + co-simulation + directed + prototype + regression + coverage closure, with the standard adjuncts: lint, CDC/RDC, X-propagation, reset) corresponds to the IEEE 1800.2 UVM standard, the IEEE 1800 SystemVerilog assertion subset, and the RISC-V International published ISA / Privileged / Debug specifications, and is broadly accepted in industrial practice. The references supporting each component are cited at the point of use.\n- **High confidence (conditional):** The 128-core scaling argument (formal has near-zero per-instance marginal cost under bit-identical replication homogeneity; dynamic at full coverage has per-instance cost) is a direct consequence of the replication-homogeneity assumption and does not require empirical data. The parameter-set caveat (re-elaboration for differing parameters) is acknowledged.\n- **Medium confidence:** Specific tool selections, sign-off numeric thresholds, and area/power tradeoffs, given the absence of repository evidence on the OPEN QUESTIONS.\n- **Low confidence (OPEN):** XH-1's tool licensing posture, core microarchitecture details, ISA profile selection, team size, design language, power architecture, and target implementation class. These drive the specifics within the proposed hybrid.\n\n## Open Questions\n\n1. What RISC-V profile does the XH-1 core implement? Candidate RISC-V profiles are defined against a base XLEN: e.g., RVA23U64 / RVA23S64 are 64-bit application / supervisor profiles, while a 32-bit core would follow a different profile track (e.g., RVA22U32). The reference model (Spike variant, Sail configuration) and the compliance test scope follow from this choice.\n2. Is the XH-1 core in-order or out-of-order? The verification plan complexity differs substantially. The instructions explicitly disallow assuming either without repository evidence.\n3. What is XH-1's toolchain posture (open-source only, commercial EDA, mixed)?\n4. What is the team size and timeline? Methodology cost scales with team capacity.\n5. What is the core's microarchitectural contract — what blocks are in scope for unit verification, and what is the boundary between core and multicore? See `research/10-verification/unit-verification.md` and `research/10-verification/multicore-verification.md`.\n6. Are the 128 cores architecturally identical, or are there variants (big/little, mixed application/accelerator, per-core ISA-subset configuration)? Heterogeneity changes the testbench architecture and invalidates the per-die cost-leverage argument.\n7. What is the core's power architecture — is clock gating, power gating, retention, or DVFS at the core level, and what are the state-retention semantics?\n8. What is XH-1's relationship to functional safety standards (ISO 26262, IEC 61508, DO-254, or none)?\n9. How will the XH-1 core's trace, debug, and performance-counter interfaces be designed, and how will core verification consume them?\n10. What is the expected defect rate target at tape-out, and how does the verification program demonstrate closure against that target?\n11. What is the XH-1 design language (SystemVerilog, Verilog-2001, Chisel/Spinal HDL, Bluespec), and does verification target the HDL source level, the generated-RTL level, or both?\n12. What is XH-1's target implementation class — ASIC tape-out, FPGA-only deployment, or both? This determines DFT/ATPG scope, post-silicon validation depth, and sign-off criteria.\n13. What physical implementation tool flow (synthesis, PnR, timing) is envisioned, and what are the timing-closure constraints (target clock frequency, slack budget)?\n\n## Sources\n\n- IEEE 1800.2-2020, *Standard for Universal Verification Methodology Based on Accellera SystemVerilog 3.1*. Defines UVM.\n- IEEE 1800-2017, *Standard for SystemVerilog — Unified Hardware Design, Specification, and Verification Language*. Defines SVA and immediate assertions.\n- RISC-V International, *The RISC-V Instruction Set Manual, Volume I: Unprivileged Architecture* (versioned).\n- RISC-V International, *The RISC-V Instruction Set Manual, Volume II: Privileged Architecture* (versioned).\n- RISC-V International, *RISC-V External Debug Support* (versioned).\n- RISC-V International, *RISC-V Profiles* (versioned, e.g., RVA23).\n- Symbiotic EDA / YosysHQ, *SymbiYosys* documentation (open-source formal verification flow).\n- `riscv-formal` framework (Verilog, BSD-licensed), maintained at github.com/YosysHQ/riscv-formal.\n- `riscv-dv` instruction-stream generator, maintained at github.com/google/riscv-dv.\n- `riscv-tests` and `riscv-arch-test`, maintained by RISC-V International.\n- Spike (the official RISC-V ISA simulator), maintained at github.com/riscv-software-src/riscv-isa-sim.\n- Sail RISC-V formal specification, maintained at github.com/rems-project/sail. Sail is a first-order imperative ISA-specification language; the RISC-V model is generated from the RISC-V ISA formal definition.\n- Kami project (Cambridge), formal RISC-V ISA specification in Coq with a Bluespec front-end. Project publications and documentation should be cited from the project's own canonical sources.\n\nQuantitative throughput, area, power, and timing claims are not asserted in the body. The XH-1 repository documents referenced (under `research/10-verification/`) are placeholders (\"SOON\") and do not provide factual content to cite. No measurements, benchmarks, processor capabilities, URLs outside the repositories named above, or experimental results have been invented.","refusal":null,"reasoning":null}}],"usage":{"prompt_tokens":11757,"completion_tokens":11041,"total_tokens":22798,"cost":0,"is_byok":false,"prompt_tokens_details":{"cached_tokens":135,"cache_write_tokens":0,"audio_tokens":0,"video_tokens":0},"cost_details":{"upstream_inference_cost":0,"upstream_inference_prompt_cost":0,"upstream_inference_completions_cost":0},"completion_tokens_details":{"reasoning_tokens":0,"image_tokens":0,"audio_tokens":0}}}