¿Qué pasa si falla un solo transistor en un microprocesador?

Question

¿Qué pasa si falla un solo transistor en un microprocesador o en la memoria RAM?

Por fallo me refiero a que deja de funcionar por completo (por sobrecalentamiento u otra razón) o da una salida incorrecta.

Un solo fallo puede cambiar el opcode especificado del microprocesador para que se lea como alguna otra instrucción o manipular la dirección de memoria prevista en la RAM y las cosas pueden ir cuesta abajo a partir de ahí.

¿Qué estrategia de salvaguarda/recuperación tiene un ordenador contra esto?

Answer 1

¿En piezas comerciales de consumo? No. Se prueban en la fábrica, quizá con un breve proceso de "rodaje" para evitar los primeros fallos. A partir de ese momento, cualquier fallo permanente acaba con el dispositivo. Afortunadamente, esto no suele ocurrir durante años si el dispositivo se mantiene dentro de los parámetros de temperatura.

En el caso de los sistemas militares y aeroespaciales, hay varios tipos de sistemas redundantes que pueden detectar y recuperarse de los fallos. Ya sea mediante un proceso llamado "ejecución por pasos", o simplemente teniendo varios ordenadores como los famosos cinco ordenadores de vuelo del transbordador espacial. (¡El proyecto Apolo llegó a la luna con un solo ordenador no redundante!)

También existe la memoria RAM ECC, que está disponible para los sistemas de nivel de servidor y puede detectar y corregir errores de un solo bit.

Answer 2

Demasiado genérico

El transistor podría estar en una sección que no usas, así que nunca lo sabrás.

Podría estar en una sección que usas, pero la condición de fallo podría seguir apareciendo para trabajar sólo necesitaba un cero allí, falló a un cero y que está bien, no me di cuenta hasta que tal vez una actualización de firmware que utiliza ese transistor de manera diferente.

O podría estar en un lugar que usted utiliza y el fallo puede dar lugar a cualquier número de posibles problemas que pueden parecer manifestarse de muchas maneras. No es posible extenderse aquí, ciertamente, ya que no sabemos qué parte está utilizando y cuán grande es el número casi inconmensurable de posibles resultados una gota en el océano no comienza a cubrir el número de hipotéticos. No merece la pena hablar de ello en general, ni siquiera en el ámbito aeroespacial.

Para COTS sistemas, no hay nada en absoluto que lo proteja; puede tener un software que cubra las cosas densas o arriesgadas como la RAM, un POST tipo de prueba de memoria. Pero si el transistor que falla está como sugieres en el núcleo del procesador, entonces tienes un ladrillo, de nuevo una gota en el océano, no es posible hacer un POST que cubra las posibilidades e informe sobre ellas adecuadamente, no merece la pena ni siquiera hablar de ello. Tiras el cacharro y te compras otro. Ahora bien, al hacer las piezas, cosas como la RAM que son de mayor riesgo podrían tener bloques alternativos en la matriz que se pueden fusionar usando el BIST u otras pruebas de pantalla. Asimismo, algunos productos se derivan de otros productos, para volver en el día a 80486SX vs 80486DX . Si la unidad de punto flotante ha fallado durante la prueba de fabricación del chip, se funden los fusibles para que pase de ser un DX potencial a un SX y se venda así.

La pantalla de chips busca y, con la experiencia, cubre más de, digamos, el 99,99% de los fallos. Dependiendo del producto, se espera que haya uno en algún número de miles o decenas de miles que falle en el camino. Esto es así.

Los flip flops aeroespaciales, especialmente los que sufren de radiación, son, o eran, cuando todavía había gente que sabía cómo construir cosas fiables (ahora se han retirado en su mayoría), triplemente votados, tres conjuntos de transistores por, si un bit falla o experimenta un un solo evento de disgusto (que es la razón principal de la triple votación) entonces los otros dos dominan la votación. Se podría argumentar que se obtiene el argumento de si uno falla. Pero no se vota triple todo lo que la lógica combinacional no es; si obtiene un acierto debería resolverse antes de engancharse al siguiente flip flop/bit. También se necesitan transistores mucho más robustos para hacer frente a las perturbaciones de un solo evento, y también hay más material para hacer frente a la dosis total para extender la vida de la pieza antes de que todo muera por la exposición. Décadas de experiencia (todas perdidas por los jóvenes que crecieron en la era de lo desechable, hacer basura espacial en lugar de hacer una que siempre funcione). El fallo de un solo transistor no es una preocupación principal, el trastorno de un solo evento y el latch-up sí lo son (que podrían/llevar a la destrucción si no se manejan) dosis total, etc. El punto único de fallo junto con el MTBF son muy importantes; el MTBF debería ser mayor que la vida de la misión, y ningún punto único de fallo debería quedar sin detectar y resolver. Dos fallos a la vez no suelen ser solucionables (una gota en el océano).

Con los COTS no te preocupas de que falle un solo transistor; todo se basa en promedios/estadísticas. Se parte de la experiencia y, de todos modos, no hay muchas fundiciones que sepan lo que hacen. Se sigue la experiencia de décadas en el diseño, la disposición, la verificación del diseño, las pruebas, etc. Y lo más seguro es que se espere un rendimiento inferior al 100%, y que de las piezas empaquetadas y entregadas se espere que un porcentaje de ellas falle sobre el terreno. Si sus clientes esperan una calidad y un precio COTS, pero piezas tolerantes a fallos o de grado militar o aeroespacial, sólo tiene que educar al cliente de que lo que está pidiendo es un orden de magnitud más en el precio y un orden de magnitud más lento en el ancho de banda/potencia de procesamiento. Además, el plazo de entrega es un orden de magnitud mayor.

La memoria RAM es un área que se enfoca mucho, no para una falla de un solo transistor, sino más bien para un evento único, un bit volteado. Así que ECC / EDAC se utilizan, como se menciona en la fabricación puede haber un BIST y un banco alternativo que se puede fusionar. Con cosas como la memoria flash y/o los discos duros son propensos a fallar, así que más allá de la vista del usuario puede haber bancos/sectores extra que pueden ser marcados como malos y otros intercambiados. Es posible con la RAM, pero normalmente no, ya que no se usa la RAM como se usa el almacenamiento no volátil, sino que se usa DIMMs por ejemplo, y hacer que el usuario los sustituya si/cuando fallan. Normalmente, al igual que el zócalo del procesador, esto es para las actualizaciones o las opciones de configuración, no porque la RAM falle a un gran ritmo en comparación con otros componentes de la placa.

Answer 3

Este es un juego de estadísticas. Cualquier transistor puede tener un efecto crítico (tal vez esté en el incrementador del contador de programa), un efecto en el rendimiento (digamos que una línea de caché nunca llega), o una degradación de la experiencia del usuario (píxel atascado o similar). O tal vez el fallo esté en la lógica de prueba, por lo que es invisible para el funcionamiento normal.

Para algunas aplicaciones, estos fallos aleatorios sólo contribuyen a la vida útil del dispositivo (el fallo de la batería o el impacto percusivo son riesgos más importantes). Los fallos transitorios son tan importantes como los fallos permanentes del hardware.

Los sistemas de servidores deben ser capaces de detectar el final de la vida útil de los nodos individuales, los sistemas críticos de seguridad son más propensos a emplear la detección y la redundancia - sin embargo, observar los fallos menos terminales es generalmente difícil. A diferencia de un disco duro magnético, en el que las tasas de corrección de errores (y otras métricas) suelen poder medirse antes del punto de fallo catastrófico.

La autocomprobación exhaustiva requiere mucho tiempo - véase http://www.memtest86.com/ para ver un ejemplo de un problema más sencillo que el de probar un procesador.

Answer 4

TL;DR si estás hablando de CPUs modernas, es poco probable que te des cuenta.
Si se trata de una memoria RAM no ECC, es posible que algunos trozos no se puedan leer/escribir de forma fiable.

CPU

El punto clave aquí es la complejidad de una CPU. Es una enorme simplificación asumir que un incrementador o el selector de opcode dependen de un transistor.

Fuera del varios miles de millones de transistores, no todos tienen una función lógica inmediata. Las CPU están altamente paralelizadas; no sólo por la presencia de múltiples núcleos, sino también por la optimización de la lógica que sufren, ya sea para reducir el número de transistores o para hacer la instrucción más rápida . Esto los hace muy redundantes (muchas copias de la misma lógica, para hacer simultáneamente más cálculos). Incluso un solo núcleo precarga varias instrucciones al mismo tiempo y intenta adivinar el resultado de la siguiente instrucción . Además, muchos transistores retuercen la señal para conseguir una sincronización más rápida, o tienen diferentes tamaños (una célula está formada por varios transistores individuales). Además, muchos de ellos pueden implementar sólo Caché de la CPU .

Al final, un solo transistor no es muy probable que sea relevante para la corrección de la salida en la mayoría de las situaciones; tal vez el camino en el que se encuentra está activo sólo cuando algunos muy condiciones específicas lo activan, y puede que nunca se dé cuenta de que está dañado porque su CPU nunca ejecutó esas instrucciones (en ese orden preciso) que hacen que el transistor sea esencial. Un transistor que es relevante para la salida en cada ciclo (por ejemplo los que participan en la distribución de la señal de reloj en el chip), va a ser extremadamente resistente.

Por supuesto, un transistor no fallará por sí solo; pero las CPUs también son probado durante años bajo muchos puntos de vista diferentes y son rediseñado para cumplir la prueba y evitar fallos, y las pruebas reflejan, por supuesto, los escenarios de uso habituales.

RAM

Las memorias RAM realizan una función mucho más sencilla que la de una CPU (almacenamiento y recuperación indexados), de ahí que la lógica es en sí mismo más sencillo. Un transistor defectuoso podría hacer que el controlador seleccionara una dirección incorrecta o impidiera la lectura/escritura.

Pero esto ocurre más a menudo de lo que uno cree (Yo mismo he tenido que sustituir varias memorias RAM dañadas). Los datos de la memoria no son los que el programa espera; y los datos de la memoria son muy a menudo los programa sí mismo. El resultado ( 1 2 ) es a menudo aleatoria, difícil de reproducir los bloqueos, que puede culminar con el ordenador colgando de repente o causando el pánico del núcleo, a menudo con SEGFAULT (esto puede ser inspeccionado en los archivos de registro).

La única protección es corrección de errores o sistemas redundantes en este caso, como señaló pjc50.

---

Un dato curioso: He dañado un procesador AMD Duron bastante antiguo al hacer overclocking y ejecutar ampliamente SETI@home y LHC@home. En algún momento mi máquina no pudo reconocer el modelo de CPU, y la CPU se había estrangulado a 1,8GHz (desde 2,4 si recuerdo).

A veces, los chips de gama baja son chips de gama alta con algunas capacidades recortadas, o la frecuencia reducida, y no todas las partes del chip pueden funcionar a la misma velocidad, por lo que el daño extenso puede haber "hervido" la parte de alta velocidad del reloj. Todo es hipotético, por supuesto, sin poder depurar los daños.