VERIFICATION METHOD

How we decide what is ready

Python2Verilog records the design contract and checks each engineering layer against a stated reference. Tool results and board tests are attached to the build they assess. The responsible engineer signs off the agreed scope.

MODEL

Different models answer different questions

Executable reference

Establishes the intended computation against customer vectors, a standard, or another independent source.

Cycle-aware model

Makes precision, schedule, state, and interfaces explicit before hardware is accepted.

RTL candidate

Simulation compares outputs and timing behavior with the declared models. Agreement is reported for tested configurations, not assumed for future variants.

CONTROL

Checks must be able to fail

A passing comparison has value only when its inputs, expected outputs, and failure path are known. We use independent references where available and negative controls to test whether a checker reports a planted error.

Reference independence

Generated outputs are checked against a source that does not simply reuse the candidate's own logic.

Negative controls

A deliberately wrong result tests whether the relevant comparison can report red.

Evidence freshness

Reports are tied to the design and inputs they certify; changed builds require new checks.

HARDWARE

Implementation and board evidence stay scoped

Synthesis and place-and-route reports describe a particular target, constraints, and tool run. A board gate adds a specific workload and hardware configuration. We inspect those results before accepting a candidate and retain failures and exclusions alongside passes.

Source and limit for each result

Device-dependent figures belong in the relevant product page or case study with their test conditions. A design target is marked as a target. Missing or stale evidence does not become a passing result.

Read a scoped case study