LLM4PQC - Accurate and Efficient Synthesis of PQC Cores by Feedback-Driven LLMs

Il paper propone LLM4PQC, un framework basato su modelli linguistici che automatizza la conversione e la verifica del codice C di crittografia post-quantistica in specifiche HLS sintetizzabili, riducendo l'impegno manuale e accelerando l'esplorazione del design rispetto ai flussi tradizionali.

L'essenziale

Immagina di dover costruire una città futuristica (la crittografia post-quantum) per proteggere i nostri segreti dai ladri del futuro (i computer quantistici).

Il Problema: Il Piano Architettonico Incompatibile

Attualmente, gli scienziati hanno già disegnato i piani della città su un foglio di carta (il codice C di riferimento). Questi piani sono perfetti per essere letti da umani e funzionano bene su un computer normale (come un software).

Tuttavia, per costruire la città nella realtà (l'hardware o i chip fisici), non possiamo usare direttamente quei fogli di carta.

1. Il linguaggio è sbagliato: I piani usano termini astratti (come "immagina un numero" o "usa memoria dinamica") che un cantiere fisico non può capire.
2. La traduzione è lenta: Tradurre manualmente questi piani in istruzioni per i costruttori (il codice HLS e RTL) è un lavoro enorme, noioso e soggetto a errori. È come se dovessimo riscrivere a mano ogni singolo mattone di un grattacielo solo perché il piano originale era disegnato per un architetto, non per un muratore.

La Soluzione: LLM4PQC (L'Architetto AI con un Controllore)

Gli autori del paper hanno creato LLM4PQC, un sistema intelligente che usa un'intelligenza artificiale (un LLM, come un ChatGPT molto esperto) per fare da "traduttore" e "architetto", ma con una regola fondamentale: l'AI non lavora da sola, ha un controllore.

Ecco come funziona, passo dopo passo, con delle analogie:

1. L'Ispezione (Estrazione)

Prima di tutto, l'AI non prova a tradurre l'intero libro di istruzioni (che è enorme). Identifica solo le parti critiche della città che devono essere costruite in acciaio e cemento (i "nuclei" matematici come l'NTT o il campionatore). È come dire: "Non ricostruiamo tutta la città, concentriamoci solo sui ponti e sulle centrali elettriche".

2. La Pulizia (Pre-elaborazione)

I piani originali contengono cose che un cantiere fisico non può gestire:

• Memoria dinamica: Chiedere "prendi tutto lo spazio che ti serve" è impossibile in un chip fisico, che deve sapere esattamente quanto spazio occupa ogni cosa prima di iniziare.
• Matematica complessa: Usare funzioni come "calcola la radice quadrata" in tempo reale è troppo costoso per un chip.
• Inizializzazione: Alcuni piani dicono "calcola i numeri mentre costruisci". I chip invece devono avere i numeri già pronti (come una lista della spesa stampata).

L'AI, guidata dal sistema, ripulisce i piani: trasforma le richieste di "spazio infinito" in scatole di dimensioni fisse e calcola i numeri complessi prima di dare il via ai lavori, trasformandoli in liste statiche.

3. La Costruzione e il Controllo (Feedback Loop)

Qui sta la magia. L'AI prova a tradurre i piani puliti in istruzioni per il chip.

• Il ciclo di prova: L'AI scrive il codice -> Il sistema lo prova a compilare (come un simulatore di volo).
• L'errore è un amico: Se il simulatore dice "Attenzione! Non puoi usare quel tipo di memoria", non si butta tutto. L'errore viene inviato all'AI come un promemoria: "Hai sbagliato qui, riprova usando questo metodo".
• Iterazione: L'AI corregge, riprova, e continua finché il codice non passa tutti i test. È come un bambino che impara a camminare: cade, si rialza, e il genitore (il sistema di feedback) gli dice come mettere meglio i piedi la volta successiva.

4. Il Risultato: Una Città Funzionante

Alla fine, il sistema produce un chip fisico (RTL) che è:

• Corretto: Funziona esattamente come previsto dai piani originali.
• Efficiente: Occupa meno spazio (meno "mattoni" o LUT/FF) rispetto a molti chip costruiti manualmente da umani esperti.
• Veloce da creare: Riduce drasticamente il tempo di sviluppo.

Cosa hanno scoperto? (I Risultati)

Hanno testato questo sistema su tre famosi "protettori" (Kyber, Dilithium, Falcon).

• Il successo: L'AI è riuscita a costruire chip complessi (come il "Campionatore di Falcon", che è notoriamente difficile) che funzionano perfettamente.
• Il compromesso: I chip costruiti dall'AI sono molto piccoli ed economici (usano pochi materiali), ma a volte sono un po' più lenti rispetto a quelli costruiti da un umano che sa esattamente come ottimizzare ogni singolo movimento. Tuttavia, sono comunque molto più veloci ed economici di quanto ci si aspetterebbe da un'AI che lavora da sola.

In Sintesi

LLM4PQC è come avere un architetto AI super-intelligente che, invece di scrivere un libro di istruzioni incomprensibile, collabora con un ispettore di cantiere (il sistema di feedback). L'ispettore dice: "No, qui non puoi usare quel materiale", e l'architetto ripensa il progetto.

Il risultato è che possiamo trasformare velocemente le idee matematiche astratte in macchine fisiche reali, rendendo la sicurezza dei nostri dati contro i computer quantistici molto più accessibile e veloce da realizzare.

Sommario tecnico

1. Il Problema

La transizione verso la crittografia post-quantistica (PQC) richiede implementazioni hardware efficienti e affidabili per proteggere le infrastrutture critiche dagli attacchi dei computer quantistici. Tuttavia, lo sviluppo di hardware PQC affronta due colli di bottiglia principali:

• Conversione del Codice: Le implementazioni di riferimento PQC fornite dal NIST sono scritte in C portabile, ottimizzate per la chiarezza e la correttezza funzionale, ma non sono direttamente sintetizzabili in hardware. La conversione manuale in specifiche per la Sintesi di Alto Livello (HLS) richiede un'ingente rifattorizzazione per gestire costrutti incompatibili (es. allocazione dinamica, librerie matematiche non sintetizzabili, inizializzazione a runtime di tabelle costanti).
• Scalabilità e Complessità: La sintesi di primitive PQC complesse, come i trasformatori di numero teorico (NTT), i campionatori gaussiani (Falcon) e le interfacce di memoria ampie, è difficile da scalare con i flussi di lavoro tradizionali.
• Limitazioni degli LLM Generici: Sebbene i Large Language Models (LLM) eccellano nella programmazione software, la progettazione hardware richiede una conoscenza specifica del dominio (HLS) e una gestione rigorosa dei vincoli di risorse e temporali che gli LLM standard non possiedono senza un'adeguata guida.

2. Metodologia: Il Framework LLM4PQC

Il paper propone LLM4PQC, un framework basato su LLM che automatizza la trasformazione delle specifiche PQC di alto livello e dei codici di riferimento C in codice C pronto per l'HLS e sintetizzabile. Il flusso di lavoro è guidato dal feedback e si articola in quattro fasi principali (illustrate nella Fig. 1 del paper):

A. Estrazione delle Sottoroutine PQC

Invece di convertire l'intera implementazione, il sistema utilizza un LLM (GPT-5.2) per identificare ed estrarre selettivamente i nuclei computazionali critici per le prestazioni (es. NTT, Sampler, FFT). Vengono generati automaticamente:

• Codice C isolato con dipendenze minime.
• Infrastruttura di verifica (Test Known-Answer - KAT, harness di test) per validare la correttezza funzionale a livello C prima della sintesi.

B. Preprocessing per la Conformità HLS

Questa fase trasforma il codice C di riferimento per rimuovere i "bloccanti" della sintesi HLS tramite un pipeline automatizzato assistito da LLM:

1. Mappatura della Memoria Statica: Sostituzione delle allocazioni dinamiche (malloc, memcpy) con array statici o allocazioni sullo stack, necessarie per l'analisi statica degli strumenti HLS.
2. Rimozione dell'Inizializzazione a Runtime: Le routine che calcolano tabelle costanti (es. fattori di rotazione per FFT) vengono eseguite in un programma wrapper standalone. I valori risultanti vengono estratti e inseriti nel codice sorgente come array const compilati a tempo di compilazione, eliminando la logica di inizializzazione dinamica.

C. Generazione HLS-C e Esplorazione dello Spazio di Progetto (DSE)

Il codice pre-processato viene inviato al framework C2HLSC (integrato con lo strumento di sintesi Catapult).

• Rifattorizzazione Strutturale: Gli LLM vengono istruiti a espandere le strutture dati complesse (struct) in tipi di dati primitivi, poiché molti strumenti HLS faticano a mappare strutture nidificate.
• Ottimizzazione Guidata dal Feedback: Il sistema utilizza un ciclo iterativo. Se la sintesi fallisce o i risultati PPA (Power, Performance, Area) non sono ottimali, gli errori e le metriche vengono inviati all'LLM come prompt correttivi.
• Ottimizzazione delle Pragma: L'LLM introduce pragmi HLS (es. loop unrolling, pipelining) per ottimizzare area e latenza, guidato dai feedback quantitativi dello strumento di sintesi.

D. Sintesi e Verifica

Il codice C generato viene sintetizzato in RTL (Register Transfer Level) per target ASIC (Nangate 45nm) e FPGA (Xilinx Artix-7, XCZU7EV). La verifica avviene tramite:

• Simulazione C a livello di KAT.
• Simulazione RTL completa (1.000 casi di test) confrontando l'output del DUT (Device Under Test) con il modello C di riferimento.

3. Contributi Chiave

1. Preprocessing Guidato da LLM: Un approccio sistematico per trasformare codice C portabile in codice C conforme all'HLS, affrontando sfide specifiche come l'allocazione dinamica e l'inizializzazione di costanti.
2. Flusso di Lavoro Strutturato e Iterativo: Un'integrazione completa che collega la trasformazione del codice LLM al feedback degli strumenti di sintesi (C2HLSC + Catapult), permettendo un raffinamento automatico basato sugli errori.
3. Studio Empirico su Algoritmi PQC: Una valutazione completa su algoritmi standardizzati NIST (Kyber, Dilithium, Falcon) e le loro primitive core, dimostrando la fattibilità del metodo su casi d'uso reali e complessi.

4. Risultati Sperimentali

Lo studio è stato condotto su cinque sottoroutine: Kyber-NTT, Dilithium-NTT, Falcon-NTT, Falcon-Sampler e Falcon-FFT.

• Tasso di Successo: Il framework ha raggiunto un tasso di successo del 100% per Kyber-NTT, Dilithium-NTT e Falcon-FFT. Per i casi più complessi come Falcon-NTT e Falcon-Sampler, i tassi sono stati rispettivamente del 70% e 40%, indicando che la complessità (specialmente per i campionatori gaussiani) richiede ancora più iterazioni o raffinamenti.
• Efficienza dell'Area (ASIC): I design generati hanno mostrato un'ottima efficienza nell'uso delle risorse. Ad esempio, Kyber-NTT ha occupato in media 2.957 µm², mentre Dilithium-NTT circa 6.506 µm².
• Confronto con lo Stato dell'Arte (FPGA):
  • Rispetto a implementazioni manuali precedenti, LLM4PQC ha ottenuto un utilizzo inferiore di LUT e Flip-Flop per Kyber, Dilithium e Falcon NTT.
  • Il Falcon-Sampler generato ha superato le prestazioni in termini di latenza rispetto al lavoro precedente basato su LLM ([18]), riducendo la latenza da 0.73 µs a 0.39 µs.
  • Tuttavia, i design generati tendono ad avere una latenza più alta rispetto ai design manuali ottimizzati a mano. Questo perché l'LLM, senza guida esplicita, tende a preferire strutture sequenziali compatte rispetto all'espansione aggressiva dei loop tipica dell'ottimizzazione manuale.

5. Significato e Conclusioni

LLM4PQC dimostra che è possibile automatizzare la sintesi di acceleratori hardware crittografici complessi riducendo significativamente lo sforzo manuale.

• Valore Principale: Il framework offre un percorso potente per l'esplorazione rapida dello spazio di progetto (DSE) e la prototipazione, superando le barriere di sintassi e di dominio che ostacolano l'uso diretto degli LLM nell'HLS.
• Trade-off: Sebbene i risultati siano competitivi in termini di area e spesso superiori ai metodi precedenti basati su LLM, c'è un compromesso con la latenza. Il lavoro evidenzia che la "stili di codifica" generati dagli LLM influenzano direttamente la qualità dell'hardware.
• Sviluppi Futuri: Le direzioni future includono un'integrazione più "agente" (dove l'LLM prende decisioni autonome basate sul feedback), il fine-tuning degli LLM su dataset specifici di HLS, e l'uso di modelli predittivi PPA per accelerare l'esplorazione senza dover eseguire sintesi complete ad ogni iterazione.

In sintesi, il paper valida che un approccio guidato dal feedback, che combina preprocessing intelligente, trasformazione assistita da LLM e verifica rigorosa, è superiore alla semplice traduzione diretta del codice, aprendo la strada a una generazione più rapida e affidabile di hardware PQC.