Debug Like a Human: Scaling LLM-based Fault Localization to Processor Design via Block-Level Instruction-Oriented Slicing

Riepilogo Tecnico: Debug come un Essere Umano

Enunciato del Problema
La localizzazione dei guasti (FL) nella progettazione di processori moderni è un collo di bottiglia critico, che consuma circa il 60% dello sforzo di sviluppo hardware. Sebbene i Modelli Linguistici di Grande Formato (LLM) abbiano mostrato promesse nella progettazione hardware a livello di modulo, la loro applicazione a progetti di processori su larga scala rimane complessa a causa di quattro limitazioni specifiche:

1. Mancanza di Tecniche Specifiche per Processori: I metodi FL esistenti progettati per hardware generico (ad esempio, controller di memoria) spesso falliscono sui processori perché non tengono conto della natura complessa e guidata dalle istruzioni delle architetture dei processori.
2. Copertura delle Istruzioni Inefficace: I metodi tradizionali basati sullo spettro si affidano a una copertura a grana grossa sugli intervalli di simulazione. Nei processori pipelined, dove le istruzioni si estendono su più moduli e cicli, ciò porta a una contaminazione della copertura dovuta a istruzioni "in volo", riducendo l'accuratezza.
3. Sottoutilizzo dei Valori dei Segnali: Le attuali tecniche hardware FL raramente sfruttano i valori concreti dei segnali (forme d'onda) perché la loro interpretazione richiede una comprensione semantica avanzata, che in precedenza era difficile per gli strumenti automatizzati.
4. Vincoli della Finestra Contestuale: I progetti di processori spesso superano i limiti del contesto degli LLM. Fornire l'intera base di codice causa la perdita di focus dei modelli, mentre fornire troppo poco contesto nasconde dipendenze critiche.

Metodologia: BluesFL
Gli autori propongono BluesFL, un framework di localizzazione dei guasti a livello di blocco basato su LLM, ispirato ai flussi di lavoro di debug umani. Il sistema opera su un framework di co-simulazione in cui un modello hardware e un modello di riferimento software vengono confrontati per generare report di test che indicano discrepanze nello stato architetturale.

La metodologia consta di quattro fasi chiave:

1. Bloccatura del Codice Basata sul Flusso di Dati:
   Per affrontare i limiti del contesto, la base di codice SystemVerilog viene partizionata in blocchi di codice disgiunti basati sulle relazioni di flusso di dati piuttosto che sulla struttura dei file. Questi blocchi sono categorizzati in quattro tipi: ModInputBlock, ModOutputBlock, AssignBlock e AlwaysBlock. Questo approccio raggruppa le dichiarazioni con dipendenze di dati, preservando la semantica locale mentre crea unità compatte adatte all'analisi degli LLM.

2. Slicing Orientato alle Istruzioni a Livello di Blocco (Blues):
   Per affrontare la complessità dell'esecuzione delle istruzioni, gli autori introducono l'algoritmo Blues. Questo algoritmo costruisce un grafo "Percorso di Esecuzione dell'Istruzione" partendo da un segnale fallito e un timestamp.

   • Analisi Intra-Blocco: Analizza il flusso di dati all'interno di un blocco per identificare i segnali pilotati. Calcola nuovi timestamp ($t'$) in base al fatto che il blocco sia combinatorio (stesso tempo) o sequenziale (ciclo precedente).
   • Analisi Inter-Blocco: Traccia all'indietro per trovare i blocchi che pilotano i segnali identificati, collegandoli nel grafo del percorso di esecuzione.
   • Risultato: Questo processo filtra il codice irrilevante, creando un percorso contenente solo i blocchi effettivamente coperti durante l'esecuzione dell'istruzione fallita, annotati con timestamp precisi.

3. Ragionamento LLM con Chiamate a Strumenti:
   L'LLM agisce come un assistente di debug che attraversa iterativamente il percorso di esecuzione. Ad ogni stato $(b, t)$, l'LLM:

   • Riceve il contesto del blocco di codice e i segnali pilotati (con i timestamp).
   • Utilizza uno strumento read_values per interrogare valori specifici dei segnali dalla forma d'onda al tempo annotato.
   • Utilizza uno strumento check_signals per interrogare il percorso di esecuzione sui blocchi che pilotano segnali specifici.
   • Decide se il blocco corrente è sospetto, aggiungendolo a una coda se lo è, o richiedendo un'ulteriore ispezione.

4. Classificazione:
   Una volta che l'LLM determina che la causa radice è stata trovata o che l'analisi è completa, assegna un punteggio di confidenza (0–1) a ciascun blocco sospetto, producendo una lista classificata delle posizioni dei guasti.

Contributi Chiave

• Framework BluesFL: La prima applicazione di localizzazione dei guasti basata su LLM specificamente a progetti di processori reali su scala di progetto.
• Bloccatura Basata sul Flusso di Dati: Un metodo per comprimere grandi basi di codice in blocchi compatti e ricchi semanticamente che rientrano nelle finestre contestuali degli LLM.
• Algoritmo Blues: Una tecnica di slicing innovativa che guida gli LLM a concentrarsi esclusivamente sui blocchi coperti dalle istruzioni e incorpora valori di segnali annotati temporalmente per imitare il ragionamento umano sul comportamento dinamico dei processori.
• Validazione Empirica: Valutazione su un core RISC-V open-source da 19K righe (Ibex) con 119 bug iniettati.

Risultati Sperimentali
Valutato sul core del processore Ibex, BluesFL ha dimostrato miglioramenti significativi rispetto alle linee di base dello stato dell'arte (inclusi slicing statico, metodi basati sullo spettro e metodi esistenti basati su LLM come LiK e Agentless):

• Accuratezza: BluesFL ha localizzato correttamente 24 bug al Top-1, rappresentando un miglioramento del 242,9% rispetto alla migliore linea di base esistente (LiK, che ne ha trovati 7).
• Efficienza: Il costo medio per localizzare un singolo bug è stato di $0,257.
• Studi di Ablazione: La rimozione dei valori dei segnali o del percorso di esecuzione dell'istruzione ha degradato significativamente le prestazioni. Nello specifico, senza valori dei segnali, l'LLM ha controllato il 609% in più di blocchi, aumentando il costo per bug a $1,821.
• Robustezza del Modello: Il framework ha operato in modo competitivo su diversi backend LLM (GPT-4o-mini, GPT-4o, Claude-3.5-Sonnet), con Claude-3.5-Sonnet che ha ottenuto il punteggio Top-1 più alto (30 bug) a un costo leggermente superiore.

Significato e Affermazioni
Il documento afferma che BluesFL scala con successo la localizzazione dei guasti basata su LLM al dominio dei processori colmando il divario tra l'intuizione umana nel debug (tracciamento dei percorsi delle istruzioni e dei valori dei segnali) e l'analisi automatizzata. Imitando il processo umano di restringimento delle regioni sospette attraverso flussi di dati e percorsi di esecuzione annotati temporalmente, il framework supera le limitazioni delle dimensioni del contesto e della contaminazione della copertura che affliggono i metodi esistenti. Gli autori posizionano questo lavoro come un passo fondamentale verso una verifica agile e automatizzata per progetti di processori complessi, notando che, sebbene i risultati attuali siano promettenti, è necessario ulteriore lavoro per migliorare il ragionamento trasversale a lunga distanza tra blocchi per gestire i casi in cui il processo di debug termina prematuramente.