Elemente ale Fiabilitatii Microprocesoarelor
Cuprins
Capitolul 1. Introducere………………………………………………………………pag 2
Capitolul 2. Fiabilitate………………………………………………………………..pag 4
2.1 Definiție……………………………………………………………………………..pag 4
2.2 Redundanță………………………………………….……………………………..pag 4
2.3 Erori tranzitate și erori permanente…………………………….……………….pag 4
2.4 Costul fiabilității/sisteme echilibrate ……………………………………………..pag 5
Capitolul 3. Creșterea fiabilității ……………………………………………..pag 6
3.1 Evitarea defectelor……………………………………………………………………….pag 6
3.2 Scheme de votare…………………………………………………………………………pag 7
Capitolul 4. Fiabilitatea programelor(software)………………………….pag 7
4.1 Biți “putreziți”……………………………………………………………………………..pag 8
4.2 Întinerirea programelor…………………………………………………………………pag 9
4.3 Verificarea formală………………………………………………………………………pag 10
Capitolul 5 Expunerea defectelor…………………………………………………pag 11
5.1 Teramac…………………………………………………………………………………….pag 12
5.2 Hardware reconfigurabil………………………………………………………………pag 12
5.3 Fiabilitatea sistemului Teramac……………………………………………………..pag 12
Introducere
În acest text voi prezenta arhitectura sistemelor de calcul dintr-un singur punct de vedere, și anume cel al fiabilității.
Principalul subiect al teoriei fiabilității (reliability theory) este construirea sistemelor fiabile din componente nefiabile. Dacă un sistem ar funcționa numai atunci toate componentele sale ar fi funcționale, ar fi virtual imposibil de construit un sistem complex, pentru că fiabilitatea ar descrește exponențial cu numărul de componente.
Principala unealtă folosită în construirea sistemelor complexe este abstracția. Un sistem este construit pe nivele; nivelul B este alcătuit din componente de nivel A. La rîndul lor, componente de nivel B sunt folosite ca și cum ar fi atomice, indivizibile, pentru a construi nivelul C, și așa mai departe. Acest proces este inspirat din matematică, unde lemele și teoremele sunt folosite drept componente elementare în demonstrațiile altor leme și teoreme. În acest text vom privi alcătuirea unor nivele din arhitectura sistemelor de calcul din punctul de vedere al fiabilității pe care o oferă nivelelor superioare. Astfel putem distinge:
Nivele care măresc fiabilitatea, construind un tot mai fiabil din componente mai puțin fiabile. Acest lucru este obținut folosind redundanță în stocarea sau calculul informației. Acest tip de nivel este cel mai adesea folosit în construcția calculatoarelor contemporane.
Nivele care expun lipsa de fiabilitate nivelelor superioare, lăsîndu-le pe acestea să rezolve imperfecțiunile. Nivelele superioare au adesea informații suplimentare despre cerințele reale de fiabilitate ale sistemului, și ca atare pot construi fiabilitate pe măsura necesităților.
În fine, anumite nivele partiționează resursele în parți oarecum independente, izolate una de alta. Partiționarea are drept efect izolarea defectelor (fault containment / fault isolation), astfel încît o defecțiune într-o parte să nu afecteze celelalte părți. În calculatoare această tehnică este folosită în sistemele de operare și clustere-le de calculatoare.
La ora actuală circuitele integrate pe scară largă (Very Large Scale Integrated circuits, VLSI) au ajuns la nivele incredibile de fiabilitate. Ca atare arhitecții calculatoarelor în general privesc nivelul hardware ca fiind „perfect'' și folosesc această abstracție foarte convenabilă în proiectarea nivelelor superioare. Anumite clase de aplicații însă au nevoie de o fiabilitate foarte ridicată (de exemplu, controlul de trafic aerian sau supervizarea centralelor nucleare). În astfel de sisteme critice arhitecții sistemelor de calcul iau în considerare și posibilitatea defectelor hardware, pe care le tratează în software.
Miniaturizarea continuă a circuitelor integrate va duce la schimbări în această stare de fapt; e de așteptat ca în viitor circuitele să conțină din ce în ce mai multe defecțiuni și să fie din ce în ce mai sensibile la fluctuații termodinamice și particule de înaltă energie din radiația cosmică sau chiar din degradarea radioactivă a circuitului integrat! Astfel de schimbări vor cere probabil o regîndire completă a arhitecturii sistemelor de calcul.
Fiabilitate
Definiție
Fiabilitatea unui obiect (o componentă sau un sistem) este o funcție de timp F(t), definită ca probabilitatea ca, în condiții de mediu specificate, obiectul să funcționeze adecvat în intervalul de timp [0,t).
Putem face cîteva observații foarte importante legate de această definiție:
Fiabilitatea este o probabilitate, cuprinsă între 0 și 1.
Nu există sisteme perfect fiabile, pentru care pentru care F(t) = 1 dacă t > 0. Putem însă vorbi de sisteme „destul de fiabile'', atunci cînd avem în minte anumite condiții de utilizare și constrîngeri bugetare pentru implementarea sistemului.
Nu putem defini fiabilitatea fără a specifica mediul în care sistemul operează. Un calculator care merge foarte bine pe birou nu este neapărat potrivit pe un satelit.
Redundanță
Ingredientul cel mai folosit pentru a construi sisteme fiabile este redundanța. Putem distinge două genuri de redundanță, spațială și temporală:
Redundanța spațială
folosește mai multe componente decît strict necesar pentru a implementa un anumit sistem. Resursele adiționale fac calcule suplimentare și rezultatele sunt comparate între ele. În general, cu cît redundanța unui sistem este mai mare, cu atît poate detecta sau tolera mai multe erori.
Redundanța temporală
constă în folosirea aceluiași dispozitiv pentru a calcula același lucru în mod repetat, după care rezultatele sunt comparate între ele.
Erori tranziente și erori permanente
Putem clasifica defectele în două mari categorii:
Erori tranziente
sunt erori care se manifestă printr-o malfuncție temporară a unei componente, dar nu prin defectarea ei definitivă. În sistemele de calcul contemporane, cea mai mare parte a erorilor sunt tranziente.
Erori permanente:
se produc la un moment dat și persistă pînă cînd sistemul este reparat. În această categorie includem și defectele din fabricație.
Redundanța temporală poate fi folosită numai pentru a tolera defecte tranziente. Pentru a tolera efecte permanente trebuie să avem o formă de redundanță spațială.
Costul fiabilității; sisteme echilibrate
Cînd proiectăm un sistem complex este foarte important să „echilibrăm'' fiabilitatea părților. De exemplu, dacă memoria unui sistem are o fiabilitate mult mai mare decît procesorul, atunci sistemul se va defecta cel mai adesea cu probleme de procesor. Faptul că memoria este de foarte bună calitate nu ne ajută cu nimic; dimpotrivă, probabil că am plătit un preț mai mare pentru memorie decît ar fi fost strict necesar. În general, o componentă este „destul de bună'' dacă nu are cea mai mare probabilitate de defectare.
Întotdeauna cînd discutăm despre fiabilitate trebuie să socotim nu numai costul componentelor fiabile, ci și costul întreținerii sistemului. Cît pierdem pe oră atunci cînd sistemul nu funcționează? Dacă cumpărăm componente foarte fiabile plătim prea mult pentru construcția sistemului, dar dacă cumpărăm componente cu fiabilitate prea redusă, ne va costa prea mult întreținerea sistemului. Numai contextul poate dicta cît de fiabil trebuie să fie un sistem.
Creșterea fiabilității
Evitarea defectelor
Evitarea defectelor este o metodologie idealizată, care presupune că toate componentele sunt perfecte. Pentru că hardware-ul de astăzi are o calitate excepțională, nivelul software în calculatoarele obișnuite adoptă o astfel de viziune idealizată. Programatorii presupun că sistemul pe care se rulează programele lor este lipsit de defecțiuni.
Fiabilitatea excelentă a dispozitivelor hardware este obținută printr-o combinație de tehnici, cum ar fi felurite forme de redundanță, proiectare și fabricație cu precizie foarte ridicată, și o fază agresivă de testare și „ardere'' (burn-in).
Empiric s-a observat că sistemele tind să aibă o mortalitate care urmărește o curbă numită albie, ilustrată în figura 1: sistemele foarte tinere și cele foarte uzate se strică mult des decît sistemele „mature''. „Burn-in'' este o fază de testare care folosește componentele pînă devin mature; în acest fel, componentele cu mortalitate infantilă ridicată sunt eliminate.
În plus fabricanții proiectează și testează sisteme de calcul în condiții mai nefavorabile decît cele specificate. De exemplu, pe acest fapt se bazează cei care fac „overclocking'': specificațiile unui procesor indică frecvența de ceas la care acesta poate opera. Dar în mod frecvent un procesor cu specificație de ceas de 1Ghz poate opera la 1.2Ghz, datorită marginilor de toleranță din fabricație.
Metoda evitării defectelor este cu adevărat extremă.
Scheme de votare
O metodă foarte simplă dar scumpă de a tolera erori este de a multiplica fiecare componentă. De exemplu, dacă duplicăm întreg sistemul de calcul, apariția unui defect poate fi detectată comparînd rezultatele celor două subsisteme.
Prima schemă de toleranță a defectelor a fost propusă de John von Neumann în 1956 și se numește „redundanță modulară triplă'' (Triple Modular Redundancy). În această schemă trei module fac aceeași operație și un modul de „vot'' alege rezultatul majoritar. Dacă fiecare componentă are o fiabilitate de peste 50%, fiabilitatea ansamblului este mai mare decît a componentelor. Există și scheme în care sistemul de votare este replicat, pentru a nu depinde de o singură componentă.
Un astfel de sistem de votare este folosit în calculatoarele care controlează naveta spațială: sistemul este compus din cinci calculatoare, din care patru fac aceleași calcule și al cincilea este folosit pentru operațiuni ne-critice. Rezultatele celor patru calculatoare se duc pînă la sistemele controlate (motoare), care calculează local rezultatul votului. În plus, fiecare calculator compară rezultatele cu celelalte trei; cînd unul dintre ele dă rezultate diferite este scos din funcțiune.
Dacă două calculatoare se defectează, sistemul intră într-un mod de funcționare în care rezultatele sunt comparate și recalculate cînd diferă. Al cincilea calculator conține un sistem de control complet separat, dezvoltat de altă companie, care intră în funcțiune cînd un bug identic este detectat în celelalte patru programe.
Fiabilitatea programelor
Ne-am putea aștepta ca, spre deosebire de hardware, software-ul să nu aibă nici un fel de probleme de fiabilitate: în definitiv programele nu se uzează, și sunt executate într-un mediu foarte specializat; în plus, programele sunt obiecte deterministe, deci ar trebui să se comporte de fiecare dată în același fel cînd procesează aceleași date de intrare. Cu toate acestea, de fapt fiabilitatea programelor este mult mai scăzută decît a sistemelor hardware; este potrivit să modelăm deci programele ca sisteme cu fiabilitate imperfectă.
Cea mai importantă cauză a malfuncțiilor programelor sunt bug-urile, adică implementări incorecte. Chiar și programatori foarte pricepuți produc programe cu defecte. Complexitatea componentelor software este pur și simplu prea mare pentru a putea fi stăpînită de către oameni, și cu tot progresul în tehnici de programare, cum ar fi descompunerea programelor în module mici, folosirea unor limbaje de programare evoluate și a unor scule complexe pentru dezvoltarea, testarea și analiza programelor, rezultatele sunt încă foarte departe de perfecțiune, și productivitatea programatorilor nu a crescut substanțial în ultimele două decenii.
Cel mai adesea problemele rezolvate în software sunt atît de complicate încît nici nu pot fi specificate în mod precis. În consecință programatorii întîlnesc tot felul de incertitudini cînd încearcă să implementeze soluțiile. O cauză fundamentală a lipsei de fiabilitate a programelor este deci specificația incompletă și imprecisă.
Cele mai insidioase defecțiuni software se manifestă numai cu ocazia unor anumite combinații de valori pentru datele de intrare sau pentru anumite succesiuni de evenimente externe, care nu au fost prevăzute de programator. Asemenea combinații apar cu probabilitate foarte mică în timpul procedurilor normale de testare, deci adesea supraviețuiesc pînă în faza operațională.
4.1Biți „putrezi''
A vedea programele software ca pe o entitate monolitică este o aproximare a realității: un program trece prin nenumărate revizii și îmbunătățiri. Versiunile noi sunt construite pe scheletul celor vechi, reparînd defecțiunile descoperite și adăugînd noi funcționalități. Cu toate acestea, procesul reparării defecțiunilor introduce adesea noi defecțiuni, pentru că efectele unei reparații au uneori consecințe nebănuite.
Uluitoarea creștere a performanței hardware-ului este o motivație constantă pentru reînnoirea sistemelor software. Pe măsură ce dispozitivele hardware devin mai ieftine și mai compacte, ele pot fi integrate în dispozitive electronice mai „deștepte''. Toate aceste noi dispozitive au nevoie de nou software care să le manipuleze. Pe măsură ce costul dispozitivelor de stocare a informației scade, din ce în ce mai complexe și bogate tipuri de informație pot fi stocate și prelucrate.
Un fenomen legat de acest ciclu permanent de înnoiri este „putrezirea biților'' (bit rot). Acest fenomen se manifestă pe două planuri: datele stocate cu mult timp în urmă nu mai pot fi folosite în noile sisteme de calcul, pentru că dispozitivele periferice învechite nu mai sunt suportate de fabricanți, și programe vechi, care mergeau foarte bine, încep să manifeste erori. „Boala'' programelor este legată de mediul în care programele se execută, și care este în continuă schimbare. De exemplu, multe programe vechi făceau anumite presupuneri despre cît de mari vor fi seturile de date pe care le vor prelucra.
De exemplu, auzim adesea despre dificultatea de a transporta programe de la procesoare pe 32 de biți la procesoare pe 64 de biți. Din moment ce orice valoare pe 32 de biți se poate reprezenta exact atunci cînd folosim 64 de biți, teoretic nu ar trebui să fie nici o problemă, și vechile programe ar trebui să funcționeze corect. În realitate multe programe depind în feluri subtile de precizia datelor pe care le manipulează. Cînd un astfel de program este mutat pe o platformă nouă toate aceste dependințe se transformă în bug-uri.
Întinerirea programelor
Diferența fundamentală între hardware și software este că un program poate avea o stare internă arbitrar de complicată. În general, dispozitivele hardware pot fi aproximate ca fiind automate finite (adică spațiul stărilor în care se pot afla, chiar dacă este foarte mare, este totuși finit). Chiar și cele mai simple programe au un spațiu de stări infinit, mai exact, nu putem pune nici o limită arbitrară dimensiunii spațiului lor.
Această diferență este foarte importantă și din punct de vedere teoretic: foarte multe proprietăți interesante ale automatelor finite sunt decidabile, adică se pot scrie algoritmi care, atunci cînd primesc descrierea unui automat finit, pot răspunde în mod exact la întrebări legate de orice evoluție viitoare a automatului. Din păcate, aceleași întrebări pentru un sistem cu stare infinită sunt adesea nedecidabile. Într-adevăr, matematicienii au arătat în anii '30 că foarte multe dintre proprietățile unui sistem software în general nu pot fi calculate de un alt sistem software.
O consecință practică a dimensiunii infinite a spațiului de stări al programelor este că, pe măsură ce un program se execută mai mult timp, cu atît mai complicată poate deveni starea sa internă. Dacă un program nu își întrerupe execuția, chiar dacă va primi aceleași date la intrare, ar putea calcula un răspuns diferit. Un bug în program poate corupe starea internă, dar efectele acestei stricăciuni pot deveni vizibile mult mai tîrziu în execuția programului, cînd programul ia o decizie bazată pe elementele de stare incorecte. Un tip faimos de problemă, în mod normal benignă, asociată cu programele care se execută un timp îndelungat, este scurgerea de memorie (memory leak).
Adesea programele alocă spațiu temporar de memorie, pe care îl eliberează după ce au terminat calculele care aveau nevoie de el. Dacă programatorul uită să elibereze această memorie se spune că memoria se scurge (leak). Aceasta este o eroare frecvent întîlnită în programare, relativ greu de descoperit. În mod normal o astfel de eroare nu afectează corectitudinea programului: rezultatele produse la final sunt corecte. Cînd programul își termină execuția, sistemul de operare recuperează automat memoria scursă. În cazul programelor care se execută timp îndelungat, cum ar fi sistemele de operare sau servere de web, dacă o scurgere se întîlnește în interiorul unei bucle, cu timpul memoria pierdută va crește pînă cînd toată memoria sistemului este pierdută. În astfel de cazuri de obicei sistemul își încetează execuția sau funcționarea sa devine extrem de lentă, din cauză că resursele rămase sunt insuficiente.
Utilizatorii sistemului de operare Windows de la Microsoft au descoperit și o soluție pentru această problemă: reboot-area calculatorului. Numele științific pentru această soluție este „reîntinerirea programelor'' (software rejuvenation). Reîntinerirea este cauzată de repornirea periodică a programelor. Repornirea cauzează inițializarea stării interne la o aceeași valoare inițială. Tehnica aceasta este aplicabilă numai dacă starea internă a programului nu este importantă și poate fi pierdută; altfel, întinerirea trebuie să fie combinată cu „checkpoint''-uri. Un checkpoint salvează informația importantă pe un mediu de memorie persistent, și o restaurează după ce programul este repornit.
Reîntinerirea se aplică cu precădere programelor de tip server, care execută tot timpul o buclă, acceptînd cereri de la clienți și răspunzîndu-le. Multe servere sunt lipsite de stare (stateless), adică nu păstrează nici un fel de informații despre o tranzacție cu un client după ce tranzacția s-a consumat. Reîntinerirea este eficace dacă costul repornirilor periodice este mai redus decît costul repornirii după o cădere catastrofică, care poate să implice o procedură sofisticată de recuperare a datelor pierdute. Reîntinerirea este de asemenea folosită cu succes cînd serverele care oferă serviciul au rezerve, astfel încît servere de rezervă pot răspunde clienților în timp ce altele se reinițializează.
Verificare formală
Verificarea formală este un nume generic pentru o serie întreagă de tehnici sofisticate care certifică corectitudinea, mai ales a sistemelor hardware, dar în ultima vreme și a unor sisteme software. Verificarea formală se ocupă de descoperirea și eliminarea bug-urilor, și în acest sens este o tehnică de creștere a fiabilității programelor.
Cheia metodelor de verificare formală este specificarea foarte precisă a comportării componentelor sistemului de analizat (folosind formule matematice) și verificarea automată a proprietăților sistemului în întregime. Dacă știm cum este construit sistemul, și dacă știm comportarea fiecăreia din componente, putem raționa despre comportarea ansamblului. Raționamentele pot fi făcute foarte precise folosind diferite variante de logici matematice. Fiecare raționament este o serie de derivări, în care din fapte știute ca fiind adevărate deducem alte adevăruri. Verificarea formală studiază aceste derivări, și verifică faptul că sunt corecte.
Două aspecte fac verificarea formală o tehnică foarte puternică:(1) calculele minuțioase sunt efectuate de către calculatoare, a căror atenție nu obosește niciodată, (2) certitudinea nu vine din faptul că demonstrăm ceva, ci din faptul că putem verifica dacă demonstrația este corectă! A verifica corectitudinea unui rezultat este mult mai simplu decît a demonstra rezultatul însuși. Acest fapt este extrem de folositor în contextul verificării formale, în care programul care face demonstrațiile este extrem de complicat, și ca atare poate conține erori (ca orice alt program complex) și deci genera demonstrații eronate. Un program care verifică dacă o demonstrație este corectă însă este mult mai simplu, și ca atare ne oferă mai multă încredere.
Expunerea defectelor
În această secțiune voi discuta o metodă complet diferită, folosită cu mult succes în construcția a două sisteme complexe. Această tehnică pleacă de la asumpția că nivelul inferior este inerent nefiabil, și că în loc de a consuma resurse pentru a-i mări fiabilitatea, e preferabil să expunem lipsa sa de fiabilitate nivelelor superioare.
Raționamentul din spatele acestei decizii aparent paradoxale se bazează pe mai multe argumente:
Costul fiabilității poate fi prea mare: dacă fiecare nivel introduce un cost suplimentar pentru a oferi fiabilitate, costul total al nivelelor suprapuse crește exponențial cu numărul de nivele. Pentru anumite situații acest cost poate deveni prohibitiv.
Nivelele superioare au propriile lor scheme de toleranță la defecte. Dacă schemele nivelelor superioare sunt suficient de eficace, ele pot tolera și defecțiunile nivelelor inferioare. De exemplu, folosind coduri corectoare de erori foarte eficace între două noduri terminale într-o rețea de comunicații poate face nenecesară transmisiunea fiabilă pe fiecare segment al rețelei.
În unele cazuri, nivelele superioare nu au nevoie decît de o formă redusă de fiabilitate, și nu de una perfectă. De exemplu, în unele tipuri de aplicații interactive, cum ar fi telefonia, e preferabil ca datele să vină repede și distorsionate decît să fie livrate cu întîrziere și impecabile. Date eronate cauzează mici zgomote la recepție, care sunt tolerate de către urechea umană; sosirea cu întîrziere a semnalului sonor este însă foarte puțin folositoare pentru a crea iluzia unei conversații interactive, și este mult mai perceptibilă.
Teramac
Acest calculator este construit din componente defecte: mai mult de 70% din circuitele sale componente au o malfuncție oarecare. Cu toate acestea, sistemul funcționează minunat și poate efectua calcule extrem de performante.
Să observăm că arhitectura Teramac tolerează numai defecțiuni permanente, care sunt prezente încă de la fabricație. Componentele Teramac sunt circuite hardware de un tip anume, numit hardware reconfigurabil.
Hardware reconfigurabil
Într-o primă aproximație, circuitele digitale obișnuite sunt compuse din elemente computaționale simple, numite porți logice, conectate între ele prin sîrme. Porțile logice sunt construite din tranzistori. Fiecare poartă logică face calcule pe mai multe valori de 1 bit. Porțile logice sunt universale, în sensul că orice proces calcul poate fi exprimat în termeni de operații ale porților logice.
În hardware-ul reconfigurabil porțile logice nu au o funcționalitate fixată, iar sîrmele formează o grilă. Fiecare poartă este configurabilă, adică poate fi forțată să efectueze orice operație logică. La fiecare intersecție de sîrme se află un mic comutator configurabil, care poate fi de asemenea programat să conecteze sîrmele. Configurarea porților și a sîrmelor se face prin semnale electrice. Fiecare poartă și fiecare comutator are o mică memorie asociată, în care-și stochează configurația. Pentru că schimbînd conținutul acestor memorii putem schimba funcționalitatea hardware-ului, circuitele acestea se numesc „reconfigurabile''.
Hardware-ul reconfigurabil este echivalent cu cel obișnuit, în sensul că orice circuit poate fi implementat folosind ambele tehnologii. Hardware-ul reconfigurabil tinde însă să fie mai ineficient: memoriile și porțile configurabile ocupă mult mai mult loc decît porțile obișnuite. Pe de altă parte, semnalele electrice care traversează doar sîrme într-un circuit obișnuit trebuie să treacă printr-o serie de comutatoare în hardware-ul reconfigurabil, ceea ce face circuitele mai lente. Un factor de 10 diferență în viteză și densitate este de așteptat între hardware obișnuit și cel configurabil de aceeași generație.
Pentru a programa un circuit reconfigurabil cu funcțiunea unui circuit obișnuit, trebuie să asociem fiecare poartă din circuit cu o poartă configurabilă; acest proces se numește „plasare''; de asemenea, fiecare sîrmă trebuie asociată cu succesiuni de segmente legate prin comutatoare, în procesul de „rutare''.
Fiabilitatea sistemului Teramac
Calitatea circuitelor reconfigurabile exploatată de Teramac pentru a obține fiabilitate este faptul că porțile logice configurabile sunt esențialmente interschimbabile. Cercetătorii proiectului Teramac au dezvoltat un program de plasare care folosește o hartă de defecte ale circuitelor reconfigurabile. Această sculă ocolește porțiunile inutilizabile și rutează conexiunile în jurul defectelor, exploatînd doar porțiunile funcționale ale fiecărui circuit. Cercetătorii au creat și o serie de scule care descoperă și cataloghează defectele. Sculele acestea folosesc chiar programabilitatea circuitelor pentru a le configura ca dispozitive care se auto-testează. Fiecare porțiune din fiecare circuit este programată să efectueze calcule simple și să verifice corectitudinea rezultatelor. Micile programe de test sunt „plimbate'' pe suprafața circuitului, acoperind toate porțile logice. Proiectarea unor programe de auto-testare este o sarcină mai complicată decît ar putea părea la prima vedere. Programele trebuie să descopere o mulțime de defecte posibile și trebuie să nu poată fi păcălite de defecțiuni (de exemplu, dacă chiar partea care compară rezultatele cu cele corecte este defectă). Programele de testare aplică în mod repetat calcule care amestecă toți biții; astfel, apariția unei singure erori se va propaga rapid la toți biții din rezultat, fiind ușor de depistat.
Proiectul Teramac a avut un succes enorm, apărînd chiar pe prima pagină a unor ziare de mare tiraj. Principala sa contribuție a constat în a demonstra că defectele din hardware pot fi expuse nivelelor superioare, și pot fi tratate în întregime în software, fără ca costul plătit în performanță să fie prohibitiv. Această metodologie este o schimbare completă de paradigmă în arhitectura calculatoarelor, care probabil va avea din ce în ce mai multe aplicații în viitor.
[Bibliografie]
[1] Iulian Bădescu, Ilie Boicu – Fiabilitate funcțională în electronică, Editura
POLITEHNICA PRESS București, 2009.
[2] I. Buciuman – Echipamente și sisteme pentru controlul deplasării vehiculelor feroviare vol.1 pag. 106 – 194, Editura STUDIA Cluj Napoca, 2008
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: Elemente ale Fiabilitatii Microprocesoarelor (ID: 149779)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.
