🤖 AI

NoTB: Oracle-Free Triage of LLM-Generated RTL via Cross-Model Formal Consensus

Il documento introduce NoTB, un framework oracle-free che sfrutta il controllo di equivalenza sequenziale attraverso molteplici design RTL generati da LLM per stabilire un segnale di consenso formale, consentendo un triage ad alta precisione della correttezza funzionale senza fare affidamento su testbench o riferimenti golden.

Autori originali: Elisavet Lydia Alvanaki, Je Yang, Biruk Seyoum, Luca P. Carloni

Pubblicato 2026-08-25

📖 5 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Elisavet Lydia Alvanaki, Je Yang, Biruk Seyoum, Luca P. Carloni

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Nel mondo della progettazione di chip per computer, gli ingegneri tradizionalmente scrivono codice che descrive come l'elettricità debba scorrere attraverso un circuito. Questo codice, noto come livello di trasferimento di registro o RTL, funge da progetto per l'hardware fisico. Per decenni, la creazione di questo codice è stata un processo meticoloso, guidato dall'uomo, in cui ogni riga viene controllata rispetto a un riferimento affidabile per garantire che il chip funzioni correttamente. Recentemente, l'intelligenza artificiale ha iniziato a scrivere questo codice per noi. I grandi modelli linguistici, la stessa tecnologia che può scrivere storie o rispondere a domande, vengono ora interrogati per generare questi complessi progetti hardware a partire da semplici descrizioni testuali. Sebbene questi modelli possano produrre molte versioni di un progetto rapidamente, rimane un problema critico: come fanno gli ingegneri a sapere quali di questi progetti generati dall'IA funzionano effettivamente? In passato, la risposta era confrontare l'output dell'IA con un riferimento perfetto creato dall'uomo o eseguirlo attraverso una simulazione di test. Tuttavia, la creazione di questi riferimenti perfetti è costosa e richiede molto tempo, e i test stessi possono talvolta trascurare errori nascosti.

Un team di ricercatori della Columbia University ha introdotto un nuovo modo per esaminare questi progetti generati dall'IA senza la necessità di un riferimento perfetto o di un test pre-scritto. Chiamano il loro sistema NoTB. Invece di affidarsi a un singolo giudice per decidere se un progetto sia buono, o di eseguire una simulazione che potrebbe mancare un difetto critico, NoTB chiede a più modelli di IA differenti di scrivere lo stesso progetto in modo indipendente. Successivamente, utilizza uno strumento matematico rigoroso chiamato controllo di equivalenza sequenziale per vedere se le diverse versioni si comportano esattamente nello stesso modo sotto ogni possibile condizione. L'idea centrale è che se diversi modelli di IA, che sono stati addestrati in modi differenti, arrivano esattamente allo stesso comportamento, è altamente probabile che abbiano trovato la soluzione corretta. Questo approccio consente agli ingegneri di identificare i progetti più affidabili nelle prime fasi del processo, risparmiando tempo e risorse prima di impegnarsi nella costruzione del chip effettivo.

I ricercatori hanno testato questo metodo su settantotto diversi compiti di progettazione hardware. Hanno utilizzato quattro distinte famiglie di modelli linguistici di grandi dimensioni per generare versioni multiple di ciascun progetto. Per ogni compito, hanno confrontato gli output per vedere quali fossero matematicamente identici. Hanno scoperto che quando i progetti di tutte e quattro le diverse famiglie di IA concordavano sullo stesso comportamento, il sistema era corretto quasi il novanta cinque per cento delle volte. Questo alto livello di fiducia comportava un compromesso: il sistema forniva una previsione solo per circa il ventisette per cento dei compiti. Tuttavia, abbassando il requisito a sole tre famiglie concordanti, il sistema poteva coprire il trentatré per cento dei compiti mantenendo comunque un tasso di accuratezza dell'ottantasette per cento. Ciò offre ai progettisti uno strumento flessibile: possono scegliere di essere estremamente cauti e accettare solo i progetti più certi, oppure possono accettare un rischio leggermente superiore per far approvare più progetti per ulteriori test.

Lo studio ha anche rivelato perché i vecchi metodi di controllo dei progetti dell'IA fossero inaffidabili. Un approccio comune consisteva nel chiedere a un secondo modello di IA di agire come giudice e prevedere se un progetto fosse corretto. I ricercatori hanno scoperto che questo metodo era incoerente; lo stesso progetto poteva essere marcato come corretto da un giudice e errato da un altro, a seconda di quale modello di IA stesse effettuando il giudizio. Un altro metodo prevedeva l'esecuzione dei progetti attraverso un test creato da un'IA. I ricercatori hanno scoperto che la qualità dei risultati dipendeva interamente dalla qualità di quel test. Se il test era debole, poteva non riuscire a rilevare gli errori, portando il sistema a credere che un progetto difettoso fosse in realtà corretto. Al contrario, il nuovo metodo non si affida a un test o a un giudice. Si basa sul fatto che i progetti stessi siano provati come identici attraverso l'intero intervallo di possibili input, rendendo l'accordo una proprietà del progetto piuttosto che dello strumento utilizzato per controllarlo.

Per rendere efficiente questo processo, il sistema utilizza una tecnica di filtraggio intelligente. Inveve di confrontare ogni singolo paio di progetti, il che richiederebbe molto tempo, esso rimuove prima i duplicati esatti e poi raggruppa i progetti che sono già stati provati come uguali. Ciò riduce significativamente il numero di confronti necessari. L'intero processo, dalla generazione dei progetti al controllo, richiede in media tra un e sedici minuti per compito, a seconda di quante versioni vengono generate. Anche il costo di esecuzione di questo sistema è gestibile, poiché evita la necessità di costose e ripetute chiamate ai modelli di IA per agire come giudici. I ricercatori sottolineano che questo metodo non sostituisce la necessità di una verifica finale. Funge invece da sistema di triage, un modo per smistare il mucchio di progetti generati dall'IA in modo che i più promettenti possano procedere con fiducia, mentre quelli incerti vengano messi da parte per un controllo più tradizionale e approfondito.

Le scoperte suggeriscono che la diversità dei modelli di IA utilizzati sia la chiave del successo del sistema. I ricercatori hanno testato cosa sarebbe successo se avessero rimosso una delle quattro famiglie di IA dal mix. Hanno scoperto che il sistema rimaneva robusto e accurato anche con la mancanza di un modello, provando che il segnale di fiducia deriva dall'accordo collettivo del gruppo piuttosto che dal ricorso a un singolo modello. Ciò rende l'approccio pratico per l'uso nel mondo reale, dove l'accesso a specifici modelli di IA può variare. Lo studio conclude che spostando l'attenzione dai test simulati alla prova matematica formale dell'accordo, gli ingegneri possono costruire una pipeline più affidabile per l'uso dell'intelligenza artificiale nella progettazione hardware. Ciò consente all'industria di sfruttare la velocità della generazione tramite IA mantenendo al contempo i rigorosi standard di sicurezza richiesti dai complessi chip che alimentano la tecnologia moderna.

Sintesi Tecnica: NoTB – Triage di RTL generato da LLM senza Oracle tramite Consenso Formale Cross-Model

Definizione del Problema
I Large Language Models (LLM) sono sempre più capaci di generare design Register-Transfer-Level (RTL) sintetizzabili a partire da specifiche in linguaggio naturale. Tuttavia, rimane un collo di bottiglia critico: valutare la correttezza funzionale di questi design generati nelle fasi iniziali del processo senza l'accesso a un "oracle" affidabile (come un testbench di riferimento o un modello RTL golden). La costruzione di tali oracle è costosa e soggetta a errori, ed è spesso non disponibile all'inizio di un compito di progettazione.

Gli approcci esistenti privi di oracle soffrono di limitazioni fondamentali:

LLM-as-a-Judge: Sostituisce l'esecuzione con la predizione basata sul modello, ma manca di garanzie formali ed esibisce un forte bias dipendente dal modello, portando a tassi di falso accetto inconsistenti (varianti fino al 45% tra i modelli).
Auto-coerenza basata su Simulazione: Si basa sull'accordo comportamentale sotto testbench generati da LLM. Questo approccio assume che il testbench copra lo spazio di input rilevante e che le implementazioni errate discordino tra loro. In pratica, testbench deboli possono mancare input critici, permettendo a design errati di formare un "falso consenso", mentre modalità di errore condivise possono causare la convergenza di più modelli sullo stesso comportamento errato.

Metodologia: Il Framework NoTB
Gli autori introducono NoTB, un framework che sostituisce l'accordo euristico con il consenso formale cross-model. L'intuizione fondamentale è che se le implementazioni prodotte da famiglie di LLM addestrate indipendentemente sono provate equivalenti su l'intero spazio di input tramite Sequential Equivalence Checking (SEC), il loro accordo è una proprietà dei design stessi, non di un insieme finito di vettori di test.

Il workflow di NoTB si articola in quattro fasi:

Generazione RTL Multi-Modello: Per una data specifica, il sistema campiona molteplici implementazioni RTL da $M$ famiglie di LLM addestrate indipendentemente (ad esempio, Claude, GPT, Gemini, Qwen). Ogni modello genera $K$ candidati, creando un insieme di candidati diversificato $D(s)$ .
Clustering di Equivalenza Formale: NoTB costruisce un grafo dove i nodi rappresentano le implementazioni candidate e gli archi rappresentano l'equivalenza provata. Utilizza uno strumento formale (Cadence JasperGold) per eseguire il Sequential Equivalence Checking (SEC) su coppie di design.
- Due design sono connessi solo se lo strumento prova che producono output identici per tutte le sequenze di input.
- Risultati inconcludenti o discrepanze nell'interfaccia non creano archi.
- I componenti connessi in questo grafo formano cluster di equivalenza.
Pruning Incrementale: Per gestire il costo computazionale ( $O(|D|^2)$ $O (∣ D ∣^{2})$ ), NoTB impiega un pruning leggero:
- File sintatticamente identici vengono uniti tramite hashing prima del SEC.
- Una struttura dati union-find traccia i componenti di equivalenza; una volta che una coppia è provata equivalente, i futuri confronti all'interno di quel componente vengono saltati.
- Le non-equivalenze provate tra i rappresentanti dei componenti impediscono controlli ridondanti tra i componenti.
Punteggio di Confidenza tramite Diversità del Modello: Il sistema identifica il più grande cluster di equivalenza ( $C^*$ $C^{*}$ ) per una specifica. Il punteggio di confidenza è definito come il conteggio dei modelli: il numero di diverse famiglie di LLM rappresentate all'interno di quel cluster.
- Un numero maggiore di modelli indica che modelli con diversi bias induttivi, indipendenti tra loro, sono confluiti nello stesso comportamento formalmente provato.
- I progettisti possono impostare una soglia $\tau$ (ad esempio, $\tau=4$ ) per accettare solo le specifiche in cui il cluster dominante contiene implementazioni provenienti da almeno $\tau$ diverse famiglie. Questo crea un tradeoff regolabile tra precisione (confidenza) e copertura (numero di specifiche accettate).

Contributi Chiave

Dimostrazione della Dipendenza dal Testbench: Il paper mostra che il triage oracle-free basato su simulazione è altamente sensibile al generatore del testbench. Su un pool di candidati fisso, la precisione di un accordo di simulazione a quattro vie variava dal 43% all'84% esclusivamente in base a quale LLM generava il testbench.
Introduzione di NoTB: Un nuovo framework che sostituisce l'accordo appreso/basato su simulazione con il consenso formale cross-model. Esso clusterizza i candidati tramite SEC e li valuta in base alla diversità delle famiglie di LLM nel cluster.
Segnale di Correttezza Calibrato: Evidenza empirica che il conteggio dei modelli è un segnale calibrato per la correttezza. Il sistema dimostra una relazione monotona: un accordo formale cross-model più forte correla con tassi di errore empirico inferiori.

Risultati Sperimentali
Valutato su 78 task di generazione RTL dal benchmark NVIDIA CVDP utilizzando quattro famiglie di LLM (Claude 3.7, GPT-OSS-120B, Gemini 2.5, Qwen 3) con 5 campioni ciascuno:

Consenso a Quattro Famiglie ( $\tau=4$ ): Ha raggiunto una precisione del 94,7% con una copertura del 27%.
Consenso a Tre Famiglie ( $\tau=3$ ): Ha raggiunto una precisione dell'87% con una copertura del 33%.
Confronto con i Baseline:
- LLM-as-a-Judge: Ha mostrato un'alta instabilità; i tassi di falsi positivi variavano significativamente a seconda del generatore e del modello giudice.
- Clustering Basato su Simulazione: La precisione fluttuava selvaggiamente (43%–84%) a seconda del generatore del testbench, mentre il SEC formale rimaneva stabile a circa il 95%.
Robustezza: Studi di ablazione leave-one-out hanno confermato che il segnale ad alta precisione non dipende da una singola famiglia di modelli specifica; l'alta precisione è stata mantenuta anche rimuovendo una famiglia.
Costo: Sebbene il SEC richieda un tempo di calcolo significativo (mediana di 1–16 minuti per specifica a seconda dei campioni), evita i costi massicci di token associati all'esecuzione di migliaia di chiamate a "judge" o alla generazione di molteplici testbench per ogni candidato.

Significatività e Rivendicazioni
Il paper sostiene che NoTB fornisca una base affidabile e oracle-free per il triage ad alta confidenza nelle fasi iniziali del design hardware. Sfruttando le garanzie formali invece di euristiche apprese o vettori di test finiti, NoTB consente ai progettisti di certificare selettivamente un sottoinsieme di design RTL generati che sono probabilmente corretti, consentendo loro di bypassare i controlli della fase iniziale o di dar loro priorità per la verifica finale. Gli autori sottolineano che NoTB non sostituisce la necessità di un oracle fidato o di un flusso di verifica completo; piuttosto, agisce come un filtro per identificare i candidati ad alta confidenza prima che sia disponibile un riferimento golden. Il metodo è presentato come una soluzione pratica al problema del "triage", offrendo un controllo esplicito sul tradeoff rischio-copertura senza richiedere oracle dipendenti dai modelli.

Articoli simili