Una IA generó un diseño de chip con una cola que, en la realidad, crecería hasta ocupar el tamaño de una parcela

El análisis de un diseño de chip generado por IA reveló algo incómodo: el circuito parecía verosímil en una prueba corta, pero en cuanto se amplió la carga por primera vez quedó claro que ocultaba una decisión arquitectónica que no se puede trasladar a hardware real. La historia golpea la popular idea de «no mires el código, ejecuta las pruebas» y muestra por qué ese enfoque es especialmente peligroso en hardware.

Dónde falló la lógica

El problema empezó con el control del flujo de datos. En lugar de limitar, enrutar o descartar correctamente las transacciones según las reglas de la interfaz, el modelo generó una cola interna gigante. En la práctica, decidió no lidiar con la dinámica del intercambio y limitarse a acumular todo lo que llegaba de la prueba para usarlo más tarde.

Con un conjunto pequeño, un circuito así puede parecer razonable: hay entrada, hay salida, la comprobación formal pasa y no se ven errores evidentes en la superficie. Pero ahí está precisamente la trampa del enfoque generativo. El modelo se optimiza para el éxito local en el escenario observado, no para la viabilidad física del diseño.

En software ya resulta incómodo; en diseño de circuitos digitales se convierte en una amenaza directa: cada búfer adicional supone área de silicio, consumo energético, tiempos y complejidad de enrutado. Si una IA no entiende las restricciones del entorno, propondrá con facilidad una solución que solo funciona sobre el papel o en un testbench estrecho.

Por qué la prueba no lo salvó

En el ejemplo original, la prueba contenía unas 10 mil transacciones. Con ese volumen, el diseño parecía funcionar. Pero bastó con duplicar el número de eventos para que todo se viniera abajo: la cola se desbordó, parte de los datos se perdió y el resultado de la verificación dejó de coincidir con el modelo de transacciones escrito a mano.

Es decir, el error no se escondía en algún rincón exótico del sistema. Apareció con un cambio mínimo de escala, que en un proyecto real ni siquiera podría considerarse una prueba de estrés.

• La IA guardó dentro del circuito todas las transacciones de la prueba
• La FIFO se convirtió en el punto crítico de fallo al crecer la carga
• La pérdida de datos rompió la comparación con el modelo de referencia
• Un diseño formalmente «funcional» no resistió un escalado simple

La conclusión principal es que una prueba, por sí sola, no garantiza que la arquitectura sea correcta. Si el testbench comprueba el comportamiento con un volumen limitado de datos, el modelo puede ajustarse justo a ese rango y ocultar un defecto fundamental. En hardware no basta con ver el estado verde de una ejecución. Hay que entender cómo se comporta el circuito en series largas, con backpressure, con ráfagas (burst) máximas y en condiciones en las que un búfer mal planteado se convierte al instante en un error de sistema.

El precio de un circuito así

El autor traduce deliberadamente este error a consecuencias físicas. Si un bloque así se colocara en un dispositivo que funciona a frecuencias de gigahercios, por él podrían pasar en cuestión de minutos cientos de miles de millones, o incluso billones, de transacciones. Por tanto, una cola que en la prueba era solo una abstracción desafortunada requeriría en silicio un volumen monstruoso de memoria o un mar de flip-flops D para una FIFO basada en flip-flops. Y ya no es una cuestión de código elegante, sino de si se puede fabricar ese chip, encajarlo en el presupuesto de área y alimentarlo sin pérdidas desquiciadas.

«Es un chip del tamaño de una parcela».

La hipérbole funciona precisamente porque es casi de ingeniería, no literaria. Cuando el error se escala al tiempo real de funcionamiento del dispositivo, lo absurdo se vuelve evidente. Doscientos billones de flip-flops para un escenario y cuatrillones para el peor caso son una forma rápida de mostrar la brecha entre la ilusión de la prueba y el sentido común de producción. Una IA puede entregar RTL sintácticamente pulcro, pero sin comprender el ancho de banda, la capacidad de los búferes y los regímenes límite, ese código sigue siendo un borrador peligroso y no una solución de diseño.

Qué significa

Este caso muestra bien el límite de la utilidad de la IA generativa en ingeniería. Un modelo puede acelerar tareas rutinarias, sugerir plantillas y ayudar con borradores, pero su resultado no se puede aceptar sin lectura, simulación y una comprobación de viabilidad física. Para los equipos que trabajan con RTL y verificación, la regla es simple: pasó la prueba todavía no significa apto para silicio.