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

Resumo Técnico: Depuração como Humano

Declaração do Problema
A localização de falhas (FL) no projeto de processadores modernos é um gargalo crítico, consumindo aproximadamente 60% do esforço de desenvolvimento de hardware. Embora os Modelos de Linguagem de Grande Porte (LLMs) tenham demonstrado promessa no projeto de hardware em nível de módulo, aplicá-los a projetos de processadores em grande escala e nível de projeto permanece desafiador devido a quatro limitações específicas:

1. Falta de Técnicas Específicas para Processadores: Métodos de FL existentes projetados para hardware geral (por exemplo, controladores de memória) frequentemente falham em processadores porque não levam em conta a natureza complexa e orientada a instruções das arquiteturas de processadores.
2. Cobertura de Instruções Ineficaz: Métodos tradicionais baseados em espectro dependem de cobertura de granularidade grossa sobre intervalos de simulação. Em processadores pipelined, onde as instruções abrangem múltiplos módulos e ciclos, isso leva à poluição de cobertura por instruções "em voo", reduzindo a precisão.
3. Subutilização de Valores de Sinal: Técnicas atuais de FL de hardware raramente aproveitam valores concretos de sinal (formas de onda) porque interpretá-los requer compreensão semântica avançada, o que era anteriormente difícil para ferramentas automatizadas.
4. Restrições da Janela de Contexto: Projetos de processadores frequentemente excedem os limites de contexto dos LLMs. Fornecer toda a base de código faz com que os modelos percam o foco, enquanto fornecer muito pouco contexto esconde dependências críticas.

Metodologia: BluesFL
Os autores propõem o BluesFL, um framework de localização de falhas baseado em LLM e em nível de bloco, inspirado em fluxos de trabalho de depuração humana. O sistema opera em um framework de co-simulação onde um modelo de hardware e um modelo de referência de software são comparados para gerar relatórios de teste que indicam incompatibilidades de estado arquitetural.

A metodologia consiste em quatro etapas principais:

1. Blocagem de Código Baseada em Fluxo de Dados:
   Para abordar os limites de contexto, a base de código SystemVerilog é particionada em blocos de código disjuntos com base em relações de fluxo de dados, em vez da estrutura de arquivos. Esses blocos são categorizados em quatro tipos: ModInputBlock, ModOutputBlock, AssignBlock e AlwaysBlock. Essa abordagem agrupa declarações com dependências de dados, preservando semânticas locais enquanto cria unidades compactas adequadas para análise por LLM.

2. Fatiamento Orientado a Instruções em Nível de Bloco (Blues):
   Para abordar a complexidade da execução de instruções, os autores introduzem o algoritmo Blues. Este algoritmo constrói um grafo de "Caminho de Execução de Instrução" começando a partir de um sinal falho e um carimbo de tempo.

   • Análise Intra-Bloco: Analisa o fluxo de dados dentro de um bloco para identificar sinais acionados. Calcula novos carimbos de tempo ($t'$) com base se o bloco é combinacional (mesmo tempo) ou sequencial (ciclo anterior).
   • Análise Inter-Bloco: Rastreia para trás para encontrar os blocos que acionam os sinais identificados, vinculando-os no grafo de caminho de execução.
   • Resultado: Este processo filtra código irrelevante, criando um caminho apenas dos blocos realmente cobertos durante a execução da instrução falha, anotados com carimbos de tempo precisos.

3. Raciocínio LLM com Chamadas de Ferramentas:
   O LLM atua como um assistente de depuração que percorre iterativamente o caminho de execução. Em cada estado $(b, t)$, o LLM:

   • Recebe o contexto do bloco de código e os sinais acionados (com carimbos de tempo).
   • Usa uma ferramenta read_values para consultar valores específicos de sinal da forma de onda no tempo anotado.
   • Usa uma ferramenta check_signals para consultar o caminho de execução por blocos que acionam sinais específicos.
   • Decide se o bloco atual é suspeito, adicionando-o a uma fila se for, ou solicitando inspeção adicional.

4. Classificação:
   Uma vez que o LLM determina que a causa raiz foi encontrada ou que a análise está completa, ele atribui uma pontuação de confiança (0–1) a cada bloco suspeito, produzindo uma lista classificada de localizações de falhas.

Contribuições Principais

• Framework BluesFL: A primeira aplicação de localização de falhas baseada em LLM especificamente para projetos de processadores reais, em nível de projeto.
• Blocagem Baseada em Fluxo de Dados: Um método para comprimir grandes bases de código em blocos compactos e semanticamente ricos que cabem dentro das janelas de contexto dos LLMs.
• Algoritmo Blues: Uma técnica de fatiamento inovadora que guia os LLMs a focar exclusivamente em blocos cobertos por instruções e incorpora valores de sinal anotados com tempo para imitar o raciocínio humano sobre o comportamento dinâmico do processador.
• Validação Empírica: Avaliação em um núcleo RISC-V de código aberto de 19K linhas (Ibex) com 119 bugs injetados.

Resultados Experimentais
Avaliado no núcleo do processador Ibex, o BluesFL demonstrou melhorias significativas sobre as linhas de base mais avançadas (incluindo fatiamento estático, baseado em espectro e métodos existentes baseados em LLM como LiK e Agentless):

• Precisão: O BluesFL localizou corretamente 24 bugs no Top-1, representando uma melhoria de 242,9% sobre a melhor linha de base existente (LiK, que encontrou 7 bugs).
• Eficiência: O custo médio para localizar um único bug foi de $0,257.
• Estudos de Ablação: A remoção de valores de sinal ou do caminho de execução de instruções degradou significativamente o desempenho. Especificamente, sem valores de sinal, o LLM verificou 609% mais blocos, aumentando o custo por bug para $1,821.
• Robustez do Modelo: O framework performou competitivamente em diferentes backends de LLM (GPT-4o-mini, GPT-4o, Claude-3.5-Sonnet), com o Claude-3.5-Sonnet alcançando a maior pontuação Top-1 (30 bugs) a um custo ligeiramente superior.

Significado e Alegações
O artigo afirma que o BluesFL escala com sucesso a localização de falhas baseada em LLM para o domínio de processadores, fechando a lacuna entre a intuição de depuração humana (rastreamento de caminhos de instruções e valores de sinal) e análise automatizada. Ao imitar o processo humano de reduzir regiões suspeitas através de fluxos de dados e caminhos de execução anotados com tempo, o framework supera as limitações de tamanho de contexto e poluição de cobertura que afligem os métodos existentes. Os autores posicionam este trabalho como um passo fundamental em direção a uma verificação ágil e automatizada para projetos complexos de processadores, observando que, embora os resultados atuais sejam promissores, mais trabalho é necessário para melhorar o raciocínio cruzado de longo alcance entre blocos para lidar com casos onde o processo de depuração termina prematuramente.