Erros de silício, folhas de errata

Em muitos microcontroladores (a maioria ??, todos ??) que eu usei nos últimos anos, há alguns erros no nível do silício, e os fabricantes fornecem aos engenheiros as folhas de errata, descrevendo o comportamento inesperado que elas podem enfrentar.

Por que eles nunca consertam esses "bugs"? Como o produto ainda é produzido e, na maioria dos casos, a solução do problema não afetará as implementações anteriores, por que eles não o revisam? Em muitos casos, o produto pode ser estabilizado, a maioria dos erros pode ter sido encontrada e pode ter uma parte significativa da vida útil do produto à sua frente.

É tão difícil (tecnicamente)? Caro?

Erros críticos são corrigidos. Geralmente eles são consertados antes que o produto entre em produção. A menos que você esteja usando amostras antigas, você poderá nunca ver os piores erros.

Corrigir bugs é difícil e caro. Não é apenas mudar uma linha do código RTL. Se você fez isso, teria que re-sintetizar, refazer o layout físico, ajustar o layout para corrigir qualquer problema de tempo, comprar um conjunto de máscaras totalmente novo, produzir novas bolachas, testar as bolachas (normalmente), validar as novas correções e possivelmente caracterizar ou qualificar o produto novamente. Isso leva meses e custa uma quantia angustiante de dinheiro. Por esse motivo, tentamos corrigir erros diretamente no layout (de preferência em uma única camada de metal). Isso é mais rápido e mais barato do que começar da síntese RTL, mas ainda não é bom.

Se estamos corrigindo um erro crítico de qualquer maneira, por que não corrigir todos os outros erros também? Novamente, isso leva tempo - tempo para descobrir e implementar uma correção - tempo para executar novamente os testes de verificação do projeto. Esse tempo significa que levará mais tempo para lançar o próximo produto no mercado. Enquanto isso, você quase certamente encontrará mais bugs no seu produto atual se procurar com atenção. É uma batalha perdida. A correção de bugs é ainda mais difícil em um produto lançado há muito tempo, pois as pessoas precisam mergulhar no design antigo para descobrir o que está acontecendo. Como diz Null, os clientes podem precisar requalificar seu produto em seus sistemas. Se o seu produto ainda estiver em desenvolvimento, atrasar o lançamento da produção pode causar um atraso na programação dos clientes, o que deixa os clientes muito insatisfeitos.

Normalmente, os erros deixados apenas acontecem em configurações estranhas, causam problemas muito pequenos, têm soluções fáceis ou todas as opções acima. Eles não são ruins o suficiente para valer a pena. E se você reutilizar um módulo de hardware no próximo produto, seus clientes existentes já terão a solução alternativa em seu software.

As cadeias de ferramentas de software são outro fator. Se um módulo permanecer por tempo suficiente, sua cadeia de ferramentas poderá mudar o suficiente para refazer os testes de validação antigos se tornar um projeto importante em si. E você provavelmente não pode simplesmente carregar as ferramentas antigas, porque não está mais pagando pela licença do site. Mas enquanto você não alterar o módulo, poderá continuar copiando e colando em novos MCUs.

O software também é um problema do lado do cliente. Se o seu bugfix quebrar a compatibilidade com versões anteriores de qualquer forma, todos os seus clientes terão que atualizar o código, para o qual talvez nem tenham mais as ferramentas.

Como alguém que trabalha no desenvolvimento de microcontroladores, posso dizer que todos gostaríamos de corrigir todos os erros. Mas tentar fazer isso atrasaria o desenvolvimento imprevisivelmente, incomodaria os clientes, custaria uma tonelada de dinheiro e, no final de tudo, provavelmente ainda falharíamos.

Geralmente é por causa das despesas.

Sempre existe o risco de quebrar outra coisa quando você "corrige" um bug. Por esse motivo, o fabricante normalmente precisa se requalificar e caracterizar completamente o dispositivo apenas para garantir que a "correção" não tenha introduzido um bug diferente (e talvez ainda mais indesejável). Isso significa dinheiro e tempo (que, para o fabricante, também é dinheiro). Isso também significa que o fabricante tem funcionários consertando um produto existente em vez de desenvolver um novo.

Em uma nota relacionada, às vezes os clientes também exigem requalificação do dispositivo fixo em seus produtos para garantir que a correção de erro também não oculte algo em seu sistema . Isso custa dinheiro e tempo para eles, e os clientes podem não estar dispostos a aceitar esses custos - eles ainda exigirão a versão "buggy".

Em alguns casos, é claro, o bug é realmente tecnicamente difícil de corrigir. Nesse caso, é ainda mais caro corrigi-lo.

Se um grande comprador de uma peça a utiliza em um projeto certificado para, por exemplo, a bordo de um avião ou de uma nave espacial, qualquer alteração em qualquer um dos componentes usados ​​no projeto exigirá a recertificação do projeto como um todo. Se o design funcionar adequadamente com todos os bugs do silício, a revisão do silício poderá exigir que o cliente refaça todos os testes de qualificação de sua placa, mantendo um suprimento de peças "não fixas" e "fixas" ou simplesmente continuando a fabricar o design antigo. Os fornecedores de chips não publicam suas listas de compradores, mas, em alguns casos, um único cliente pode representar uma fração suficientemente grande da demanda por um chip específico e a empresa pode estar relutante em fazer qualquer coisa para incomodá-lo.

Dito isto, existem algumas erratas de silício que continuam aparecendo nas gerações seguintes de peças, algumas das quais não têm soluções decentes. Provavelmente, minha maior preocupação é com uma condição de corrida na lógica de transmissão do UART nas partes 18Fxx do Microchip, que pode causar a transmissão de bytes NUL espúrios se o código tentar transmitir dados na hora errada. A solução alternativa sugerida pelo Microchip é que o código garanta que ele não tente carregar o registro de dados de transmissão entre o momento em que o UART começa a enviar o bit de parada para um caracter anterior e o tempo em que essa transmissão é concluída, mas se houver interrupções desativado, o código em um manipulador de interrupção de buffer de transmissão vazio geralmente ganha '

Embora eu possa entender como erros como o bug do Microchip UART podem se infiltrar, a correção não deve ser difícil: espero que o Microchip gere um sinal de "go" com base no "AND" da "transmissão concluída" não sincronizada e no "personagem carregado" "sinaliza e apresenta problemas se o sinal anterior mudar de estado logo após o último (fazendo com que o circuito do buffer TX perca a chance de carregar os dados dos caracteres em um determinado ciclo, mas permitindo que o sequenciador TX inicie uma nova transmissão nesse ciclo) ; mesmo que o Microchip não queira adicionar atrasos de sincronização aos casos normais em que o transmissor está vazio e um caractere é carregado, ou quando o transmissor fica vazio após o carregamento de um caractere, o problema pode ser corrigido sem afetar o tempo em qualquer desses casosadicionando três portas NAND e duas travas de sincronização. Entretanto, várias peças foram enviadas desde que o problema foi publicado, sem a adição de nenhuma correção.

Realmente depende da empresa e da complexidade da correção. Por exemplo, consulte esta errata para o PIC18F23K22. Você pode ver que havia oito erros conhecidos que afetaram a primeira revisão ("A1") do silício.

No momento desta resposta, eles tinham uma revisão "A2" atualizada. Dos oito erros originais, três deles foram corrigidos nesta nova revisão.

Outro fator decisivo é a vida útil de fabricação do produto. Mesmo que um fabricante opte por não corrigir um problema específico em uma peça existente, ele ainda pode "resolver" o problema, garantindo que os novos produtos não tenham os mesmos bugs.

Talvez eles já tenham produzido (mas ainda não tenham vendido) milhares ou milhões de CIs quando um bug é encontrado. Eles não jogam todos fora só por causa de um bug.

Eu acho que você pode compará-lo à impressão de livros. Os livros são impressos em números de muitos milhares em uma execução em um curto período de tempo (dias, semanas). Mas eles são vendidos dentro de anos ou décadas. Os livros não são descartados e reimpressos assim que um erro de digitação ou outro erro é encontrado. Também para livros, as folhas de errata são impressas e entregues ao usuário.

É claro que os bugs conhecidos (erros de digitação, erros) serão corrigidos na próxima edição.