🤖 AI

ContractHIL-HLS: Contract-Aligned Multi-Agent Workflow with Hardware-in-the-Loop Feedback for HLS Design

Este artículo presenta ContractHIL-HLS, un flujo de trabajo multiagente alineado con contratos que integra la traducción estructurada de lenguaje natural a contrato con retroalimentación de hardware en el bucle para mejorar significativamente las tasas de aprobación en tareas de diseño HLS y optimizar los aceleradores de criptografía post-cuántica a nivel de placa.

Autores originales: Jingbo Zhang, Haoxiang Sun, Wenbo Wang, Wenbo Zhang

Publicado 2026-07-29

📖 7 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Jingbo Zhang, Haoxiang Sun, Wenbo Wang, Wenbo Zhang

Artículo original bajo licencia CC BY 4.0 (http://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 tratando de enseñarle a un robot brillante y ultrarrápido a construir una máquina compleja, como una consola de videojuegos personalizada o una bóveda súper segura. Le das instrucciones al robot en inglés sencillo, como "Hazlo rápido y seguro". El robot, impulsado por un Modelo de Lenguaje Grande (una IA que lee y escribe código), intenta construirlo. Pero aquí está el truco: el robot es excelente escribiendo la idea del código, pero a menudo olvida las reglas diminutas y aburridas que las máquinas reales necesitan para funcionar de verdad, como cuánta energía consumen o si las piezas encajan entre sí. Este es el mundo de la Síntesis de Alto Nivel (HLS), donde los humanos intentan usar la IA para convertir ideas simples en diseños de hardware reales para chips. La gran pregunta no es solo "¿Puede la IA escribir código?", sino "¿Puede la IA construir algo que realmente funcione en una placa real sin que tengamos que corregir cada uno de sus errores a mano?".

Aquí es donde un equipo de investigadores de la Universidad de Tecnología de Beijing entra con una nueva idea llamada ContractHIL-HLS. Piensa en esto como un "gestor de proyectos inteligente" para la IA. En lugar de simplemente dejar que la IA charle de ida y vuelta contigo, la obligan a firmar un "contrato" formal primero. Este contrato es una lista estricta y estructurada de reglas: "Aquí está exactamente lo que la máquina debe hacer, estas son las cosas que absolutamente no puede hacer y así es como la probaremos". Si la IA intenta romper las reglas, el sistema la detecta de inmediato. Aún más genial, conectan este proceso con el hardware real. Si la IA diseña un chip que se calienta demasiado o es demasiado lento, la máquina real envía un "informe de error" de vuelta a la IA, que luego tiene que reescribir el diseño para solucionarlo. Es como un videojuego donde el personaje no solo adivina la solución; recibe un golpe por una trampa, ve exactamente por qué falló e intenta de nuevo con un mejor plan.

El Problema: La IA es buena charlando, mala construyendo

Normalmente, cuando le pides a una IA que diseñe hardware, actúa como un escritor creativo. Genera código basado en tu instrucción, pero a menudo olvida la "letra pequeña". Tal vez utiliza una función que el chip de hardware no soporta, o crea un diseño que se ve bien en papel pero falla cuando intentas ejecutarlo. Los métodos anteriores intentaron solucionar esto haciendo que la IA desempeñara diferentes roles, como "Arquitecto" o "Programador", pero la IA a menudo olvidaba lo que el Arquitecto dijo para cuando el Programador comenzaba a trabajar. La intención del diseño se perdía en la conversación.

Los investigadores se dieron cuenta de que, en lugar de confiar en una conversación larga y desordenada, necesitaban un contrato estructurado. Imagina que estás pidiendo una pizza personalizada. En lugar de decir simplemente "Quiero una pizza deliciosa", llenas un formulario: "Masa: Fina. Ingredientes: Solo pepperoni. Sin champiñones. Debe estar lista en 10 minutos". Este formulario es el "contrato". En el mundo del diseño de chips, este contrato traduce tu idea vaga en un conjunto estricto de reglas que la IA debe seguir.

La Solución: El Flujo de Trabajo de Tres Agentes

El equipo construyó un sistema con tres "agentes" especializados (ayudantes de IA) que trabajan juntos como una máquina bien aceitada:

El Agente de Contrato: Este agente toma tu solicitud desordenada en lenguaje natural (por ejemplo, "Haz un sistema de mensajes seguro") y la convierte en ese estricto contrato de "pedido de pizza". Define la interfaz, las restricciones (qué está prohibido) y las reglas para las pruebas.
El Agente HTML: Este agente toma el contrato y lo convierte en una página web (HTML) limpia y estructurada. ¿Por qué una página web? Porque es fácil de leer para los humanos, fácil de entender para el siguiente agente de IA y fácil de verificar para los scripts de computadora. Actúa como un registro permanente e inalterable de las reglas.
El Agente de Hardware-in-the-Loop (HIL): Este es el constructor. Mira el contrato HTML, escribe el código y luego —aquí está la parte mágica— lo prueba realmente en hardware o lo simula. Si el hardware dice: "Oye, este diseño usa demasiada memoria", el agente HIL ve esa evidencia, lee el contrato y reescribe el código para arreglarlo. Si no puede arreglarlo, el sistema sabe que debe "retroceder" e intentar un enfoque diferente.

Lo que Encontraron: Pequeñas Victorias y Grandes Saltos

El equipo probó este sistema de dos maneras muy diferentes para ver si realmente funcionaba.

1. La Prueba de "Diseño Pequeño" (HLS-Eval)
Primero, probaron el sistema en 94 tareas de codificación pequeñas y estándar. Compararon tres métodos:

Directo: Simplemente pedirle a la IA sin reglas especiales.
Contrato: Usar el contrato estructurado pero sin la retroalimentación del hardware real.
ContractHIL-HLS: Usando el sistema completo con el contrato y la retroalimentación del hardware.

Los resultados fueron claros. El método "Directo" pasó las pruebas aproximadamente el 64.0% de las veces. Cuando añadieron el Contrato, la tasa de éxito saltó al 70.2%. El sistema completo alcanzó el 70.4% para intentos únicos y el 76.6% si dejabas que la IA lo intentara cinco veces. Esto demuestra que el simple hecho de obligar a la IA a seguir un contrato estructurado la hace mucho más confiable, incluso antes de tocar el hardware real.

2. La Prueba del "Mundo Real" (Caso de Estudio PQC)
Las pruebas pequeñas son geniales, pero ¿funcionan para sistemas grandes y complejos? Para averiguarlo, el equipo construyó un acelerador de mensajes seguro usando Criptografía Post-Cuántica (PQC), una forma súper segura de enviar mensajes que incluso las futuras computadoras cuánticas no pueden descifrar. Este es un desafío de ingeniería masivo que involucra memoria, tiempo y potencia.

Comenzaron con un único diseño (un "bitstream") que tardaba 207.3 ms en procesar un mensaje. El sistema analizó la retroalimentación del hardware y se dio cuenta de que el diseño estaba demasiado saturado y era lento. Siguiendo las reglas del contrato, la IA dividió el diseño en dos partes separadas (una organización de "doble bitstream"). Una parte manejaba el envío y la otra la recepción.

¿El resultado? ¡El nuevo diseño procesó mensajes en solo 52.4 ms! Es una aceleración masiva. También utilizó menos energía y pasó todas las comprobaciones de tiempo. El sistema utilizó con éxito el "contrato" para guiar a la IA de un diseño único y lento a un diseño dividido y rápido, manteniendo intactas todas las reglas de seguridad.

Por qué esto importa

El artículo muestra que no necesitamos esperar a que la IA se convierta en un "genio" por sí sola. En su lugar, podemos construir un flujo de trabajo donde la IA sea guiada por un contrato estricto e inquebrantable y corregida por evidencia del mundo real. Los investigadores descubrieron que este enfoque no solo hace que la IA escriba código más rápido; hace que el código funcione.

Sin embargo, el artículo es cuidadoso al notar que esto no es una varita mágica para todo. En sus pruebas, hubo un grupo de tareas (llamadas "machsuite") donde la IA todavía fallaba por completo, incluso con el contrato. Esto sugiere que, si bien el contrato ayuda a la IA a seguir reglas, no puede arreglarlo si la IA simplemente no conoce la matemática o la lógica subyacente todavía.

En resumen, ContractHIL-HLS es un puente entre el mundo desordenado de las ideas humanas y el mundo rígido de los chips de hardware. Convierte a la IA de un escritor creativo en un ingeniero disciplinado, asegurando que cuando pedimos una máquina segura y rápida, realmente obtenemos una que funciona.

Resumen Técnico: ContractHIL-HLS

Planteamiento del Problema

Si bien los Modelos de Lenguaje de Gran Escala (LLMs) han demostrado la capacidad de generar código de hardware, la ingeniería práctica de Síntesis de Alto Nivel (HLS) requiere flujos de trabajo que mantengan la intención del diseño a través de las iteraciones, asegurando la alineación con la retroalimentación de la Automatización de Diseño Electrónico (EDA), el control del host, la propiedad de la memoria y las mediciones de despliegue en FPGAs. Los benchmarks existentes (p. ej., Chip-Chat, RTLLM, HLS-Eval) muestran que los modelos pueden generar código válido, pero a menudo fallan al establecer un flujo de trabajo donde la intención del diseño sea trazable frente a la retroalimentación de las herramientas y los resultados de despliegue. Los enfoques actuales suelen depender de prompts de rol conversacionales o del historial de la conversación como estado, lo que puede derivar en que las restricciones introducidas por un prompt de "arquitecto" sean omitidas por un prompt posterior de "programador". Además, el trabajo actual de asistencia de LLM en HLS se centra principalmente en el núcleo (kernel), careciendo de cobertura para la partición de bitstreams, la propiedad del estado vivo y los límites de seguridad entre etapas.

Metodología

El artículo propone ContractHIL-HLS, un flujo de trabajo multi-agente alineado por contrato diseñado para transformar solicitudes imprecisas de lenguaje natural en implementaciones de HLS trazables. El flujo de trabajo se distingue por tres mecanismos centrales:

Contrato Estructurado como un Artefacto de Ejecución: En lugar de depender de un historial conversacional laxo, el flujo de trabajo introduce un contrato formal ( $C = \langle R, I, F, H, K, O, V, B \rangle$ ) que codifica los requisitos en campos explícitos: Rol/Plataforma, Interfaz Pública, Intención Funcional, Restricciones Duras/Negativas, Compatibilidad, Intención de Optimización, Evidencia de Validación y Política de Reversión (Rollback). Este contrato sirve como el artefacto de alineación semántica y ejecución de tareas.
Descomposición de Agentes por Reducción Semántica: Los agentes se definen por sus tareas de transformación en lugar de sus roles conversacionales:
- Agente de Contrato: Normaliza el lenguaje natural en el contrato estructurado.
- Agente HTML: Renderiza el contrato en un artefacto HTML estable e inspeccionable que contiene secciones, tablas y listas de verificación. Este artefacto es legible tanto por humanos como por scripts.
- Agente de Hardware-in-the-Loop (HIL): Implementa y revisa el diseño utilizando el artefacto HTML combinado con evidencia de hardware medida.
Bucle de Retroalimentación de Hardware-in-the-Loop: El flujo de trabajo integra la retroalimentación de las herramientas HLS (Vitis), las herramientas de implementación (Vivado) y las mediciones de tiempo de ejecución de la placa (PYNQ) directamente en el bucle de generación y decisión. Esto extiende la asistencia de LLM desde el código del kernel hacia el cierre de sistema y de placa. El bucle incluye solicitudes de implementación acotadas, verificaciones de rechazo de bajo costo (parsing, compilación, testbench), verificaciones de síntesis/implementación, y una decisión de mantener o revertir basada en evidencia medida (p. ej., Worst Negative Slack, utilización de recursos, potencia, tiempo de ejecución).

Contribuciones Clave

El artículo describe tres contribuciones primarias:

Contrato Estructurado como un Artefacto de Ejecución: Los requisitos se codifican como campos explícitos (interfaz, restricciones, validación, optimización, reversión) para alinear la generación con un objeto de ingeniería compartido en lugar de texto de prompt repetido.
HTML Persistente y Bucle de Retroalimentación HIL: El contrato se renderiza en un HTML estructurado, y las salidas de las herramientas (HLS, Vivado, métricas de despliegue) se retroalimentan como estados de primer nivel del flujo de trabajo para dirigir las decisiones de implementación y reversión.
Coordinación de Agentes desde Benchmarks hasta Casos de Ingeniería: El flujo de trabajo demuestra que un enfoque alineado por contrato mejora los resultados en 94 tareas locales de HLS-Eval y traslada con éxito el bucle de diseño hacia un sistema de mensajes seguros de Criptografía Post-Cuántica (PQC) probado en placa.

Resultados

Evaluación HLS-Eval (Entorno de Diseño Pequeño)

Evaluado en 94 tareas de HLS-Eval ejecutables localmente utilizando una cadena de herramientas Vitis HLS:

Línea Base vs. Contrato: La introducción del contrato estructurado por sí sola mejoró la tasa de paso estimada del testbench de muestra única (pass@1) del 64.0% (Prompt directo) al 70.2%.
Flujo de Trabajo Completo: El flujo completo de ContractHIL-HLS logró un 70.4% de pass@1 y un 76.6% de pass@5.
Eficiencia de Tokens: La configuración de "Contrato" utilizó menos tokens (3555) que la configuración "Directa" (3741) al reemplazar instrucciones repetidas laxamente por campos con nombre, lo que sugiere una mayor fiabilidad sin simplemente aumentar la longitud del prompt.
Análisis de Categorías: Se observaron mejoras en la mayoría de las familias de benchmarks (p. ej., chstone, polybench, rosetta), aunque el grupo machsuite se mantuvo en una tasa de paso del 0.0%, lo que indica que el flujo de trabajo mejora la fiabilidad para implementaciones plausibles pero no puede compensar las carencias algorítmicas.

Caso de Estudio PQC (Despliegue a Nivel de Placa)

Validado en un acelerador de mensajes seguros de Criptografía Post-Cuántica (ML-KEM/ML-DSA):

Rendimiento: El flujo de trabajo logró la transición de un diseño monolítico de bitstream único a una organización de dual-bitstream (dividiendo la lógica KEM y DSA/XOR). Esto redujo el tiempo de ejecución de texto promedio de 207.3 ms a 52.4 ms.
Eficiencia: El Producto Energía-Retraso (EDP) conservador mejoró de 171.3 mJ·s a 23.6 mJ·s.
Tiempo y Recursos: El diseño dividido resolvió las violaciones de tiempo (el WNS mejoró de 1.570 ns en la imagen monolítica a 0.769 ns y 0.171 ns en las imágenes divididas) y redistribuyó la presión de memoria, logrando ambas imágenes un slack de tiempo de ruta positivo.
Validación: El flujo de trabajo preservó las reglas de frontera del receptor y la verificación del mensaje desencriptado, asegurando que la propiedad del estado fuera visible y correcta.

Significancia y Reivindicaciones

El artículo afirma que ContractHIL-HLS aborda la brecha entre la generación de código aislada y la ejecución de un flujo de trabajo trazable. Su significancia radica en:

Alineación de Estado: Demostrar que convertir los requisitos de lenguaje natural implícitos en estructuras estables e inspeccionables (contratos/HTML) mejora significativamente la fiabilidad de la generación de código de hardware antes de que haya retroalimentación de la placa disponible.
Cierre a Nivel de Sistema: Probar que el mismo flujo de trabajo alineado por contrato puede escalar desde kernels de nivel de benchmark hacia sistemas complejos probados en placa que involucran partición de bitstreams, orquestación de host y límites de seguridad.
Revisión Basada en Evidencia: Establecer un mecanismo donde la salida de la herramienta (QoR, tiempo, potencia) se convierte en un artefacto de primer nivel que impulsa las decisiones de reversión, evitando la propagación silenciosa de diseños que fallan en puertas específicas (p. ej., restricciones de tiempo o recursos).

Los autores mantienen una postura modesta, señalando que el flujo de trabajo es un mecanismo de alineación de estado que mejora la fiabilidad cuando el modelo está cerca de una implementación plausible, en lugar de ser una solución universal para todas las brechas algorítmicas. El caso PQC sirve como una prueba de estrés de despliegue para la completitud del sistema más que como una reivindicación de superioridad de latencia a nivel primitivo.