- Home
- Quality
Verification & quality
A core that works in the demonstration and fails in your design has cost you more than it saved. This page describes what has to be true before we are willing to release something, in enough detail that you can judge whether it is sufficient for your programme.
What must be true before a core ships
These are gates, not targets. A core that misses one does not ship with a caveat in the release note; it does not ship.
-
Bit-exact agreement with the reference model
The RTL and the reference model must produce identical outputs across the full regression suite in every supported configuration. Not "within a tolerance" — identical. Any divergence is a defect in one of the two, and until it is understood we do not know which.
-
Full code and functional coverage
100 % statement, branch and toggle coverage, and 100 % of the functional coverage model, with every exclusion individually reviewed and justified in writing. An unexplained exclusion is treated as a hole, because that is what it usually is.
-
Assertions on every interface
Protocol assertions on all AXI interfaces, plus internal assertions on overflow, FIFO occupancy, state reachability and handshake validity. They stay enabled in your simulations, so a protocol violation in your integration is reported where it happens rather than three blocks later.
-
Formal proof on control logic
Deadlock freedom, reset correctness and mutual exclusion are proven formally rather than sampled by simulation. These are properties where simulation coverage gives false confidence — the failing sequence is usually one no constrained-random generator will produce in a practical number of cycles.
-
Fixed-point characterisation
Output SNR, spurious level or BER measured as a function of internal word length across the parameter range, and published. This is what lets you size the datapath from your noise budget instead of adding guard bits until it looks acceptable.
-
Timing closure on reference targets
Every supported target must close timing at the published clock frequency with positive slack, from the delivered constraints, using a clean script run. The reports go in the release archive so you can compare against your own build.
-
Hardware validation
Every core runs on real hardware against real signals before release — a signal generator and analyser for the modem and DFE cores, a captured live signal set for the receive chains. Simulation does not exercise clock jitter, converter non-linearity or thermal drift, and those are exactly the things that make a design fail in the field.
-
Independent documentation review
An engineer who did not write the core integrates it from the documentation alone. Anything they have to ask about is a documentation defect and gets fixed before release. This is the single most effective quality practice we have, and the one most often skipped in this industry.
How the verification environment is built
Coverage model first
The functional coverage model is written from the specification before the RTL exists, by a different engineer. Writing it afterwards produces a model that covers what the design does rather than what it is supposed to do.
Independent implementation
The reference model and the RTL are written by different engineers from the same specification. When they disagree, one of them has misread the specification — and finding out which is how specification ambiguities get caught before you find them.
Continuous regression
Every commit triggers lint, a smoke regression and a synthesis trial. The full regression — all configurations, all simulators — runs nightly. A red nightly blocks the next day's commits.
Multi-simulator
Sign-off regressions run on Questa, VCS and Xcelium. Simulators disagree on corner cases of the language standard, and code that depends on one interpretation is a defect waiting for your tool version.
Configuration sweeps
Parameterised cores are regressed across a swept configuration matrix, not one favourable set. Where the space is too large to cover exhaustively, the sample is random per night with a recorded seed.
Traceable requirements
Each specification requirement maps to identified tests and coverage points. The matrix is delivered with the core, which is what makes it usable as evidence in a DO-254 or functional-safety argument.
Certification and controlled programmes
We do not certify our IP ourselves — certification applies to a system, not to a component. What we provide is the evidence package a certifying authority will ask you for, in a form that can be entered into your own process.
- DO-254 evidence Requirements traceability, coverage reports, review records and problem reports supplied as DAL-C or DAL-B evidence for airborne programmes.
- Space qualification Radiation-tolerant coding style, TMR options and SEU-mitigation guidance for cores intended for flight FPGAs. Radiation testing is programme-specific and performed by the integrator.
- Standards conformance Conformance test reports against the relevant standard's own test specification, where the standards body publishes one.
- Security review On request, a review report covering the absence of undocumented interfaces, hidden state and unspecified external behaviour — the questions a security accreditation actually asks.
Audit us before you buy.
We will walk your verification lead through the environment, the coverage model and the regression results for any core in the portfolio, under NDA, before you commit to anything.