NVIDIA Research presentó HORIZON, un marco de agente manos libres para el diseño de hardware. Trata el diseño de hardware como una evolución del código a nivel de repositorio. Este equipo de investigación ejercita la instanciación del nivel de transferencia de registro (RTL). Un arnés Markdown estructurado se convierte en un paquete de proyecto. Luego, un bucle de agente autónomo desarrolla un árbol de trabajo git aislado. Confirma una versión solo cuando pasa una puerta de aceptación ejecutable.
El equipo de investigación informa que se completó el 100 % en cada conjunto de pruebas comparativas de RTL evaluado. También afirma claramente que el diseño de hardware agente no está resuelto.
¿Qué es HORIZONTE?
La generación de código de un solo giro tiene un límite claro en las tareas de diseño ejecutables. Verilog plausible no es suficiente para hardware real. La corrección depende del comportamiento a nivel de ciclo, las convenciones de reinicio, los anchos de bits y la retroalimentación del simulador.
HORIZON aloja cada problema de diseño como un repositorio controlado por versiones, no como un mensaje de una sola vez. La única entrada requerida es un arnés Markdown estructurado. Ese arnés tiene cuatro componentes: una meta, direcciones de conocimiento del dominio, una especificación del evaluador y un predicado de aceptación.
Un agente de arranque compila el arnés en un paquete de proyecto. El equipo de investigación escribe esto como p = (πagente, Ep, Ap, Γp, Ωp). Esos términos cubren la política del agente, el evaluador ejecutable y el predicado de aceptación. También cubren la política de control de versiones y las habilidades de dominio.
Para RTL, el evaluador Ep puede incluir compilación, simulación, extracción de cobertura y comprobaciones de afirmación o banco de pruebas. En otros dominios, ese mismo espacio podría contener pruebas unitarias, demostradores de teoremas, perfiladores o herramientas de síntesis. Por lo tanto, los problemas se definen sobre árboles de trabajo de git, no sobre un tipo de repositorio fijo.
Cómo funciona el bucle a nivel de repositorio
Después del arranque, el bucle se ejecuta sin más intervención humana. Cada ciclo planifica un objetivo, edita el árbol de trabajo, invoca herramientas y ejecuta el evaluador. El predicado de aceptación decide entonces una cosa: confirmar la nueva versión o registrar el error.
Git es el sustrato aquí, no la contabilidad incidental. Las diferencias exponen los cambios de estado propuestos. Las confirmaciones definen los puntos de control aceptados. Las notas adjuntan evidencia del evaluador. El tronco recupera la trayectoria completa.
El bucle se basa en comandos nativos de git para mantener el seguimiento económico. Las ediciones preparadas se inspeccionan con git diff –cached. Cada intento aceptado se convierte en un compromiso de git cuyas notas llevan el veredicto y la recompensa. Los compromisos exitosos se convierten en ejemplos de reparación positivos. Los intentos rechazados se registran como ejemplos negativos. El historial del repositorio es el búfer de experiencia, no un almacén de datos separado.
El equipo de investigación tomó prestado vocabulario del proceso de decisión semi-Markov para un propósito concreto. Nombra los objetos grabados, nada más. Un ‘estado’ es una instantánea versionada del repositorio. Una “opción” es un episodio entre dos puntos de control. HORIZON no capacita ni actualiza una política de RL en este trabajo. La columna vertebral del agente permanece fija durante toda la campaña.
La reutilización de sesiones mantiene los costos bajos. HORIZON mantiene una sesión de modelo persistente a través de iteraciones. El arnés, el paquete de proyectos y las fuentes estables se proporcionan desde la caché de avisos del proveedor. Los tokens recién facturados están entonces dominados por la diferencia actual y el último resultado del evaluador.
Dónde se encuentra HORIZON entre los sistemas que evolucionan a sí mismos
HORIZON extiende un linaje de autoevolución a escala de repositorio. Los sistemas anteriores evolucionaron el software que ejecutan los ingenieros. En cambio, HORIZON evoluciona los artefactos de hardware que crean los ingenieros.
Los cuatro comparten un principio. Un cambio de candidato se admite sólo cuando evidencia ejecutable lo respalda.
Resultados de referencia
La columna vertebral es GPT-5.3, fija para todos los experimentos. Cada resultado utiliza el modo manos libres de un solo agente. Las campañas se ejecutaron en un host AMD EPYC 9334 de 32 núcleos con 512 GB de RAM.
La evaluación abarca ChipBench, RTLLM-2.0 y Verilog-Eval. Agrega nueve categorías de generación de verificación y código CVDP, CID 002 a 016. CVDP contiene 783 problemas creados por humanos en 13 categorías de tareas (Pinckney et al., 2025).
Una iteración es un paso externo automatizado. El agente edita el árbol de trabajo, ejecuta el evaluador y luego confirma una aprobación o registra un rechazo. HORIZON alcanza una tasa de aprobación del 100% en todas las suites. El único error residual es un defecto en el arnés de especificación de ChipBench, no una falla del agente.
La tasa agregada de aprobación de la primera iteración es del 47,8%. Iteración-0 no es una medición Pass@1 independiente. Es el estado del repositorio después de la primera iteración del agente. El agente puede posponer la depuración y reparación a iteraciones posteriores por diseño.
La dificultad de convergencia varía ampliamente entre categorías. RTLLM-2.0 y Verilog-Eval alcanzan el 100 % en dos iteraciones. La generación de verificadores (CID 013) comienza en sólo el 3,8%. Sin embargo, aumenta constantemente hasta el 100% en la iteración 19, casi sin estabilizarse. La finalización del código (CID 002) necesita 82 iteraciones. Su larga cola es el mayor coste simbólico.