Tape-out sign-off governance for synthetic AI-authored SVA

On a fixed synthetic board, 8/8 PROVEN becomes 5/8 TRUSTWORTHY after audit.

Proof Firewall re-audits synthetic PROVEN SystemVerilog assertions for vacuity, assertion strength, and cone of influence before they enter a sign-off file. On the fixed board, it turns 8/8 bare-flow proofs into five certified TRUSTWORTHY results and routes the rest to human review with a reason. Agents advise, code decides.

8/8 to 5/8

PROVEN to TRUSTWORTHY

Fixed synthetic eight-property board after firewall audit

0/6

PIPE3 mutation kills

Featured synthetic weak pipeline case

18/18

Labeled synthetic benchmark agreement

Local demo benchmark, not an open-world accuracy claim

This is a runnable, reproducible demonstration using fixture-authored synthetic transition-system designs and properties. It does not use customer RTL, a cloud solver, or a live LLM call on the default path.

The sign-off failure is hidden inside a green result

First-silicon success was reported as 14% in the Wilson Research Group and Siemens EDA study from 2024. A formal result deserves more scrutiny when the assertion may be AI-authored: an implication can be PROVEN because its antecedent never occurs, or because its consequent constrains nothing useful.

Proof Firewall is a deterministic post-proof governance gate for that decision. It does not declare a formal engine wrong. It asks whether the proof is defensible enough to file for human tape-out sign-off, then leaves a concrete reason for every result it certifies or withholds.

How the governance gate works

The anchor is proof quality. Each deterministic check tests whether a green proof has enough substance to be filed.

Reachability before credit

The explicit-state model checker tests whether an implication's antecedent can occur in the synthetic transition-system IR. An unreachable antecedent is routed as VACUOUS rather than filed as evidence.

Mutation kill-test for strength

Relevant single-point design mutations test whether the assertion rejects broken variants. A property that survives those mutations is routed as WEAK rather than allowed to borrow confidence from a green solver result.

COI and policy routing

The gate calculates cone of influence and assigns TRUSTWORTHY, BOUNDED-PROVEN, VACUOUS, WEAK, DEAD, or VIOLATED. Only TRUSTWORTHY receives a signed demonstration certificate.

The demo's pure-Python explicit-state checker finds reachability and counterexample traces in the finite model. A bounded-depth fallback is labeled as bounded, not recast as an unqualified proof.

Worked proof review on the synthetic board

Every image is a screenshot of the running synthetic demo. The board begins as eight PROVEN bare-flow results, then the audit makes the withheld evidence visible.

The audit reverses three green results

The Tape-Out Sign-Off Board initially shows 8/8 PROVEN in its bare-flow view. After the firewall audit, 5/8 are certified TRUSTWORTHY; the remaining three are one VACUOUS and two WEAK properties. This is a fixed synthetic fixture, not a customer design or a commercial-engine result.

Proof Firewall Tape-Out Sign-Off Board showing five of eight synthetic properties marked TRUSTWORTHY, with one VACUOUS and two WEAK results withheld for review. — The audited synthetic board: the firewall converts an 8/8 PROVEN view into five TRUSTWORTHY certificates and three explained holds.

ARB3 proves nothing because its trigger never occurs

The synthetic ARB3 assertion, assert (g0 && g1) |-> (turn == 0), is VACUOUS because its antecedent is unreachable in the synthetic arbiter. The result demonstrates why a proven implication can still certify nothing.

Waveform from the synthetic arbiter showing ARB3, whose g0 and g1 antecedent is unreachable and therefore classified VACUOUS. — ARB3: an unreachable antecedent turns a green implication into a VACUOUS result.

PIPE3 survives the mutations it should catch

The synthetic PIPE3 assertion, assert v2 |-> (s2 == s2), is WEAK. Its tautological consequent survives the relevant injected mutations, and the featured pipeline case records 0/6 mutation kills.

Waveform from the synthetic pipeline showing PIPE3, a tautological property classified WEAK after recording zero of six mutation kills. — PIPE3: a tautological consequent earns a WEAK result after a 0/6 mutation kill-test.

A stronger CDC property can show its own counterexample

The synthetic weak CDC2 property is WEAK. Strengthening it to assert (req && !ack) |-> ##1 req makes it VIOLATED on the synthetic CDC fixture and produces a concrete counterexample waveform. It illustrates a lost-transaction CDC failure class, not a claim about a real chip.

Concrete counterexample waveform for a strengthened synthetic CDC property classified VIOLATED on the fixture. — The strengthened synthetic CDC property is VIOLATED, with a counterexample a reviewer can inspect.

The review leaves a structured receipt

The signed demonstration certificate records each property's verdict, reachability, mutation results, COI, and counterexample records where applicable, plus a SHA-256 field. It makes the audit reviewable without asking a reviewer to infer why a status changed.

Proof Firewall signed demonstration certificate showing per-property verdicts, reachability, mutation results, cone of influence, counterexample records, and a SHA-256 field. — The signed demonstration certificate preserves the evidence behind certification or human review.

An engine-agnostic production direction, not a replacement solver

Proof Firewall demonstrates a gate around proof evidence. The scope below separates what the demo does from work that is deferred.

Question	Proof Firewall demo	Production direction
Proof input	Fixture-authored synthetic transition-system IR and SVA	A gate around a customer's existing formal flow
Checks shown	Vacuity, mutation kill-test, COI, policy routing, certificate export	Same governance questions applied to supplied proof evidence
Formal engines	No real-engine adapter	Engine-agnostic direction, not a claim of integration
Result handling	TRUSTWORTHY certificates and explained holds	Human sign-off review with a structured evidence record

What this demo does not do

✓ It does not parse Verilog or SystemVerilog RTL, operate on customer RTL, GDSII, or a real chip design. V1 uses synthetic transition-system IR fixtures.
✓ It does not replace JasperGold, VC Formal, Questa Formal, SymbiYosys, or another formal engine. Real-engine adapters are deferred.
✓ It does not use a live LLM by default. The properties are fixture-authored LLM-authored SVA, and the default recording path is deterministic.
✓ It does not claim tape-out readiness, safety certification, zero respins, customer outcomes, deployments, ROI, or regulatory qualification.
✓ It does not present 5/8, 18/18, 0/6, or 7/7 as production or industry-wide performance. These are results from fixed local synthetic fixtures and tests.

Questions verification leaders ask

We already run formal. Why would we put another gate after a PROVEN result?

A PROVEN result can still rest on an unreachable antecedent or a property that does not fail when the relevant design behavior is broken. Proof Firewall demonstrates a deterministic post-proof gate for those questions: reachability, mutation kill-testing, cone of influence, and policy routing. It does not replace a formal engine; its production direction is an engine-agnostic gate around an existing formal flow.

Does Proof Firewall connect to JasperGold, VC Formal, Questa Formal, or SymbiYosys today?

No. Real-engine adapters are deferred in this demo, so it must not be read as a replacement for JasperGold, VC Formal, Questa Formal, SymbiYosys, or another formal engine. The demonstrated production direction is an engine-agnostic governance gate around a customer's existing formal workflow.

Are these results from customer RTL or a live AI assertion generator?

No. The board, SystemVerilog assertions, designs, benchmark, and counterexamples are synthetic. The default recording path uses fixture-authored LLM-authored SVA properties and a synthetic transition-system IR, not customer RTL or a live LLM call.

What did the 8/8 to 5/8 result actually measure?

It is a fixed synthetic eight-property board. Its bare-flow baseline displays 8/8 PROVEN; after the firewall audit, five are certified TRUSTWORTHY while one is VACUOUS and two are WEAK. It is not a production RTL rate, a customer result, or a general result for synthetic AI-authored assertions.

How does the demo decide that an assertion is vacuous or weak?

The governance gate checks whether the antecedent is reachable, runs relevant single-point design mutations, and calculates each property's cone of influence. ARB3 is VACUOUS because its antecedent is unreachable in the synthetic arbiter. PIPE3 is WEAK because its tautological consequent survives the relevant injected mutations, with a 0/6 mutation kill result in the featured pipeline case.

What evidence can a reviewer take out of this demo?

The UI exports signoff_certificate.json with per-property verdicts, reachability, mutation results, cone of influence, counterexample records where applicable, and a SHA-256 field. Only TRUSTWORTHY receives a signed demonstration certificate; BOUNDED-PROVEN, VACUOUS, WEAK, DEAD, and VIOLATED results are withheld for human review with a reason.

Technical Research

The research behind this demo — the architecture, the verification design, and the enterprise blueprint.

Full solution

Explore the Semiconductor AI Verification & Silicon Correctness solution →

Bring proof-quality governance into the sign-off conversation

We invite verification leaders to discuss deterministic evidence paths for high-stakes AI-assisted engineering workflows.

The useful next conversation is about the proof artifacts your team needs to inspect, the policy boundary a reviewer can defend, and what an engine-agnostic production direction would require.

Proof-Governance Assessment

✓ Map the current proof-review path
✓ Identify vacuity and strength evidence
✓ Define sign-off policy states
✓ Specify reviewable certificate records

Governance-Path Design

✓ Design engine-agnostic evidence gates
✓ Build deterministic policy routing
✓ Model audit and exception workflows
✓ Plan human sign-off handoffs

Connect via WhatsApp Email Our Team