Blog

Modalità di guasto emergenti: sfide e opportunità di ricerca

Modalita di guasto emergenti sfide e opportunita di ricerca | itkovian

Panoramica

L’affidabilità è essenziale per l’informatica. Tuttavia, con il ridimensionamento dei nodi tecnologici, ci sono state diverse sfide fisiche fondamentali da superare per fornire l’astrazione dell’affidabilità. Una di queste sfide è stata l’emergere di difetti marginali causati da difetti che sono difficili da affrontare esclusivamente utilizzando le migliori pratiche di test e screening di produzione. Per prima cosa inquadriamo la dichiarazione del problema e sottolineiamo l’importanza delle cause alla radice del guasto. Discutiamo quindi i difetti osservati, il ruolo del test e del design per affrontare questo problema e identifichiamo le opportunità di ricerca.

Sfondo

UN colpa è una condizione che causa l’impossibilità di soddisfare una specifica. Un esempio di specifica è il corretto funzionamento dell’hardware di un microprocessore. Ogni difetto ha un causa ultima. Una causa ben nota dei guasti che si verificano in un processore è una particella ad alta energia, come un neutrone o una particella alfa. Un difetto del silicio è un’altra causa principale. Un difetto può essere transitorio, intermittenteO permanente in base alla frequenza con cui compare il guasto ed è strettamente legato alla sua causa principale. Ad esempio, le particelle ad alta energia tendono a produrre guasti transitori, mentre i difetti possono causare guasti intermittenti o permanenti. UN errore è il sintomo di un difetto. Esistono diversi possibili sintomi, che possono essere compresi dalla tassonomia mostrata di seguito, da cui è stato adattato Qui.

Se un errore non viene mai letto o non si accede, si dice che è benigno e non produce un errore. Quando viene letto l’errore, ci sono diversi scenari possibili in base al fatto che il bit abbia un qualche tipo di protezione. Se l’errore viene rilevato e corretto, si dice che il risultato sia a Errore corretto (CE). Una tecnica di protezione di esempio che può fornire questa capacità è un codice di correzione degli errori (ECC). Se viene rilevato un bit ma non è correggibile, si dice che il risultato è a Errore rilevato ma irreversibile (DUE). Ad esempio, la parità può fornire solo il rilevamento. Se l’errore viene letto ma non viene rilevato, il risultato potrebbe essere Corruzione silenziosa dei dati (SDC). Un SDC è il peggior risultato possibile di un guasto, in quanto può avere un impatto arbitrario sulla correttezza del software in esecuzione sull’hardware.

Pertanto, il verificarsi di un CE, DUE o SDC dipende sia dall’errore riscontrato dal bit sia dal tipo di protezione (se presente) per quel bit. Quindi, il ragionamento sugli errori in un processore richiede la comprensione dei tipi di guasti che l’hardware potrebbe riscontrare, che a sua volta dipende dalla causa principale dell’errore.

I moderni microprocessori ad alte prestazioni sono in genere progettati con specifici obiettivi di affidabilità, disponibilità e manutenzione (RAS) che vengono poi tradotti in decisioni di protezione per ogni flop o struttura in cui un errore diventa un CE o un DUE, garantendo al contempo che il rischio SDC sia ridotto al minimo . Sebbene gli obiettivi e la scelta degli schemi di protezione siano specifici dell’implementazione, le migliori pratiche del settore come Fattore di vulnerabilità dell’architettura (AVF) esistono modelli per guidare queste scelte.

L’emergere di difetti causati da difetti

Un obiettivo chiave del progetto RAS è stato quello di far fronte ai guasti transitori indotti dalle particelle (noti anche come « errori soft »). La modellazione AVF è stata sviluppata per tali guasti. Si presume che altre cause alla radice, come i difetti, vengano rilevate da tecniche come il burn-in e il test a livello di wafer, come la scansione, prima della spedizione del silicio ai clienti. Ciò ha consentito alla progettazione RAS di concentrarsi sui guasti che non possono essere eliminati o sufficientemente ridotti attraverso questi altri approcci. Recentemente, Meta E Google ha segnalato la presenza di SDC nella loro flotta, che ha sollevato campanelli d’allarme che potrebbero esserci cause alla radice finora sconosciute per guasti nei processori moderni.

Difetti marginali sono alcune delle cause alla radice di questi difetti. Un difetto marginale può causare un guasto in condizioni specifiche di temperatura, tensione, frequenza, modelli di carico di lavoro, ecc. I difetti marginali tendono a produrre guasti intermittenti. Oltre ai difetti, anche ricerche precedenti lo hanno dimostrato degradazione E affidabilità a vita sono preoccupazioni per le tecnologie di processo in scala e possono indurre guasti sia intermittenti che permanenti durante la vita utile del processore. Pertanto, il raggiungimento dell’affidabilità e della resilienza richiede la conoscenza di molteplici cause alla radice, dei tipi di errori che inducono e degli errori che ne derivano in base a dove si verificano gli errori in un processore.

Il test è importante

Il test è un modo per identificare la presenza di difetti. La conoscenza delle cause alla radice è importante per test efficaci. Ad esempio, consideriamo un tipo di difetto marginale: un piccolo difetto di ritardo (SDD). Un SDD è un difetto che può causare un ritardo inferiore al tempo di ciclo di clock per un determinato nodo di processo: un errore di ritardo. Generazione automatica di modelli di test (ATPG) le tecniche possono essere utilizzate per testare gli errori di ritardo assegnando la priorità ai percorsi con un margine di temporizzazione minimo. ATPG può essere utilizzato per testare altri tipi di difetti utilizzando modelli di guasto rappresentativi appropriati.

Oltre ai progressi nell’ATPG mirati a nuove modalità di difetto, è importante migliorare i metodi utilizzati per accelerare l’attivazione dei guasti dai difetti. I miglioramenti nella valutazione e nell’implementazione della copertura burn-in possono aiutare in questo senso. Infine, oltre ai test di produzione, i test di accettazione presso il cliente saranno uno strumento importante nell’arsenale per rilevare i difetti che potrebbero essere sfuggiti ai test precedenti e qualsiasi potenziale effetto di degradazione che potrebbe verificarsi sul campo.

Sebbene i test siano importanti, i test esaustivi sono impegnativi date le dimensioni dei moderni progetti di processori. Il test per i difetti marginali richiede un’ampia gamma di tensioni, temperature, modelli di carico di lavoro, ecc., che si aggiungono alla sfida complessiva del test. Anche le differenze nell’ambiente e nelle condizioni tra le apparecchiature di test automatizzate (ATE) e le normali piattaforme server rappresentano delle sfide. Ad esempio, i processori moderni utilizzano complessi algoritmi di gestione dell’alimentazione durante l’esecuzione di carichi di lavoro di produzione. Questa interazione di meccanismi di gestione dell’alimentazione, condizioni ambientali e comportamento del carico di lavoro può dar luogo a condizioni specifiche in cui un difetto marginale può indurre un errore che può essere molto difficile da replicare utilizzando tecniche di test basate su scansione su ATE. Pertanto, è improbabile che il test da solo sia la soluzione definitiva per affrontare questi nuovi difetti.

Integrare i test con un design resiliente

Una volta compresi i guasti e le loro cause alla radice, esiste il potenziale per risolverli attraverso una progettazione resiliente. Il miglioramento della progettazione RAS di un processore che è a conoscenza di nuovi errori può anche migliorare l’osservabilità dei test a livello di sistema esistenti, che a sua volta può aiutare a rilevare i difetti durante i test di produzione. Come per i test, la conoscenza delle cause alla radice guida specifiche azioni RAS. Ad esempio, consideriamo una struttura di array (ad esempio, una cache). Se è noto che la maggior parte dei guasti che si verificano in quell’array sono transienti indotti da particelle che incidono su un singolo bit durante la lettura dei dati, un codice di correzione degli errori (ECC) può essere sufficiente per rilevare un errore singolo corretto-doppio errore (SEC-DED) per fornire rimedio effettivo contro tali difetti. Tuttavia, se è noto che la causa principale è a guasto transitorio multi-bit, potrebbe essere necessario un ECC più forte. Se i guasti permanenti sono un problema, possono essere incorporati meccanismi di riparazione.

Esistono tecniche di ridondanza pervasiva per rilevare guasti ovunque all’interno del processore e hanno implementazioni commerciali (ad esempio, core lock-stepping). Tali tecniche tendono a comportare costi generali significativi in ​​termini di prestazioni/potenza e possono essere proibitivi per il mercato dei server più ampio. Tuttavia, è imperativo che l’informatica sia affidabile e che vengano affrontati i rischi posti dai guasti derivanti da difetti marginali. Qui, la storia può essere una guida.

La figura seguente presenta una retrospettiva storica del problema dell’errore soft come sequenza temporale. I cerchi denotano episodi segnalati pubblicamente di errori soft da varie fonti. I dati in figura sono sintetizzati da Qui. Le scatole contengono documenti selezionati sulla modellazione e la mitigazione dei guasti e il loro anno di pubblicazione.

1689599092 366 Modalita di guasto emergenti sfide e opportunita di ricerca | itkovian

Un momento cruciale è stato nei primi anni 2000, quando si sono verificati numerosi incidenti di alto profilo di guasti in sistemi su larga scala e da importanti produttori di processori. Una volta che i guasti sono stati causati alla radice da particelle ad alta energia, c’è stata una forte spinta sia da parte dell’industria che della comunità accademica a esplorare le tecniche di modellazione dei guasti per ragionare su tali guasti e progettare per la resilienza.

Ci sono state due conclusioni chiave da questa ricerca, che ora sono diventate le migliori pratiche del settore:

  • Comprendere la causa principale e le caratteristiche del guasto associate è stato importante perché ha poi aperto la strada ad approcci sistematici e quantitativi alla modellazione del guasto.
  • La protezione mirata delle parti del processore vulnerabili ai guasti consente di progettare l’hardware per un determinato obiettivo di affidabilità.

Opportunità per la ricerca

Ora siamo in un momento storico non dissimile dai primi anni 2000. Abbiamo nuovi difetti, derivanti da nuove cause profonde. I test sono un pilastro fondamentale per combattere questi problemi, ma è necessaria una combinazione di test e RAS per affrontare il problema in modo completo. Sia il test che la RAS devono essere fondati sulle cause alla radice. La resilienza e l’affidabilità devono essere raggiunte, ma non a scapito di prestazioni elevate ed efficienza energetica.

Pertanto, la progettazione resiliente deve essere realizzata in modo ponderato e mirato, con obiettivi quantificabili e i mezzi per misurare se le scelte progettuali effettuate soddisfano tali obiettivi. Per raggiungere questi risultati, riteniamo che sia necessaria la ricerca per sviluppare tecniche sistematiche di modellazione dei guasti pre-silicio. Essere in grado di accertare gli errori di impatto da queste nuove cause alla radice può aiutare sia a migliorare RAS che a testare. È inoltre necessaria la ricerca per esplorare come combinare efficacemente RAS e testare ed esplorare lo spazio delle tecniche di resilienza che possono aprire la strada a un’elaborazione affidabile ed efficiente su larga scala.

Riguardo agli Autori: Sudhanva Gurumurthi è Fellow presso AMD, dove guida lo sviluppo avanzato di RAS. Vilas Sridharan è AMD Senior Fellow e guida il team RAS Architecture. Sankar Gurumurthy è un direttore e guida l’iniziativa AMD FailSafe, coprendo RAS e test.

© 2023 Advanced Micro Devices, Inc. Tutti i diritti riservati. AMD, il logo AMD Arrow e le relative combinazioni sono marchi di Advanced Micro Devices, Inc. Altri nomi di prodotti utilizzati in questa pubblicazione sono solo a scopo identificativo e possono essere marchi delle rispettive società.

Dichiarazione di non responsabilità AMD

Le informazioni presentate in questo documento sono solo a scopo informativo e possono contenere imprecisioni tecniche, omissioni ed errori tipografici. Le informazioni contenute nel presente documento sono soggette a modifiche e possono essere rese imprecise per molte ragioni, tra cui, a titolo esemplificativo ma non esaustivo, modifiche al prodotto e alla roadmap, modifiche alla versione dei componenti e della scheda madre, nuovi modelli e/o versioni del prodotto, differenze di prodotto tra diversi produttori, modifiche al software, Flash del BIOS, aggiornamenti del firmware o simili. Qualsiasi sistema informatico presenta rischi di vulnerabilità della sicurezza che non possono essere completamente prevenuti o mitigati. AMD non si assume alcun obbligo di aggiornare o altrimenti correggere o rivedere queste informazioni. Tuttavia, AMD si riserva il diritto di rivedere queste informazioni e di apportare modifiche di volta in volta al contenuto del presente documento senza obbligo da parte di AMD di notificare a terzi tali revisioni o modifiche.

QUESTE INFORMAZIONI SONO FORNITE « COSÌ COME SONO ». AMD NON FORNISCE ALCUNA DICHIARAZIONE O GARANZIA IN RELAZIONE AI CONTENUTI DEL PRESENTE CONTENUTO E NON SI ASSUME ALCUNA RESPONSABILITÀ PER EVENTUALI IMPRECISIONI, ERRORI O OMISSIONI CHE POSSONO APPARIRE IN QUESTE INFORMAZIONI. AMD NEGA SPECIFICAMENTE QUALSIASI GARANZIA IMPLICITA DI NON VIOLAZIONE, COMMERCIABILITÀ O IDONEITÀ PER QUALSIASI SCOPO PARTICOLARE. IN NESSUN CASO AMD SARÀ RESPONSABILE NEI CONFRONTI DI QUALSIASI PERSONA PER AFFIDABILITÀ, DANNI DIRETTI, INDIRETTI, SPECIALI O ALTRI DANNI CONSEQUENZIALI DERIVANTI DALL’UTILIZZO DI QUALSIASI INFORMAZIONE QUI CONTENUTA, ANCHE SE AMD È ESPRESSAMENTE AVVISATA DELLA POSSIBILITÀ DI TALI DANNI.

Disclaimer: Questi post sono scritti da singoli contributori per condividere i propri pensieri sul blog Computer Architecture Today a beneficio della comunità. Qualsiasi punto di vista o opinione rappresentata in questo blog è personale, appartiene esclusivamente all’autore del blog e non rappresenta quelli di ACM SIGARCH o della sua organizzazione madre, ACM.

Hi, I’m Samuel