Bugs en silicone, feuilles d'errata

Dans de nombreux microcontrôleurs (la plupart ??, tous ??) que j'ai utilisés au cours des dernières années, il y a parfois des bogues de niveau de silicium et les fabricants fournissent aux ingénieurs les feuilles d'errata, décrivant le comportement inattendu auquel ils peuvent être confrontés.

Pourquoi ne corrigent-ils jamais ces "bugs"? Étant donné que le produit est toujours produit et que, dans la plupart des cas, la résolution du problème n'affectera pas les implémentations précédentes, pourquoi ne le révise-t-il pas simplement? Dans de nombreux cas, le produit peut être stabilisé, la plupart des bogues peuvent avoir été trouvés et peuvent avoir une partie importante de la durée de vie de son produit devant lui.

Est-ce si difficile (techniquement)? Coûteux?

Les bogues critiques sont corrigés. Habituellement, ils sont corrigés avant que le produit n'entre en production. À moins que vous n'utilisiez les premiers échantillons, vous ne verrez peut-être jamais les pires bugs.

La correction des bogues est difficile et coûteuse. Il ne s'agit pas simplement de changer une ligne de code RTL. Si vous faisiez cela, vous devrez resynthétiser, refaire la disposition physique, modifier la disposition pour résoudre les problèmes de synchronisation, acheter un tout nouvel ensemble de masques, produire de nouvelles tranches, tester les tranches (normalement), valider les nouveaux correctifs et éventuellement caractériser ou qualifier à nouveau le produit. Cela prend des mois et coûte cher. Pour cette raison, nous essayons de corriger les bogues directement dans la mise en page (de préférence sur une seule couche métallique). C'est plus rapide et moins cher que de recommencer à partir de la synthèse RTL, mais ce n'est toujours pas bon.

Si nous corrigeons un bogue critique de toute façon, pourquoi ne pas corriger tous les autres bogues aussi? Encore une fois, cela prend du temps - du temps pour trouver et implémenter un correctif, du temps pour relancer les tests de vérification de conception. Ce délai signifie qu'il faudra plus de temps pour commercialiser le prochain produit. Et en attendant, vous trouverez presque certainement plus de bogues dans votre produit actuel si vous regardez bien. C'est une bataille perdue. La correction des bogues est encore plus difficile sur un produit qui est sorti depuis longtemps, car les gens doivent plonger dans l'ancien design pour comprendre ce qui se passe. Comme le dit Null, les clients devront peut-être requalifier votre produit dans leur système. Si votre produit est encore en développement, le report de la mise en production peut entraîner un glissement des horaires des clients, ce qui les rend très mécontents.

Normalement, les bogues qui restent ne se produisent que dans des configurations étranges, causent des problèmes très mineurs, ont des solutions de contournement faciles ou tout ce qui précède. Ils ne sont tout simplement pas assez mauvais pour en valoir la peine. Et si vous réutilisez un module matériel sur le produit suivant, vos clients existants auront déjà la solution de contournement dans leur logiciel.

Les chaînes d'outils logiciels sont un autre facteur. Si un module persiste assez longtemps, votre chaîne d'outils pourrait changer suffisamment pour que refaire les anciens tests de validation devienne un projet majeur en soi. Et vous ne pouvez probablement pas simplement charger les anciens outils, car vous ne payez plus pour la licence du site. Mais tant que vous ne changez pas le module, vous pouvez continuer à le copier et à le coller dans de nouveaux MCU.

Le logiciel est également un problème côté client. Si votre correction de bug rompt la compatibilité en arrière de quelque manière que ce soit, tous vos clients devront mettre à jour leur code, dont ils n'auront peut-être même plus les outils.

En tant que personne travaillant dans le développement de microcontrôleurs, je peux vous dire que nous aimerions tous corriger chaque bogue. Mais essayer de le faire retarderait le développement de manière imprévisible, ennuierait les clients, coûterait une tonne d'argent, et à la fin de tout cela, nous échouerions probablement.

C'est généralement à cause des dépenses.

Il y a toujours un risque de casser quelque chose d'autre lorsque vous "corrigez" un bogue. Pour cette raison, le fabricant doit généralement requalifier et caractériser complètement le périphérique juste pour s'assurer que le "correctif" n'a pas introduit un bogue différent (et peut-être encore plus indésirable). Cela signifie de l'argent et du temps (qui, pour le fabricant, c'est aussi de l'argent). Cela signifie également que le fabricant a des employés qui réparent un produit existant au lieu d'en développer un nouveau.

Sur une note connexe, parfois, les clients doivent également requalifier le périphérique fixe dans leurs produits pour s'assurer que la correction de bogue ne casse pas non plus quelque chose dans leur système . Cela leur coûte de l'argent et du temps, et les clients peuvent ne pas être disposés à accepter ces coûts - ils exigeront toujours la version "buggy".

Dans certains cas, bien sûr, le bogue est vraiment techniquement difficile à corriger. Dans ce cas, il est encore plus coûteux de le réparer.

Si un acheteur important d'une pièce l'utilise dans une conception qu'il a certifiée, par exemple pour une utilisation à bord d'un avion ou d'un vaisseau spatial, toute modification apportée à l'un des composants utilisés dans la conception nécessitera une recertification de la conception dans son ensemble. Si la conception fonctionne correctement autour de tous les bogues du silicium, la révision du silicium peut nécessiter soit que le client refasse tous les tests de qualification pour sa carte, en maintenant un approvisionnement en pièces "non fixes" et "fixes", soit simplement continuer à fabriquer l'ancien design. Les fournisseurs de puces ne publient pas leurs listes d'acheteurs, mais dans certains cas, un seul client peut représenter une fraction suffisamment importante de la demande pour une puce particulière que l'entreprise peut être réticente à faire quoi que ce soit pour gêner ce client.

Cela étant dit, il y a quelques errata de silicium qui continuent d'apparaître dans les générations successives de pièces, dont certaines manquent de solutions de contournement décentes. Mon plus gros problème est probablement avec une condition de concurrence critique dans la logique de transmission, l'UART dans les parties 18Fxx de Microchip, ce qui peut l'amener à transmettre des octets NUL parasites si le code tente de transmettre des données au mauvais moment. La solution de contournement suggérée par Microchip consiste à s'assurer que le code n'essaye pas de charger le registre de transmission de données entre le moment où l'UART commence à envoyer le bit d'arrêt pour un caractère antérieur et le moment où cette transmission est terminée, mais si des interruptions sont jamais désactivé, le code dans un gestionnaire d'interruption de transmission-tampon-vide est généralement gagné "

Bien que je puisse comprendre comment des bogues comme le bogue Microchip UART pourraient se faufiler, le correctif ne devrait pas être difficile: je m'attends à ce que Microchip génère un signal "go" basé sur le "ET" de la transmission non synchronisée "terminée" et "chargé de caractères" "signaux, et a des problèmes si le premier signal change d'état juste après le dernier (ce qui fait que le circuit tampon TX rate une chance de charger les données de caractère sur un cycle donné, mais permet au séquenceur TX de démarrer une nouvelle transmission sur ce cycle) ; même si Microchip ne souhaite pas ajouter de délais de synchronisation aux cas normaux où l'émetteur est vide et un caractère est chargé, ou lorsque l'émetteur devient vide après le chargement d'un caractère, le problème peut être résolu sans affecter la synchronisation dans les deux cas. de ces casen ajoutant trois portes NAND et deux verrous de synchronisation. De nombreuses pièces, cependant, ont été expédiées depuis la publication de ce problème, sans ajouter aucun correctif de ce type.

Cela dépend vraiment de l'entreprise et de la complexité du correctif. Par exemple, consultez cet errata pour le PIC18F23K22. Vous pouvez voir qu'il y avait huit bogues connus qui ont affecté la première révision ("A1") du silicium.

Au moment de cette réponse, ils ont une révision "A2" mise à jour. Sur les huit bugs d'origine, trois d'entre eux ont été corrigés dans cette nouvelle version.

Un autre facteur décisif est la durée de vie de fabrication du produit. Même si un fabricant choisit de ne pas résoudre un problème spécifique dans une pièce existante, il peut toujours "résoudre" le problème en s'assurant que les nouveaux produits n'ont pas les mêmes bogues.

Peut-être qu'ils ont déjà produit (mais pas encore vendu) des milliers ou des millions de circuits intégrés lorsqu'un bug est détecté. Ils ne les jettent pas tous simplement à cause d'un bug.

Je pense que vous pouvez le comparer à l'impression de livres. Les livres sont imprimés en nombre de plusieurs milliers en une seule fois en peu de temps (jours, semaines). Mais ils sont vendus en quelques années ou décennies. Les livres ne sont pas jetés et réimprimés dès qu'une faute de frappe ou autre erreur est détectée. Pour les livres, les feuilles d'errata sont imprimées et remises à l'utilisateur.

Bien entendu, les bugs connus (fautes de frappe, erreurs) seront corrigés dans la prochaine édition.