Bug di silicio, fogli di errata

In molti (quasi tutti,) microcontrollori che ho usato negli ultimi anni, là dove a volte alcuni bug a livello di silicio, e i produttori forniscono agli ingegneri i fogli errata, descrivendo quale comportamento inaspettato possono affrontare.

Perché non risolvono mai questi "bug"? Poiché il prodotto è ancora prodotto e, nella maggior parte dei casi, la risoluzione del problema non influisce sulle implementazioni precedenti, perché non lo revisionano? In molti casi il prodotto può essere stabilizzato, la maggior parte dei bug potrebbe essere stata trovata e potrebbe avere una parte significativa della sua durata di vita del prodotto.

È così difficile (tecnicamente)? Costoso?

I bug critici vengono corretti. Di solito vengono riparati prima che il prodotto entri in produzione. A meno che tu non stia usando i primi campioni, potresti non vedere mai i peggiori bug.

La correzione di bug è difficile e costosa. Non sta cambiando solo una riga di codice RTL. Se lo facessi, dovresti risincronizzare, ripetere il layout fisico, modificare il layout per risolvere eventuali problemi di temporizzazione, acquistare un nuovo set di maschere, produrre nuovi wafer, testare i wafer (normalmente), convalidare le nuove correzioni e eventualmente caratterizzare o qualificare nuovamente il prodotto. Questo richiede mesi e costa una quantità di denaro angosciante. Per questo motivo, proviamo a correggere i bug direttamente nel layout (preferibilmente su un singolo strato di metallo). Questo è più veloce ed economico rispetto a ricominciare dalla sintesi RTL, ma non è ancora buono.

Se stiamo risolvendo un bug critico, perché non correggere anche tutti gli altri bug? Ancora una volta, ciò richiede tempo - tempo per capire e attuare una correzione, tempo per rieseguire i test di verifica del progetto. Quel tempo significa che ci vorrà più tempo per commercializzare il prossimo prodotto. E nel frattempo, quasi sicuramente troverai più bug nel tuo prodotto attuale se guardi abbastanza bene. È una battaglia persa. Risolvere i bug è ancora più difficile su un prodotto che è stato rilasciato da molto tempo, poiché le persone devono tuffarsi nel vecchio design per capire cosa sta succedendo. Come afferma Null, i clienti potrebbero dover riqualificare il prodotto nel proprio sistema. Se il tuo prodotto è ancora in fase di sviluppo, ritardare il rilascio della produzione può far scivolare le pianificazioni dei clienti, il che rende i clienti molto scontenti.

Normalmente, i bug che vengono lasciati si verificano solo in strane configurazioni, causano problemi molto lievi, hanno soluzioni alternative facili o tutto quanto sopra. Non sono abbastanza male da valere la pena. E se riutilizzi un modulo hardware sul prodotto successivo, i tuoi clienti esistenti avranno già la soluzione alternativa nel loro software.

Le toolchain software sono un altro fattore. Se un modulo rimane abbastanza a lungo, la tua toolchain potrebbe cambiare abbastanza da rifare i vecchi test di validazione diventa un grande progetto in sé. E probabilmente non puoi semplicemente caricare i vecchi strumenti, perché non stai più pagando per la licenza del sito. Ma finché non si modifica il modulo, è possibile continuare a copiarlo e incollarlo in nuovi MCU.

Anche il software rappresenta un problema per il cliente. Se il tuo bugfix rompe in qualche modo la retrocompatibilità, tutti i tuoi clienti dovranno aggiornare il loro codice, per il quale potrebbero non avere più gli strumenti.

Come qualcuno che lavora nello sviluppo di microcontrollori, posso dirti che ci piacerebbe tutti correggere ogni bug. Ma provare a farlo ritarderebbe lo sviluppo in modo imprevedibile, infastidire i clienti, costare un sacco di soldi e, alla fine, probabilmente avremmo comunque fallito.

È generalmente a causa delle spese.

C'è sempre il rischio di rompere qualcos'altro quando si "corregge" un bug. Per questo motivo, il produttore deve in genere riqualificare e ricodificare completamente il dispositivo solo per assicurarsi che la "correzione" non abbia introdotto un bug diverso (e forse anche più indesiderabile). Ciò significa denaro e tempo (che, per il produttore, è anche denaro). Significa anche che il produttore ha dipendenti che riparano un prodotto esistente invece di svilupparne uno nuovo.

Su una nota correlata, a volte i clienti richiedono anche la riqualificazione del dispositivo fisso nei loro prodotti per assicurarsi che la correzione dei bug non rompa qualcosa nel loro sistema . Ciò costa tempo e denaro per loro, e i clienti potrebbero non essere disposti ad accettare quei costi - richiederanno comunque la versione "buggy".

In alcuni casi, ovviamente, il bug è davvero tecnicamente difficile da risolvere. In tal caso, è ancora più costoso ripararlo.

Se un importante acquirente di una parte lo utilizza in un progetto che ha certificato, ad esempio per l'uso a bordo di un aereo o di una nave spaziale, qualsiasi modifica a uno qualsiasi dei componenti utilizzati nel progetto richiederà una nuova certificazione del progetto nel suo insieme. Se il design funziona in modo adeguato attorno a tutti i bug nel silicio, la revisione del silicio può richiedere che il cliente debba ripetere tutti i test di qualificazione per la sua scheda, mantenendo una fornitura di parti "non fisse" e "fisse", o semplicemente continuando a produrre il vecchio design. I venditori di chip non pubblicano i loro elenchi di acquirenti, ma in alcuni casi un singolo cliente può rappresentare una frazione sufficientemente grande della domanda di un determinato chip che la società potrebbe essere detestata a fare qualsiasi cosa per arrecare disturbo al cliente.

Detto questo, ci sono alcuni errata di silicio che continuano ad apparire nelle generazioni successive di parti, alcune delle quali mancano soluzioni alternative decenti. Probabilmente la mia più grande peeve è con una condizione di competizione nella logica di trasmissione dell'UART nelle parti 18Fxx di Microchip che può indurlo a trasmettere byte NUL spuri se il codice tenta di trasmettere dati nel momento sbagliato. La soluzione suggerita da Microchip consiste nell'avere il codice per garantire che non tenti di caricare il registro di trasmissione dei dati tra il tempo in cui l'UART inizia a inviare il bit di stop per un carattere precedente e il tempo in cui tale trasmissione è completa, ma se gli interrupt sono mai disabilitato, il codice in un gestore di interrupt di trasmissione-buffer-vuoto generalmente vince '

Mentre riesco a capire come bug come il microchip UART potrebbero insinuarsi, la correzione non dovrebbe essere difficile: mi aspetto che Microchip generi un segnale "go" basato su "AND" di "trasmissione completata" non sincronizzata e "carattere caricato "segnala e ha problemi se il primo segnale cambia stato subito dopo il secondo (facendo perdere al circuito del buffer TX la possibilità di caricare i dati dei caratteri su un determinato ciclo, ma consentendo al sequencer TX di avviare una nuova trasmissione su quel ciclo) ; anche se Microchip non desidera aggiungere ritardi di sincronizzazione ai normali casi in cui il trasmettitore è vuoto e un carattere viene caricato o in cui il trasmettitore si svuota dopo che un carattere è stato caricato, il problema potrebbe essere risolto senza influire sui tempi in di quei casiaggiungendo tre porte NAND e due chiavistelli di sincronizzazione. Numerose parti, tuttavia, sono state spedite da quando è stato pubblicato il problema, senza aggiungere alcuna correzione.

Dipende molto dall'azienda e dalla complessità della correzione. Ad esempio, vedere questo errata per PIC18F23K22. Si può vedere che c'erano otto bug noti che interessavano la prima revisione ("A1") del silicio.

Al momento di questa risposta, hanno una revisione "A2" aggiornata. Degli otto bug originali, tre di questi sono stati corretti in questo nuovo rev.

Un altro fattore decisivo è la durata di fabbricazione del prodotto. Anche se un produttore sceglie di non risolvere un problema specifico in una parte esistente, può comunque "risolvere" il problema assicurandosi che i nuovi prodotti non abbiano gli stessi bug.

Forse hanno già prodotto (ma non ancora venduto) migliaia o milioni di circuiti integrati quando viene rilevato un bug. Non li buttano via tutti solo a causa di un bug.

Penso che tu possa confrontarlo con la stampa di libri. I libri vengono stampati in numero di molte migliaia in una sola volta in breve tempo (giorni, settimane). Ma sono venduti entro anni o decenni. I libri non vengono eliminati e ristampati non appena viene trovato un errore di battitura o altro errore. Anche per i libri i fogli errata vengono stampati e consegnati all'utente.

Di certo i bug noti (errori di battitura, errori) saranno corretti nella prossima edizione.