Gouvernance de sign-off pour le tape-out d'assertions SVA synthétiques générées par IA

Sur un tableau synthétique fixe, 8/8 PROVEN devient 5/8 TRUSTWORTHY après audit.

Proof Firewall réaudite les assertions SystemVerilog synthétiques marquées PROVEN pour en vérifier la vacuité, la force d'assertion et le cône d'influence avant leur intégration dans un fichier de sign-off. Sur le tableau fixe, il convertit 8/8 preuves issues du flux brut en cinq résultats certifiés TRUSTWORTHY et oriente le reste vers une revue humaine assortie d'un motif. Les agents conseillent, le code décide.

8/8 à 5/8

PROVEN à TRUSTWORTHY

Tableau synthétique fixe à huit propriétés après audit par le pare-feu

0/6

Éliminations de mutations pour PIPE3

Cas de pipeline synthétique faible mis en avant

18/18

Concordance sur le benchmark synthétique étiqueté

Benchmark de démonstration locale, et non affirmation d'exactitude en monde ouvert

Il s'agit d'une démonstration exécutable et reproductible utilisant des conceptions et propriétés de systèmes de transition synthétiques issues d'un banc d'essai. Elle n'utilise aucun RTL client, aucun solveur cloud, ni aucun appel LLM en direct sur le chemin par défaut.

L'échec de sign-off est masqué au sein d'un résultat vert

Le taux de réussite au premier silicium a été rapporté à 14% dans l'étude de 2024 de Wilson Research Group et Siemens EDA. Un résultat formel mérite un examen plus approfondi lorsque l'assertion est susceptible d'avoir été générée par IA : une implication peut être PROVEN parce que son antécédent ne se produit jamais, ou parce que son conséquent n'impose aucune contrainte utile.

Proof Firewall est une porte de gouvernance post-preuve déterministe dédiée à cette décision. Il ne déclare pas qu'un moteur formel est erroné. Il détermine si la preuve est suffisamment défendable pour être soumise au sign-off humain de tape-out, puis consigne un motif concret pour chaque résultat certifié ou retenu.

Comment fonctionne la porte de gouvernance

Le point d'ancrage est la qualité de la preuve. Chaque contrôle déterministe teste si une preuve verte possède suffisamment de substance pour être déposée.

Accessibilité avant attribution de crédit

Le vérificateur de modèles à états explicites teste si l'antécédent d'une implication peut se produire dans l'IR du système de transition synthétique. Un antécédent inaccessible est orienté en tant que VACUOUS plutôt que déposé comme preuve.

Test d'élimination par mutation pour mesurer la force

Des mutations de conception ponctuelles pertinentes testent si l'assertion rejette les variantes défaillantes. Une propriété qui survit à ces mutations est orientée en tant que WEAK plutôt que d'emprunter sa confiance à un résultat de solveur vert.

COI et routage de politique

La porte calcule le cône d'influence et attribue TRUSTWORTHY, BOUNDED-PROVEN, VACUOUS, WEAK, DEAD ou VIOLATED. Seul TRUSTWORTHY reçoit un certificat de démonstration signé.

Le vérificateur à états explicites en Python pur de la démonstration trouve l'accessibilité et les traces de contre-exemples dans le modèle fini. Un repli à profondeur bornée est étiqueté comme borné, et non requalifié en preuve sans réserve.

Revue de preuve détaillée sur le tableau synthétique

Chaque image est une capture d'écran de la démonstration synthétique en cours d'exécution. Le tableau commence par huit résultats PROVEN du flux brut, puis l'audit rend visibles les preuves retenues.

L'audit infirme trois résultats verts

Le tableau de sign-off pour le tape-out affiche initialement 8/8 PROVEN dans sa vue du flux brut. Après l'audit par le pare-feu, 5/8 sont certifiées TRUSTWORTHY ; les trois restantes comprennent une propriété VACUOUS et deux propriétés WEAK. Il s'agit d'un banc d'essai synthétique fixe, et non d'une conception client ou d'un résultat de moteur commercial.

Tableau de sign-off pour le tape-out de Proof Firewall montrant cinq propriétés synthétiques sur huit marquées TRUSTWORTHY, avec un résultat VACUOUS et deux résultats WEAK retenus pour examen. — Le tableau synthétique audité : le pare-feu convertit une vue 8/8 PROVEN en cinq certificats TRUSTWORTHY et trois mises en attente expliquées.

ARB3 ne prouve rien car son déclencheur ne se produit jamais

L'assertion synthétique ARB3, assert (g0 && g1) |-> (turn == 0), est VACUOUS parce que son antécédent est inaccessible dans l'arbitre synthétique. Ce résultat démontre pourquoi une implication prouvée peut pourtant ne rien certifier.

Forme d'onde de l'arbitre synthétique montrant ARB3, dont l'antécédent g0 et g1 est inaccessible et par conséquent classé VACUOUS. — ARB3 : un antécédent inaccessible transforme une implication verte en résultat VACUOUS.

PIPE3 survit aux mutations qu'elle devrait intercepter

L'assertion synthétique PIPE3, assert v2 |-> (s2 == s2), est WEAK. Son conséquent tautologique survit aux mutations injectées pertinentes, et le cas de pipeline mis en avant enregistre 0/6 éliminations par mutation.

Forme d'onde du pipeline synthétique montrant PIPE3, une propriété tautologique classée WEAK après avoir enregistré zéro élimination sur six mutations. — PIPE3 : un conséquent tautologique obtient un résultat WEAK après un test de 0/6 éliminations par mutation.

Une propriété CDC plus forte peut afficher son propre contre-exemple

La propriété synthétique faible CDC2 est WEAK. La renforcer en assert (req && !ack) |-> ##1 req la rend VIOLATED sur le banc d'essai CDC synthétique et produit une forme d'onde de contre-exemple concrète. Elle illustre une classe de défaillance CDC de perte de transaction, et non une affirmation sur une puce réelle.

Forme d'onde de contre-exemple concrète pour une propriété CDC synthétique renforcée classée VIOLATED sur le banc d'essai. — La propriété synthétique CDC renforcée est VIOLATED, avec un contre-exemple qu'un réviseur peut inspecter.

La revue produit un récépissé structuré

Le certificat de démonstration signé consigne le verdict de chaque propriété, son accessibilité, ses résultats de mutation, son COI et les enregistrements de contre-exemples le cas échéant, ainsi qu'un champ SHA-256. Il rend l'audit vérifiable sans contraindre l'examinateur à deviner pourquoi un statut a changé.

Certificat de démonstration signé de Proof Firewall montrant les verdicts par propriété, l'accessibilité, les résultats de mutation, le cône d'influence, les enregistrements de contre-exemples et un champ SHA-256. — Le certificat de démonstration signé conserve les preuves sous-tendant la certification ou la revue humaine.

Une orientation de production agnostique au moteur, et non un solveur de remplacement

Proof Firewall présente une porte encadrant les preuves formelles. Le périmètre ci-dessous distingue ce que réalise la démonstration des travaux différés.

Question	Démo Proof Firewall	Orientation de production
Entrée de preuve	IR de système de transition synthétique et SVA issus du banc d'essai	Une porte encadrant le flux formel existant du client
Vérifications présentées	Vacuité, test d'élimination par mutation, COI, routage de politique, export de certificat	Mêmes questions de gouvernance appliquées aux preuves formelles fournies
Moteurs formels	Aucun adaptateur de moteur réel	Orientation agnostique au moteur, sans revendication d'intégration
Traitement des résultats	Certificats TRUSTWORTHY et mises en attente expliquées	Revue humaine de sign-off avec un dossier de preuves structuré

Ce que cette démonstration ne fait pas

✓ Elle n'analyse pas de RTL Verilog ou SystemVerilog et n'opère pas sur du RTL client, du GDSII ou une conception de puce réelle. La V1 utilise des bancs d'essai d'IR de systèmes de transition synthétiques.
✓ Elle ne remplace pas JasperGold, VC Formal, Questa Formal, SymbiYosys ou un autre moteur formel. Les adaptateurs de moteurs réels sont différés.
✓ Elle n'utilise pas de LLM en direct par défaut. Les propriétés sont des SVA rédigées par LLM issues d'un banc d'essai, et le chemin d'enregistrement par défaut est déterministe.
✓ Elle ne revendique pas l'aptitude au tape-out, de certification de sûreté, de zéro respin, de résultats clients, de déploiements, de ROI ou de qualification réglementaire.
✓ Elle ne présente pas 5/8, 18/18, 0/6 ou 7/7 comme des performances de niveau production ou à l'échelle de l'industrie. Ce sont des résultats issus de bancs d'essai et de tests synthétiques locaux fixes.

Questions que posent les responsables de la vérification

Nous exécutons déjà de la vérification formelle. Pourquoi ajouter une autre porte après un résultat PROVEN ?

Un résultat PROVEN peut toujours reposer sur un antécédent inaccessible ou sur une propriété qui n'échoue pas lorsque le comportement de conception pertinent est altéré. Proof Firewall démontre une porte post-preuve déterministe pour traiter ces questions : accessibilité, tests d'élimination par mutation, cône d'influence et routage de politique. Il ne remplace pas un moteur formel ; son orientation de production est une porte agnostique au moteur encadrant un flux formel existant.

Proof Firewall se connecte-t-il aujourd'hui à JasperGold, VC Formal, Questa Formal ou SymbiYosys ?

Non. Les adaptateurs de moteurs réels sont différés dans cette démonstration, elle ne doit donc pas être interprétée comme un remplacement de JasperGold, VC Formal, Questa Formal, SymbiYosys ou d'un autre moteur formel. L'orientation de production démontrée est une porte de gouvernance agnostique au moteur encadrant le flux de travail formel existant du client.

Ces résultats proviennent-ils du RTL d'un client ou d'un générateur d'assertions IA en direct ?

Non. Le tableau, les assertions SystemVerilog, les conceptions, le benchmark et les contre-exemples sont synthétiques. Le chemin d'enregistrement par défaut utilise des propriétés SVA rédigées par LLM issues d'un banc d'essai et une IR de système de transition synthétique, et non du RTL client ou un appel LLM en direct.

Qu'a réellement mesuré le résultat de 8/8 à 5/8 ?

Il s'agit d'un tableau synthétique fixe de huit propriétés. Sa référence en flux brut affiche 8/8 PROVEN ; après l'audit par le pare-feu, cinq sont certifiées TRUSTWORTHY, tandis qu'une est VACUOUS et deux sont WEAK. Il ne s'agit pas d'un taux de RTL en production, d'un résultat client ou d'un résultat général pour les assertions synthétiques rédigées par IA.

Comment la démonstration détermine-t-elle qu'une assertion est vacueuse ou faible ?

La porte de gouvernance vérifie si l'antécédent est accessible, exécute des mutations de conception ponctuelles pertinentes et calcule le cône d'influence de chaque propriété. ARB3 est VACUOUS parce que son antécédent est inaccessible dans l'arbitre synthétique. PIPE3 est WEAK parce que son conséquent tautologique survit aux mutations injectées pertinentes, avec un résultat de 0/6 éliminations par mutation dans le cas de pipeline mis en avant.

Quelles preuves un réviseur peut-il extraire de cette démonstration ?

L'interface utilisateur exporte le fichier signoff_certificate.json contenant les verdicts par propriété, l'accessibilité, les résultats de mutation, le cône d'influence, les enregistrements de contre-exemples le cas échéant, ainsi qu'un champ SHA-256. Seul TRUSTWORTHY reçoit un certificat de démonstration signé ; les résultats BOUNDED-PROVEN, VACUOUS, WEAK, DEAD et VIOLATED sont retenus pour revue humaine avec un motif explicatif.

Recherche technique

La recherche derrière cette démonstration — l'architecture, la conception de la vérification et le plan d'ensemble pour l'entreprise.

Solution complète

Découvrez la solution Semiconductor AI Verification & Silicon Correctness →

Introduisez la gouvernance de la qualité des preuves dans la discussion de sign-off

Nous invitons les responsables de la vérification à échanger sur les parcours de preuves déterministes pour les flux d'ingénierie assistés par IA à enjeux critiques.

La prochaine discussion utile porte sur les artefacts de preuve que votre équipe doit inspecter, la frontière de politique qu'un réviseur peut défendre et ce qu'exigerait une orientation de production agnostique au moteur.

Évaluation de la gouvernance des preuves

✓ Cartographier le parcours actuel de revue des preuves
✓ Identifier les preuves de vacuité et de force
✓ Définir les états de politique de sign-off
✓ Spécifier des enregistrements de certificat vérifiables

Conception du parcours de gouvernance

✓ Concevoir des portes de preuves agnostiques au moteur
✓ Construire un routage de politique déterministe
✓ Modéliser les flux d'audit et de gestion des exceptions
✓ Planifier les passages de relais pour le sign-off humain

Échanger via WhatsApp Envoyer un e-mail à notre équipe