El error de 475 millones de dólares de Intel: el problema de silicio detrás del bug FDIV del Pentium
(righto.com)- El Pentium lanzado en 1993 adoptó el método SRT para lograr una división de coma flotante más rápida que la del Intel 486, pero cuando en 1994 se reveló el error de la instrucción FDIV, Intel aceptó reemplazar todos los chips defectuosos y el costo fue de 475 millones de dólares
- El defecto estaba en la tabla de búsqueda implementada en la PLA para la división; Intel dijo que faltaban 5 entradas por un error de script, pero el análisis del die apunta a 16 omisiones y a que 5 de ellas provocaban errores reales
- La división SRT radix-4 genera 2 bits del cociente por etapa, por lo que es más rápida, pero tiene una estructura compleja que mapea el residuo parcial y el divisor a una tabla P-D de 2048 entradas y luego la comprime en una PLA de 112 filas
- La causa clave es que, por el carry-save adder, el índice de búsqueda puede quedar una celda por debajo del residuo parcial real, y Intel aplicó una corrección matemática equivocada en el límite superior de la región +2, dejando algunas celdas en 0
- El Pentium corregido no solo llenó las 5 entradas faltantes, sino que puso 2 en toda la región no utilizada de la tabla para simplificar los límites, y las filas usadas de la PLA bajaron de 120 a 74, por lo que quedó aproximadamente un tercio más pequeña que la PLA defectuosa
Cómo se reveló el bug FDIV y cuánto costó
- Intel lanzó el procesador Pentium de alto rendimiento en 1993 e incorporó un algoritmo de división de coma flotante más rápido que el del anterior Intel 486
- En mayo de 1994, pruebas internas de Intel detectaron que la división de coma flotante del Pentium era incorrecta en casos muy raros
- Intel calculó que solo 1 de cada 9 mil millones de valores causaba el problema y lo consideró menor
- Aun así, el circuito del Pentium fue corregido silenciosamente
- En octubre de 1994, el profesor Thomas Nicely encontró resultados erróneos mientras investigaba recíprocos de primos gemelos
- El cálculo de
1/824633702441dio mal en tres computadoras Pentium distintas, mientras que computadoras anteriores daban la respuesta correcta - Al no recibir suficiente respuesta del soporte técnico de Intel, Nicely envió correos a revistas de computación y a particulares
- Ese correo apareció en foros de Compuserve, y Electronic Engineering Times publicó el 7 de noviembre Intel fixes a Pentium FPU glitch
- El cálculo de
- Al principio, Intel solo quería ofrecer reemplazo a clientes que convencieran a sus ingenieros de que realmente necesitaban esa precisión, y los usuarios expresaron su descontento en grupos en línea como comp.sys.intel
- Tras un reporte de CNN el 22 de noviembre, creció el interés público, y la situación empeoró cuando IBM anunció el 12 de diciembre que suspendía los envíos de computadoras Pentium
- El 19 de diciembre, Intel anunció que reemplazaría los chips defectuosos a todos los clientes
- El costo del recall fue de 475 millones de dólares
- En valor actual, supera los mil millones de dólares
La división SRT que usaba Pentium
- La división larga binaria tradicional es lenta porque requiere un ciclo de reloj por cada bit del cociente
- El Intel 486 y procesadores anteriores usaban ese enfoque
- El Pentium usó el algoritmo SRT en radix-4, es decir, en unidades de 2 bits
- Genera 2 bits del cociente por etapa y es el doble de rápido que la división binaria convencional
- Cada dígito del cociente puede ser
-2,-1,0,1, o2
- Como SRT permite dígitos negativos en el cociente, si en una etapa se elige un valor un poco grande, puede corregirse con un dígito negativo en la siguiente
- No hace falta que el dígito del cociente quede determinado de forma única, así que puede elegirse rápido con una tabla de búsqueda
- Se toman solo algunos bits del residuo parcial y del divisor para mantener el tamaño de la tabla en un nivel práctico
- Este método es rápido, pero requiere además la tabla de búsqueda, circuitos para sumar o restar múltiplos de
1o2, y lógica para convertir el resultado al formato estándar del cociente
La estructura que comprimía 2048 entradas en una PLA de 112 filas
- La tabla de búsqueda SRT del Pentium toma como entrada el residuo parcial
py el divisord, y produce el dígito de cociente adecuado - La tabla está compuesta por 2048 entradas
- El divisor se escala entre 1 y 2 y forma la coordenada del eje X
- El residuo parcial toma valores entre -8 y 8 y forma la coordenada del eje Y
- Del divisor
1.ddddse usan 4 bits, excluyendo el bit inicial que siempre es 1 - El residuo parcial se trunca a un valor signed de 7 bits
pppp.ppp - En total, un índice de 11 bits apunta a
2^11 = 2048entradas
- La tabla tiene 5 regiones correspondientes a los dígitos de cociente
+2,+1,0,-1, y-2- Algunas regiones superiores e inferiores no se usan según la matemática de SRT
- En la tabla defectuosa original, las entradas no utilizadas se llenaban con 0
- Las 5 entradas rojas problemáticas debían ser
+2, pero quedaron en 0
- El Pentium implementó esta tabla no como ROM, sino como una PLA (Programmable Logic Array)
- Guardar toda la tabla como ROM habría requerido 2048 filas
- Como la estructura de la tabla era regular y tenía muchas zonas vacías, con PLA bastaban 112 filas
- La PLA está compuesta por un plano AND y un plano OR
- El plano AND genera términos lógicos a partir de combinaciones de bits de entrada y sus complementos
- El plano OR suma esos términos para producir bits de salida que indican si el cociente es
1o2
- Si se extrae con microscopio el patrón de transistores de la PLA, puede reconstruirse la expresión lógica de cada fila
- Una fila de la PLA no cubre una sola celda de la tabla, sino una región rectangular de varias celdas a la vez
- Cuanto más irregular es un límite de la tabla, más filas de PLA hacen falta
Los límites matemáticos y la región +2 incorrecta
- El paso central de la división SRT consiste en elegir el dígito de cociente
qa partir de la razónp/dentre el residuo parcialpy el divisord - Por razones matemáticas, el rango permitido de
p/ddebe quedar dentro de[-8/3, 8/3]- Después de elegir el dígito de cociente, se resta
q*dy se multiplica por 4 para formar el residuo parcial de la siguiente etapa - Para que este proceso pueda repetirse, el nuevo rango debe tener el mismo tamaño que el original
- Después de elegir el dígito de cociente, se resta
- SRT tiene redundancia, así que en algunos intervalos puede elegirse cualquiera de dos dígitos de cociente
- Pero si se elige
0donde debía irq=2, el siguiente residuo parcial sale del rango permitido y el algoritmo ya no puede recuperarse - El bug FDIV corresponde a ese caso
- Pero si se elige
- La tabla P-D del Pentium es una cuantización por celdas de esos límites matemáticos
- Los límites diagonales determinan qué celdas deben ser forzosamente
+2, cuáles pueden ser+1o+2, cuáles deben ser+1, etc.
- Los límites diagonales determinan qué celdas deben ser forzosamente
- Según el análisis del die, la línea de límite magenta superior de la tabla defectuosa debería estar siempre por encima de la línea de límite matemática negra, pero la cruza repetidamente
- Como resultado, algunas celdas que debían ser obligatoriamente
+2quedaron en 0 - Esas celdas son las entradas faltantes que provocaban el bug FDIV
- Como resultado, algunas celdas que debían ser obligatoriamente
Cómo el carry-save adder volvió el error raro pero decisivo
- El circuito de división del Pentium usa un carry-save adder para acelerar sumas y restas
- Un carry-save adder no propaga de inmediato los acarreos, sino que los guarda en una palabra separada, lo que lo hace conveniente para divisiones que requieren varias sumas
- Al final sí hace falta una suma lenta para combinar los acarreos guardados
- El índice de la tabla de búsqueda necesita el residuo parcial, pero el carry-save adder lo mantiene dividido en bits de suma y bits de acarreo
- Para calcular rápidamente los 7 bits necesarios para el índice de la tabla, el Pentium usa un carry-lookahead adder
- Este circuito calcula en paralelo el carry de cada posición
- En palabras grandes se vuelve demasiado complejo, pero para un valor de 7 bits es práctico
- El problema es que el residuo parcial tiene 64 bits, mientras que el cálculo del índice de la tabla usa solo 7 bits
- Los bits restantes se recortan antes de sumarse, de modo que el residuo parcial usado para el índice puede quedar un poco por debajo del valor real
- En concreto, puede aparecer un desplazamiento de una celda hacia abajo respecto de la celda correcta, es decir, un offset de
1/8
- Por este efecto, algunas líneas de límite deben moverse
1/8hacia abajo, pero no todas- El límite superior de la región
+2no debe moverse hacia abajo, pero Intel generó una tabla que sí lo movía por error - Este efecto del carry-save ya era conocido y estaba mencionado en artículos sobre división SRT de la época
- El límite superior de la región
Dónde divergen la explicación de Intel y el análisis del die
- En su whitepaper, Intel explicó que hubo un problema en el script que cargaba la tabla en la PLA y que por eso faltaban algunas entradas
- Intel lo llamó Programmable Lookup Array, pero la estructura real es una Programmable Logic Array
- El análisis del die considera que las entradas faltantes encajan mejor con un error en el límite matemático que con un simple fallo de copiado
- Es posible que el programa generador de la tabla definiera mal la condición de frontera
- La palabra “script” podría ser técnicamente correcta si se refiere a un programa en C que generó la tabla, pero la esencia del problema sería un límite matemático incorrecto
- The Pentium Chronicles de Robert Colwell ofrece otra explicación
- Según ese relato, el diseño del Pentium usaba originalmente una tabla de búsqueda similar a la del 486 y el error apareció al optimizarla a último momento para ahorrar espacio en el die antes del lanzamiento
- Esa explicación tiene puntos que no encajan
- El Pentium usó desde el inicio un algoritmo de división distinto al del 486
- El Pentium usa SRT radix-4, mientras que el 486 usa división binaria estándar
- El 486 no tiene esa tabla de búsqueda
- La PLA defectuosa todavía dejaba 8 filas sin usar, así que si el objetivo hubiera sido simplemente reducir circuito, se podrían haber eliminado primero esas filas
Por qué la PLA corregida terminó siendo más pequeña
- En ese momento, algunos reportes dijeron que Intel había añadido unas decenas de transistores o una secuencia extra de gates en la PLA para corregir el defecto
- La PLA corregida observada en el die muestra exactamente lo contrario
- El tamaño físico de la PLA es el mismo
- Se eliminó cerca de un tercio de los términos
- Solo se usan 74 de 120 filas, y las otras 46 quedan vacías
- En la PLA defectuosa original solo había 8 filas vacías
- La corrección de Intel no consistió solo en llenar con
2las 5 entradas faltantes- Llenó con 2 toda la región de entradas no utilizadas de la tabla
- Así desapareció la posibilidad de acceder por error a una entrada vacía
- Al llenar con 2 la región no utilizada, los límites de la tabla se simplificaron
- Los límites irregulares requieren muchos términos de PLA
- Las regiones rectangulares grandes pueden cubrirse con un solo término de PLA
- Por eso, aunque se llenaron más celdas de la tabla, las expresiones de la PLA se volvieron más simples
- Como los términos lógicos de la PLA corregida son totalmente distintos de los de la original, es difícil señalar unos pocos transistores concretos como responsables de la corrección del bug
Impacto real y controversia
- En divisiones aleatorias, la probabilidad de que aparezca el defecto era de aproximadamente 1 en 9 mil millones, muy baja
- Incluso cuando la división era incorrecta, la diferencia normalmente aparecía en el noveno o décimo decimal
- En casos raros y peores, el error podía aparecer en la cuarta cifra significativa
- En su whitepaper, Intel estimó que un usuario común encontraría el problema una vez cada 27,000 años
- Afirmó que para la mayoría no era un problema, aunque algunos usuarios de ciencia, ingeniería y finanzas cuantitativas sí podían necesitar un procesador corregido o un workaround por software
- IBM, en su propio análisis, concluyó que sus clientes podían encontrarse con el problema cada pocos días y suspendió la venta de Pentium
- IBM también tenía en ese momento el procesador competidor PowerPC
- Según algunos análisis, en uso real solo parece haberlo detectado el profesor Nicely
- Se considera que el análisis de IBM quizá eligió números especialmente propensos a disparar el error
- La mayoría de los usuarios probablemente nunca se toparía con el bug y, aun si lo hiciera, la pequeña pérdida de precisión en coma flotante quizá no les causaría problemas
- Pero el bug FDIV era determinista
- Si un dividendo y divisor concretos disparaban el problema, el resultado era incorrecto el 100% de las veces
- Como los clientes podían reproducirlo fácilmente en sus propias computadoras, a Intel le resultaba difícil sostener que era un problema que “nunca iban a encontrar”
Bugs posteriores en procesadores y microcódigo parcheable
- El bug FDIV es uno de los errores de procesador más famosos, pero Intel tuvo otros bugs importantes
- Algunos procesadores 386 tempranos tenían un problema con multiplicación de 32 bits
- Bajo ciertas condiciones de temperatura, voltaje y frecuencia, daban resultados erróneos de forma impredecible
- La causa era un problema de layout con márgenes eléctricos insuficientes
- Intel vendió esos chips defectuosos restringidos al mercado de 16 bits, marcados como “16 BIT S/W ONLY”
- Otro problema del Pentium fue el F00F bug, descubierto en 1997
- Cierta secuencia de instrucciones que empezaba con
F0 0Fdejaba al procesador colgado hasta reiniciarlo - Se solucionó con una actualización del sistema operativo
- Cierta secuencia de instrucciones que empezaba con
- El Pentium tenía el microcódigo fijado en ROM, así que el bug FDIV no podía corregirse con una actualización de microcódigo
- Intel añadió microcódigo parcheable al Pentium Pro en 1995
- Originalmente era para depuración y pruebas del chip
- Después del bug FDIV quedó claro que también servía para corregir bugs
- El Pentium Pro tenía microcódigo ROM junto con SRAM para hasta 60 microinstrucciones, y el BIOS podía cargar parches durante el arranque
- Los parches de microcódigo en procesadores Intel modernos se usan para problemas muy diversos, desde la vulnerabilidad Spectre hasta problemas de voltaje
Un error nacido de circuitos cada vez más complejos
- A medida que la ley de Moore aumentó la cantidad de transistores en los procesadores, también crecieron la complejidad de los circuitos y de los algoritmos
- La evolución del soporte para división lo muestra claramente
- El Intel 8080 usaba 6,000 transistores en 1974 y no tenía división por hardware ni aritmética de coma flotante
- El Intel 8086 usaba 29,000 transistores en 1978 e implementaba la división entera con microcódigo, pero para coma flotante necesitaba el coprocesador 8087
- El Intel 486 integró soporte de coma flotante en el chip en 1989 con 1.2 millones de transistores
- El Pentium, con 3.1 millones de transistores en 1993, adoptó el algoritmo de división SRT, más rápido pero también más complejo
- Solo la PLA de división del Pentium tiene unos 4,900 sitios de transistores
- Eso es más que todo el procesador MOS Technology 6502
- Es decir, un solo componente del circuito de división del Pentium usaba más transistores que un procesador completo de 1975
- El efecto de largo plazo del bug FDIV sigue siendo debatible
- Competidores como AMD aprovecharon el problema del Pentium en anuncios burlones
- Robert Colwell sostiene que el bug FDIV pudo haber tenido un efecto neto positivo al hacer mucho más conocido el nombre Pentium y mostrar que Intel respaldaba su marca
- Intel sobrevivió al bug FDIV, pero el defecto mostró que cuando se combinan matemáticas complejas, compresión de circuitos y límites de verificación, incluso un error extremadamente raro puede convertirse en un gran problema de confianza
1 comentarios
Opiniones de Hacker News
Soy el autor. Si tienen preguntas sobre Pentium, puedo responderlas :-)
Quizá esto les resulte familiar porque un hilo de Mastodon sobre este bug apareció en HN hace unas semanas, pero ya terminé una publicación de blog detallada. La publicación anterior en HN también tiene bastantes comentarios: https://news.ycombinator.com/item?id=42391079
Dentro de Intel hubo errores peores, y también en otras empresas, pero esos quedaron completamente olvidados. Me da curiosidad la reelaboración de la pila de valores de la unidad de punto flotante del Pentium; no sé el nombre exacto. Fue hace mucho, pero ¿no era algo parecido a una forma temprana de renombrado de registros (register renaming), donde había que gestionar manualmente
fxchgcon cuidado?¿Qué tan difícil sería “dumpear” el microcódigo como un bitstream? ¿Sería posible hacerlo con software a partir de fotos de alta resolución del die? Claro que eso podría ser la parte fácil comparado con hacer ingeniería inversa de lo que significa el bitstream
También me intriga la parte de “examinar cuidadosamente el PLA con un microscopio”. Quisiera saber si este tipo de trabajo se hace en casa, qué equipo hay en el laboratorio y cómo se aprenden estas técnicas
En retrospectiva, me pregunto por qué las partes no utilizadas de la tabla de búsqueda no se llenaron con 2 y -2 desde el principio
El bug en sí es interesante, pero la respuesta de Intel también lo es por derecho propio. Parece que no reemplazaron los procesadores defectuosos por otros sin fallas a todos los que lo pidieron, y como resultado recibieron críticas durísimas
Como comparación, me recuerda mucho al lanzamiento de Amazon Colorsoft. Algunas unidades, incluida la mía, tenían un problema gráfico de una franja amarilla; Amazon tardó uno o dos días en verificar los hechos, luego lo reconoció y después simplemente las fue reemplazando todas en silencio. No fue un recall: si lo pedías, te enviaban uno nuevo. Mi reemplazo llega el viernes; espero que esté resuelto. Cuando un lanzamiento tropieza, parece claro que tener un sistema de devoluciones/soporte muy sólido es una ventaja mucho mayor de lo que uno anticiparía en un análisis
De forma parecida, el problema de ruido de los Apple AirPods Pro de hace algunos años tampoco recibió tanta cobertura últimamente. Tuve que reemplazar mis AirPods dos veces, pero Apple también los cambió en silencio, y me dio la impresión de que su capacidad de soporte, aunque no sea muy visible, funciona con bastante fuerza
Colorsoft: https://www.tomsguide.com/tablets/e-readers/amazon-kindle-co...
AirPods Pro: https://support.apple.com/airpods-pro-service-program-sound-...
Del lado de Apple, una comparación mejor sería el Antennagate del iPhone 4. Ahí, la solución equivalente habría sido reemplazar gratis su producto insignia central para las ventas, pero Apple no lo hizo
En cambio, Intel finalmente ofreció reemplazos gratuitos a cualquiera que los solicitara y asumió un gran golpe financiero
Esa forma en que Apple se hacía responsable del producto era realmente digna de respeto
Entiendo a qué te refieres porque viví la situación de la “garantía en la sombra” de Apple para consumidores, pero creo que fue muy distinta de la crisis de IT que enfrentó Intel. En esa época, la frase “IBM lo dijo” tenía un peso enorme en IT
En el white paper de Intel se decía que un usuario común se encontraría con el problema una vez cada 27.000 años, y que era despreciable frente a otras causas de error como los bit flips en DRAM. En cambio, IBM estimó en su propio análisis que un cliente podría toparse con él cada pocos días.
Tal vez esas cifras no estén tan alejadas como parecen. Intel parece haberlo visto desde la perspectiva de un solo usuario, mientras que IBM posiblemente lo pensó desde el punto de vista de las consultas a soporte.
En el trabajo me pasó algo parecido. Si procesas 100 millones de solicitudes al día, un problema de uno en mil millones aparece varias veces al mes. Si es del tipo que un cliente —o peor, un gerente— nota, la gente ignora el denominador y empieza a sospechar que todos son incompetentes. Cuatro veces al mes puede traducirse como “siempre” dentro del sesgo de la experiencia humana. Si se producen dos agrupaciones estadísticas de tres veces en una semana, alguien explota.
Además, consideró que los números que usa la gente tenían 90 veces más probabilidades de provocar el error que los números con distribución uniforme de Intel. Por eso llegó al resultado de que un usuario sufriría un error cada 24 días.
Hay una parte que dice: “Parece que solo una persona, el profesor Nicely, notó este bug en uso real”.
Me recuerda a un estudio de hace mucho en el que les dieron calculadoras a estudiantes para una clase de matemáticas. Las calculadoras estaban manipuladas para dar resultados incorrectos, y los investigadores querían saber qué tan equivocada tenía que estar la calculadora para que los estudiantes notaran que algo andaba raro.
La respuesta fue el doble.
Notar un error y verse afectado por un error son cosas completamente distintas. ¿Cuánta gente verifica si la salida de una computadora es correcta? Muy, muy, muy poca, creo. Yo tampoco lo hacía cuando hacía cálculos de ingeniería en Boeing, salvo una vez en que invertí las ecuaciones para comprobar que la salida coincidiera con la entrada.
Al final depende mucho del contexto y de cuánto entiende del tema la persona que hace el cálculo.
¿Cuánto del uso de FDIV en el Pentium era para salidas numéricamente importantes y no para multimedia?
Recuerdo ese bug. Como no podía controlar en qué CPU ejecutaban mis clientes, tuve que meter en la biblioteca código de detección de FPU defectuosa y ejecutar un workaround. Ese código lo proporcionó Intel.
Es decir, el problema de Intel se convirtió en mi problema, ugh.
Me acuerdo de un chiste que circulaba en esa época. Capturaba muy bien varios ambientes de los 90:
I AM PENTIUM OF BORG.
DIVISION IS FUTILE.
YOU WILL BE APPROXIMATED.
Otro gran artículo de Ken. Lo recuerdo especialmente porque la primera PC que compré con mi propio dinero tenía una CPU afectada. Antes de eso no me interesaban mucho las PC porque no podían correr software “real”.
Pero Windows NT cambió eso, y se lo agradezco a Cutler. Las motherboards taiwanesas baratas también hicieron realista armar tu propia máquina, y mucha gente todavía lo hace. Ken señaló que era fácil para los usuarios comprobar si su CPU estaba afectada. Recuerdo que era tan simple como ingresar en Excel una fórmula de división con números mágicos. Si Microsoft hubiera sacado una versión de Excel que esquivara el bug, creo que menos usuarios habrían pedido el reemplazo.
Es un análisis interesante y realmente obstinado. Es impresionante el esfuerzo de analizar el silicio y compartir los resultados. En particular, me gustó que, aunque el PR de Intel hizo sonar la causa real como una omisión menor, el artículo identifica la causa raíz real.
En realidad era un problema mucho menos perdonable y más criticable. Habían arruinado el algoritmo de generación de la tabla.
La frase “Smith publicó ese email en un foro de Compuserve, la versión de los años 90 de las redes sociales” me hace sentir raro.
La tabla corregida se volvió mucho más simple al hacer que devolviera 2 directamente para los valores fuera de rango, en vez de agregar un circuito que devolviera 0. Entonces me pregunto por qué no hicieron eso desde el principio.
La persona que generó la tabla no sabía que llenar los valores fuera de rango con 2 produciría un PLA más simple, y la persona que metió la tabla en el PLA quizá no sabía que el 0 era un valor indiferente (don't care) y asumió que había que conservarlo.
O tal vez dejaron de optimizar en cuanto sintieron que el PLA ya era lo suficientemente pequeño. Si ya habían terminado el plan de colocación, hacer el PLA más chico no habría reducido el tamaño total del chip, y habría sido mejor usar el tiempo de ingeniería en otra cosa.
Como en la mayoría del software, había una optimización pendiente que nadie pensó a tiempo. Y las CPU de esa época no se podían parchear.