El verificador formal dijo «demostrado». El chip seguía roto.

La primera vez que una de nuestras propias herramientas me mintió, lo hizo con cortesía. El motor formal devolvió una marca de verificación verde. Todas las propiedades que le habíamos pedido demostrar volvieron como demostradas. La biblioteca de aserciones parecía completa. Sobre el papel, el diseño estaba verificado.

Nos tomó dos días darnos cuenta de que el certificado no valía nada — y de que todo lo que yo había supuesto sobre la verificación de IA de semiconductores nos estaba protegiendo del fallo equivocado.

Las propiedades habían sido generadas por un modelo de lenguaje grande que habíamos envuelto alrededor del motor formal — exactamente el tipo de demo llamativa y agéntica de diseño de chips que todo el mundo estaba construyendo. Y el motor las había demostrado en milisegundos, lo que debería haber sido la señal reveladora. Estaban demostradas porque las condiciones que las pondrían a prueba nunca se activaban. Una propiedad que dice «toda solicitud acaba recibiendo una concesión» es trivialmente cierta si la solicitud nunca puede ocurrir. El solucionador no se equivocaba. Respondió la pregunta que hicimos sin querer, y la pregunta estaba vacía. Ese es el momento en que comprendí contra qué tienen que defenderse realmente estas canalizaciones de verificación por IA — y por qué casi nadie que vendía una se estaba defendiendo de lo correcto.

Quiero contarte lo que encontramos, porque las clases de errores que matan los chips modernos no son las que la industria anuncia que puede atrapar. Construimos canalizaciones de verificación a medida para equipos de chips fabless — modelos de pesos abiertos afinados envueltos alrededor del motor formal que un equipo ya posee, ejecutándose por completo en su propio hardware — y todo el enfoque surgió de equivocarnos primero en esto. Puedes ver la forma que tiene en veriprajna.com/solutions/semiconductor-ai-verification. Pero el enfoque solo cobra sentido una vez que has visto fallar un diseño «aprobado».

Una cifra que debería aterrar a todo director financiero fabless

Una sola estadística enmarca todo el problema. El estudio de Verificación Funcional de 2024 del Wilson Research Group / Siemens EDA — el punto de referencia de mayor recorrido en la industria — situó el éxito de primer silicio en el 14 %. El nivel más bajo en veinte años de seguimiento. En 2020 esa cifra rondaba el 32 %. Se ha reducido a menos de la mitad en cuatro años.

Esto no es una historia sobre ingenieros que se volvieron perezosos. Es una historia sobre la complejidad superando a las herramientas, y sobre una especificación que muta más rápido que el banco de pruebas que la persigue. El mismo estudio halló que aproximadamente el 70 % de los respins son causados por errores ligados a cambios de especificación — no por errores puros de lógica.

El éxito de primer silicio no cayó porque los equipos de chips empeoraran. Cayó porque la especificación ahora se mueve más rápido de lo que la verificación puede cerrarla.

Estuve dándole vueltas a esa cifra del 70 % durante mucho tiempo, porque acusa en silencio a muchos discursos de «IA para el diseño de chips». Si la mayoría de los respins provienen de la deriva de la especificación, entonces una herramienta que solo atrapa errores de lógica está abordando una porción del problema y llamándola el pastel entero.

Y el coste de equivocarse es brutal de una forma que la gente del software subestima. Un juego de máscaras de 5 nm cuesta 10–20 M$. A 3 nm te acercas a los 40 M$, con más de setenta capas de máscara, incluidas más de veinte capas EUV. Un tape-out completo de 2 nm cuesta ahora del orden de 725 M$ en total. Cuando algo se cuela, un respin es un deslizamiento de calendario de 3 a 6 meses encima de la factura de las máscaras. En una ventana de producto de dieciocho meses, un desliz de seis meses puede borrar la mitad de los ingresos de por vida de un chip. El director financiero no ve la verificación como un centro de costes. La ve como un seguro contra un único error de ocho cifras.

¿Cómo alucina realmente un LLM en el hardware?

Tu equipo ya está usando LLM sobre Verilog. No voy a fingir lo contrario, y tampoco debería hacerlo nadie que te venda algo. El campo de investigación es real ahora — los artículos sobre LLM que escriben Verilog pasaron de uno en 2020 a sesenta y cuatro en 2025. En los problemas más difíciles del benchmark VerilogEval, los modelos de la clase GPT-4 rondan el 43 % de corrección funcional. Útil. No digno de confianza.

La pregunta interesante no es si los modelos ayudan. Es cómo fallan, porque los modos de fallo no se parecen a los fallos que los ingenieros de software están entrenados para temer. Después de suficientes noches en vela mirando por qué un RTL «de aspecto correcto» salió mal, empecé a clasificar los fallos en cinco clases.

El primero es el inofensivo. Sintáctica: alucinación — código que sencillamente no compila. Verilator o el front-end de síntesis lo atrapa en segundos. Todo el mundo ya sabe cómo manejar esto, y es la clase que la gente señala cuando quiere afirmar que el problema está resuelto.

El segundo es donde empieza a doler. Semántica: alucinación, y el caso de manual es la asignación bloqueante frente a la no bloqueante. Un modelo entrenado en Python y C lee Verilog como si las sentencias se ejecutaran de arriba abajo. Así que escribe una asignación bloqueante — un simple = — dentro de un bloque always_ff sincronizado por reloj donde el lenguaje exige la no bloqueante <=. El diseñador quería una canalización de dos ciclos. Con asignaciones bloqueantes, la segunda etapa lee el valor nuevo del primero, no el antiguo, y el silicio entrega un bypass de un ciclo en su lugar. Algunos simuladores planifican los eventos en un orden que oculta la carrera por completo. Simula bien. Se sintetiza en la máquina equivocada.

La tercera clase es la que me enseñó a mantener la especificación AMBA abierta en un segundo monitor. De protocolo: alucinación. El código compila, pasa el noventa por ciento de las pruebas dirigidas, y luego afirma una señal de dato-de-escritura-válido antes de que el esclavo esté listo para aceptar la dirección — una violación del handshake AXI. O mantiene una señal válida en alto mientras cambia el dato por debajo. O activa una subcláusula enterrada en la página 84 de la especificación del bus que ningún humano ha memorizado. El chip funciona a la perfección en tu banco de pruebas interno y se cuelga en el instante en que se conecta a un controlador de memoria de terceros. No puedes resolver esto por fuerza bruta con más ciclos de simulación. Lo atrapas con bibliotecas de aserciones preverificadas escritas contra cada protocolo.

La cuarta clase es la que nos engañó, y es la peligrosa.

¿Por qué «demostrado» es la palabra más peligrosa en un informe de verificación?

De vacuidad: alucinación. El modelo genera una aserción SystemVerilog. El motor formal la demuestra. Tú la entregas. Y la propiedad era trivialmente cierta porque su antecedente — la parte del «si» — nunca llegó a ser cierto en primer lugar.

Imagina una propiedad de árbitro: si se eleva una solicitud, debe seguir una concesión dentro de cierto número de ciclos. Ahora supón que el mismo modelo, intentando ser útil, también escribió una suposición que fuerza la señal de solicitud a estar en bajo. El motor formal demuestra diligentemente la propiedad de concesión en milisegundos, porque no hay ninguna solicitud que la viole jamás. El árbitro real subyacente podría estar completamente roto. El certificado dice «demostrado». No vale nada.

Una prueba formal que se ejecuta en milisegundos no es rápida. Es sospechosa. Puede que el motor no haya demostrado nada en absoluto.

Esto no es un riesgo marginal. Siemens lleva publicando advertencias sobre pruebas vacuas desde 2017, y el campo sigue entregando flujos sin comprobación automática de vacuidad. Cuando le digo a la gente que un flujo de verificación formal sin detección de vacuidad es peor que no tener verificación formal, creen que estoy siendo dramático. No lo estoy. Ninguna verificación te deja apropiadamente asustado. Un «demostrado» vacuo te deja confiado y equivocado, con un bloque aprobado camino del tape-out. Ese es el fallo que casi se coló en nuestro propio prototipo temprano, y cambió de forma permanente lo que construimos.

La quinta clase es la que la simulación estructuralmente no puede ver. Cruce de dominios de reloj: puntos ciegos. Un LLM lee nombres de señales; no percibe dominios de reloj. Así que conecta una señal de un dominio de CPU de 2 GHz directamente a un flop de un dominio periférico de 400 MHz, saltándose el sincronizador de doble flop que previene la metaestabilidad. La simulación RTL no modela la metaestabilidad — así que la regresión pasa, cada vez, y el silicio se bloquea en el campo. Por esto los errores de CDC devoran juegos de máscaras. También es por lo que Accellera abrió un estándar de interoperabilidad CDC/RDC en 2024: la fragmentación entre las herramientas comerciales de CDC se había vuelto lo bastante mala como para romper la aprobación final.

Las clases de la dos a la cinco comparten una propiedad aterradora: pasan la simulación. Solo salen a la superficie en el silicio. Ese es el subconjunto de errores que aún revienta los tape-outs, y es precisamente el subconjunto que un discurso de «atrapa errores de lógica» deja sobre la mesa.

El muro de proveedores frente al que un equipo de chips está realmente parado

Cuando me puse a buscar ayuda genuinamente independiente para un tape-out, encontré menos opciones de las que habría tenido unos años antes — y eso no es nostalgia, es la estructura del mercado. Los tres proveedores de EDA entre los que un responsable de verificación de diseño puede realmente elegir — Synopsys, Cadence, Siemens — han pasado de menos del 75 % del mercado hace una década a más del 85 % hoy. Suma la adquisición de Ansys por 35 000 M$ de Synopsys y los cuatro primeros controlan aproximadamente el 90 %. El terreno en el que compra una startup fabless se ha estrechado, no ampliado, justo cuando el problema se ha vuelto más difícil.

Y los actores establecidos no se quedan quietos con la IA. Synopsys lanzó AgentEngineer en marzo de 2026, un flujo de verificación agéntico que afirma de dos a cinco veces más productividad, y se apoya sobre VC Formal — la pila agéntica de proveedor más creíble que he evaluado. Cadence anunció su ChipStack AI Super Agent en febrero de 2026 y ejecuta Cerebrus AI Studio para implementación impulsada por aprendizaje por refuerzo, con JasperGold manteniéndose como el motor formal de referencia con el que se mide a todos los demás. Lo digo sin rodeos: JasperGold y VC Formal son genuinamente excelentes. Cualquiera que abra un discurso despotricando contra ellos te ha dicho que nunca ha cerrado un tape-out real.

El truco está en el precio y la postura. La línea base histórica de JasperGold rondaba los 225 000 $ más 45 000 $ por puesto — bien para una gran empresa fabless, fuera del alcance de las startups de RISC-V y de aceleradores de IA en fase temprana que hacen el trabajo más interesante. Y las funciones de IA más nuevas de los actores establecidos son cloud-first, lo que choca de frente con el único requisito en el que estos clientes no van a ceder. Más sobre eso en un momento.

Luego está la ola de startups, y es ruidosa. En el último DAC y DVCon, a un responsable de verificación con el que trabajo le habían presentado ocho empresas distintas de «IA agéntica para el diseño de chips» en un solo trimestre. ChipAgents ha recaudado 74 M$ a principios de 2026 y afirma diez veces más productividad de diseño y verificación. Normal Computing recaudó 50 M$ liderados por el Catalyst Fund de Samsung, construyendo autoformalización — LLM que traducen la intención del ingeniero directamente en propiedades formales y las demuestran — y dice que la mitad de las diez principales firmas de diseño de semiconductores del mundo la están usando. Hay más: MooresLabAI generando bancos de pruebas completos, Bronco en análisis de regresión, Silimate en predicción de potencia-rendimiento-área.

Algunas de estas son reales. Ninguna de ellas resuelve el problema real del cliente, que es que ahora ha comprado tres de estas herramientas puntuales y no tiene ni idea de cómo hacerlas funcionar juntas dentro del flujo de aprobación en el que ya confía.

La historia del emplazamiento por aprendizaje por refuerzo que nadie quiere decir en voz alta

Hay una tentación paralela en el diseño de chips más allá de la verificación: usar el aprendizaje por refuerzo para hacer la planificación física — decidir dónde se sitúan los grandes bloques en el troquel. Es seductor, y el resultado más citado está en disputa de una forma que la mayoría de los discursos convenientemente omite.

El artículo de Google en Nature de 2020 afirmaba que el RL supera al recocido simulado para el emplazamiento de macros, y se ha usado en silicio real — generaciones de TPU se entregaron con él. Pero en 2023, Nature añadió una nota editorial tras plantearse inquietudes metodológicas. Igor Markov, ahora en Synopsys, publicó una crítica línea por línea cuya comparación titular es difícil de olvidar: el enfoque de RL tardó 32,31 horas, una línea base de recocido simulado ajustada tardó 12,5 horas, y una herramienta comercial de Cadence terminó el mismo trabajo en 0,05 horas. DeepMind respondió con un artículo titulado «That Chip Has Sailed». Años después, ninguna replicación externa independiente ha confirmado las afirmaciones originales, y tanto la crítica como la refutación siguen vivas.

Saco esto a colación por lo que ocurre cuando un consultor propone emplazamiento por RL a un equipo formal de verdad y finge que la controversia no existe. Lo huelen en diez minutos, y has perdido la sala. La posición honesta es que hay nichos genuinos — planificación física con conciencia térmica de chiplets y 3D-IC, disposición analógica, optimización de IP RISC-V sobre herramientas abiertas — donde un enfoque híbrido se gana su sitio. Un asalto frontal a los motores de emplazamiento de los actores establecidos no. Conocer la diferencia, y decirla en voz alta, es todo el trabajo.

Qué cambió después de que nuestra herramienta nos engañara

Así que aquí es adonde nos llevó el desastre de la prueba vacua. Dejamos de intentar construir una IA mejor que escribiera Verilog, porque esa es una carrera abarrotada con ocho corredores financiados, y empezamos a construir lo que ninguno de ellos vende: la capa de integración neutral respecto al proveedor que hace que las herramientas existentes de un equipo sean dignas de confianza.

En concreto, eso significa unas cuantas decisiones, cada una forzada por un fallo que habíamos visto. Afinamos un modelo de pesos abiertos — Qwen Coder, Llama, el que encaje — sobre el corpus RTL propio del cliente, sus especificaciones, su historial de errores pasado, porque un modelo que no ha visto tu estilo particular alucina contra él. Lo envolvemos alrededor de cualquier motor formal que el equipo ya posea: JasperGold, VC Formal, Questa Formal, o SymbiYosys de código abierto. Nunca les pedimos que arranquen la herramienta de referencia en la que ya confían. Y cada propiedad que el modelo propone pasa por comprobaciones de vacuidad y cobertura antes de que se permita a nadie leer la palabra «demostrado» — porque aprendimos por las malas que una prueba sin protección es teatro.

Las bibliotecas de aserciones preverificadas importan tanto como el modelo. Para un núcleo RISC-V, el arnés formal viene con las comprobaciones de conformidad AXI4, AHB y TileLink, las aserciones de riesgos de canalización, el scoreboarding de carga-almacenamiento, las propiedades de corrección de la unidad de depuración — las cosas que atrapan la alucinación de protocolo y semántica antes de que lo haga el silicio. Esto no es especulativo. La consultoría formal Axiomise ha encontrado más de 65 errores en Ibex, el núcleo RISC-V abierto dentro de OpenTitan de Google, incluidos errores de instrucción de bifurcación en la unidad de depuración que solo lo formal podía atrapar. Lo formal funciona sobre RISC-V. Lo escaso no es el método; es un equipo que sabe cómo blandirlo.

La verdadera oportunidad aquí nunca fue un modelo de Verilog más inteligente. Fue un arnés honesto envuelto alrededor de las costosas herramientas en las que un equipo ya confía.

¿Por qué no lo ejecutas simplemente en la nube?

La gente me pregunta esto constantemente, y la respuesta es la misma razón por la que toda startup de IA-EDA cloud-first está muerta al llegar con los clientes que me importan: el RTL son las joyas de la corona, y no sale del edificio.

El código de nivel de transferencia de registros de una empresa fabless es la empresa. Los clientes de defensa y aeroespacial lo necesitan aislado del aire, a veces en una instalación segura. Los equipos fabless comerciales quieren on-prem, nube privada virtual como mínimo absoluto. Así que lo ejecutamos todo en el propio hardware del cliente — inferencia con vLLM o similar en su clúster H100 o H200 existente, recuperación local sobre su propio corpus, sin que el RTL cruce jamás el límite de la red. Las funciones agénticas más nuevas de los actores establecidos son cloud-first; eso es una ventaja para ellos y un factor eliminatorio para un equipo de chips sensible a la propiedad intelectual. La mayor oportunidad que veo no es en absoluto un problema de algoritmos. Es un problema de despliegue e integración que la gente con los mejores algoritmos ha decidido no resolver.

La otra pregunta viene de los equipos de automoción, y es la que lo decide todo para ellos. Envía un chip a un coche en ASIL C o D — los niveles de integridad de seguridad donde la ISO 26262 deja de meramente sugerir la verificación formal y empieza a exigirla — y la herramienta misma tiene que llevar un paquete de cualificación TCL2 o TCL3. Los motores centrales de los actores establecidos tienen esa certificación de terceros; una herramienta de IA totalmente nueva no. He visto cómo una herramienta genuinamente mejor quedaba apartada en un programa de automoción exactamente por esta razón: sin paquete de cualificación, sin sitio en el flujo de aprobación, fin de la conversación. Así que no intentamos ser la herramienta cualificada. Ayudamos a los equipos a ejecutar asistencia de IA junto a los motores cualificados de los actores establecidos sin romper la cadena de cualificación — porque en automoción, una herramienta técnicamente superior que no puede sobrevivir a una auditoría no vale nada.

El certificado no es el chip

Sigo volviendo a esos dos días que pasamos confiando en una marca de verificación verde que no significaba nada. La lección no fue «los LLM son malos con Verilog». Mejoran cada trimestre. La lección fue que en el hardware, la brecha entre parece verificado y está verificado se mide en juegos de máscaras de ocho cifras y deslices de seis meses — y las herramientas que se precipitan hacia este espacio en su mayoría corren por hacer más rápida la parte del «parece verificado».

En un juego de máscaras de 10 M$, un «demostrado» que no puedes rastrear hasta una prueba no vacua, ejecutado en hardware que controlas, contra aserciones escritas por alguien que se ha leído la página 84 de la especificación — eso no es verificación. Es una esperanza con buenos valores de producción. Si quieres ver cómo distinguimos la diferencia, está todo expuesto en veriprajna.com/solutions/semiconductor-ai-verification.

Al chip no le importa lo que diga el informe. Solo hace lo que el silicio fue realmente construido para hacer. La verificación es la disciplina de hacer que esas dos cosas sean lo mismo — y en el momento en que una IA te dice que son lo mismo en milisegundos, ese es exactamente el momento en que deberías echar mano de la especificación.