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

Resumen Técnico: Depurar como un Humano

Enunciado del Problema
La localización de fallos (FL) en el diseño de procesadores modernos es un cuello de botella crítico, que consume aproximadamente el 60% del esfuerzo de desarrollo de hardware. Si bien los Modelos de Lenguaje Grande (LLM) han demostrado ser prometedores en el diseño de hardware a nivel de módulo, su aplicación a diseños de procesadores a gran escala y a nivel de proyecto sigue siendo un desafío debido a cuatro limitaciones específicas:

1. Falta de Técnicas Específicas para Procesadores: Los métodos de FL existentes diseñados para hardware general (por ejemplo, controladores de memoria) a menudo fallan en procesadores porque no tienen en cuenta la naturaleza compleja y dirigida por instrucciones de las arquitecturas de procesadores.
2. Cobertura de Instrucciones Ineficaz: Los métodos tradicionales basados en espectro dependen de una cobertura de grano grueso sobre intervalos de simulación. En procesadores con pipeline, donde las instrucciones abarcan múltiples módulos y ciclos, esto conduce a contaminación de cobertura por instrucciones "en vuelo", reduciendo la precisión.
3. Subutilización de los Valores de Señal: Las técnicas actuales de FL en hardware raramente aprovechan los valores concretos de las señales (formas de onda) porque su interpretación requiere una comprensión semántica avanzada, lo cual era previamente difícil para las herramientas automatizadas.
4. Restricciones de la Ventana de Contexto: Los proyectos de procesadores a menudo superan los límites de contexto de los LLM. Proporcionar toda la base de código hace que los modelos pierdan el enfoque, mientras que proporcionar demasiado poco contexto oculta dependencias críticas.

Metodología: BluesFL
Los autores proponen BluesFL, un marco de localización de fallos basado en LLM a nivel de bloque, inspirado en los flujos de trabajo de depuración humana. El sistema opera sobre un marco de co-simulación donde se compara un modelo de hardware con un modelo de referencia de software para generar informes de prueba que indican discrepancias en el estado arquitectónico.

La metodología consta de cuatro etapas clave:

1. Bloqueo de Código Basado en Flujo de Datos:
   Para abordar los límites de contexto, la base de código SystemVerilog se divide en bloques de código disjuntos basados en relaciones de flujo de datos en lugar de la estructura de archivos. Estos bloques se categorizan en cuatro tipos: ModInputBlock, ModOutputBlock, AssignBlock y AlwaysBlock. Este enfoque agrupa declaraciones con dependencias de datos, preservando la semántica local mientras crea unidades compactas adecuadas para el análisis de LLM.

2. Segmentación Orientada a Instrucciones a Nivel de Bloque (Blues):
   Para abordar la complejidad de la ejecución de instrucciones, los autores introducen el algoritmo Blues. Este algoritmo construye un gráfico de "Ruta de Ejecución de Instrucciones" comenzando desde una señal fallida y una marca de tiempo.

   • Análisis Intra-Bloque: Analiza el flujo de datos dentro de un bloque para identificar señales impulsadas. Calcula nuevas marcas de tiempo ($t'$) basándose en si el bloque es combinacional (mismo tiempo) o secuencial (ciclo anterior).
   • Análisis Inter-Bloque: Rastrea hacia atrás para encontrar los bloques que impulsan las señales identificadas, vinculándolos en el gráfico de ruta de ejecución.
   • Resultado: Este proceso filtra el código irrelevante, creando una ruta que solo incluye los bloques realmente cubiertos durante la ejecución de la instrucción fallida, anotados con marcas de tiempo precisas.

3. Razonamiento de LLM con Llamadas a Herramientas:
   El LLM actúa como un asistente de depuración que recorre iterativamente la ruta de ejecución. En cada estado $(b, t)$, el LLM:

   • Recibe el contexto del bloque de código y las señales impulsadas (con marcas de tiempo).
   • Utiliza una herramienta read_values para consultar valores específicos de señales de la forma de onda en el momento anotado.
   • Utiliza una herramienta check_signals para consultar la ruta de ejecución en busca de bloques que impulsan señales específicas.
   • Decide si el bloque actual es sospechoso, agregándolo a una cola si es así, o solicitando una inspección adicional.

4. Clasificación:
   Una vez que el LLM determina que se ha encontrado la causa raíz o que el análisis está completo, asigna una puntuación de confianza (0–1) a cada bloque sospechoso, produciendo una lista clasificada de ubicaciones de fallos.

Contribuciones Clave

• Marco BluesFL: La primera aplicación de localización de fallos basada en LLM específicamente a diseños de procesadores reales a nivel de proyecto.
• Bloqueo Basado en Flujo de Datos: Un método para comprimir grandes bases de código en bloques compactos y semánticamente ricos que caben dentro de las ventanas de contexto de los LLM.
• Algoritmo Blues: Una técnica de segmentación novedosa que guía a los LLM para que se centren exclusivamente en los bloques cubiertos por instrucciones e incorpora valores de señales anotados con tiempo para imitar el razonamiento humano sobre el comportamiento dinámico de los procesadores.
• Validación Empírica: Evaluación en un núcleo de código abierto RISC-V de 19K líneas (Ibex) con 119 errores inyectados.

Resultados Experimentales
Evaluado en el núcleo del procesador Ibex, BluesFL demostró mejoras significativas sobre las líneas base más avanzadas (incluyendo segmentación estática, métodos basados en espectro y métodos existentes basados en LLM como LiK y Agentless):

• Precisión: BluesFL localizó correctamente 24 errores en la posición Top-1, lo que representa una mejora del 242,9% sobre la mejor línea base existente (LiK, que encontró 7 errores).
• Eficiencia: El costo promedio para localizar un solo error fue de 0,257 dólares.
• Estudios de Ablación: Eliminar los valores de señal o la ruta de ejecución de instrucciones degradó significativamente el rendimiento. Específicamente, sin valores de señal, el LLM verificó un 609% más de bloques, aumentando el costo por error a 1,821 dólares.
• Robustez del Modelo: El marco funcionó de manera competitiva en diferentes backends de LLM (GPT-4o-mini, GPT-4o, Claude-3.5-Sonnet), con Claude-3.5-Sonnet logrando la puntuación Top-1 más alta (30 errores) a un costo ligeramente superior.

Significado y Afirmaciones
El artículo afirma que BluesFL escala con éxito la localización de fallos basada en LLM al dominio de los procesadores al cerrar la brecha entre la intuición de depuración humana (rastrear rutas de instrucciones y valores de señales) y el análisis automatizado. Al imitar el proceso humano de reducir las regiones sospechosas a través de flujos de datos y rutas de ejecución anotadas con tiempo, el marco supera las limitaciones de tamaño de contexto y contaminación de cobertura que afectan a los métodos existentes. Los autores posicionan este trabajo como un paso fundamental hacia la verificación automatizada y ágil para diseños de procesadores complejos, señalando que, aunque los resultados actuales son prometedores, se necesita más trabajo para mejorar el razonamiento cruzado entre bloques a larga distancia para manejar casos donde el proceso de depuración termina prematuramente.