AMD confiesa que las primeras CPU EPYC no podían arrancar cuando llegaron al laboratorio

De forma sorpresiva, AMD se ha subido de alguna manera a la carrera y moda de los podcast y entrevistas. El gigante rojo ha comenzado a publicar una serie de vídeos a modo de episodios con los principales protagonistas de sus diseños y hardware, donde el primero de ellos denominado Advanced Insights Ep.1, tiene de protagonistas a dos viejos conocidos como son Mark Papermaster y Forrest Norrod, los cuales han tocado temas complejos, destacando los problemas con las primeras CPU EPYC y cómo no podían arrancar, algo que AMD tardó poco en corregir.

La entrevista es un poco a dos bandas, algo poco inusual, porque ambos ingenieros son parte de la empresa, pero Papermaster coge la batuta de entrevistador frente a Norrod, el cual, comenta cómo llegó a AMD, lo que le costó comprender dónde estaban, la filosofía de lo que habían realizado y lo nuevo que tenían por lanzar al mercado de la mano de Jim Keller.

AMD reconoce un error de diseño en las primeras CPU EPYC: no podían arrancar

No fue sencillo competir con Intel. Los azules venían de una cuota de mercado mundial del 98%, es decir, eran prácticamente dominadores de todo el segmento. Por ello, AMD tuvo que fichar paulatinamente a las personas correctas para poder hacer despegar a EPYC.

Lo más interesante de este comienzo de la historia según Norrod, es que cuando él pasó de Dell hacia AMD, Keller y Papermaster ya tenían prácticamente finalizado el diseño central de Zen para EPYC, así que simplemente había que especificar el núcleo en concreto, con sus respectivas interfaces para poder crear las CPU. Norrod aportó la visión desde el segmento de los centros de datos, y de ahí se confeccionó Naples.

Pero no fue sencillo. Papermaster confiesa ahora que AMD tuvo un error de diseño, es decir, Zen para EPYC tuvo fallos de diseño en la CPU en su concepción que ni Keller supo ver, pero, ¿cómo de graves eran y cuánto tardaron en corregirlos?

Tres grupos de ingenieros para dar con la solución

Papermaster afirma que cuando se encontraron el problema, cuando vieron que la primera CPU EPYC no podía arrancar en el laboratorio de prueba, reunió a tres grupos de ingenieros: CPU, IP y el de plataforma del sistema.

Tras esto, Norrod comenta que, efectivamente, todos se reunieron para valorar el problema. Lo malo es que no confirman cuál fue el problema en concreto, pero sí que dicen que tuvieron que pasar por una especie de "disco de arranque". Además, también confirman que algo similar pasó con la siguiente generación, Rome, por lo que Norrod pasó de una regla de 24 horas a una de 72 horas.

Estas reglas no son más que una manera de quitar "hierro al asunto", es decir, no darle demasiada gravedad hasta que no pasen 24 horas, algo que hacía ya en Dell. Pero en AMD, debido a la complejidad de los diseños, pasó a 72 horas antes de entrar en un modo más alarmante.

Y es que Norrod afirma que errores que parecen imposibles de resolver al principio, solo unos días más tarde los ingenieros encuentran la manera de solucionarlo, normalmente, en esas 72 horas, la mayor parte de las veces sin consecuencias, mientras que otras veces pueden simplemente sortearlo.

Esto solo demuestra la complejidad que tiene actualmente un diseño de CPU, más si cabe para HPC o IA, donde hasta que el procesador no está funcionando en un entorno de pruebas no saben a ciencia cierta si han acertado con la arquitectura y en solucionar problemas que pueden arrastrar de anteriores.