RTL en la era del vibe coding: 5 puertas de verificación que los ingenieros deben mantener

«¿Se puede escribir RTL con IA?», «¿Podemos confiar en un testbench creado por un LLM?» Son preguntas que últimamente escucho a menudo de ingenieros de diseño y verificación, así como de candidatos que buscan empleo. Sin citar a ninguna persona ni proyecto concreto, generalizo solo inquietudes anónimas recurrentes y respondo desde la perspectiva de un profesional del sector.

Respuesta en una línea: Es posible crear un primer borrador de RTL con IA. Sin embargo, un responsable humano debe aprobar las cinco puertas de verificación: especificación → lint → simulación·coverage → formal·CDC → síntesis·STA·PPA.

Ya hemos dejado atrás la fase en la que la IA solo ayudaba a escribir unas líneas de Verilog. Cadence explica que ChipStack AI Super Agent conecta agentes especializados en generación de RTL, generación de testbenches, orquestación de regresiones y depuración. En abril de 2026 anunció mejoras de productividad de hasta 10 veces en trabajos iniciales con clientes. Esta cifra procede del proveedor, no de un benchmark independiente, por lo que no debe generalizarse sin más. Aun así, está claro que la interfaz de EDA está pasando de un modelo centrado en GUI y Tcl a «agentes que reciben un objetivo y realimentan los resultados de las herramientas».

La tendencia general sobre qué fase de la industria cambiará primero con la EDA basada en IA se analizó en La pila de productividad de AI EDA: la verificación y el closure cambiarán antes que el RTL. Este artículo se centra en las puertas de aprobación que pueden aplicarse a proyectos y portfolios reales.

El problema surge al aplicar al RTL el criterio del vibe coding de software: «si compila y la demo funciona, basta». El RTL no es código que termine cuando la funcionalidad es correcta. Es una especificación de implementación que debe satisfacer simultáneamente los requisitos de clock, reset, protocol, CDC, power intent, capacidad de síntesis, PPA y constraints de signoff.

Puerta 1: ¿se ha convertido el lenguaje natural en una especificación ejecutable?

«Crea un slave AXI» no es una especificación. Como mínimo, deben definirse los siguientes puntos.

• protocol y subset compatibles
• anchura de datos y direcciones
• número de outstanding transactions
• objetivos de latency y throughput
• tipo y polarity del reset
• gestión de accesos inválidos
• condiciones de backpressure
• dominios de clock y de power

No permita que la IA rellene arbitrariamente los vacíos. Los puntos sin definir deben devolverse como preguntas. Estudios recientes sobre RTL generado por LLM también muestran que una parte considerable de los errores no procede solo de la capacidad de razonamiento del modelo, sino de descripciones ambiguas y malentendidos sobre conceptos de circuitos.

Condición de aprobación: la lista de requisitos, la tabla de I/O, las transiciones de estado, los ejemplos de timing y el comportamiento ante errores están documentados, y cada elemento tiene un ID de trazabilidad.

Puerta 2: ¿se ha evaluado la calidad del RTL y no solo la sintaxis?

Compilar correctamente es el umbral más bajo. Deben comprobarse de forma estática la inferencia de latches, el truncamiento de anchura, el signedness, las asignaciones incompletas, los bucles combinacionales, la omisión del reset y la posibilidad de discrepancias entre simulación y síntesis.

Aunque un agente de IA lea los resultados de lint y aplique correcciones automáticas, no debe poder suprimir warnings indiscriminadamente. Cada waiver necesita una justificación, un responsable, un ámbito de aplicación y condiciones de expiración.

Condición de aprobación: compile/elaboration correctos, cumplimiento de los umbrales de severidad de lint y justificación documentada para cada waiver.

Puerta 3: ¿hay self-checking simulation y coverage?

Si la IA crea conjuntamente el RTL y el testbench, puede replicar el mismo malentendido en ambos archivos. El reference model, las assertions y el testbench deben crearse, en la medida de lo posible, como representaciones independientes.

El conjunto mínimo de pruebas debe incluir lo siguiente.

• reset y liberación del reset
• single transactions normales y transacciones consecutivas
• backpressure y latencia máxima
• valores límite e inputs ilegales
• combinaciones posibles del protocol ordering
• long random regression

Es la misma razón por la que los estudios de la familia VerilogEval evalúan el RTL generado por LLM mediante testbenches y trabajos recientes mejoran el rendimiento incorporando un simulation-error localization-correction loop. Un ciclo de feedback basado en herramientas es más importante que la generación one-shot.

Condición de aprobación: cada ID de requisito está vinculado a un test o una assertion, la regresión es reproducible y se explican los puntos no alcanzados de functional coverage.

Puerta 4: ¿se han superado verificaciones independientes de formal·CDC·equivalence?

La simulación solo observa las rutas ejecutadas. Las formal properties son potentes en bloques donde importa el espacio de estados, como control logic, arbitration y protocol safety properties. Si hay varios clocks o un reset asíncrono, el análisis CDC/RDC debe constituir una puerta independiente.

Si la IA ha optimizado RTL existente o creado un ECO, la equivalence es especialmente importante. Cadence describe las herramientas de equivalence de la familia Conformal como auditores independientes que comprueban si el resultado creado por las herramientas de implementación es lógicamente idéntico. La palabra clave aquí no es IA, sino independencia. El generador y el evaluador no deben quedar ligados al mismo razonamiento.

Condición de aprobación: se conservan la prueba de las assertions o un bound explícito, la resolución de las violations de CDC/RDC y los resultados de equivalence antes y después del cambio.

Puerta 5: ¿se cumplen las condiciones de síntesis·STA·PPA·implementación física?

Incluso un RTL funcionalmente correcto puede fallar después de la síntesis. Los ejemplos más comunes son un combinational path largo, una priority chain excesiva, clock gating incorrecto, fanout elevado y fallos de memory inference.

No proporcione a la IA un objetivo de PPA como una sola cifra. Reducir únicamente el area puede perjudicar el timing o la testability. Tras fijar los constraints, la library, el corner y la versión de la herramienta, deben compararse conjuntamente los siguientes elementos.

• worst/total negative slack
• area y cell count
• estimación de dynamic/leakage power
• congestion y physical feasibility
• impacto sobre las reglas de DFT y low-power

Condición de aprobación: se mantienen la equivalence funcional con el RTL de referencia y los rangos acordados de timing·area·power·physical feasibility.

Qué puede delegarse a la IA y qué debe aprobar una persona

Capacidades del ingeniero que ganan valor en la era de la IA

La proporción del trabajo dedicada a escribir código puede disminuir. En cambio, aumentará el valor de cuatro capacidades.

1. convertir requisitos ambiguos en contratos ejecutables
2. encontrar la causa real en los logs de las herramientas y los waveforms
3. diseñar la independencia entre el generador y el verificador
4. explicar los trade-offs entre funcionalidad, rendimiento, potencia e implementación física

Preguntas frecuentes

P. ¿Puedo incluir en mi portfolio RTL creado con ChatGPT o Claude?

Sí. Pero muestre evidencias de verificación, no solo el prompt. Debe incluir la especificación, el test plan, las assertions, el coverage, los resultados de síntesis y un registro de cómo detectó y corrigió los errores creados por la IA.

P. Si la IA crea también el testbench, ¿no ha terminado la verificación?

No. El RTL y el testbench pueden compartir la misma interpretación errónea. Se necesitan otros oracles, como un reference model independiente, protocol assertions, formal o VIP comercial.

P. Entonces, ¿disminuirán los puestos de trabajo para ingenieros de RTL?

Puede reducirse el peso de la programación repetitiva y la clasificación de logs. En cambio, aumentará la importancia de quienes asumen la responsabilidad de spec, architecture, verification closure y physical trade-offs. Es más probable que se desplace el centro de responsabilidad a que desaparezca el rol.

P. ¿Puedo introducir código de la empresa en una IA externa?

No lo haga sin una política corporativa y una aprobación de seguridad. El RTL, los constraints, los logs y los waveforms pueden contener la estructura y vulnerabilidades del producto. Primero deben existir un entorno enterprise aprobado y límites de datos definidos.

Conclusión

«¿Se puede confiar en el RTL creado por IA?» no es la pregunta correcta. Una pregunta mejor es esta.

Independientemente de quién lo haya creado, ¿se le ha obligado a superar las mismas cinco puertas de verificación?

El vibe coding acelera la creación de borradores. El silicio sigue requiriendo evidencias verificables.

Fuentes públicas

• Cadence ChipStack AI Super Agent
• Anuncio de Cadence–NVIDIA sobre agentic AI
• Cadence Conformal AI Studio
• Artículo OpenLLM-RTL
• Understanding and Mitigating Errors of LLM-Generated RTL Code
• Repositorio NVIDIA VerilogEval

Principio editorial: este artículo generaliza inquietudes anónimas escuchadas de forma recurrente. No se utilizó información privada que pudiera identificar a personas o proyectos concretos, y las cifras de rendimiento de proveedores se distinguieron como afirmaciones de esos proveedores.