Errores de silicio, hojas de errata

Los errores críticos se arreglan. Por lo general, se fijan antes de que el producto entre en producción. A menos que esté utilizando muestras tempranas, es posible que nunca vea los errores más graves.

La reparación de errores es difícil y costosa. No es solo cambiar una línea de código RTL. Si hiciera eso, tendría que volver a sintetizar, rehacer el diseño físico, modificar el diseño para solucionar cualquier problema de tiempo, comprar un conjunto de máscaras completamente nuevo, producir obleas nuevas, probar las obleas (normalmente), validar las nuevas correcciones y Posiblemente caracterice o califique el producto nuevamente. Esto lleva meses y cuesta una cantidad angustiosa de dinero. Por esa razón, tratamos de corregir errores directamente en el diseño (preferiblemente en una sola capa de metal). Esto es más rápido y más barato que comenzar desde la síntesis de RTL, pero aún no es bueno.

De todos modos, si estamos solucionando un error crítico, ¿por qué no solucionamos todos los otros errores? Nuevamente, esto toma tiempo, tiempo para descubrir e implementar una solución, tiempo para volver a ejecutar las pruebas de verificación de diseño. Ese tiempo significa que tomará más tiempo llevar el siguiente producto al mercado. Y mientras tanto, es casi seguro que encontrarás más errores en tu producto actual si te fijas lo suficiente. Es una batalla perdida. Reparar errores es aún más difícil para un producto que ha estado fuera durante mucho tiempo, ya que la gente tiene que sumergirse en el diseño antiguo para descubrir qué está pasando. Como dice Null, los clientes pueden tener que recalificar su producto en su sistema. Si su producto aún está en desarrollo, retrasar el lanzamiento de producción puede hacer que los calendarios de los clientes se deslicen, lo que hace que los clientes sean muy infelices.

Normalmente, los errores que quedan solo ocurren en configuraciones extrañas, causan problemas muy pequeños, tienen soluciones fáciles o todo lo anterior. Simplemente no son lo suficientemente malos como para merecer la pena. Y si reutiliza un módulo de hardware en el siguiente producto, sus clientes actuales ya tendrán la solución en su software de todos modos.

Las cadenas de herramientas de software son otro factor. Si un módulo permanece el tiempo suficiente, su cadena de herramientas podría cambiar lo suficiente como para rehacer las antiguas pruebas de validación y convertirse en un gran proyecto en sí mismo. Y probablemente no pueda simplemente cargar las herramientas antiguas, porque ya no está pagando la licencia del sitio. Pero mientras no cambie el módulo, puede seguir copiándolo y pegándolo en las nuevas MCU.

El software también es un problema del lado del cliente. Si su corrección de errores rompe la compatibilidad hacia atrás de alguna manera, todos sus clientes tendrán que actualizar su código, para lo cual es posible que ni siquiera tengan las herramientas.

Como alguien que trabaja en el desarrollo de microcontroladores, puedo decirles que a todos nos encantaría corregir todos los errores. Pero tratar de hacerlo demoraría el desarrollo de manera impredecible, molestaría a los clientes, costaría una tonelada de dinero y, al final, probablemente fallaríamos.

Generalmente se debe a gastos.

Siempre hay un riesgo de romper otra cosa cuando "arreglas" un error. Debido a eso, el fabricante normalmente necesita recalificar completamente y volver a caracterizar el dispositivo solo para asegurarse de que el "arreglo" no haya introducido un error diferente (y quizás aún más indeseable). Eso significa dinero y tiempo (que, para el fabricante, también es dinero). También significa que el fabricante tiene empleados que arreglan un producto existente en lugar de desarrollar uno nuevo.

En una nota relacionada, a veces los clientes también requieren la recalificación del dispositivo fijo en sus productos para asegurarse de que la corrección de errores no rompa algo en su sistema , tampoco. Eso cuesta dinero y tiempo para ellos, y es posible que los clientes no estén dispuestos a aceptar esos costos; aún así exigirán la versión "con errores".

En algunos casos, por supuesto, el error es realmente técnicamente difícil de solucionar. En ese caso, es aún más caro arreglarlo.

Si un comprador importante de una pieza la usa en un diseño para el que ha certificado, por ejemplo. Para usar a bordo de un avión o nave espacial, cualquier cambio en cualquiera de los componentes utilizados en el diseño requerirá la recertificación del diseño en su totalidad. Si el diseño funciona adecuadamente alrededor de todos los errores en el silicio, la revisión del silicio puede requerir que el cliente repita todas las pruebas de calificación para su placa, mantenga un suministro de partes "no fijas" y "fijas", o simplemente Continuando con la fabricación del antiguo diseño. Los proveedores de chips no publican sus listas de compradores, pero en algunos casos, un solo cliente puede representar una fracción suficientemente grande de la demanda de un chip en particular, por lo que la compañía puede estar dispuesta a hacer algo para incomodar a ese cliente.

Dicho esto, hay algunas erratas de silicio que siguen apareciendo en generaciones sucesivas de partes, algunas de las cuales carecen de soluciones adecuadas. Probablemente mi mayor motivo es una condición de carrera en la lógica de transmisión, el UART en las partes 18Fxx de Microchip, lo que puede hacer que transmita bytes NUL espurios si el código intenta transmitir datos en el momento equivocado. La solución sugerida de Microchip es tener un código que garantice que no intente cargar el registro de datos de transmisión entre el momento en que el UART comienza a enviar el bit de parada para un carácter anterior y el momento en que dicha transmisión se completa, pero si alguna vez se producen interrupciones deshabilitado, el código en un controlador de interrupción vacío de búfer de transmisión generalmente no tendrá ninguna forma de saber cuánto tiempo puede haber transcurrido entre la transmisión de un carácter anterior (lo que habría hecho que un espacio de búfer de transmisión esté disponible) y cuando el controlador de interrupciones realmente recibió el control y, por lo tanto, no tendrá ninguna forma de saber cuándo debe abstenerse de transmitir.

Si bien puedo entender cómo podrían introducirse errores como el error UART del Microchip, la solución no debería ser difícil: espero que el Microchip genere una señal de "ir" basada en el "Y" de la "transmisión completa" no sincronizada y las señales de "carácter cargado", y tiene problemas si la señal anterior cambia de estado justo después de la última (lo que hace que el circuito de búfer de TX pierda la oportunidad de cargar los datos de caracteres en un ciclo dado, pero permite que el secuenciador de TX inicie una nueva transmisión) ese ciclo); incluso si Microchip no quiere agregar demoras de sincronización a los casos normales donde el transmisor está vacío y se carga un carácter, o cuando el transmisor se queda vacío después de que se haya cargado un carácter, el problema podría solucionarse sin afectar el cronometrando en cualquiera de esos casos agregando tres puertas NAND y dos pestillos de sincronización. Sin embargo, se han enviado numerosas partes desde que se publicó el problema, sin agregar ninguna solución de este tipo.

Realmente depende de la compañía y la complejidad de la solución. Por ejemplo, consulte esta errata para el PIC18F23K22. Puede ver que hubo ocho errores conocidos que afectaron la primera revisión ("A1") del silicio.

En el momento de esta respuesta, tienen una revisión "A2" actualizada. De los ocho errores originales, tres de ellos se han corregido en esta nueva versión.

Otro factor decisivo es la vida útil de fabricación del producto. Incluso si un fabricante decide no solucionar un problema específico en una pieza existente, aún puede "resolver" el problema asegurándose de que los nuevos productos no tengan los mismos errores.

Tal vez ya hayan producido (pero aún no se hayan vendido) miles o millones de circuitos integrados cuando se encuentra un error. No los tiran a todos solo por un error.

Creo que puedes compararlo con la impresión de libros. Los libros se imprimen en números de muchos miles en una carrera en poco tiempo (días, semanas). Pero se venden dentro de años o décadas. Los libros no se tiran y se reimprimen tan pronto como se encuentra un error tipográfico u otro error. También para libros, las hojas de errata se imprimen y se entregan al usuario.

Por supuesto, los errores conocidos (errores tipográficos, errores) se corregirán en la próxima edición.