Errores de silicio, hojas de erratas

En muchos (la mayoría, ¿todos ??) microcontroladores que he utilizado en los últimos años, allí a veces hay algunos errores de nivel de silicio, y los fabricantes proporcionan a los ingenieros las hojas de erratas, que describen el comportamiento inesperado que pueden enfrentar.

¿Por qué nunca arreglan estos "errores"? Dado que el producto todavía se produce y, en la mayoría de los casos, resolver el problema no afectará a las implementaciones anteriores, ¿por qué no solo lo revisan? En muchos casos, el producto puede estabilizarse, la mayoría de los errores pueden haberse encontrado y puede tener una parte significativa de su vida útil por delante.

¿Es tan difícil (técnicamente)? ¿Costoso?

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

Arreglar errores es difícil y costoso. No se trata solo de cambiar una línea de código RTL. Si hiciera eso, tendría que volver a sintetizar, rehacer el diseño físico, ajustar el diseño para solucionar cualquier problema de tiempo, comprar un conjunto de máscaras completamente nuevo, producir nuevas obleas, probar las obleas (normalmente), validar las nuevas correcciones y posiblemente caracterizar o calificar el producto nuevamente. Esto lleva meses y cuesta una cantidad de dinero angustiosa. Por esa razón, tratamos de corregir los 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 RTL, pero aún no es bueno.

Si de todos modos estamos solucionando un error crítico, ¿por qué no reparar también todos los demás errores? Nuevamente, esto lleva 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 llevará más tiempo sacar el próximo producto al mercado. Y mientras tanto, seguramente encontrará más errores en su producto actual si busca lo suficiente. Es una batalla perdida. Corregir errores es aún más difícil en un producto que ha estado fuera durante mucho tiempo, ya que las personas tienen que sumergirse en el diseño anterior para descubrir qué está sucediendo. Como dice Null, los clientes pueden tener que volver a calificar su producto en su sistema. Si su producto aún está en desarrollo, retrasar el lanzamiento de la producción puede hacer que los horarios de los clientes se desvanezcan, lo que los hace muy infelices.

Normalmente, los errores que quedan solo suceden 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 valer la pena. Y si reutiliza un módulo de hardware en el siguiente producto, sus clientes existentes 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 que rehacer las antiguas pruebas de validación se convierta en un proyecto importante en sí mismo. Y probablemente no pueda simplemente cargar las herramientas antiguas, porque ya no está pagando por la licencia del sitio. Pero siempre que no cambie el módulo, puede seguir copiando y pegando en nuevas MCU.

El software también es un problema del lado del cliente. Si su corrección de errores rompe la compatibilidad con versiones anteriores de alguna manera, todos sus clientes tendrán que actualizar su código, para el cual tal vez ya no tengan las herramientas.

Como alguien que trabaja en el desarrollo de microcontroladores, puedo decirte que a todos nos encantaría solucionar cada error. Pero tratar de hacerlo retrasaría el desarrollo de manera impredecible, molestaría a los clientes, costaría una tonelada de dinero y, al final de todo, probablemente todavía fracasaríamos.

Generalmente es por gastos.

Siempre existe el riesgo de romper algo más cuando "arreglas" un error. Debido a eso, el fabricante generalmente necesita volver a calificar por completo y volver a caracterizar el dispositivo solo para asegurarse de que la "corrección" 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 arreglando un producto existente en lugar de desarrollar uno nuevo.

En una nota relacionada, a veces los clientes también requieren una recalificación del dispositivo fijo en su (s) producto (s) para asegurarse de que la corrección de errores tampoco rompa algo en su sistema . Eso les cuesta dinero y tiempo, y los clientes pueden no estar dispuestos a aceptar esos costos, aún exigirán la versión "con errores".

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

Si un comprador importante de una pieza la utiliza en un diseño que ha certificado, por ejemplo, para su uso 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 conjunto. Si el diseño funciona adecuadamente alrededor de todos los errores en el silicio, la revisión del silicio puede requerir que el cliente rehaga todas las pruebas de calificación para su placa, manteniendo un suministro de partes "no fijas" y "fijas", o simplemente continuando fabricando el viejo diseño. Los vendedores 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 que la empresa puede ser reacia a hacer cualquier cosa 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 decentes. Probablemente mi mayor molestia es con una condición de carrera en la lógica de transmisión del UART en las partes 18Fxx de Microchip que puede hacer que transmita bytes NUL espurios si el código intenta transmitir datos en el momento incorrecto. La solución sugerida de Microchip es que el código garantice que no intente cargar el registro de transmisión de datos 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 de transmisión-búfer-vacío generalmente ganó '

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

Realmente depende de la empresa y la complejidad de la solución. Por ejemplo, vea 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 actualizada "A2". De los ocho errores originales, tres de ellos han sido corregidos en esta nueva revisió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 parte existente, aún puede "resolver" el problema asegurándose de que los nuevos productos no tengan los mismos errores.

Tal vez ya han producido (pero aún no se han vendido) miles o millones de circuitos integrados cuando se encuentra un error. No los tiran a la basura 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 sola ejecución en poco tiempo (días, semanas). Pero se venden en años o décadas. Los libros no se tiran y se vuelven a imprimir tan pronto como se encuentra un error tipográfico u otro error. También para los libros, las hojas de erratas 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.