Tape-Out-Sign-off-Governance für synthetische, KI-generierte SVA

Auf einem festen synthetischen Board wird 8/8 PROVEN nach Audit zu 5/8 TRUSTWORTHY.

Proof Firewall prüft synthetische PROVEN-SystemVerilog-Assertionen vor dem Eintrag in eine Sign-off-Datei erneut auf Vakuität, Assertionsstärke und Cone of Influence. Auf dem festen Board wandelt sie 8/8 Bare-Flow-Beweise in fünf zertifizierte TRUSTWORTHY-Ergebnisse um und leitet den Rest mit Begründung an die menschliche Überprüfung weiter. Agenten beraten, Code entscheidet.

8/8 zu 5/8

PROVEN zu TRUSTWORTHY

Festes synthetisches Acht-Eigenschaften-Board nach Firewall-Audit

0/6

PIPE3-Mutations-Kills

Vorgestellter Fall einer schwachen synthetischen Pipeline

18/18

Übereinstimmung mit gelabeltem synthetischem Benchmark

Lokaler Demo-Benchmark, kein Anspruch auf Open-World-Genauigkeit

Dies ist eine lauffähige, reproduzierbare Demonstration unter Verwendung von Fixture-basierten synthetischen Transitionssystem-Designs und -Eigenschaften. Auf dem Standardpfad werden weder Kunden-RTL noch ein Cloud-Solver oder ein Live-LLM-Aufruf verwendet.

Der Sign-off-Fehler verbirgt sich hinter einem grünen Ergebnis

Der First-Silicon-Erfolg lag laut der Studie der Wilson Research Group und Siemens EDA aus dem Jahr 2024 bei nur 14 %. Ein formales Ergebnis verdient noch genauere Prüfung, wenn die Assertion von einer KI generiert wurde: Eine Implikation kann PROVEN sein, weil ihre Prämisse niemals auftritt oder weil ihre Konklusion nichts Nützliches einschränkt.

Proof Firewall ist ein deterministisches Post-Proof-Governance-Gate für diese Entscheidung. Es erklärt eine formale Engine nicht für fehlerhaft. Es prüft, ob der Beweis vertretbar genug ist, um für das menschliche Tape-Out-Sign-off eingereicht zu werden, und hinterlässt für jedes zertifizierte oder zurückgehaltene Ergebnis eine konkrete Begründung.

So funktioniert das Governance-Gate

Der Anker ist die Beweisqualität. Jede deterministische Prüfung testet, ob ein grüner Beweis genügend Substanz aufweist, um eingereicht zu werden.

Erreichbarkeit vor Anerkennung

Der Explicit-State-Model-Checker prüft, ob die Prämisse einer Implikation in der synthetischen Transitionssystem-IR auftreten kann. Eine unerreichbare Prämisse wird als VACUOUS eingestuft, anstatt als Nachweis eingereicht zu werden.

Mutations-Kill-Test auf Stärke

Relevante Einzelpunkt-Designmutationen prüfen, ob die Assertion fehlerhafte Varianten zurückweist. Eine Eigenschaft, die diese Mutationen übersteht, wird als WEAK eingestuft, anstatt Vertrauen aus einem grünen Solver-Ergebnis zu beziehen.

COI und Richtlinien-Routing

Das Gate berechnet den Cone of Influence und weist TRUSTWORTHY, BOUNDED-PROVEN, VACUOUS, WEAK, DEAD oder VIOLATED zu. Nur TRUSTWORTHY erhält ein signiertes Demonstrationszertifikat.

Der reine Python-Explicit-State-Checker der Demo ermittelt Erreichbarkeit und Gegenbeispiel-Traces im endlichen Modell. Ein Bounded-Depth-Fallback wird als beschränkt gekennzeichnet und nicht als uneingeschränkter Beweis umgedeutet.

Detaillierte Beweisüberprüfung auf dem synthetischen Board

Jedes Bild ist ein Screenshot der laufenden synthetischen Demo. Das Board beginnt mit acht PROVEN-Bare-Flow-Ergebnissen, woraufhin das Audit die zurückgehaltenen Nachweise sichtbar macht.

Das Audit revidiert drei grüne Ergebnisse

Das Tape-Out Sign-Off Board zeigt in der Bare-Flow-Ansicht anfangs 8/8 PROVEN. Nach dem Firewall-Audit sind 5/8 als TRUSTWORTHY zertifiziert; die verbleibenden drei sind eine VACUOUS- und zwei WEAK-Eigenschaften. Dies ist ein festes synthetisches Fixture, kein Kundendesign und kein Ergebnis einer kommerziellen Engine.

Proof Firewall Tape-Out Sign-Off Board: Zeigt fünf von acht synthetischen Eigenschaften als TRUSTWORTHY markiert, während ein VACUOUS- und zwei WEAK-Ergebnisse zur Überprüfung zurückgehalten werden. — Das auditierte synthetische Board: Die Firewall wandelt eine 8/8-PROVEN-Ansicht in fünf TRUSTWORTHY-Zertifikate und drei begründete Zurückhaltungen um.

ARB3 beweist nichts, da sein Trigger niemals auftritt

Die synthetische ARB3-Assertion, assert (g0 && g1) |-> (turn == 0), ist VACUOUS, da ihre Prämisse im synthetischen Arbiter unerreichbar ist. Das Ergebnis verdeutlicht, warum eine bewiesene Implikation dennoch nichts bescheinigen kann.

Signalverlauf aus dem synthetischen Arbiter für ARB3, dessen g0- und g1-Prämisse unerreichbar ist und daher als VACUOUS eingestuft wird. — ARB3: Eine unerreichbare Prämisse verwandelt eine grüne Implikation in ein VACUOUS-Ergebnis.

PIPE3 übersteht Mutationen, die es abfangen sollte

Die synthetische PIPE3-Assertion, assert v2 |-> (s2 == s2), ist WEAK. Ihre tautologische Konklusion übersteht die relevanten injizierten Mutationen, und der vorgestellte Pipeline-Fall verzeichnet 0/6 Mutations-Kills.

Signalverlauf aus der synthetischen Pipeline für PIPE3, eine tautologische Eigenschaft, die nach null von sechs Mutations-Kills als WEAK eingestuft wurde. — PIPE3: Eine tautologische Konklusion führt nach einem 0/6-Mutations-Kill-Test zu einem WEAK-Ergebnis.

Eine stärkere CDC-Eigenschaft kann ihr eigenes Gegenbeispiel aufzeigen

Die synthetische schwache CDC2-Eigenschaft ist WEAK. Eine Verstärkung zu assert (req && !ack) |-> ##1 req führt auf dem synthetischen CDC-Fixture zu VIOLATED und erzeugt einen konkreten Gegenbeispiel-Signalverlauf. Dies veranschaulicht eine CDC-Fehlerklasse mit verlorenen Transaktionen, stellt jedoch keine Behauptung über einen echten Chip dar.

Konkreter Gegenbeispiel-Signalverlauf für eine verstärkte synthetische CDC-Eigenschaft, die auf dem Fixture als VIOLATED eingestuft wurde. — Die verstärkte synthetische CDC-Eigenschaft ist VIOLATED – mit einem Gegenbeispiel, das Prüfer untersuchen können.

Die Überprüfung hinterlässt einen strukturierten Nachweis

Das signierte Demonstrationszertifikat erfasst das Urteil jeder Eigenschaft, die Erreichbarkeit, Mutationsergebnisse, COI und gegebenenfalls Gegenbeispielaufzeichnungen sowie ein SHA-256-Feld. Dadurch wird das Audit nachvollziehbar, ohne dass Prüfer mutmaßen müssen, warum sich ein Status geändert hat.

Signiertes Proof Firewall Demonstrationszertifikat mit Urteilen je Eigenschaft, Erreichbarkeit, Mutationsergebnissen, Cone of Influence, Gegenbeispieldaten und einem SHA-256-Feld. — Das signierte Demonstrationszertifikat sichert die Nachweise hinter der Zertifizierung oder menschlichen Überprüfung.

Eine engine-agnostische Produktionsausrichtung, kein Ersatz-Solver

Proof Firewall demonstriert ein Gate um Beweisnachweise. Die folgende Übersicht trennt den Leistungsumfang der Demo von künftigen Arbeiten ab.

Frage	Proof Firewall Demo	Produktionsausrichtung
Beweiseingabe	Fixture-basierte synthetische Transitionssystem-IR und SVA	Ein Gate um den bestehenden formalen Ablauf des Kunden
Gezeigte Prüfungen	Vakuität, Mutations-Kill-Test, COI, Richtlinien-Routing, Zertifikatsexport	Dieselben Governance-Fragen angewandt auf bereitgestellte Beweisnachweise
Formale Engines	Kein Adapter für reale Engines	Engine-agnostische Ausrichtung, kein Anspruch auf Integration
Ergebnisbehandlung	TRUSTWORTHY-Zertifikate und begründete Zurückhaltungen	Menschliche Sign-off-Überprüfung mit strukturiertem Nachweisprotokoll

Was diese Demo nicht leistet

✓ Sie parst weder Verilog- noch SystemVerilog-RTL und operiert nicht auf Kunden-RTL, GDSII oder realen Chipdesigns. V1 verwendet synthetische Transitionssystem-IR-Fixtures.
✓ Sie ersetzt weder JasperGold, VC Formal, Questa Formal, SymbiYosys noch andere formale Engines. Adapter für reale Engines sind künftigen Versionen vorbehalten.
✓ Sie verwendet standardmäßig kein Live-LLM. Bei den Properties handelt es sich um Fixture-basierte, von LLMs generierte SVA, und der Standard-Aufzeichnungspfad ist deterministisch.
✓ Sie erhebt keinen Anspruch auf Tape-Out-Bereitschaft, Sicherheitszertifizierung, null Respins, Kundenergebnisse, Produktiveinsätze, ROI oder regulatorische Qualifikation.
✓ Sie stellt 5/8, 18/18, 0/6 oder 7/7 nicht als produktionsreife oder branchenweite Leistung dar. Dies sind Ergebnisse aus festen lokalen synthetischen Fixtures und Tests.

Fragen von Verifikationsleitern

Wir setzen bereits formale Verifikation ein. Warum sollten wir nach einem PROVEN-Ergebnis ein weiteres Gate einrichten?

Ein PROVEN-Ergebnis kann immer noch auf einer unerreichbaren Prämisse oder einer Eigenschaft beruhen, die bei fehlerhaftem Designverhalten nicht fehlschlägt. Proof Firewall demonstriert ein deterministisches Post-Proof-Gate für diese Fragen: Erreichbarkeit, Mutations-Kill-Tests, Cone of Influence und Richtlinien-Routing. Es ersetzt keine formale Engine; seine Produktionsausrichtung ist ein engine-agnostisches Gate um einen bestehenden formalen Ablauf.

Ist Proof Firewall heute an JasperGold, VC Formal, Questa Formal oder SymbiYosys angebunden?

Nein. Adapter für reale Engines sind in dieser Demo zurückgestellt; sie darf daher keinesfalls als Ersatz für JasperGold, VC Formal, Questa Formal, SymbiYosys oder eine andere formale Engine verstanden werden. Die demonstrierte Produktionsausrichtung ist ein engine-agnostisches Governance-Gate um den bestehenden formalen Workflow des Kunden.

Stammen diese Ergebnisse aus Kunden-RTL oder von einem Live-KI-Assertionsgenerator?

Nein. Das Board, die SystemVerilog-Assertionen, Designs, Benchmarks und Gegenbeispiele sind synthetisch. Der Standard-Aufzeichnungspfad verwendet Fixture-basierte, von LLMs erstellte SVA-Properties und eine synthetische Transitionssystem-IR, keine Kunden-RTL oder Live-LLM-Aufrufe.

Was hat das Ergebnis von 8/8 auf 5/8 tatsächlich gemessen?

Es handelt sich um ein festes synthetisches Acht-Eigenschaften-Board. Seine Bare-Flow-Baseline zeigt 8/8 PROVEN; nach dem Firewall-Audit sind fünf als TRUSTWORTHY zertifiziert, während eine Eigenschaft VACUOUS und zwei WEAK sind. Es ist keine Produktions-RTL-Rate, kein Kundenergebnis und kein allgemeingültiges Ergebnis für synthetische KI-generierte Assertionen.

Wie entscheidet die Demo, dass eine Assertion vakant oder schwach ist?

Das Governance-Gate prüft, ob die Prämisse erreichbar ist, führt relevante Einzelpunkt-Designmutationen durch und berechnet den Cone of Influence jeder Eigenschaft. ARB3 ist VACUOUS, da seine Prämisse im synthetischen Arbiter unerreichbar ist. PIPE3 ist WEAK, da seine tautologische Konklusion die relevanten injizierten Mutationen übersteht, mit einem Ergebnis von 0/6 Mutations-Kills im vorgestellten Pipeline-Fall.

Welche Nachweise kann ein Prüfer aus dieser Demo entnehmen?

Die Benutzeroberfläche exportiert signoff_certificate.json mit Urteilen je Eigenschaft, Erreichbarkeit, Mutationsergebnissen, Cone of Influence, gegebenenfalls Gegenbeispiel-Datensätzen und einem SHA-256-Feld. Nur TRUSTWORTHY erhält ein signiertes Demonstrationszertifikat; BOUNDED-PROVEN-, VACUOUS-, WEAK-, DEAD- und VIOLATED-Ergebnisse werden mit Begründung zur menschlichen Überprüfung zurückgehalten.

Technische Forschung

Die Forschung hinter dieser Demo – die Architektur, das Verifikationsdesign und die Enterprise-Blueprint.

Vollständige Lösung

Entdecken Sie die Lösung für Halbleiter-KI-Verifikation & Silizium-Korrektheit →

Beweisqualitäts-Governance in die Sign-off-Diskussion einbringen

Wir laden Verifikationsleiter ein, deterministische Nachweispfade für geschäftskritische, KI-gestützte Engineering-Workflows zu diskutieren.

Das zielführende nächste Gespräch dreht sich um die Beweisartefakte, die Ihr Team prüfen muss, die Richtliniengrenzen, die ein Prüfer vertreten kann, und welche Anforderungen eine engine-agnostische Produktionsausrichtung stellt.

Proof-Governance-Assessment

✓ Den aktuellen Beweisprüfpfad erfassen
✓ Nachweise für Vakuität und Assertionsstärke identifizieren
✓ Sign-off-Richtlinienstatus definieren
✓ Prüfbare Zertifikatsdatensätze spezifizieren

Governance-Pfad-Design

✓ Engine-agnostische Nachweis-Gates entwerfen
✓ Deterministisches Richtlinien-Routing aufbauen
✓ Audit- und Ausnahmeworkflows modellieren
✓ Übergaben für das menschliche Sign-off planen

Über WhatsApp verbinden E-Mail an unser Team