🤖 AI

ContractHIL-HLS: Contract-Aligned Multi-Agent Workflow with Hardware-in-the-Loop Feedback for HLS Design

Questo articolo introduce ContractHIL-HLS, un workflow multi-agente allineato ai contratti che integra la traduzione strutturata dal linguaggio naturale al contratto con il feedback hardware-in-the-loop per migliorare significativamente i tassi di successo nei compiti di progettazione HLS e ottimizzare gli acceleratori di crittografia post-quantistica a livello di scheda.

Autori originali: Jingbo Zhang, Haoxiang Sun, Wenbo Wang, Wenbo Zhang

Pubblicato 2026-07-29

📖 7 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Jingbo Zhang, Haoxiang Sun, Wenbo Wang, Wenbo Zhang

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

Immagina di cercare di insegnare a un robot brillante e iperveloce come costruire una macchina complessa, come una console per videogiochi personalizzata o una cassaforte super sicura. Fornisci al robot istruzioni in linguaggio naturale, come "Rendila veloce e sicura". Il robot, alimentato da un Large Language Model (un'IA che legge e scrive codice), prova a costruire il progetto. Ma c'è un problema: il robot è bravo a scrivere l'idea del codice, ma spesso dimentica le regole minuscole e noiose di cui le macchine reali hanno bisogno per funzionare davvero, come quanta energia consumano o se i componenti si incastrano tra loro. Questo è il mondo della Sintesi ad Alto Livello (HLS), dove gli esseri umani cercano di usare l'IA per trasformare idee semplici in veri design hardware per chip. La grande domanda non è solo "L'IA sa scrivere codice?", ma "Lamente l'IA sia in grado di costruire qualcosa che funzioni davvero su una scheda reale senza che noi dobbiamo correggere ogni singolo errore a mano?".

È qui che entra in gioco un team di ricercatori della Università di Tecnologia di Pechino con una nuova idea chiamata ContractHIL-HLS. Immaginala come un "project manager intelligente" per l'IA. Invece di lasciare semplicemente che l'IA chiacchieri con te, la costringono a firmare un "contratto" formale prima di iniziare. Questo contratto è una lista rigorosa e strutturata di regole: "Ecco esattamente cosa deve fare la macchina, ecco le cose che assolutamente non può fare e ecco come la testeremo". Se l'IA tenta di infrangere le regole, il sistema lo rileva immediatamente. Ancora più interessante, collegano questo processo all'hardware reale. Se l'IA progetta un chip che scotta troppo o è troppo lento, la macchina reale invia un "rapporto di errore" all'IA, la quale deve quindi riscrivere il design per risolvere il problema. È come in un videogioco dove il personaggio non si limita a indovinare la soluzione; viene colpito da una trappola, vede esattamente perché ha fallito e riprova con un piano migliore.

Il Problema: L'IA è brava a chiacchierare, ma scarsa a costruire

Di solito, quando chiedi a un'IA di progettare dell'hardware, essa agisce come uno scrittore creativo. Genera codice basato sul tuo prompt, ma spesso dimentica le "clausole scritte in piccolo". Magari utilizza una funzione che il chip hardware non supporta, o crea un design che sembra bello sulla carta ma che crasha quando provi a eseguirlo. I metodi precedenti cercavano di risolvere il problema facendo interpretare all'IA ruoli diversi, come "Architetto" o "Programmatore", ma l'IA spesso dimenticava ciò che l'Architetto aveva detto nel momento in cui il Programmatore iniziava a lavorare. L'intento del design andava perduto nella conversazione.

I ricercatori si sono resi conto che, invece di affidarsi a una conversazione lunga e disordinata, avevano bisogno di un contratto strutturato. Immagina di ordinare una pizza personalizzata. Invece di dire semplicemente "Voglio una pizza deliziosa", compili un modulo: "Crosta: Sottile. Condimenti: Solo Pepperoni. Niente funghi. Deve essere pronta in 10 minuti". Questo modulo è il "contratto". Nel mondo del design dei chip, questo contratto traduce la tua idea vaga in un insieme rigoroso di regole che l'IA deve seguire.

La Soluzione: Il Workflow a Tre Agenti

Il team ha costruito un sistema con tre "agenti" specializzati (aiutanti IA) che lavorano insieme come un ingranaggio ben oliato:

L'Agente del Contratto (Contract Agent): Questo agente prende la tua richiesta disordinata in linguaggio naturale (ad esempio, "Crea un sistema di messaggistica sicuro") e la trasforma in quel contratto rigoroso tipo "ordine della pizza". Definisce l'interfaccia, i vincoli (cosa è proibito) e le regole per i test.
L'Agente HTML (HTML Agent): Questo agente prende il contratto e lo trasforma in una pagina web pulita e strutturata (HTML). Perché una pagina web? Perché è facile da leggere per gli umani, facile da comprendere per il successivo agente IA ed è facile da controllare tramite script informatici. Funge da registro permanente e immutabile delle regole.
L'Agente Hardware-in-the-Loop (HIL Agent): Questo è il costruttore. Esamina il contratto HTML, scrive il codice e poi — ecco la parte magica — lo testa effettivamente su hardware reale o lo simula. Se l'hardware dice: "Ehi, questo design usa troppa memoria", l'agente HIL vede questa evidenza, legge il contratto e riscrive il codice per correggere l'errore. Se non riesce a ripararlo, il sistema sa di dover fare un "rollback" e provare un approccio diverso.

Cosa hanno scoperto: Piccole vittorie e Grandi balzi

Il team ha testato questo sistema in due modi molto diversi per vedere se funzionasse davvero.

1. Il "Test del Piccolo Design" (HLS-Eval)
Per prima cosa, hanno testato il sistema su 94 piccoli compiti di programmazione standard. Hanno confrontato tre metodi:

Diretto: Chiedere all'IA senza regole speciali.
Contratto: Usare il contratto strutturato ma senza il feedback dell'hardware reale.
ContractHIL-HLS: Usare il sistema completo con il contratto e il feedback dell'hardware.

I risultati sono stati chiari. Il metodo "Diretto" ha superato i test circa il 64,0% delle volte. Quando hanno aggiunto il Contratto, il tasso di successo è salito al 70,2%. Il sistema completo ha raggiunto il 70,4% per tentativi singoli e il 76,6% se si lasciava l'IA provare cinque volte. Questo dimostra che il semplice fatto di costringere l'IA a seguire un contratto strutturato la rende molto più affidabile, anche prima di toccare l'hardware reale.

2. Il "Test del Mondo Reale" (Caso di studio PQC)
I test piccoli sono utili, ma funzionano per sistemi grandi e complessi? Per scoprirlo, il team ha costruito un acceleratore di messaggi sicuri utilizzando la Crittografia Post-Quantistica (PQC) — un modo super sicuro per inviare messaggi che nemmeno i futuri computer quantistici possono violare. Questa è una sfida ingegneristica enorme che coinvolge memoria, tempi di esecuzione e potenza.

Sono partiti da un singolo design (un singolo "bitstream") che impiegava 207,3 ms per elaborare un messaggio. Il sistema ha analizzato il feedback dell'hardware e ha capito che il design era troppo affollato e lento. Seguendo le regole del contratto, l'IA ha diviso il design in due parti separate (un'organizzazione a "dual-bitstream"). Una parte gestiva l'invio, l'altra la ricezione.

Il risultato? Il nuovo design elaborava i messaggi in soli 52,4 ms. Si tratta di un aumento di velocità enorme! Ha anche consumato meno energia e ha superato tutti i controlli temporali. Il sistema ha usato con successo il "contratto" per guidare l'IA da un design lento e singolo a un design veloce e diviso, mantenendo intatte tutte le regole di sicurezza.

Perché questo è importante

Il documento dimostra che non dobbiamo aspettare che l'IA diventi un "genio" da sola. Invece, possiamo costruire un workflow in cui l'IA è guidata da un contratto rigido e infrangibile e corretta da prove del mondo reale. I ricercatori hanno scoperto che questo approccio non serve solo a far scrivere codice più velocemente all'IA; serve a far sì che il codice funzioni.

Tuttovià, il documento avverte con cautela che questo non è un bacchetta magica per tutto. Nei loro test, c'era un gruppo di compiti (chiamati "machsuite") in cui l'IA falliva completamente, anche con il contratto. Ciò suggerisce che, sebbene il contratto aiuti l'IA a seguire le regole, non può risolvere il problema se l'IA semplicemente non conosce ancora la matematica o la logica sottostante.

In breve, ContractHIL-HLS è un ponte tra il mondo disordinato delle idee umane e il mondo rigido dei chip hardware. Trasforma l'IA da uno scrittore creativo in un ingegnere disciplinato, assicurando che quando chiediamo una macchina sicura e veloce, otteniamo effettivamente una macchina che funziona.

Sintesi Tecnica: ContractHIL-HLS

Definizione del Problema

Sebbene i Large Language Models (LLM) abbiano dimostrato la capacità di generare codice hardware, l'ingegneria pratica dell'HLS (High-Level Synthesis) richiede workflow che mantengano l'intento progettuale attraverso le iterazioni, garantendo l'allineamento con il feedback degli strumenti EDA (Electronic Design Automation), il controllo dell'host, la proprietà della memoria e le misurazioni di deployment su FPGA (Field-Programmable Gate Array). I benchmark esistenti (ad es. Chip-Chat, RTLLM, HLS-Eval) mostrano che i modelli possono generare codice valido, ma spesso non riescono a stabilire un workflow in cui l'intento progettuale rimanga tracciabile rispetto al feedback degli strumenti e ai risultati di deployment. Gli approcci attuali si affidano tipicamente a prompt di ruolo conversazionali o alla cronologia della conversazione come stato, il che può portare all'omissione di vincoli introdotti da un prompt di tipo "architetto" da parte di un successivo prompt di tipo "coder". Inoltre, il lavoro esistente sull'assistenza LLM per l'HLS rimane principalmente centrato sul kernel, mancando di copertura per la partizione del bitstream, la proprietà dello stato vivo (live-state ownership) e i confini di sicurezza tra gli stadi.

Metodologia

Il documento propone ContractHIL-HLS, un workflow multi-agente allineato tramite contratto progettato per trasformare richieste in linguaggio naturale imprecise in implementazioni HLS tracciabili. Il workflow si distingue per tre meccanismi fondamentali:

Contratto Strutturato come Artefatto di Esecuzione: Invece di fare affidamento su una cronologia conversazionale sciolta, il workflow introduce un contratto formale ( $C = \langle R, I, F, H, K, O, V, B \rangle$ ) che codifica i requisiti in campi espliciti: Ruolo/Piattaforma, Interfaccia Pubblica, Intento Funzionale, Vincoli Hard/Negativi, Compatibilità, Intento di Ottimizzazione, Evidenza di Validazione e Politica di Rollback. Questo contratto funge da artefatto di allineamento semantico e di esecuzione del compito.
Decomposizione degli Agenti per Abbassamento Semantico (Semantic Lowering): Gli agenti sono definiti dai loro compiti di trasformazione piuttosto che dai ruoli conversazionali:
- Agente del Contratto (Contract Agent): Normalizza il linguaggio naturale nel contratto strutturato.
- Agente HTML: Renderizza il contratto in un artefatto HTML stabile e ispezionabile contenente sezioni, tabelle e checklist. Questo artefatto è leggibile sia dagli umani che dagli script.
- Agente Hardware-in-the-Loop (HIL): Implementa e revisiona il design utilizzando l'artefatto HTML combinato con l'evidenza hardware misurata.
Ciclo di Feedback Hardware-in-the-Loop: Il workflow integra il feedback dagli strumenti HLS (Vitis), dagli strumenti di implementazione (Vivado) e dalle misurazioni di runtime della scheda (PYNQ) direttamente nel ciclo di generazione e decisione. Ciò estende il design assistito da LLM dal codice del kernel verso la chiusura a livello di sistema e di scheda. Il ciclo include richieste di implementazione limitate, controlli di rifiuto a basso costo (parsing, compilazione, testbench), controlli di sintesi/implementazione e una decisione di mantenimento o rollback basata sull'evidenza misurata (ad es. Worst Negative Slack, utilizzo delle risorse, potenza, tempo di esecuzione).

Contributi Chiave

Il documento delinea tre contributi primari:

Contratto Strutturato come Artefatto di Esecuzione: I requisiti sono codificati come campi espliciti (interfaccia, vincoli, validazione, ottimizzazione, rollback) per allineare la generazione a un oggetto ingegneristico condiviso piuttosto che a ripetuti testi di prompt.
HTML Persistente e Ciclo di Feedback HIL: Il contratto viene renderizzato in HTML strutturato, e gli output degli strumenti (HLS, Vivado, metriche di deployment) vengono riportati come stati del workflow di prima classe per guidare le decisioni di implementazione e rollback.
Coordinamento degli Agenti dai Benchmark ai Casi Ingegneristici: Il workflow dimostra che un approccio allineato al contratto migliora i risultati su 94 task HLS-Eval locali e trasporta con successo il ciclo di design verso un sistema di messaggistica sicura Post-Quantum Cryptography (PQC) testato su scheda.

Risultati

Valutazione HLS-Eval (Setting di Small-Design)

Valutato su 94 task HLS-Eval eseguibili localmente utilizzando una toolchain Vitis HLS:

Baseline vs. Contratto: L'introduzione del solo contratto strutturato ha migliorato il tasso stimato di superamento del testbench a singolo campione (pass@1) dal 64,0% (Direct prompt) al 70,2%.
Workflow Completo: Il flusso completo ContractHIL-HLS ha raggiunto un 70,4% di pass@1 e un 76,6% di pass@5.
Efficienza dei Token: L'impostazione "Contract" ha utilizzato meno token (3555) rispetto all'impostazione "Direct" (3741) sostituendo le istruzioni ripetute in modo sciolto con campi nominati, suggerendo una maggiore affidabilità senza semplicemente aumentare la lunghezza del prompt.
Analisi per Categoria: Sono stati osservati miglioramenti nella maggior parte delle famiglie di benchmark (ad es. chstone, polybench, rosetta), sebbene il gruppo machsuite sia rimasto allo 0,0% di pass rate, indicando che il workflow migliora l'affidabilità per implementazioni plausibili ma non può compensare la mancanza di capacità algoritmiche.

Caso di Studio PQC (Deployment a Livello di Scheda)

Validato su un acceleratore di messaggistica sicura Post-Quantum Cryptography (ML-KEM/ML-DSA):

Performance: Il workflow è passato con successo da un design monolitico a bitstream singolo a un'organizzazione a doppio bitstream (dividendo la logica KEM e DSA/XOR). Ciò ha ridotto il tempo di esecuzione medio del testo da 207,3 ms a 52,4 ms.
Efficienza: L'Energy-Delay Product (EDP) conservativo è migliorato da 171,3 mJ·s a 23,6 mJ·s.
Timing e Risorse: Il design diviso ha risolto le violazioni di timing (il WNS è migliorato da 1,570 ns nell'immagine monolitica a 0,769 ns e 0,171 ns nelle immagini divise) e ha ridistribuito la pressione sulla memoria, con entrambe le immagini che hanno raggiunto uno slack di routing positivo.
Validazione: Il workflow ha preservato le regole del confine del ricevitore e la verifica del messaggio decriptato, garantendo che la proprietà dello stato fosse visibile e corretta.

Significato e Rivendicazioni

Il documento sostiene che ContractHIL-HLS colma il divario tra la generazione di codice isolata e l'esecuzione di un workflow tracciabile. Il suo significato risiede in:

Allineamento dello Stato: Dimostrare che la conversione dei requisiti impliciti in linguaggio naturale in strutture stabili e ispezionabili (contratti/HTML) migliora significativamente l'affidabilità della generazione di codice hardware prima che sia disponibile qualsiasi feedback dalla scheda.
Chiusura a Livello di Sistema: Provare che lo stesso workflow allineato al contratto può scalare dai kernel-level benchmark a sistemi complessi testati su scheda che coinvolgono la partizione del bitstream, l'orchestrazione dell'host e i confini di sicurezza.
Revisione Basata su Evidenze: Stabilire un meccanismo in cui l'output degli strumenti (QoR, timing, potenza) diventa un artefatto di prima classe che guida le decisioni di rollback, prevenendo la propagazione silenziosa di design che falliscono specifici gate (ad es. vincoli di timing o risorse).

Gli autori mantengono una posizione modesta, osservando che il workflow è un meccanismo di allineamento dello stato che migliora l'affidabilità quando il modello è vicino a un'implementazione plausibile, piuttosto che una soluzione universale per tutte le lacune algoritmiche. Il caso PQC serve come stress test di deployment per la completezza del sistema piuttosto che come rivendicazione di superiorità della latenza a livello primitivo.