Lo sviluppo di agenti AI incontra i worktree RTL di NVIDIA
NVIDIA Research ha presentato HORIZON il 4 luglio 2026 come framework hands-free per lo sviluppo di agenti AI nel design hardware, trattando il lavoro RTL come evoluzione del codice a livello di repository invece di generazione one-shot. Questo è importante perché sposta il design dell'agente dall'output di codice plausibile all'accettazione eseguibile, con i commit git che fungono da checkpoint rigidi. Secondo un riassunto di MarkTechPost sul paper, il sistema ha raggiunto il 100% di completamento nelle suite di benchmark RTL valutate.
HORIZON di NVIDIA trasforma l'RTL in un loop agent nativo git
Ho interpretato HORIZON meno come una storia di modello e più come una storia di workflow. Il team di ricerca di NVIDIA Research non sostiene che un backbone più grande abbia risolto improvvisamente il design hardware. Sostiene che l'unità di lavoro era sbagliata. Invece di chiedere a un modello una risposta Verilog finita, HORIZON inserisce il task all'interno di un git worktree isolato, modifica i file, esegue gli evaluator e salva il progresso solo quando il gate viene superato.
Questa distinzione conta nei team semiconductor e EDA perché l'RTL plausibile è economico, ma l'RTL che passa i test è costoso. Un modulo può sembrare corretto e comunque fallire sul comportamento di reset, la gestione dei bit-width o i casi limite del simulatore. HORIZON fa diventare il repository, non il prompt, la superficie operativa.
Il risultato principale è solido: 100% di completamento su ChipBench, RTLLM, Verilog-Eval e CVDP nel paper HORIZON su arXiv, con il paper che nota come un miss residuo fosse dovuto a un difetto dell'harness di benchmark piuttosto che a un fallimento dell'agente. Ma la claim più importante è architetturale: il feedback eseguibile è il loop.
Come parafrasa il riassunto originale, "il design hardware agentico non è risolto." Questa cautela è importante. Il paper riporta un traguardo, non una conclusione.
Come l'harness Markdown diventa il project pack
L'input rivolto all'operatore è un harness Markdown strutturato con quattro parti: obiettivo, guida di dominio, specifica dell'evaluator e predicato di accettazione. Mi piace questo design perché obbliga il team a scrivere cosa significa successo prima che l'agente inizi a modificare il codice.
In termini pratici, l'harness diventa un project pack contenente la policy dell'agente, l'evaluator eseguibile, la regola di accettazione, il comportamento di version control e le skill di dominio. Per l'RTL, quell'evaluator può includere compilazione, simulazione, asserzioni ed estrazione di coverage. In altre parole, HORIZON non sta solo generando codice; sta generando codice all'interno di un ambiente che può rifiutarlo.
Questo è un pattern utile per agenti AI personalizzati oltre l'hardware. In un engagement con un cliente, la modalità di fallimento più grande non era la qualità del modello. Era l'assenza di una condizione di pass eseguibile. Se l'unico criterio è "sembra buono," un agente deriverà. Se il criterio è "passa questo test harness," il loop diventa gestibile.
Il paper su arXiv fa anche un'importante osservazione implementativa: lo stesso slot usato per la simulazione in RTL potrebbe contenere unit test, theorem prover, profiler o tool di sintesi in altri domini. Ecco perché questa ricerca conta tanto per le più ampie integrazioni AI enterprise quanto per i team di chip.
Cosa significa l'evoluzione a livello di repository per i team hardware
Ecco la parte che mi aspetto i leader ingegneristici prendano in prestito per primi. Git in HORIZON non è solo logging. È il control plane. I diff espongono la modifica di stato proposta, i commit segnano i checkpoint accettati e le note preservano l'evidenza dell'evaluator. Questo è operativamente più pulito che agganciare un memory store separato su uno stack agent e sperare che resti consistente.
Ho visto progetti di automazione dei workflow AI fallire perché ogni run lascia dietro modifiche parziali, retry non tracciabili e output di test ambigui. Il loop di HORIZON è più rigido: ispeziona le modifiche staged, esegue l'evaluator, committa se passa, logga se fallisce. Questo rende il rollback, il replay e l'audit molto più semplici.
Per i team hardware, i casi d'uso a breve termine sono piuttosto diretti:
- generazione RTL da specifiche in linguaggio naturale
- code completion all'interno di moduli esistenti
- modifica e riuso di moduli
- generazione di stimulus di test, checker e asserzioni
- debugging contro il feedback del simulatore
Questi mappano da vicino alle categorie in CVDP e RTLLM-2.0. Mappano anche a come gli agenti di automazione AI vengono deployati in ambienti ingegneristici reali: non come copilot universali, ma come worker all'interno di loop bounded.
C'è anche un angolo economico. Il report dice che le nove categorie CVDP hanno consumato 203,9 milioni di token, ovvero il 97,1% dell'uso totale di token, mentre circa il 91% di tutti i token erano input cached. Questo mi dice che il problema del costo si è spostato. Una volta che la correttezza diventa alta, i team smettono di discutere se l'agente può risolvere il task e iniziano a chiedere quante iterazioni ci vogliono per farlo a buon mercato.
Da dove vengono i guadagni di benchmark — e dove no
Il numero del 100% necessita di contesto. Il pass rate aggregato di HORIZON alla prima iterazione era del 47,8%, non del 100%. Il punteggio finale è arrivato dalla riparazione iterativa. Questa è una feature, non una debolezza, ma cambia come farei benchmark internamente dello sviluppo di agenti AI.
Se un team traccia solo Pass@1, perderà ciò per cui questo sistema è costruito. HORIZON è progettato per differire parte del debugging a iterazioni successive. Sulle suite più semplici come RTLLM-2.0 e Verilog-Eval-v2, la convergenza è avvenuta entro due iterazioni. Sulle categorie più difficili, la coda era lunga. La generazione di checker CID 013 di CVDP è partita dal 3,8% e ha raggiunto il 100% all'iterazione 19. Il code completion CID 002 ha necessitato 82 iterazioni e 56,0 milioni di token.
Questa dispersione è il vero segnale operativo. Alcuni task sono quasi pronti per l'automazione di routine. Altri sono tecnicamente risolvibili ma costosi al punto che si vorrebbe un'architettura di integrazione AI migliore prima di deployare a scala.
Penso anche che il dettaglio del backbone fisso conti. Il paper dice che GPT-5.3 è rimasto fisso per tutta la campagna. HORIZON registra le transizioni di stato usando linguaggio semi-Markov, ma non sta addestrando una nuova policy RL durante la run. Questo significa che il miglioramento delle prestazioni deriva dal design del loop, dalla disciplina di valutazione e dalla memoria del repository, non da aggiornamenti dei pesi online.
Per i team enterprise che guardano a servizi di automazione dei workflow AI, questa è la lezione trasferibile. Loop migliori spesso battono più tinkering sul modello.
I limiti: passare l'harness non è la stessa cosa che risolvere il design
Qui penso che il paper sia rinfrescante onesto. Passare l'harness visibile non è la stessa cosa che soddisfare il pieno intento di design. Gli autori evidenziano esplicitamente il rischio di reward hacking e over-solving. Se l'evaluator vede solo una parte della specifica, l'agente può ottimizzare per il test visibile piuttosto che per il requisito reale.
Questo problema non è unico dell'RTL. Si manifesta anche in repository software, automazioni di supporto e agent di tooling interni. Se il predicato di accettazione è superficiale, la metrica di successo sarà superficiale.
L'altra limitazione è il tempo di turnaround. HORIZON appare più forte dove il feedback è relativamente veloce: compila, simula, asserisci, ripeti. Il paper nota che i loop orientati al PPA possono richiedere giorni o settimane. In quel contesto, la stessa struttura nativa del repository può ancora aiutare, ma l'economia e la logica di scheduling cambiano completamente.
Quindi cosa dovrebbero guardare i team? Primo, se i lavori successivi aggiungono test nascosti, check randomizzati e verifica formale per ridurre il reward hacking. Secondo, se questi loop nativi del repository possono mantenere la loro disciplina quando gli evaluator diventano più lenti, più ampi e più costosi degli harness di benchmark attuali.
Letture correlate
Martin Kuvandzhiev
CEO and Founder of Encorp.io with expertise in AI and business transformation