RuC: HDL-Agnostic Rule Completion Benchmark Generation

Aquí se presenta un resumen técnico detallado del artículo "RuC: Benchmark de Finalización de Reglas Agnóstico a HDL".

1. Planteamiento del Problema

Si bien los Modelos de Lenguaje Grande (LLM) han demostrado ser prometedores en la Automatización de Diseño Electrónico (EDA), los benchmarks existentes para evaluar sus capacidades de finalización de código en Lenguajes de Descripción de Hardware (HDL) adolecen de limitaciones significativas:

• Falta de Control de Granularidad: Los benchmarks actuales generalmente caen en dos categorías: Finalización de Módulo (MC), que enmascara un módulo completo (a menudo demasiado complejo y cargado de contexto para reconstruirlo sin especificaciones), y Finalización de Línea Única (SLC), que enmascara una línea aleatoria.
• Unidades Arbitrarias: SLC depende de "líneas" como unidad de enmascaramiento, lo cual es un artefacto de formato en lugar de un constructo semánticamente significativo de HDL. Una línea aleatoria podría ser trivial o sintácticamente incompleta, fallando al probar características específicas del lenguaje.
• Rigor en la Evaluación: Muchos benchmarks dependen de métricas de coincidencia exacta o simulación simple, que no capturan la corrección parcial ni la equivalencia funcional rigurosa en diseños de hardware.

Los autores argumentan que existe la necesidad de un marco que permita una granularidad arbitraria y semánticamente significativa (desde una sola asignación hasta un bloque lógico completo) y utilice un enmascaramiento guiado por gramática para evaluar sistemáticamente la comprensión de los LLM de constructos HDL específicos.

2. Metodología: El Marco RuC

Los autores proponen RuC (Finalización Basada en Reglas), un marco guiado por gramática y agnóstico al lenguaje para generar benchmarks de finalización de reglas.

A. Concepto Central: Enmascaramiento Guiado por Gramática

En lugar de enmascarar líneas aleatorias o módulos completos, RuC analiza el código fuente HDL en un Árbol de Análisis basado en la gramática formal del lenguaje (por ejemplo, SystemVerilog).

• Selección de Reglas: Los usuarios seleccionan reglas gramaticales específicas (no terminales) para enmascarar, como port_declaration, continuous_assignment, case_statement o always_construct.
• Control de Granularidad: Al elegir diferentes reglas, la dificultad de la tarea puede ajustarse. Por ejemplo, enmascarar un simple_identifier es más fácil que enmascarar un always_construct completo.
• Agnóstico a HDL: El marco funciona para cualquier lenguaje siempre que esté disponible una definición de gramática (por ejemplo, mediante ANTLR).

B. Pipeline de Construcción de Tareas

El pipeline consta de tres etapas:

1. Preprocesamiento: Resuelve directivas del compilador y fusiona proyectos de múltiples archivos en una fuente unificada para proporcionar un contexto completo.
2. Análisis y Muestreo de Reglas: Analiza la fuente para generar un árbol de análisis, identifica ocurrencias de las reglas gramaticales seleccionadas y las enmascara. Filtra el código muerto o los constructos eliminados durante la elaboración.
3. Presupuesto de Contexto: Aborda los límites de la ventana de contexto de los LLM. Extrae dependencias de módulos (instanciaciones e importaciones) y poda el contexto para incluir solo dependencias relevantes, permitiendo a los usuarios intercambiar el tamaño del contexto por información estructural.

C. Estrategias de Prompting

RuC soporta dos paradigmas de prompting para alinearse con diferentes estrategias de entrenamiento de modelos:

• Basado en Chat: Reemplaza la región enmascarada con un token <MASK> y proporciona el contexto circundante con una instrucción.
• Relleno en el Medio (FIM): Divide el código en Prefijo, Medio (enmascarado) y Sufijo. Se solicita al modelo que genere el medio faltante mediante Prefijo + Sufijo + <TOKEN_MEDIO>. Esto se alinea con los objetivos de pre-entrenamiento de muchos LLM de codificación.

D. Pipeline de Verificación

Para garantizar una evaluación rigurosa, RuC emplea un proceso de verificación en dos pasos:

1. Validación Sintáctica (STX): Reinserta el código generado y lo revisa (utilizando Verilator) para asegurar que compile y se adhiera a las reglas del lenguaje.
2. Equivalencia Funcional (EQV): Utiliza verificación formal (solucionadores SAT mediante Yosys) para demostrar que el diseño generado por el LLM es funcionalmente equivalente a la verdad fundamental original. Construye un "circuito miter" y verifica si alguna secuencia de entrada puede producir salidas diferentes.

3. Contribuciones Clave

• Marco RuC: Un sistema novedoso y automatizado para generar benchmarks de finalización de código HDL con granularidad controlable basado en reglas gramaticales formales.
• Diseño Agnóstico a HDL: El enfoque es aplicable a cualquier lenguaje de descripción de hardware con una gramática definida, no solo a SystemVerilog.
• Evaluación Rigurosa: Va más allá de las métricas simples de similitud de texto para incluir verificación formal de equivalencia funcional, asegurando que el código generado funcione realmente como se pretende.
• Generación de Benchmark: Creó dos nuevos benchmarks de SystemVerilog derivados del shuttle Tiny Tapeout TT07 y el núcleo CVE2 RISC-V, cubriendo una amplia gama de complejidades de diseño.

4. Resultados Experimentales

Los autores evaluaron cinco LLM de código abierto (incluyendo Qwen2.5/3 Coder, Seed Coder y DeepSeek) en los benchmarks generados.

• Estrategia de Prompting: El prompting FIM superó consistentemente al prompting basado en Chat. Esto sugiere que el objetivo de "relleno" es crítico para tareas HDL donde el contexto es bidireccional.
• Variantes de Modelo: Sorprendentemente, los modelos Base (pre-entrenados únicamente) a menudo superaron a sus contrapartes ajustadas por instrucciones en la finalización de reglas. Esto indica que el ajuste por instrucciones, aunque útil para la codificación general, puede degradar las capacidades específicas de predicción del siguiente token requeridas para el relleno preciso de código.
• Dificultad de la Regla: El rendimiento varió significativamente según la regla gramatical:
  • Más fácil: PORT (declaraciones de puertos) y PARAM (parámetros), ya que estos a menudo pueden inferirse del uso de la interfaz.
  • Moderado: Reglas de asignación (CONT, BLK, NBLK).
  • Más difícil: Reglas de flujo de control (COND, CASE, ALWAYS), que requieren reconstruir lógica de comportamiento compleja.
• Tamaño del Modelo vs. Rendimiento: Aunque los modelos más grandes generalmente tuvieron un mejor rendimiento, la correlación no fue absoluta. Modelos más pequeños (por ejemplo, Seed Coder 8B) a veces superaron a los más grandes en reglas específicas, lo que sugiere que la selección de modelo específica por regla es más efectiva que un enfoque de talla única.
• Influencia de la Base de Código: El rendimiento se vio influenciado por regularidades estilísticas en la base de código (por ejemplo, las asignaciones no bloqueantes en CVE2 seguían un patrón altamente regular, aumentando las puntuaciones).

5. Significado

• Evaluación Granular: RuC proporciona el primer marco capaz de aislar y probar la comprensión de un LLM de constructos HDL específicos, superando la evaluación "todo o nada" de módulos completos o líneas aleatorias.
• Escalabilidad: Al automatizar la generación de tareas a partir de diseños de código abierto del mundo real, permite una evaluación escalable que anteriormente estaba limitada por la curación manual de conjuntos de datos.
• Integración en el Flujo de Trabajo EDA: Los hallazgos destacan que el prompting FIM y los modelos base son actualmente superiores para la asistencia al estilo de copiloto RTL, guiando el desarrollo de futuras herramientas EDA.
• Investigación Futura: El marco abre la puerta para estudiar cómo los LLM manejan longitudes de contexto variables y patrones lógicos específicos, lo cual es esencial para construir asistentes de IA confiables para el diseño de hardware.

En conclusión, RuC establece un nuevo estándar para evaluar LLM en diseño de hardware al combinar el análisis de gramática formal con la verificación funcional rigurosa, revelando que los modelos actuales luchan con la lógica de control compleja pero sobresalen en la reconstrucción estructural cuando se les solicita correctamente.