💻 computer science

AI-Generated RTL Code: A Functional Evaluation of Natural-Language and HLS Prompting

Este estudio evalúa la capacidad de los LLM comerciales para generar RTL de Verilog funcional a partir de especificaciones de alto nivel, encontrando que el uso de prompts de HLS-C mejora significativamente la corrección en comparación con el lenguaje natural, al tiempo que revela desafíos persistentes con errores de simulación y una generalización limitada a través de anchos de bits variables.

Autores originales: Giordano Santorum Lorenzetto, Vanderlei Bonato, Oliver Sinnen

Publicado 2026-08-05

📖 6 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Giordano Santorum Lorenzetto, Vanderlei Bonato, Oliver Sinnen

Artículo original bajo licencia CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que estás intentando construir una fábrica diminuta y súper rápida dentro de un microchip. Esta no es una fábrica que fabrique juguetes o coches; es una fábrica digital que procesa información a la velocidad de la luz. Para construirla, los ingenieros escriben un tipo especial de manual de instrucciones llamado código RTL (Nivel de Transferencia de Registros). Piensa en este código como el plano de las cintas transportadoras, los brazos de ensamblaje y los semáforos de la fábrica. Si el plano tiene incluso un error minúsculo, toda la fábrica podría atascarse, prenderse fuego o simplemente dejar de funcionar por completo.

Durante mucho tiempo, escribir estos planos ha sido como hablar un lenguaje secreto y rígido que solo unos pocos expertos entienden. Pero ahora, tenemos Inteligencia Artificial (IA) que es increíblemente buena escribiendo código para software, como las aplicaciones de tu teléfono o los sitios web que visitas. La gente empezó a preguntarse: "Si la IA puede escribir código de software tan bien, ¿puede también escribir estos complicados planos de hardware?". Esta es la gran pregunta que los investigadores abordaron. Querían ver si una IA inteligente podía mirar una descripción simple de una tarea de hardware y convertirla en un plano de fábrica funcional, o si simplemente se confundiría con las estrictas reglas del hardware.

El Experimento: Hablar vs. Programar

Los investigadores configuraron una prueba masiva para ver qué tan bien podían realizar este trabajo diferentes modelos de IA. Le dieron a la IA dos formas muy diferentes de pedir un plano:

El enfoque "Charlatán" (Lenguaje Natural): Simplemente le dijeron a la IA en inglés sencillo lo que el hardware debía hacer. Por ejemplo, "Haz una máquina que multiplique dos números". Es como pedirle a un amigo: "Oye, hazme un sándwich", sin darle una receta.
El enfoque de "Programador" (Prompting HLS-C): En lugar de inglés sencillo, le dieron a la IA un fragmento de código C (un lenguaje de programación común) que describía la lógica. Esto es como entregarle a la IA una receta detallada escrita en un lenguaje que conoce muy bien, y pedirle que traduzca esa receta al "lenguaje de fábrica" específico (Verilog).

Probaron esto con siete modelos de IA diferentes (incluyendo nombres importantes como GPT-4 y Gemini) y les pidieron construir ocho tipos diferentes de circuitos digitales, que iban desde simples controladores de semáforos hasta complejos calculadores matemáticos. Realizaron cada prueba 30 veces para ver si la IA lo lograba por azar o si realmente comprendía la tarea.

Los Resultados: La Receta Gana

Los hallazgos fueron bastante claros y podrían sorprenderte. Cuando se "chateaba" con la IA en inglés sencillo, esta tenía dificultades. En promedio, solo alrededor del 26.9% de los planos que generaba funcionaban realmente. La mayoría de las veces, la IA cometía errores que eran como intentar construir una casa con los ladrillos equivocados: el código ni siquiera compilaba (no arrancaba), o se ejecutaba pero producía resultados incorrectos.

Sin embargo, cuando los investigadores cambiaron al código de receta C (prompting HLS-C), el rendimiento de la IA aumentó. La tasa de éxito subió al 39.5%. ¡Es una gran mejora! Esto sugiere que, aunque la IA es inteligente, piensa más como un programador que como un ingeniero de hardware. Cuando le das una receta de código estructurada, sabe exactamente cómo traducir esos pasos al lenguaje de hardware. Es como si la IA dijera: "Ah, ¿me diste una receta en francés? Puedo traducir eso al español perfectamente. Pero si solo dices 'haz un sándwich' en inglés, podría adivinar mal los ingredientes".

La Prueba del "Número Extraño": ¿Memoriza o Entiende?

Para ver si la IA solo estaba copiando respuestas que había visto antes (memorización) o si realmente entendía cómo construir estas máquinas, los investigadores hicieron un truco. Le pidieron a la IA construir un multiplicador (una máquina matemática) usando números de bits extraños e inusuales, como 7 bits o 31 bits. Estos son números que casi nunca se ven en la vida real, por lo que la IA no podría haber memorizado la respuesta de sus datos de entrenamiento.

Los resultados aquí fueron fascinantes. Algunos de los modelos de IA más inteligentes (como o4-mini y Gemini 2.5 Pro) manejaron estos números extraños casi perfectamente, acertando más del 90% de las veces. Esto sugiere que estos modelos no están solo copiando y pegando; realmente entienden la lógica de cómo construir la máquina, sin importar su tamaño. Pueden generalizar, lo que significa que pueden aplicar las reglas a situaciones nuevas que nunca han visto antes.

El Problema: Aún no es Perfecta

A pesar de las mejoras, el artículo deja muy claro que aún no hemos llegado a la meta. Incluso con el enfoque de "receta", la IA todavía falla más de lo que tiene éxito. El mayor problema no es que la IA cometa errores de sintaxis (como errores ortográficos); es que se equivoca en el tiempo (timing).

Imagina que la IA construye una fábrica donde la cinta transportadora se mueve un segundo demasiado rápido. El plano parece perfecto y la máquina se enciende, pero los productos se caen de la línea antes de ser empacados. En el estudio, estos "errores de simulación" fueron los fallos más comunes. La IA a menudo crea código que parece correcto, pero que se comporta de forma ligeramente errónea cuando el reloj empieza a correr. Corregir estos errores es difícil porque requiere una comprensión profunda de cómo el hardware se comporta a través del tiempo, algo con lo que la IA todavía tiene dificultades.

Los investigadores también descubrieron que, cuando la IA sí lo hacía bien, el hardware resultante era a menudo tan rápido, o incluso más rápido, que los planos escritos por expertos humanos. Esta es una gran victoria, lo que sugiere que si podemos lograr que la IA deje de cometer esos pequeños errores de tiempo, podría ser un asistente superpotente para los ingenieros.

La Conclusión

Entonces, ¿cuál es la conclusión? La IA se está volviendo muy buena ayudándonos a diseñar chips de computadora, pero aún no está lista para tomar el control del trabajo por completo. Es como un pasante brillante que puede redactar un gran diseño si le das un plan claro y estructurado (como una receta de código C), pero que todavía necesita un supervisor humano para revisar los detalles finales y asegurarse de que la fábrica no colapse.

El estudio sugiere que usar prompts basados en código es una forma mucho mejor de hablar con estos modelos de IA que simplemente chatear en inglés sencillo. Aunque la IA todavía comete errores que requieren depuración humana, ya está demostrando ser una herramienta poderosa para acelerar el proceso de diseño y ayudar a las personas que son nuevas en la ingeniería de hardware a comenzar. No estamos en el punto en que la IA pueda construir un chip desde cero sin ayuda, pero definitivamente nos dirigimos en la dirección correcta.

Resumen Técnico: Código RTL Generado por IA: Una Evaluación Funcional del Prompting de Lenguaje Natural y de HLS

Planteamiento del Problema
La creciente complejidad del diseño de hardware ha despertado el interés en el uso de Modelos de Lenguaje Extensos (LLMs) para generar código de Transferencia de Registros a Nivel (RTL). Aunque los LLMs han demostrado competencia en la generación de código de software, su aplicabilidad al desarrollo de hardware sigue siendo poco explorada. El diseño de hardware impone requisitos más estrictos que el software, necesitando corrección funcional, optimización de recursos y un manejo preciso de la concurrencia y el tiempo (timing). Aunque las herramientas de Síntesis de Alto Nivel (HLS) permiten a los diseñadores describir hardware en C/C++, a menudo requieren directivas específicas y ofrecen un control limitado sobre la estructura RTL resultante. Este estudio investiga si los LLMs de propósito general disponibles comercialmente pueden generar RTL en Verilog funcionalmente correcto directamente a partir de especificaciones de alto nivel sin ajuste fino (fine-tuning), y evalúa cómo diferentes estrategias de prompting influyen en la calidad de la generación.

Metodología
La investigación utilizó el benchmark RTLLM, un conjunto de datos que comprende especificaciones en lenguaje natural, implementaciones de referencia en Verilog y bancos de pruebas (testbenches) funcionales para diversos módulos de hardware (que van desde lógica combinacional hasta circuitos secuenciales). Los autores evaluaron siete LLMs distintos de OpenAI (GPT-4.1, GPT-4o, o4-mini) y Google (Gemini 1.5 Pro, 2.0 Flash, 2.5 Flash, 2.5 Pro).

Se compararon dos estrategias de prompting utilizando un enfoque zero-shot:

Prompting de Lenguaje Natural (NL): Descripciones textuales directas de funcionalidad, puertos de E/S y directrices de implementación.
Prompting de C estilo HLS: Fragmentos de código C estructurados que representan la funcionalidad de hardware deseada, diseñados para ser sintetizables por AMD Vitis HLS.

El flujo de trabajo de evaluación fue totalmente automatizado:

Generación: Cada modelo generó $n=30$ salidas de Verilog independientes por cada prompt.
Compilación: El código fue verificado en busca de errores de sintaxis utilizando el simulador Questa.
Simulación: El código compilado exitosamente fue integrado con bancos de pruebas y simulado.
Verificación: Las salidas se compararon contra los resultados esperados. Los errores se categorizaron como de Compilación, Integración o Simulación.
Síntesis: Los diseños que funcionaron correctamente fueron sintetizados en una FPGA Intel Cyclone V para medir la frecuencia máxima de operación ( $F_{max}$ ) y la utilización de área (ALMs) frente a los diseños de referencia escritos por humanos.

Adicionalmente, se realizó un estudio de caso exploratorio sobre el escalado de ancho de bits utilizando un diseño de multiplicador secuencial. El ancho de bits se varió a través de valores estándar (8, 32, 64) y valores inusuales y dispersos (7, 12, 15, 23, 24, 31, 50, 63) para probar la capacidad de los modelos para generalizar la lógica algorítmica frente al mero recuerdo de patrones de entrenamiento.

Resultados Clave

Impacto de la Estrategia de Prompting: El prompting de HLS-C superó significativamente al de Lenguaje Natural. La tasa promedio de corrección funcional aumentó del 26.9% (NL) al 39.5% (HLS-C).
Distribución de Errores: Los prompts de HLS-C redujeron sustancialmente los errores de compilación (del 33.5% al 24.2% en promedio) y los errores de integración. Sin embargo, los errores de simulación siguieron siendo el principal desafío, representando aproximadamente el 35% de los intentos incluso con HLS-C, lo que indica que los modelos aún tienen dificultades con la traducción ciclo a ciclo del comportamiento complejo del hardware.
Desempeño de los Modelos: Los modelos o4-mini y Gemini 2.5 Pro lograron consistentemente las tasas de corrección más altas en ambas estrategias.
Generalización: En el experimento de escalado de ancho de bits, o4-mini y Gemini 2.5 Pro demostraron una robusta generalización, manteniendo una alta corrección (>90%) en anchos no estándar (por ejemplo, 7 bits, 23 bits), lo que sugiere que no están simplemente memorizando datos de entrenamiento, sino comprendiendo algoritmos subyacentes.
Calidad del Hardware: Los diseños sintetizados a menudo alcanzaron valores de $F_{max}$ superiores a los diseños de referencia escritos por humanos. No obstante, los prompts de HLS-C tendieron a producir diseños con menor variabilidad de desempeño pero, ocasionalmente, con huellas de área más grandes en comparación con los prompts de NL, probablemente debido a que los modelos traducen constructos procedimentales de C en estructuras de hardware rígidas.

Contribuciones Clave

Análisis Comparativo de Prompts: El estudio demuestra que proporcionar entradas estructuradas y centradas en el código (HLS-style C) mejora significativamente la corrección funcional del RTL generado por LLM en comparación con las descripciones de lenguaje natural.
Evaluación de la Generalización: Proporciona un análisis de cómo los LLM manejan parámetros de diseño poco comunes, revelando que los modelos de frontera pueden abstraer la lógica algorítmica de manera efectiva, mientras que los modelos más ligeros suelen fallar al generalizar más allá de los patrones estándar.
Evaluación de la Calidad del Hardware: El trabajo ofrece un análisis de calidad comparando los diseños generados por LLM contra referencias humanas en términos de tiempo ( $F_{max}$ ) y área, destacando que, si bien los LLM pueden producir arquitecturas competitivas, a menudo requieren una selección manual de entre múltiples intentos para lograr resultados óptimos.

Significancia y Reivindicaciones
Los autores concluyen que, aunque los LLM aún no son capaces de producir de forma autónoma código RTL listo para producción debido a los persistentes errores de simulación y al alto costo de depuración, representan una poderosa herramienta de asistencia para los desarrolladores de hardware. La mejora en el desempeño con prompts de HLS-C sugiere que aprovechar la familiaridad de los modelos con la sintaxis de software puede cerrar la brecha en la generación de hardware. El artículo postula que los LLM son particularmente valiosos para generar implementaciones preliminares o código "boilerplate" para que ingenieros experimentados lo revisen y optimicen, y como herramientas educativas para ayudar a los ingenieros de software a transicionar hacia el diseño de hardware mediante el mapeo de constructos de C familiares a RTL. El estudio enfatiza que las limitaciones actuales hacen necesaria la supervisión humana, particularmente para la lógica secuencial compleja y los diseños críticos de tiempo.

El Experimento: Hablar vs. Programar

Los Resultados: La Receta Gana

La Prueba del "Número Extraño": ¿Memoriza o Entiende?

El Problema: Aún no es Perfecta

La Conclusión

Más como este