💻 computer science

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

BluesFL is een nieuw framework voor foutlokalisatie op blok-niveau dat gebruikmaakt van LLM's en een door de mens geïnspireerd, instructiegericht slicing-algoritme om state-of-the-art bugdetectienauwkeurigheid en lage kosten te bereiken in grootschalige RISC-V-processorontwerpen.

Oorspronkelijke auteurs: Zizhen Liu, Xiaoguang Mao, Deheng Yang, Jiayu He, Yihao Qin, Guangda Zhang, Yan Lei, Jianjun Xu, Jiang Wu

Gepubliceerd 2026-05-19

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Zizhen Liu, Xiaoguang Mao, Deheng Yang, Jiayu He, Yihao Qin, Guangda Zhang, Yan Lei, Jianjun Xu, Jiang Wu

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je probeert een enorme, ongelooflijk complexe uurwerkmachine (een computerprocessor) te repareren die niet meer correct tikt. Deze machine is gemaakt van miljoenen kleine tandwielen en veren (regels code). Als hij kapot gaat, stopt de machine niet alleen; hij kan beginnen met een tandwiel de verkeerde kant op te draaien of een slag over te slaan.

Het vinden van precies welk tandwiel kapot is, is als het zoeken naar een speld in een hooiberg, maar de hooiberg is zo groot als een stad en de speld is onzichtbaar. Dit is het probleem dat het artikel "Debug Like a Human" probeert op te lossen.

Hier is hoe de auteurs, onder leiding van Zizhen Liu en zijn team, een nieuw hulpmiddel genaamd BluesFL hebben gebouwd om dit op te lossen, eenvoudig uitgelegd:

Het Probleem: Te Veel Ruis

Momenteel staan ingenieurs die bugs in deze gigantische machines proberen te vinden, voor vier grote hoofdpijndossiers:

Het "Hele Bibliotheek"-Probleem: De code is zo groot dat als je het allemaal aan een computerbrein (een AI) laat zien, de AI overweldigd en verward raakt, zoals een student die probeert een hele encyclopedie te lezen om één typefout te vinden.
Het "Overvolle Kamer"-Probleem: De machine verwerkt veel taken tegelijk. Traditionele hulpmiddelen kijken naar de hele kamer en kunnen niet vertellen welke specifieke persoon (instructie) de rommel veroorzaakte.
Het "Blinddoek"-Probleem: Oude hulpmiddelen kijken naar de codestructuur maar negeren de daadwerkelijke getallen en waarden die door de machine stromen. Het is alsof je probeert een motorkap te repareren door naar de blauwdrukken te kijken maar het geluid van de motor negeert.
De "Menselijke" Kloof: Mensen zijn geweldig in debuggen omdat ze een spoor volgen: "Als dit tandwiel verkeerd is, moet het zijn omdat dat andere tandwiel het duwde." Computers worstelen om deze specifieke redeneerketen na te bootsen.

De Oplossing: BluesFL (De Slimme Detective)

De auteurs creëerden BluesFL, een systeem dat een AI leert te debuggen precies zoals een menselijke ingenieur dat doet. Ze deden dit in drie slimme stappen:

1. De Hooiberg Snijden in Beheersbare Stapels (Code Blokkering)

In plaats van de AI de hele 19.000 pagina's tellende handleiding in één keer te tonen, hakten ze de code in kleine, logische "blokken".

De Analogie: Stel je voor dat de machine een gigantische stad is. In plaats van de detective een kaart van de hele wereld te geven, geven ze hen een kaart van slechts één wijk. Ze groeperen alle straten (regels code) die met elkaar praten, zodat de AI zich alleen op één kleine, relevante wijk per keer hoeft te concentreren.

2. De Voetsporen Traceer (Instructie-Georiënteerde Slicing)

Wanneer de machine een fout maakt, gebeurt dat op een specifiek moment in de tijd. De auteurs bouwden een speciaal algoritme genaamd Blues dat de "voetsporen" traceert van de specifieke instructie die faalde.

De Analogie: Stel je een misdaadplek voor. In plaats van elke persoon in de stad te ondervragen, vraagt de detective: "Wie was er precies in de kamer toen het alarm afging?" Het Blues-algoritme bouwt een tijdlijn van alleen de specifieke tandwielen en draden die actief waren tijdens de fout. Het negeert iedereen anders die gewoon stond te wachten en niets deed.

3. De Clues Lezen (Signaalwaarden)

Dit is het meest menselijke deel. De AI kijkt niet alleen naar de code; het kijkt naar de waarden (de getallen) die op het exacte moment van de crash door de draden stromen.

De Analogie: Een menselijke monteur luistert naar de motor. Als een tandwiel 100 toeren per minuut moet draaien maar 50 draait, is dat een aanwijzing. BluesFL laat de AI deze getallen "lezen" uit de "golfform" van de machine (een opname van zijn hartslag). Dit helpt de AI te begrijpen waarom de fout gebeurde, niet alleen waar het gebeurde.

Hoe Het In De Praktijk Werkt

Wanneer een bug wordt gevonden, handelt BluesFL als een detective:

Het krijgt een rapport met de melding: "De machine sprong op tijdstip 19 naar het verkeerde adres."
Het gebruikt het Blues-algoritme om een pad te bouwen van alleen de codeblokken die bij die specifieke sprong betrokken waren.
Het vraagt de AI: "Kijk naar dit kleine blok code. Hier zijn de getallen die erin stromen. Ziet dit eruit als de dader?"
Als de AI zegt "Misschien", graaft het dieper, door de getallen terug te volgen naar de bron.
Het blijft doorgaan totdat het de specifieke regel code vindt die kapot is en rangschikt deze als de meest waarschijnlijke verdachte.

De Resultaten

Het team testte dit op een echte, open-source computerprocessor (de Ibex RISC-V kern).

De Oude Manier: De beste bestaande hulpmiddelen konden het kapotte tandwiel vinden in ongeveer 7 van de 100 gevallen.
De Nieuwe Manier (BluesFL): Hun systeem vond het kapotte tandwiel in 24 van de 100 gevallen (een enorme sprong!).
Kosten: Het was ook goedkoop om te draaien, met kosten die overeenkwamen met ongeveer 25 cent per gevonden bug.

De Conclusie

Het artikel beweert dat door AI te leren denken als een mens – door te focussen op kleine, relevante stukjes code, het specifieke spoor van de fout te volgen en de daadwerkelijke betrokken getallen te lezen – we bugs in gigantische computerprocessors veel sneller en nauwkeuriger kunnen vinden dan voorheen. Het gaat er niet om de AI in het algemeen slimmer te maken; het gaat erom het de juiste kaart en de juiste loupe te geven.

Technische Samenvatting: Debuggen als Mens

Probleemstelling
Foutlocatie (FL) in modern processorontwerp is een kritieke knelpunt, die ongeveer 60% van de hardware-ontwikkelinspanning in beslag neemt. Hoewel Large Language Models (LLM's) veelbelovend zijn gebleken voor hardware-ontwerp op module-niveau, blijft het toepassen ervan op grootschalige, projectmatige processorontwerpen uitdagend vanwege vier specifieke beperkingen:

Gebrek aan processor-specifieke technieken: Bestaande FL-methoden die zijn ontworpen voor algemene hardware (bijvoorbeeld geheugencontrollers) falen vaak bij processoren omdat ze geen rekening houden met de instructie-gedreven, complexe aard van processorarchitecturen.
Ondoeltreffende instructie-dekking: Traditionele spectrumbased-methoden vertrouwen op grofkorrelige dekking over simulatie-intervallen. In gepipelined processoren, waar instructies over meerdere modules en cycli strekken, leidt dit tot dekkingvervuiling door "in-flight" instructies, wat de nauwkeurigheid vermindert.
Onderschatting van signaalwaarden: Huidige hardware-FL-technieken maken zelden gebruik van concrete signaalwaarden (golven), omdat het interpreteren ervan geavanceerd semantisch inzicht vereist, wat voorheen moeilijk was voor geautomatiseerde tools.
Beperkingen van het contextvenster: Processorprojecten overschrijden vaak de contextlimieten van LLM's. Het verstrekken van de volledige codebase zorgt ervoor dat modellen hun focus verliezen, terwijl het verstrekken van te weinig context cruciale afhankelijkheden verbergt.

Methodologie: BluesFL
De auteurs stellen BluesFL voor, een op blok-niveau gebaseerd, LLM-gebaseerd raamwerk voor foutlocatie dat is geïnspireerd op menselijke debugwerkstromen. Het systeem werkt op een co-simulatiekader waarbij een hardwaremodel en een software-referentiemodel worden vergeleken om testrapporten te genereren die architecturale statemismatches aangeven.

De methodologie bestaat uit vier belangrijke fasen:

Op dataflow gebaseerde code-blokken:
Om contextlimieten aan te pakken, wordt de SystemVerilog-codebase opgesplitst in disjuncte codeblokken op basis van dataflow-relaties in plaats van bestandsstructuur. Deze blokken worden gecategoriseerd in vier types: ModInputBlock, ModOutputBlock, AssignBlock en AlwaysBlock. Deze benadering clustert statements met data-afhankelijkheden, behoudt lokale semantiek en creëert compacte eenheden die geschikt zijn voor LLM-analyse.
Op blok-niveau instructie-georiënteerde slicing (Blues):
Om de complexiteit van instructie-uitvoering aan te pakken, introduceren de auteurs het Blues-algoritme. Dit algoritme construeert een "Instructie-uitvoeringspad"-grafiek die begint bij een falend signaal en tijdstempel.
- Intra-blok analyse: Analyseert dataflow binnen een blok om aangedreven signalen te identificeren. Het berekent nieuwe tijdstempels ( $t'$ ) op basis van of het blok combinatief (zelfde tijd) of sequentieel (vorige cyclus) is.
- Inter-blok analyse: Traceert achterwaarts om de blokken te vinden die de geïdentificeerde signalen aandrijven, en koppelt deze in de uitvoeringspad-grafiek.
- Resultaat: Dit proces filtert irrelevante code weg en creëert een pad van alleen de blokken die daadwerkelijk worden gedekt tijdens de uitvoering van de falende instructie, geannoteerd met precieze tijdstempels.
LLM-redenering met tool-aanroepen:
De LLM fungeert als een debug-assistent die iteratief door het uitvoeringspad navigeert. Bij elke staat $(b, t)$ :
- Ontvangt de LLM de code-blokcontext en aangedreven signalen (met tijdstempels).
- Gebruikt een read_values-tool om specifieke signaalwaarden uit de golfvorm op het geannoteerde tijdstip op te vragen.
- Gebruikt een check_signals-tool om het uitvoeringspad op te vragen voor blokken die specifieke signalen aandrijven.
- Beslist of het huidige blok verdacht is, voegt het toe aan een wachtrij indien van toepassing, of vraagt om verdere inspectie.
Rangschikking:
Zodra de LLM bepaalt dat de oorzaak is gevonden of de analyse voltooid is, wijst het een betrouwbaarheidsscore (0–1) toe aan elk verdacht blok, waardoor een gerangschikte lijst van foutlocaties wordt geproduceerd.

Belangrijkste bijdragen

BluesFL-raamwerk: De eerste toepassing van LLM-gebaseerde foutlocatie specifiek op real-world, projectmatige processorontwerpen.
Op dataflow gebaseerde blokkering: Een methode om grote codebases te comprimeren tot semantisch rijke, compacte blokken die binnen de contextvensters van LLM's passen.
Blues-algoritme: Een nieuwe slicing-techniek die LLM's leidt om uitsluitend te focussen op door instructies gedekte blokken en tijds-geannoteerde signaalwaarden integreert om menselijke redenering over dynamisch processorgedrag na te bootsen.
Empirische validatie: Evaluatie op een open-source RISC-V-core (Ibex) van 19K regels met 119 ingebrachte bugs.

Experimentele resultaten
Geëvalueerd op de Ibex-processorcore, toonde BluesFL significante verbeteringen ten opzichte van state-of-the-art baselines (inclusief statische slicing, spectrumbased-methoden en bestaande LLM-gebaseerde methoden zoals LiK en Agentless):

Nauwkeurigheid: BluesFL lokaliseerde correct 24 bugs op Top-1, wat een 242,9% verbetering vertegenwoordigt ten opzichte van de beste bestaande baseline (LiK, die 7 bugs vond).
Efficiëntie: De gemiddelde kosten om een enkele bug te lokaliseren bedroegen $0,257.
Ablatiestudies: Het verwijderen van signaalwaarden of het instructie-uitvoeringspad degradeerde de prestaties aanzienlijk. Specifiek controleerde de LLM zonder signaalwaarden 609% meer blokken, wat de kosten per bug verhoogde tot $1,821.
Modelrobuustheid: Het raamwerk presteerde concurrerend over verschillende LLM-backends (GPT-4o-mini, GPT-4o, Claude-3.5-Sonnet), waarbij Claude-3.5-Sonnet de hoogste Top-1-score behaalde (30 bugs) tegen iets hogere kosten.

Betekenis en claims
Het artikel claimt dat BluesFL succesvol LLM-gebaseerde foutlocatie schaalt naar het procesordomein door de kloof te overbruggen tussen menselijke debug-intuïtie (het traceren van instructiepaden en signaalwaarden) en geautomatiseerde analyse. Door het menselijke proces van het terugbrengen van verdachte gebieden via dataflow en tijds-geannoteerde uitvoeringspaden na te bootsen, overwint het raamwerk de beperkingen van contextgrootte en dekkingvervuiling die bestaande methoden teisteren. De auteurs positioneren dit werk als een fundamentele stap richting agile, geautomatiseerde verificatie voor complexe processorontwerpen, met de opmerking dat hoewel huidige resultaten veelbelovend zijn, er meer werk nodig is om redenering over lange afstand tussen blokken te verbeteren om gevallen aan te pakken waar het debugproces voortijdig eindigt.