Riepilogo Tecnico: HLS-Seek

Enunciato del Problema

La Sintesi di Alto Livello (HLS) compila descrizioni algoritmiche in C/C++ in hardware a livello di trasferimento di registro (RTL). La Qualità dei Risultati (QoR) — in particolare la latenza di esecuzione e l'utilizzo delle risorse (LUT, DSP, BRAM, FF) — è critica per il dispiegamento di acceleratori nel mondo reale. Tuttavia, la QoR è determinata da strutture microarchitettoniche, configurazioni di pragma e ottimizzazioni del codice che non possono essere inferite con precisione dall'analisi del codice software da sola; richiede una costosa valutazione di sintesi e implementazione.

Gli approcci esistenti basati su Modelli Linguistici di Grande Dimensione (LLM) per la generazione di codice HLS si concentrano principalmente sulla correttezza funzionale (generazione di codice compilabile ed eseguibile) ma sono agnostici rispetto alla QoR. Trattano tutti i progetti compilabili allo stesso modo, indipendentemente dalle loro prestazioni hardware. Sebbene l'Apprendimento per Rinforzo (RL) con feedback di sintesi reale (sintesi nel ciclo) abbia mostrato promesse nel dominio RTL, applicarlo all'HLS è proibitivamente costoso. Una singola esecuzione di sintesi HLS può richiedere da minuti a ore, e l'addestramento RL richiede tipicamente migliaia di valutazioni, rendendo l'approccio non fattibile su larga scala.

Metodologia

Gli autori propongono HLS-Seek, un framework da Linguaggio Naturale a HLS consapevole della QoR che sostituisce il costoso RL con sintesi reale con un modello di reward proxy comparativo potenziato da un meccanismo di commutazione consapevole dell'incertezza.

1. Intuizione Fondamentale

Gli autori osservano che l'RL per HLS non richiede valori assoluti di QoR (numeri esatti di latenza/risorse) dalla sintesi. Invece, richiede solo confronti relativi tra progetti candidati per stimare vantaggi relativi al gruppo. Questa intuizione permette l'addestramento di un modello proxy leggero per prevedere quale dei due progetti sia migliore, evitando la necessità di sintesi durante la maggior parte dei passaggi di addestramento.

2. Pipeline di Addestramento in Tre Fasi

HLS-Seek impiega un processo di addestramento in tre fasi:

• Fase 1: Fine-Tuning Supervisionato Orientato alla Diversità (SFT): Il LLM base viene affinato su un ampio corpus HLS con descrizioni QoR per esporre il modello a diverse configurazioni di pragma e pattern di codifica, stabilendo una fondazione nella sintassi HLS.
• Fase 2: SFT a Freddo con Tracce di Ragionamento: Utilizzando un dataset curato di progetti prossi-mi al Pareto (trade-off ottimali) arricchito con tracce di ragionamento Chain-of-Thought (CoT) generate da modelli di ragionamento commerciali, il modello impara il ragionamento hardware strutturato e come selezionare configurazioni di pragma ottimali.
• Fase 3: Ottimizzazione della Policy Relativa al Gruppo (GRPO): Il modello viene raffinato utilizzando GRPO con un segnale di reward a quattro componenti:
  1. Formato del Ragionamento: Garantisce un output strutturato con tracce CoT.
  2. Compilazione: Verifica la correttezza sintattica (compilazione GCC).
  3. Correttezza Funzionale: Verifica la correttezza semantica rispetto ai testbench.
  4. Reward Proxy QoR: Un reward comparativo derivato da una rete Siamese che prevede la dominanza a coppie.

3. Modello di Reward Proxy Comparativo

• Architettura: Un'architettura Siamese di tipo Bradley-Terry che prende in input due progetti HLS e restituisce una probabilità di dominanza di uno sull'altro.
• Addestramento: Addestrato su confronti a coppie provenienti dai risultati dell'Esplorazione dello Spazio di Progetto (DSE), distinguendo tra dominanza Pareto completa (migliore su tutte le 5 metriche) e superiorità di latenza.
• Commutazione Consapevole dell'Incertezza: Per prevenire l'"hacking del reward" (dove la policy sfrutta i punti ciechi del modello proxy), il sistema impiega il dropout Monte Carlo (MC) durante l'inferenza per stimare l'incertezza.
  • Se un progetto candidato presenta un'alta incertezza, il sistema attiva la sintesi reale Vitis HLS per ottenere la QoR di verità fondamentale.
  • Questi risultati di sintesi reale vengono reinseriti per aggiornare online il modello di reward proxy, espandendo continuamente la sua copertura e affidabilità.
  • Questo meccanismo garantisce che il proxy rimanga accurato mantenendo bassa la frequenza di attivazione della sintesi (obiettivo <5% alla convergenza).

4. Curatela dei Dati

Il framework utilizza una strategia di Campionamento Qualità-Diversità Prossimo al Pareto. Invece di utilizzare solo progetti strettamente ottimali Pareto (che sono troppo pochi), include progetti vicini al fronte di Pareto, classificati in base alla loro distanza euclidea dal fronte, garantendo che il modello apprenda trade-off risorse-latenza fini.

Contributi Chiave

1. Intuizione del Reward Relativo: Identificazione che l'RL per HLS richiede solo segnali QoR relativi, non risultati di sintesi assoluti, permettendo l'uso di un modello proxy comparativo.
2. Sistema Proxy Consapevole dell'Incertezza: Un meccanismo innovativo che combina un modello di reward comparativo Siamese con la stima dell'incertezza tramite dropout MC e aggiornamenti online tramite sintesi reale selettiva. Questo previene l'hacking del reward e garantisce il miglioramento autonomo.
3. Framework HLS-Seek: Una pipeline completa da NL a HLS che raggiunge prestazioni all'avanguardia con soli 7 miliardi di parametri, utilizzando una strategia di addestramento in tre fasi (SFT Diversità $\to$ SFT a Freddo con Ragionamento $\to$ GRPO con Reward Proxy).

Risultati Sperimentali

Valutato sul benchmark HLS-eval e su un set di test ForgeHLS:

• Correttezza Sintattica e Funzionale:

  • Ha raggiunto un 81,5% di pass@1 per la correttezza sintattica e un 81,4% di pass@5 per la correttezza funzionale su HLS-eval.
  • Ha superato modelli all'avanguardia (inclusi GPT-5.1, DeepSeek-V3.2 e Qwen3-235B) e baseline HLS specializzate (SAGE-HLS, Gai et al.) nonostante abbia significativamente meno parametri (7B vs 235B+ o modelli di codice più grandi).
  • Nello specifico, ha superato GPT-5.1 di +2,3 punti percentuali nel pass@5 funzionale su HLS-eval.

• Qualità dei Risultati (QoR):

  • Ha raggiunto la latenza più bassa su 16 su 30 kernel.
  • Dominia Pareto le baseline specifiche per HLS (SAGE-HLS e Gai et al.) su 9 kernel (5 vs SAGE-HLS, 4 vs Gai et al.) con solo 1 vittoria inversa.
  • Ha dimostrato la capacità di eseguire ristrutturazione algoritmica del codice (ad esempio, espansione scalare e fissioni di loop) piuttosto che solo l'inserimento di pragma, portando a riduzioni significative della latenza (ad esempio, una riduzione di 4,1 volte in GEMVER).

• Efficienza dell'Addestramento:

  • Ha raggiunto un speedup di 8,5 volte nell'addestramento rispetto all'RL con reward reale.
  • In un budget di tempo reale di 73 ore, HLS-Seek ha completato 12.500 passaggi di addestramento, mentre un approccio con reward reale ne ha completati solo 1.460.
  • Il meccanismo di reward proxy ha mantenuto un'alta accuratezza (99,53% di accuratezza di dominanza Pareto) riducendo il sovraccarico di sintesi a meno del 5% alla convergenza.

Significato e Affermazioni

Il paper afferma che HLS-Seek dimostra che l'RL specifico di dominio con reward QoR appresi è un percorso praticabile verso la generazione di codice HLS completamente automatizzata ed efficiente per l'hardware. Disaccoppiando la necessità di risultati di sintesi assoluti dal ciclo di addestramento RL, gli autori superano il collo di bottiglia di scalabilità degli approcci con sintesi nel ciclo.

Il lavoro evidenzia che:

1. La consapevolezza della QoR è raggiungibile senza costosa sintesi nel ciclo sfruttando confronti relativi.
2. I modelli piccoli (7B) possono superare modelli all'avanguardia massicci in compiti di generazione hardware specializzati quando addestrati con segnali consapevoli della QoR e tracce di ragionamento appropriati.
3. La ristrutturazione algoritmica è una capacità chiave appresa attraverso questo processo, andando oltre la semplice sintonizzazione dei pragma per ottimizzare fondamentalmente la struttura del codice per il parallelismo hardware.

Gli autori concludono che il loro sistema di reward proxy consapevole dell'incertezza bilancia con successo il compromesso tra velocità di addestramento e fedeltà del reward, permettendo la generazione di progetti hardware che non sono solo funzionalmente corretti, ma anche ottimizzati per latenza e utilizzo delle risorse.