# Core Verification

## Status
Stub — this document is a placeholder. Substantive research has not yet been written.

## Abstract
INSUFFICIENT EVIDENCE. The current document contains no technical content. This section will summarize the chosen per-core verification methodology (simulation-based, formal, FPGA prototyping, or hybrid), the coverage targets, and the relationship to the broader 10-verification strategy once defined.

## Research Question
The specific research question for this document is not yet formulated. Candidate questions include:
- 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 before replication to 128 instances?
- How should directed, constrained-random, and formal methods be partitioned across the core's microarchitectural units (fetch, decode, rename, issue, execute, memory, retire, CSR, MMU, PMP, debug, trace)?
- What coverage model (line, branch, toggle, functional, assertion, mutation) is required at the core level versus deferred to multicore verification?

## Background
INSUFFICIENT EVIDENCE. No prior XH-1 core-verification decisions are recorded. Industry baseline: core-level verification of modern RISC-V cores (e.g., SiFive, Andes, OpenHW Group CV32E40P/E40PX) typically combines constrained-random simulation with a defined coverage model, supplemented by formal property checks on targeted blocks (e.g., CSR file, MMU TLB, scoreboard/ROB). The RISC-V ISA provides architectural compliance tests (riscv-tests) that form a baseline but are not sufficient on their own.

## Existing Approaches
INSUFFICIENT EVIDENCE to compare specific commercial EDA or academic flows without repository context. General categories that exist in the field:
- Constrained-random UVM/SystemVerilog simulation with coverage-driven closure
- Formal property verification (JasperGold, Cadence Jasper, Synopsys Formality/VC-Formal, Onespin, RVX) on selected sub-modules
- FPGA prototyping/emulation acceleration
- Co-simulation with architectural reference models (e.g., Spike, SAIL, riscvOVPsim)
- Compliance test suites: riscv-tests, riscv-arch-test, RISC-V International signing framework
- Mutation-based verification tools
- Coverage merging across simulators/prototypes

## Alternative Designs
INSUFFICIENT EVIDENCE. The repository has not yet selected between approaches such as:
- Pure simulation-driven sign-off vs. hybrid simulation + formal
- In-house UVM testbench vs. commercial VIP vs. generator-based (e.g., riscv-dv from Google/CHIPS Alliance) flows
- Single-language (SystemVerilog) vs. multi-language (SystemVerilog + Cocotb/Chisel/SpinalFlow co-simulation) environments
- Coverage model: line/branch/toggle only vs. full functional coverage matrix indexed by ISA extension × privilege level × interrupt/exception path

## Comparison
INSUFFICIENT EVIDENCE. Quantitative trade-offs (run time, license cost, engineering effort, coverage closure time, debug productivity) cannot be cited without source data.

## Advantages
INSUFFICIENT EVIDENCE. The document does not yet commit to a methodology, so advantages of any chosen approach cannot be stated.

## Disadvantages
INSUFFICIENT EVIDENCE.

## XH-1 Considerations
ASSUMPTION: because XH-1 is a custom 128-core RISC-V design, core-level verification must produce a sign-off artifact that is reusable across all 128 replicated instances. Open questions that bear on this:
- Whether the 128 cores are identical (homogeneous) or partially heterogeneous (e.g., different privileged/IoT variants). The current document does not state this.
- Whether per-core verification is gated on the L1 cache, MMU/TLB, and coherence-related agent behavior, or whether those are deferred to the multicore verification document. That boundary is not defined.
- How the debug (RISC-V Debug Spec 0.13/1.0) and trace (RISC-V Trace Spec) modules are partitioned.

## 128-Core Scalability
PROPOSAL: structure core-level sign-off so that verification collateral (testbench, sequences, assertions, coverage models) is parameterizable by core index / instance ID, allowing reuse when validating replicated cores. This avoids redeveloping verification for each of the 128 instances.

ASSUMPTION: the 128-core design reuses a single verified core RTL. If cores are unique, this scalability argument does not apply directly.

OPEN QUESTION: does XH-1 use a tiled layout with replicated cores, a mesh/NoC of heterogeneous cores, or a mix? Not stated in the document or related research artifacts.

## Performance Considerations
INSUFFICIENT EVIDENCE. Core-level simulation throughput (instructions/sec, coverage points/hour) depends on the chosen simulator (commercial event-driven, open-source Verilator, cocotb, etc.) which is not yet selected in this document.

## Area Considerations
INSUFFICIENT EVIDENCE. Verification-influenced area decisions (e.g., adding observability/assertion logic, formal-friendly state encoding) have not been characterized.

## Power and Energy Considerations
INSUFFICIENT EVIDENCE.

## Implementation Considerations
ASSUMPTION: the design captures the RISC-V ISA, the privilege levels, and the specific extensions (RV32I/RV64I, M, A, F/D, C, V, B, K, H, etc.) that the core must implement. None of this is captured in the current document set, all of which are stubs.

ASSUMPTION: a reference model (Spike, SAIL, or hand-written golden) will be available for differential checking.

## Verification Considerations
PROPOSAL: define a coverage closure plan with explicit exit criteria before any RTL is signed off. Candidates:
- Functional coverage: every instruction in every supported extension × every privilege mode × representative operand values (0, 1, -1, max, NaN-boxed, sign-extension edge cases).
- Exception/interrupt coverage: every exception cause × every priority × MRET/SRET/URET paths × nested traps.
- CSR coverage: every CSR address × every writable bit × reset value × WARL semantics.
- Memory access coverage: misaligned, PMP-denied, MMU miss, page-fault, atomics, fence ordering, I/O regions.
- Reset and debug entry/exit: every reset reason (power-on, debug, warm, retention) and every debug state transition.
- Formal: targeted unbounded proofs for FSMs, scoreboard/ROB, MMU TLB invariants, exception priority encoders.

OPEN QUESTION: what is the coverage closure target (e.g., 100% legal-bin coverage, X% toggle, X% mutation score)? Not stated.

## Software Considerations
PROPOSAL: align core verification artifacts with downstream software flows:
- The architectural compliance test signature (riscv-arch-test) must be producible from the verified core so that OS porters and toolchain builders can adopt the platform.
- A linker script, boot ROM, and SBI interface contract should be specified in parallel with the core's CSRs to avoid post-silicon software surprises.
- A pre-silicon architectural reference (Spike-compatible or SAIL) should be published for software teams.

## Recommendation
INSUFFICIENT EVIDENCE. The current document does not contain enough context (ISA profile, microarchitecture choice, EDA toolchain, sign-off criteria) to recommend a specific core-verification methodology. A recommendation is not forced.

## Confidence
Low. The document is a stub; no research has been performed.

## Open Questions
- What RISC-V base and extensions does XH-1 implement (RV32/RV64, I/M/A/F/D/C/V/B/H/K, privilege modes, hypervisor)?
- Is the core in-order or out-of-order? This dramatically changes the verification surface (e.g., scoreboard, load-store queue, speculation recovery).
- Is the 128-core array homogeneous, or are there variants (e.g., application cores + management/IoT cores)?
- What simulator stack is available or mandated (commercial, Verilator, cocotb, custom)?
- What is the targeted process node, clock frequency, and tape-out timeline? These bound verification wall-clock time.
- Does the project have access to FPGA prototyping capacity at the scale required to boot 128 cores?
- What is the project's stance on the RISC-V International compliance sign-off process?
- Which verification sub-area (formal, fault injection, ISA compliance, multicore, regression, strategy, unit) should consume artifacts produced at the core level?
- What coverage exit criteria does the project accept for tape-out?
- How is debug and trace verification partitioned between this document and multicore verification?

## Sources
No sources cited. The document contains no factual claims requiring attribution. To be populated once the ISA profile, toolchain, and microarchitecture are documented in this repository.
