Governance del sign-off di tape-out per SVA sintetiche generate da AI

Su una scheda sintetica fissa, 8/8 PROVEN diventa 5/8 TRUSTWORTHY dopo l'audit.

Proof Firewall ri-audita le asserzioni SystemVerilog sintetiche contrassegnate come PROVEN per vacuità, robustezza dell'asserzione e cono di influenza prima che entrino in un file di sign-off. Sulla scheda fissa, trasforma 8/8 prove di flusso bare-flow in cinque risultati certificati TRUSTWORTHY e instrada il resto a revisione umana con una motivazione. Gli agenti consigliano, il codice decide.

Da 8/8 a 5/8

Da PROVEN a TRUSTWORTHY

Scheda fissa sintetica a otto proprietà dopo l'audit del firewall

0/6

Kill di mutazione su PIPE3

Caso in evidenza della pipeline debole sintetica

18/18

Concordanza del benchmark sintetico etichettato

Benchmark di demo locale, non una rivendicazione di accuratezza in contesti aperti

Questa è una dimostrazione eseguibile e riproducibile che impiega progetti e proprietà di sistemi di transizione sintetici definiti da fixture. Non utilizza RTL dei clienti, un solver cloud o chiamate LLM in tempo reale sul percorso predefinito.

Il fallimento di sign-off si nasconde dentro un risultato verde

Il successo al primo silicio è stato riportato al 14% nello studio del 2024 di Wilson Research Group e Siemens EDA. Un risultato formale merita un esame più attento quando l'asserzione può essere generata da AI: un'implicazione può risultare PROVEN perché il suo antecedente non si verifica mai, o perché il suo conseguente non vincola nulla di utile.

Proof Firewall è un gate deterministico di governance post-prova per questa decisione. Non dichiara errato un motore formale. Si chiede se la prova sia sufficientemente difendibile da essere registrata per il sign-off umano di tape-out, lasciando quindi una motivazione concreta per ogni risultato certificato o trattenuto.

Come funziona il gate di governance

Il fulcro è la qualità della prova. Ciascun controllo deterministico verifica se una prova verde abbia sostanza sufficiente per essere registrata.

Raggiungibilità prima del credito

Il model checker a stati espliciti verifica se l'antecedente di un'implicazione possa verificarsi nell'IR del sistema di transizione sintetico. Un antecedente irraggiungibile viene instradato come VACUOUS invece di essere registrato come evidenza.

Test di eliminazione delle mutazioni per la robustezza

Mutazioni di progetto a singolo punto rilevanti verificano se l'asserzione respinge le varianti difettose. Una proprietà che sopravvive a tali mutazioni viene instradata come WEAK invece di poter prendere in prestito affidabilità da un risultato verde del solver.

COI e instradamento delle policy

Il gate calcola il cono di influenza e assegna TRUSTWORTHY, BOUNDED-PROVEN, VACUOUS, WEAK, DEAD o VIOLATED. Solo TRUSTWORTHY riceve un certificato dimostrativo firmato.

Il checker a stati espliciti in puro Python della demo individua tracce di raggiungibilità e controesempi nel modello finito. Un fallback a profondità limitata viene etichettato come bounded, non riformulato come prova incondizionata.

Revisione dettagliata delle prove sulla scheda sintetica

Ogni immagine è uno screenshot della demo sintetica in esecuzione. La scheda inizia come otto risultati bare-flow PROVEN, poi l'audit rende visibile l'evidenza trattenuta.

L'audit ribalta tre risultati verdi

La Tape-Out Sign-Off Board mostra inizialmente 8/8 PROVEN nella sua vista bare-flow. Dopo l'audit del firewall, 5/8 sono certificate TRUSTWORTHY; le rimanenti tre sono una proprietà VACUOUS e due WEAK. Si tratta di una fixture sintetica fissa, non del progetto di un cliente o del risultato di un motore commerciale.

La Tape-Out Sign-Off Board di Proof Firewall mostra cinque proprietà sintetiche su otto contrassegnate come TRUSTWORTHY, con un risultato VACUOUS e due WEAK trattenuti per la revisione. — La scheda sintetica sottoposta ad audit: il firewall converte una vista 8/8 PROVEN in cinque certificati TRUSTWORTHY e tre sospensioni motivate.

ARB3 non prova nulla perché il suo trigger non si verifica mai

L'asserzione sintetica ARB3, assert (g0 && g1) |-> (turn == 0), è VACUOUS perché il suo antecedente è irraggiungibile nell'arbitro sintetico. Il risultato dimostra perché un'implicazione provata può comunque non certificare nulla.

Forma d'onda dall'arbitro sintetico che mostra ARB3, il cui antecedente g0 e g1 è irraggiungibile e quindi classificato VACUOUS. — ARB3: un antecedente irraggiungibile trasforma un'implicazione verde in un risultato VACUOUS.

PIPE3 sopravvive alle mutazioni che dovrebbe intercettare

L'asserzione sintetica PIPE3, assert v2 |-> (s2 == s2), è WEAK. Il suo conseguente tautologico sopravvive alle mutazioni rilevanti iniettate, e il caso di pipeline in evidenza registra 0/6 mutazioni eliminate.

Forma d'onda dalla pipeline sintetica che mostra PIPE3, una proprietà tautologica classificata WEAK dopo aver registrato zero eliminazioni di mutazioni su sei. — PIPE3: un conseguente tautologico ottiene un risultato WEAK dopo un test di eliminazione delle mutazioni di 0/6.

Una proprietà CDC più forte può mostrare il proprio controesempio

La proprietà sintetica debole CDC2 è WEAK. Rafforzarla in assert (req && !ack) |-> ##1 req la rende VIOLATED sulla fixture CDC sintetica e produce una forma d'onda di controesempio concreta. Illustra una classe di guasto CDC con transazione persa, non un'affermazione su un chip reale.

Forma d'onda di controesempio concreta per una proprietà CDC sintetica rafforzata classificata VIOLATED sulla fixture. — La proprietà CDC sintetica rafforzata è VIOLATED, con un controesempio che un revisore può ispezionare.

La revisione lascia una ricevuta strutturata

Il certificato dimostrativo firmato registra per ciascuna proprietà verdetto, raggiungibilità, risultati delle mutazioni, COI e registri di controesempi ove applicabile, oltre a un campo SHA-256. Rende l'audit esaminabile senza richiedere a un revisore di dedurre il motivo per cui uno stato è cambiato.

Certificato dimostrativo firmato di Proof Firewall che mostra i verdetti per proprietà, la raggiungibilità, i risultati delle mutazioni, il cono di influenza, i record di controesempio e un campo SHA-256. — Il certificato dimostrativo firmato conserva le evidenze a supporto della certificazione o della revisione umana.

Una direzione di produzione agnostica rispetto al motore, non un solver sostitutivo

Proof Firewall dimostra un gate attorno alle evidenze di prova. L'ambito sottostante separa ciò che la demo fa dal lavoro differito.

Domanda	Demo di Proof Firewall	Direzione di produzione
Input di prova	IR del sistema di transizione sintetico e SVA definiti da fixture	Un gate attorno al flusso formale esistente del cliente
Controlli mostrati	Vacuità, test di eliminazione delle mutazioni, COI, instradamento delle policy, esportazione del certificato	Le stesse questioni di governance applicate alle evidenze di prova fornite
Motori formali	Nessun adapter per motori reali	Direzione agnostica rispetto al motore, non una rivendicazione di integrazione
Gestione dei risultati	Certificati TRUSTWORTHY e sospensioni motivate	Revisione umana del sign-off con un registro strutturato delle evidenze

Cosa non fa questa demo

✓ Non analizza il codice RTL Verilog o SystemVerilog, né opera su RTL dei clienti, GDSII o progetti di chip reali. La V1 impiega fixture IR sintetiche di sistemi di transizione.
✓ Non sostituisce JasperGold, VC Formal, Questa Formal, SymbiYosys o altri motori formali. Gli adapter per motori reali sono differiti.
✓ Non impiega un LLM live per impostazione predefinita. Le proprietà sono SVA generate da LLM definite da fixture, e il percorso di registrazione predefinito è deterministico.
✓ Non rivendica prontezza per il tape-out, certificazioni di sicurezza, zero respin, risultati dei clienti, implementazioni, ROI o qualificazioni normative.
✓ Non presenta 5/8, 18/18, 0/6 o 7/7 come prestazioni di produzione o di settore. Si tratta di risultati ricavati da fixture e test sintetici locali e fissi.

Domande che i responsabili della verifica pongono

Eseguiamo già la verifica formale. Perché dovremmo inserire un altro gate dopo un risultato PROVEN?

Un risultato PROVEN può comunque poggiare su un antecedente irraggiungibile o su una proprietà che non fallisce quando il comportamento di progetto rilevante è compromesso. Proof Firewall dimostra un gate deterministico post-prova per queste problematiche: raggiungibilità, test di eliminazione delle mutazioni, cono di influenza e instradamento delle policy. Non sostituisce un motore formale; la sua direzione di produzione è un gate agnostico rispetto al motore attorno a un flusso formale esistente.

Proof Firewall si connette oggi a JasperGold, VC Formal, Questa Formal o SymbiYosys?

No. Gli adapter per motori reali sono differiti in questa demo, pertanto non deve essere interpretata come un sostituto di JasperGold, VC Formal, Questa Formal, SymbiYosys o altri motori formali. La direzione di produzione dimostrata è un gate di governance agnostico rispetto al motore attorno al flusso di lavoro formale esistente del cliente.

Questi risultati provengono dall'RTL di un cliente o da un generatore di asserzioni AI in tempo reale?

No. La scheda, le asserzioni SystemVerilog, i progetti, il benchmark e i controesempi sono sintetici. Il percorso di registrazione predefinito utilizza proprietà SVA create da LLM e definite da fixture e un IR di sistema di transizione sintetico, non RTL dei clienti o chiamate LLM in tempo reale.

Cosa ha effettivamente misurato il risultato da 8/8 a 5/8?

Si tratta di una scheda sintetica fissa a otto proprietà. La sua baseline bare-flow mostra 8/8 PROVEN; dopo l'audit del firewall, cinque sono certificate TRUSTWORTHY mentre una è VACUOUS e due sono WEAK. Non è una percentuale su RTL di produzione, un risultato di un cliente o un risultato generale per asserzioni sintetiche generate da AI.

In che modo la demo decide che un'asserzione è vacua o debole?

Il gate di governance verifica se l'antecedente sia raggiungibile, esegue mutazioni di progetto a singolo punto rilevanti e calcola il cono di influenza di ciascuna proprietà. ARB3 è VACUOUS perché il suo antecedente è irraggiungibile nell'arbitro sintetico. PIPE3 è WEAK perché il suo conseguente tautologico sopravvive alle mutazioni rilevanti iniettate, con un risultato di eliminazione delle mutazioni di 0/6 nel caso di pipeline in evidenza.

Quali evidenze può trarre un revisore da questa demo?

L'interfaccia utente esporta signoff_certificate.json con i verdetti per proprietà, la raggiungibilità, i risultati delle mutazioni, il cono di influenza, i registri dei controesempi ove applicabile e un campo SHA-256. Solo TRUSTWORTHY riceve un certificato dimostrativo firmato; i risultati BOUNDED-PROVEN, VACUOUS, WEAK, DEAD e VIOLATED vengono trattenuti per la revisione umana con una motivazione.

Ricerca tecnica

La ricerca alla base di questa demo: l'architettura, il progetto di verifica e il blueprint aziendale.

Soluzione completa

Esplora la soluzione Semiconductor AI Verification & Silicon Correctness →

Porta la governance della qualità delle prove nella discussione sul sign-off

Invitiamo i leader della verifica a confrontarsi sui percorsi di evidenza deterministici per i flussi di lavoro ingegneristici assistiti da AI ad alta posta in gioco.

La conversazione successiva più utile riguarda gli artefatti di prova che il tuo team deve esaminare, il confine di policy che un revisore può difendere e ciò che richiederebbe una direzione di produzione agnostica rispetto al motore.

Valutazione della governance delle prove

✓ Mappa l'attuale percorso di revisione delle prove
✓ Identifica le evidenze di vacuità e robustezza
✓ Definisci gli stati delle policy di sign-off
✓ Specifica i registri dei certificati esaminabili

Progettazione del percorso di governance

✓ Progetta gate di evidenza agnostici rispetto al motore
✓ Costruisci un instradamento deterministico delle policy
✓ Modella i flussi di lavoro di audit ed eccezioni
✓ Pianifica i passaggi di consegne per il sign-off umano

Contattaci via WhatsApp Invia un'email al nostro team