# Core Verification

## Status

DRAFT — Initial framework established. Detailed methodologies, quantitative thresholds, and tool selections to be expanded in subsequent revisions.

## Abstract

This 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").

## Research Question

What verification methodology, toolchain, environment abstraction, coverage model, and sign-off criteria are appropriate for verifying a single XH-1 core such that the methodology:

1. Provides evidence that the core implements the RISC-V ISA subset selected for XH-1 (see `research/10-verification/isa-compliance.md`).
2. Provides evidence that the core's microarchitecture meets timing, area, and power targets for a design that will be replicated 128 times.
3. Scales economically — verification effort, compute cost, and human review time must not grow linearly with the 128-core replication factor.
4. Produces artifacts (testbenches, coverage models, formal proofs, regression suites) that compose cleanly with the surrounding verification layers (unit, multicore, system, post-silicon).
5. Is implementable given that the related XH-1 documents in area 10 are not yet populated, indicating a greenfield verification program.

## Background

Verification of a processor core is conventionally decomposed into:

- **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`.
- **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.
- **Multicore verification** — coherence, consistency, interconnect, and shared-resource correctness across multiple core instances. See `research/10-verification/multicore-verification.md`.

For XH-1, the core is the replication unit. A defect that escapes core verification manifests in 128 instances. The cost model is therefore asymmetric: the marginal cost of catching a bug at the core level is far lower than the marginal cost of catching it after tape-out, in silicon debug, or in the field across 128 cores.

Core verification draws on several formal and semi-formal techniques:

- **Dynamic simulation** with constrained-random or directed tests, against an ISA reference model, with functional coverage.
- **Static (formal) verification** — model checking, equivalence checking, property proving against the RTL.
- **Hardware-assisted verification** — FPGA prototyping and emulation, trading compile time for runtime speed.
- **Co-simulation** — RTL plus architectural performance/functional models run in lockstep.
- **Waveform and assertion-based methodologies** — SystemVerilog Assertions (SVA), PSL, custom monitors, end-of-test checkers.

Coverage 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.

## Existing Approaches

The following approaches are established in industry and academic practice. Their applicability to XH-1 is analyzed; none is recommended in isolation.

### A. Constrained-Random Simulation with UVM

**FACT:** Universal Verification Methodology (UVM) is the dominant industry standard for block- and core-level verification of processor designs. It provides constrained-random stimulus generation, reference model integration, self-checking scoreboards, functional coverage, and phasing.

**ASSUMPTION:** UVM-class libraries and SystemVerilog support are available in the XH-1 toolchain. This is standard for commercial simulators and most academic flows.

**Application to core verification:**
- Sequence generation over the RISC-V ISA state space.
- Reference model: an instruction-accurate golden model (e.g., Spike, Sail, or a custom RV reference) running in co-simulation.
- Scoreboard: architectural state comparison per committed instruction.
- Coverage: explicit cover points for instruction × operand-mode × privilege × exception interactions.

**PROPOSAL:** Use UVM as the primary dynamic verification environment for XH-1 core-level testing, paired with a chosen ISA reference.

### B. Directed and Hand-Written Tests

**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.

**Application:** A XH-1-specific directed test suite for:
- Pipeline hazard combinations specific to the XH-1 microarchitecture.
- Corner cases in the chosen RVA23 (or other) profile subset.
- Reset, wake, low-power entry/exit.
- Debug transport (if present at core level).

### C. Formal Property Verification

**FACT:** Bounded model checking and induction-based proofs are applied pervasively to control-dominated blocks: fetch, decode, CSR, MMU/TLB, branch predictor, retirement, exception delivery.

**Application to XH-1:**
- Per-block formal sign-off for the blocks listed above.
- End-to-end pipeline flushing, exception priority, and CSR read/write semantics.
- For a custom RISC-V core, 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.

**FACT:** The related document `research/10-verification/formal-verification.md` exists as a placeholder, indicating formal is planned. Coordinate with that document for tool selection (commercial model checkers vs. open-source options such as SymbiYosys / SBY).

### D. Co-Simulation with an ISA Reference

**FACT:** Comparing DUT architectural state against Spike, Sail, or another formal RISC-V specification implementation per instruction is a widely deployed pattern. The DUT may run ahead of the reference using a deferred-check queue, with results compared at synchronization points.

**Application:** Required for ISA-compliance evidence. See `research/10-verification/isa-compliance.md`.

### E. FPGA Prototyping and Emulation

**FACT:** FPGA-based prototyping runs the RTL at orders-of-magnitude higher throughput than software simulation, enabling long multi-thread and multi-core workloads. Emulation platforms (e.g., commercial emulators, open-source FireSim-like flows) provide a middle ground.

**Application to core verification:**
- Speeds up bring-up of the core testbench by running entire test programs end-to-end.
- Enables fault-injection campaigns that are infeasible in simulation (see `research/10-verification/fault-injection.md`).
- For 128-core XH-1, an FPGA prototype is the natural place to begin validating the multicore layer; core verification is the upstream prerequisite.

### F. Regression Infrastructure

**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`.

**Application:** For XH-1, the regression infrastructure must support a single-core nightly run, a multicore run, and a system run with shared seeds where appropriate.

### G. Coverage Closure Methodology

**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.

### H. Assertion-Based Verification

**FACT:** SystemVerilog Assertions and immediate assertions encode design intent and serve both as live checkers and as inputs to formal tools.

**Application:** 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").

## Alternative Designs

The 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.

### Alternative 1: UVM-Centric with Formal Supplements

- **Approach:** UVM as the workhorse for dynamic verification, with formal applied to control-dominated blocks.
- **Strengths:** Industry-standard tooling, well-understood coverage and sign-off conventions, mature ecosystem.
- **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.

### Alternative 2: Lightweight Python/C++ Test Harness with Spike Co-Simulation

- **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.
- **Strengths:** Lower setup cost than UVM. Excellent generator productivity. Easy integration with regression infrastructure. Open-source-friendly.
- **Weaknesses:** Less mature scoreboard/reuse infrastructure than UVM. Coverage closure tooling is less standardized.
- **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.

### Alternative 3: Formal-First

- **Approach:** Formal proofs form the primary verification evidence; dynamic simulation is used for reach and to validate properties that formal cannot discharge.
- **Strengths:** Highest assurance per proven property. Strong fit for control logic and CSR behavior.
- **Weaknesses:** Pipeline formalization is hard. World-of-design complexity grows combinatorially for large cores. May not reach proof closure on timing-agnostic models.

### Alternative 4: Emulation-Centric

- **Approach:** Skip large-scale software simulation; use FPGA/emulation throughput as the primary engine.
- **Strengths:** Excellent long-workload capability; native fault-injection support.
- **Weaknesses:** Poor waveform/observability; slow compile/turnaround; harder to drive corner-case stimulus; debug cycle is slow.

### Alternative 5: Hybrid (Recommended Direction — See Recommendation)

A combination of (1) or (2) for dynamic, formal supplements for control logic, and FPGA prototyping/emulation for throughput and multicore bring-up.

## Comparison

| Dimension | UVM-Centric | Lightweight Harness | Formal-First | Emulation-Centric | Hybrid |
|---|---|---|---|---|---|
| Setup cost | High | Low | High | Medium | High |
| Per-test runtime | Slow | Slow–Medium | N/A (proof time) | Fast | Mixed |
| Corner-case reach | Strong (with seeds) | Strong (with fuzzing) | Strong (when discharged) | Weak–Medium | Strong |
| Assurance on control logic | Medium | Medium | High | Low–Medium | High |
| Debug ergonomics | Good (waveform, logs) | Good | Strong counterexamples | Weak | Mixed |
| Open-source viability | Weak (commercial sims) | Strong | Medium | Medium | Medium |
| Fit for 128-core reuse | High (if designed so) | High (if designed so) | High | High | High |
| Pre-tape-out risk reduction | Strong | Medium–Strong | Strong (partial) | Medium | Strong |

INSUFFICIENT EVIDENCE to rank absolute quality without XH-1-specific RTL data, tool licensing posture, and team size.

## Advantages

The advantages of investing in a robust core verification methodology for XH-1:

- **Replication leverage.** Every bug caught at the core layer is caught 128 times. The methodology amortizes across the die.
- **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`.
- **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.
- **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.
- **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.

## Disadvantages

Costs and risks of a robust core verification program:

- **Engineering cost.** A UVM-class environment plus formal plus emulation can easily exceed the RTL design cost for a single core.
- **Tooling lock-in.** Heavy UVM usage often implies commercial simulator licensing; this may not match XH-1's tool posture.
- **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".
- **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.
- **Coverage false confidence.** Hitting a cover point is not the same as proving correctness; the verification plan must distinguish cover and check.
- **128-core replication pressure.** If the core testbench is not designed to compose with the multicore testbench, redundant effort emerges.

## XH-1 Considerations

XH-1-specific factors that constrain the methodology choice:

- **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.
- **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.
- **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.
- **RISC-V ISA.** The RISC-V ecosystem provides mature reference models (Spike, Sail) and compliance tests (riscv-tests, riscv-arch-test). These are the natural anchors.
- **Tool posture (ASSUMPTION).** Without evidence in the repository, the project's tool posture (open-source only, commercial EDA, mixed) is **OPEN**.

## 128-Core Scalability

- **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.
- **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.
- **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.
- **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).
- **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.
- **Symmetry assumption.** 128-core verification typically assumes the cores are identical. If XH-1 has heterogeneous cores or per-core configuration, this assumption must be lifted explicitly.

## Performance Considerations

- **Testbench throughput.** Dynamic simulation throughput determines how many random seeds can be run per unit wall-clock. Constrained-random at the core level typically runs at 10s to 100s of kIPS on commercial simulators, slower on open-source simulators (e.g., Verilator) by 1–2 orders of magnitude but with parallelism.
- **Compiler/optimizer.** Coverage instrumentation slows simulation. Production coverage runs and fast-turnaround debug runs should be separable.
- **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.
- **FPGA prototype throughput.** A XH-1 core on FPGA can realistically run tens to hundreds of MHz depending on LUT count, Fmax, and memory subsystem. This is 3–5 orders of magnitude faster than software simulation and is the natural engine for long workloads.
- **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.

INSUFFICIENT EVIDENCE to provide numerical throughput estimates without XH-1-specific RTL data and toolchain selection.

## Area Considerations

- **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.
- **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.
- **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.
- **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.

INSUFFICIENT EVIDENCE to quantify area without access to XH-1's core area budget or process node.

## Power and Energy Considerations

- **Power-aware verification.** The core testbench should be able to drive representative switching activity to enable power estimation. Power intent (UPF / CPF) and power-aware simulation may be required to verify that power-gated domains behave correctly.
- **Energy proportionality.** 128-core verification must consider that not all cores will be active in the same workload; the core testbench should be aware of the core's low-power states (clock gating, power gating, retention) and verify transitions.
- **Thermal and DVFS interactions.** 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.
- **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.

## Implementation Considerations

- **Methodology composition.** The project must select one of the alternative strategies (or a hybrid) and codify it in the verification plan.
- **Toolchain selection.** Open-source (Verilator, cocotb, SymbiYosys, RISCV-ISAC, Spike, GTKWave) vs. commercial (Synopsys VCS, Cadence Xcelium, Siemens Questa, JasperGold, FormalPro) is a strategic decision. The choice cascades through licensing, hiring, training, and CI.
- **Reference model choice.** Spike (C++, C-ISAs-style) vs. Sail (functional language) vs. a custom golden model. Spike is the most common reference but has known corner-case behaviors that the verification plan must document.
- **Coverage database.** Where the coverage is stored (Synopsys DDC, Cadence IMC, custom SQLite) affects tooling, tooling lock-in, and CI integration.
- **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).
- **Seed management.** Random seeds should be reproducible. Seed pools should be partitioned into "core regressions", "block regressions", and "fuzzing".
- **Bring-up sequencing.** Block-level → core-level → multicore → system. The core testbench is the transition point between block-level and system-level work.

## Verification Considerations

Core verification is itself subject to verification — the verification of the verification environment:

- **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.
- **Reference model validation.** The reference model (Spike, Sail) must be validated against the chosen RISC-V compliance tests before being used as a checker.
- **Coverage sanity.** Cover points must be reviewed to ensure they are not trivially self-firing.
- **Mutation testing.** A subset of RTL defects should be intentionally injected to confirm the testbench catches them. See `research/10-verification/fault-injection.md`.
- **Tool qualification.** If the verification tools are used in any safety-relevant context, tool qualification (per ISO 26262, DO-254, or similar) is required. This is **OPEN** for XH-1.
- **Version control and baselines.** Every test run must be reproducible from committed source. Coverage baselines must be versioned.

## Software Considerations

- **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.
- **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.
- **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.
- **Debug and trace protocols.** The core's debug-transport module (RISC-V Debug spec) must be exercised. JTAG or cJTAG interactions with the core's debug module are typically a core-level concern.
- **Performance analysis tools.** Tools that analyze trace data, performance counters, and profile information should be able to consume the artifacts the core testbench produces.
- **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.

## Recommendation

PROPOSAL — Recommend a **hybrid methodology** for XH-1 core verification with the following structure:

1. **Dynamic simulation** as the primary verification engine. Select either UVM (if a commercial simulator and a larger team are available) or a lightweight cocotb/Verilator harness with Spike co-simulation (if an open-source-first posture is preferred). The choice is **OPEN** pending XH-1 tool posture.
2. **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.
3. **Co-simulation against a RISC-V reference model** (Spike or Sail) for ISA-compliance evidence. Coordinate with `research/10-verification/isa-compliance.md`.
4. **Directed tests** for XH-1 microarchitectural corner cases that random cannot reach economically.
5. **FPGA prototyping** for throughput-driven verification and as a substrate for fault injection and multicore bring-up.
6. **Regression infrastructure** with version-controlled seeds, baselines, and coverage data. Coordinate with `research/10-verification/regression.md`.
7. **Coverage closure** as an explicit, tracked funnel with cover points defined in the verification plan, not ad hoc.
8. **Reusable testbench architecture** so the core testbench composes inside the multicore testbench without modification.
9. **Mutation testing** as a periodic check that the testbench is still doing useful work. Coordinate with `research/10-verification/fault-injection.md`.

INSUFFICIENT EVIDENCE to recommend a single dynamic-verification framework (UVM vs. lightweight) without XH-1's tool licensing posture, team size, and design timeline. The hybrid is recommended; the specific framework within the hybrid is OPEN.

## Confidence

- **High confidence:** The general methodology composition (dynamic + formal + co-simulation + directed + prototype + regression + coverage closure) is industry consensus and applies to any single core.
- **High confidence:** Core verification must produce reusable, composable testbench artifacts to be viable at 128-core scale.
- **Medium confidence:** Specific tool selections, throughput numbers, and area/power tradeoffs, given the absence of repository evidence.
- **Low confidence (OPEN):** XH-1's tool licensing posture, core microarchitecture details, ISA profile selection, and team size. These drive the specifics within the recommended hybrid.

## Open Questions

1. What RISC-V profile (RV32I, RV64I, RVA23, custom) does the XH-1 core implement? This drives ISA-compliance coverage and reference model selection.
2. 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.
3. What is XH-1's toolchain posture (open-source only, commercial EDA, mixed)?
4. What is the team size and timeline? Methodology cost scales with team capacity.
5. 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`.
6. Are the 128 cores identical, or are there variants? Heterogeneity changes the testbench architecture.
7. What is the core's power architecture — is power gating at the core level, and what are the retention semantics?
8. What is XH-1's relationship to functional safety standards (ISO 26262, IEC 61508, DO-254, or none)?
9. How will the XH-1 core's trace, debug, and performance-counter interfaces be designed, and how will core verification consume them?
10. What is the expected defect rate target at tape-out, and how does the verification program demonstrate closure against that target?

## Sources

No external sources are cited. All claims in this document derive from industry-standard verification practice as background knowledge; the XH-1 repository documents referenced (under `research/10-verification/`) are placeholders ("SOON") and do not provide factual content to cite. Quantitative claims (throughput, area, power, timing) are explicitly labeled INSUFFICIENT EVIDENCE or OPEN. No citations, papers, measurements, benchmarks, processor capabilities, URLs, or experimental results have been invented.
