Contribuții în proiectarea unităților centrale utilizate ... Andrei rezumat.pdf · 5.6 Proiectarea logicii de testare ... servicii, convergența funcționalității dispozitivelor

UNIVERSITATEA TEHNICĂ

“GHEORGHE ASACHI” DIN IAȘI

Facultatea de Automatică și Calculatoare

Contribuții în proiectarea unităților centrale

utilizate în arhitecturi de calcul dedicate

REZUMATUL TEZEI DE DOCTORAT

Contributions in designing central processing units

used in dedicated computing architectures

PH.D. Thesis summary

Conducător de doctorat

Prof. univ. dr. ing. Alexandru Valachi

Doctorand

Asist. ing. Andrei Stan

IAȘI – 2011

5

Cuprins

Cuprins ................................................................................................................................................. 5

1 Introducere ................................................................................................................................ 7

1.1 Motivație ............................................................................................................................ 7

1.2 Structura tezei .................................................................................................................... 8

2 Sisteme de calcul dedicate ...................................................................................................... 11

2.1 Introducere ....................................................................................................................... 11

2.2 Caracteristici ale sistemelor de calcul dedicate ............................................................... 12

2.2.1 Caracteristici structurale și funcționale .................................................................... 12

2.2.2 Caracteristici non-funcționale .................................................................................. 13

3 Sisteme de calcul dedicate cu microcontroler ......................................................................... 15

3.1 Automate finite ................................................................................................................ 15

3.1.1 Opțiuni de implementare .......................................................................................... 15

3.1.2 Model de automat finit pentru sisteme dedicate ....................................................... 16

3.1.3 Automat finit cu mecanism de siguranță .................................................................. 23

3.2 Bibliotecă de funcții pentru criptare ................................................................................ 27

3.2.1 Metode de criptare .................................................................................................... 27

3.2.2 Algoritmi de criptare ................................................................................................ 29

3.2.3 Evaluarea implementării algoritmilor de criptare .................................................... 29

3.2.4 Arhitectură pentru securizarea sistemelor dedicate .................................................. 31

3.2.5 Exemplu de utilizare a metodei propuse .................................................................. 32

3.3 Conversie de cod în virgulă mobilă în cod în virgulă fixă .............................................. 34

3.3.1 Proiectarea aplicației de conversie a codului ........................................................... 34

3.3.2 Transformarea fluxului de date ................................................................................ 35

3.3.3 Tehnici folosite în proiectarea aplicației .................................................................. 38

3.3.4 Generarea codului..................................................................................................... 38

3.3.5 Evaluarea metodei propuse ...................................................................................... 38

3.4 Concluzii .......................................................................................................................... 40

4 Sisteme de calcul dedicate cu circuite digitale reconfigurabile .............................................. 41

4.1 Sisteme reconfigurabile ................................................................................................... 41

4.2 Spatial computing ............................................................................................................ 42

4.3 Structură pentru monitorizarea timpului de execuție al subprogramelor ........................ 42

4.3.1 Studii similare........................................................................................................... 42

4.3.2 Arhitectura structurii de monitorizare ...................................................................... 43

4.3.3 Evaluarea structurii de monitorizare ........................................................................ 45

4.4 Structură pentru monitorizare a execuției aplicațiilor pe un MPSoC .............................. 46

4.4.1 Arhitectura sistemului MPSoC ................................................................................. 47

4.4.2 Arhitectura structurii de monitorizare ...................................................................... 49

4.5 Arhitectură pentru transformarea dinamică a codului în module hardware .................... 51

4.5.1 Arhitectura sistemului reconfigurabil ....................................................................... 52

4.5.2 Algoritmii de funcționare pentru sistemul reconfigurabil ........................................ 54

4.6 Concluzii .......................................................................................................................... 56

5 Structură autotestabilă pentru memoriile RAM ...................................................................... 59

5.1 Defecte de memorie ......................................................................................................... 59

5.2 Notaţii folosite în descrierea testelor de memorie ........................................................... 59

5.3 Testul de memorie MarchS2C ......................................................................................... 61

5.4 Comparație cu alți algoritmi de testare March ................................................................ 63

5.5 Structuri autotestabile ...................................................................................................... 63

5.6 Proiectarea logicii de testare ............................................................................................ 64

5.6.1 Logica de generare a adresei .................................................................................... 64

5.6.2 Logica de generare a datelor şi de verificare ............................................................ 64

5.6.3 Logica de control microprogramată ......................................................................... 65

5.7 Concluzii .......................................................................................................................... 66

6 Concluzii ................................................................................................................................. 67

6.1 Contribuții personale ....................................................................................................... 69

6.2 Diseminare rezultate ........................................................................................................ 70

6.2.1 Sumar publicaţii ....................................................................................................... 70

6.2.2 Detalii publicaţii ....................................................................................................... 70

6.3 Direcții viitoare de cercetare ............................................................................................ 73

Bibliografie ........................................................................................................................................ 74

7

1 Introducere

1.1 Motivație

Calculatoarele și tehnologia informației au avut un impact major în evoluția societății umane

în cursul ultimilor zeci de ani. Această influență se va face simțită și în viitor având în vedere că

aceste tehnologii au un rol important și o utilizare largă în infrastructura societății actuale. Datorită

legăturilor create între societate și tehnologie, evoluția societății este strâns acompaniată de evoluția

tehnologică.

În privința calculatoarelor și tehnologiei informației, tendințele actuale sunt reprezentate de

un interes foarte ridicat pentru acces la informație prin multiple medii, servicii personalizate și

servicii de realitate virtuală de înaltă calitate. Simultan, se constată o decuplare a proceselor de

calcul și cele de stocare a informației în paralel cu o creștere semnificativă a centrelor de procesare

a datelor (engl. data processing centers). Aplicațiile domestice, roboții, mijloacele de transport

autonome, sistemele de teleprezență și alte aplicații curente sunt exemple de tehnologii care susțin

și cauzează schimbări în societate.

Dezvoltarea acestor tehnologii și aplicații sunt influențate de tendințe din mediul economic

precum presiunea exercitată de costuri, restructurarea industriilor, modele de afaceri orientate către

servicii, convergența funcționalității dispozitivelor electronice și mediul cooperativ de dezvoltare al

aplicațiilor.

Provocările la care trebuie să răspundă sistemele de calcul dedicate (sunt denumite și

sisteme de calcul încorporate – engl. embedded) sunt generate de mai multe surse (Duranton, et al.,

2010).

Provocări tehnologice

Schimbări ale societății

Caracteristicile aplicațiilor

Aspecte economie

Constrângeri tehnologice

Figura 1.1.1 Surse ale provocărilor tehnologice pentru sistemele de calcul dedicate,

(Duranton, et al., 2010)

Proiectarea sistemelor de calcul pentru crearea tehnologiilor și implementarea aplicațiile

secolului 21 se confruntă cu următoarele constrângeri tehnologice:

Introducere

Partea hardware are o flexibilitate comparabilă sau mai ridicată decât partea

software a unui sistem de calcul.

Puterea consumată este o metrică a performanței sistemelor.

Caracteristicile comunicațiilor sunt o metrică a performanței sistemelor.

Circuitele de tip ASIC devin neatractive economic.

Proiectarea circuitelor ASIC pentru condițiile cele mai defavorabile conduce la

faliment.

Sistemele complexe trebuie să se bazeze pe componente nefiabile.

Timpul devine relevant.

Sistemele de calcul sunt supuse atacurilor în mod continuu.

Paralelismul pare să fie dificil de exploatat eficient.

Legea lui Moore are un sfârșit.

1.2 Structura tezei

Teza este structurată în șase capitole al căror conținut este prezentat în continuare.

În capitolul unu este prezentată motivația abordării temei propuse cu precizarea surselor

provocărilor tehnologice la care trebuie să răspundă sistemele de calcul dedicate.

În capitolul al doilea sunt prezentate elementele caracteristice ale arhitecturilor sistemelor

de calcul dedicate. Este prezentată o clasificare a arhitecturilor sistemelor de calcul, precum și o

structură generală pentru arhitectura sistemelor de calcul dedicate. Sunt enumerate trăsături

specifice care trebuie considerate în proiectarea sistemelor dedicate și modele pentru dezvoltarea de

aplicații pentru acest tip de sisteme. De asemenea, sunt amintite și standarde folosite în certificarea

și validarea implementării sistemelor de calcul dedicate utilizate în sisteme cu cerințe speciale de

siguranță în funcționare.

Capitolul al treilea prezintă proiectarea de module software utilizate în dezvoltarea

aplicaților software pentru sisteme de calcul dedicate cu microcontroler. Modulele implementate

sunt evaluate prin măsurarea unor caracteristici precum timpul de execuție, cantitatea de memorie

utilizată sau consumul de energie. Este prezentată proiectarea unui modul software care

implementează un model computațional de tip automat finit. Acest modul este extins cu adăugarea

unui mecanism de siguranță pentru prevenirea blocării automatului finit. Al doilea modul software

proiectat conține algoritmi de criptare, cu diverse performanțe de securizare a informațiilor, care

sunt evaluați prin estimarea consumului de energie necesar execuției lor pe un sistem dedicat. Este

propusă utilizarea acestor algoritmi într-o arhitectură adaptivă de securizare a sistemelor dedicate

prin care se obține o scădere a consumului de energie prin adaptarea algoritmilor de criptare la

condițiile de operare. Al treilea modul proiectat este o aplicație de generare de cod pentru

optimizarea implementării filtrelor digitale folosind numai operanzi și operații cu numere întregi.

Aplicația poate genera mai multe soluții folosind o funcție de cost în care sunt luate în considerare

complexitatea calculelor și acuratețea rezultatului.

Capitolul al patrulea prezintă proiectarea de arhitecturi de sisteme de calcul dedicate care

folosesc circuite reconfigurabile. Sunt proiectate două structuri de monitorizare hardware care pot fi

incluse în sistemele dedicate pentru a crește nivelul de siguranță în funcționare. Structurile de

monitorizare urmăresc comportamentul temporal al execuției aplicațiilor. Prima structură

monitorizează timpul de execuție al rutinelor care sunt apelate în timpul rulării aplicațiilor de către

un microprocesor, iar cea de a doua structură monitorizează transferurile de informații care au loc

într-un sistem multiprocesor. Arhitecturile de monitorizare sunt evaluate pe sisteme cu circuite

reconfigurabile FPGA (engl. Field Programmable Gates Array). Tot în acest capitol este prezentată

o arhitectură pentru un sistem de calcul capabil să monitorizeze și să evalueze execuția unei

aplicații de către un microprocesor pentru a genera apoi module hardware care implementează

funcționalități identice cu porțiuni din codul aplicației monitorizare.

Introducere

Capitolul al cincilea prezintă proiectarea unui modul de memorie autotestabil. Este

prezentată proiectarea unui test de memorie de tip March capabil să detecteze toate defectele de tip

cuplaj între două celule de memorie. Se demonstrează că acest test acoperă toate tipurile de

defectele de tip cuplaj între două celule, precum și optimalitatea testului relativ la numărul de

operații de scriere și citire necesar pentru a detecta defectele. Este realizată și o analiză comparativă

cu alte teste de memorie din care reiese eficiența testului propus. Acest algoritm este implementat

într-un modul al unei structuri autotestabile cu cale de control microprogramată.

Capitolul al șaselea prezintă concluziile tezei, contribuțiile personale, diseminarea

rezultatelor, precum și direcțiile viitoare de cercetare.

11

2 Sisteme de calcul dedicate

2.1 Introducere

Evoluția sistemelor de calcul a condus la trei categorii principale (Hennessy & Patterson,

2007) caracterizate de aplicațiile pe care le rulează, cerințele la care trebuie să facă față și

tehnologiile folosite la implementare .

Tabelul 2.1.1 Tipuri de sisteme de calcul și criterii de clasificare, după (Hennessy & Patterson, 2007)

Caracteristică Desktop Server Sisteme dedicate

Preț sistem 500 – 5000 $ 5000 – 5000000 $ 10-100000 $

Preț microprocesor 50 – 500 $ 200 – 10000 $ 0.01 – 100 $

Cerințe de

proiectare speciale

Raport

preț/performanță

Performanțe grafice

Disponibilitate,

Scalabilitate, Rata de

răspuns

Preț, Putere

consumată,

performanțe specifice

aplicației

Bucăți vândute 200.000.000 10.000.000 3.000.000.000

Sistemele de calcul dedicate reprezintă categoria cu creșterea cea mai rapidă. Aceste sisteme

sunt prezente în aplicații de consum, de la cuptoare cu microunde până la telefoane mobile și

console de jocuri.

Sistemele dedicate au cea mai largă plajă pentru costuri și puterea de calcul disponibilă. În

construcția lor sunt utilizate microprocesoare ieftine pe 8 sau 16 biți sau microprocesoare pe 32 de

biți cu performanțe de 100 MIPS la un cost de 5$. Tipurile de microprocesoare disponibile pentru

sistemele dedicate sunt foarte variate ca performanțe de calcul și ca urmare prețul este un factor

determinant în proiectarea acestor sisteme. Există cerințe de performanță în proiectarea acestor

sisteme, însă obiectivul principal este atingerea performanțelor cu costuri minime.

Sistemele de calcul dedicate sunt proiectate și construite pentru a îndeplini doar o anumită

funcție sau un set restrâns de funcții înrudite. Aceste sisteme electronice fac parte din sisteme mai

complexe și implementează cel mai adesea funcții de control, comunicație sau interfață cu

utilizatorul (acolo unde este cazul). Datorită acestei incluziuni, sistemele de calcul dedicate se mai

numesc și sisteme de calcul încorporate (engl. embedded). În continuare se va folosi termenul de

sisteme de calcul dedicate pentru a denumi această categorie de sisteme de calcul.

Sistemele de calcul dedicate se deosebesc de sistemele de calcul de uz general prin faptul că

ele execută o singură aplicație care implementează funcțiile necesare îndeplinirii sarcinilor pentru

care a fost construit sistemul dedicat.

Sisteme de calcul dedicate

12

2.2 Caracteristici ale sistemelor de calcul dedicate

2.2.1 Caracteristici structurale și funcționale

Sistemele de calcul dedicate sunt sisteme de calcul specializate care reprezintă părți

componente ale unor sisteme mai complexe. Un sistem de calcul dedicat este alcătuit dintr-o

combinație de elemente hardware și software (Stallings, 2010) care formează un nucleu de calcul

proiectat special pentru realizarea unei funcții specifice (Figura 2.2.1).

Figura 2.2.1 Organizarea unui sistem de calcul dedicat (încorporat – engl. embedded)

(Stallings, 2010)

Foarte frecvent, sistemele de calcul dedicate prezintă următoarele caracteristici funcționale

care determină luarea de decizii potrivite în procesul de proiectare și implementare:

Procesarea în timp real a informației. Sistemele dedicate trebuie să reacționeze în

limite de timp bine definite la evenimentele provenite din mediu. Nerespectarea

acestor limite poate avea consecințe neprevăzute și uneori periculoase pentru

siguranța mediului și a utilizatorilor.

Sunt sisteme reactive. Simt evenimente din mediu prin intermediul senzorilor și

controlează mediul utilizând actuatoare. Acest fapt impune sistemelor dedicate

atingerea unor performanțe în funcționare consistente cu mediul în care operează. Un

sistem reactiv folosește o combinație de elemente hardware și software pentru a

răspunde evenimentelor provenite din mediu cu respectarea unor constrângeri bine

definite. Evenimentele externe pot fi periodice și predictibile sau aperiodice și greu

de anticipat. Planificarea în vederea procesării ține cont atât de evenimentele

periodice cât și de ce cele aperiodice iar performanțele execuției trebuie garantate

pentru cele mai defavorabile condiții.

Sunt sisteme hibride. Includ elemente hardware utilizate pentru procesări analogice

(e.g. convertoare analog-numerice și/sau numeric-analogice) și elemente hardware

utilizate pentru procesări digitale (e.g. numărătoare, interfețe pentru comunicații

digitale). Circuitele integrate folosite în proiectarea de sisteme de calcul dedicate

sunt de diverse tipuri: microcontrolere, microprocesoare, procesoare digitale de

semnal sau circuite FPGA (engl. Field Programmable Gates Array).

Au resurse de procesare limitate. Adesea, unitățile centrale ale sistemelor dedicate

au arhitecturi simple (e.g. fără memorii cache, fără pipeline) și cantități reduse de

memorie de cod și date. Datorită acestui lucru, dezvoltarea de aplicații pentru

sisteme dedicate este o provocare și implementarea lor trebuie să fie foarte eficientă.

Au constrângeri pentru consumul de energie Sistemele dedicate sunt frecvent

folosite în aplicații pentru care autonomia energetică și disponibilitatea îndelungată

(e.g. rețele de senzori) sunt calități foarte importante. Pentru a satisface aceste

Sisteme de calcul dedicate

13

cerințe, proiectarea aplicațiilor trebuie să aibă în vedere și să implementeze tehnici

pentru optimizarea consumului de energie pentru procesările efectuate.

Au cerințe de siguranță în funcționare. Unele sisteme dedicate sunt incluse în

sisteme complexe pentru a implementa funcții de control (e.g. în industria

automobilelor: sisteme ABS sau controlul tracțiunii). Funcționarea defectuoasă a

acestor sisteme poate afecta siguranța utilizatorilor și ca atare procesul de dezvoltare

trebuie să prevadă mijloace și metode pentru satisfacerea unui nivel acceptabil de

siguranță a implementării.

Costul. Sistemele dedicate sunt sensibile la costuri. Costurile provin din surse

precum: costuri de proiectare, de producție sau de mentenanță.

Modelele computaționale sunt abstractizări care guvernează interacțiunile dintre

componentele unui sistem. Modelele computaționale pentru proiectarea de sisteme dedicate trebuie

să ofere mijloace și metode pentru exprimarea și implementarea concurenței și a comportamentului

temporal. Exemple de modele computaționale utilizate pentru dezvoltarea de aplicații pentru

sistemele dedicate sunt:

Flux de date (engl. dataflow). Componentele aplicației sunt reprezentate de module

care realizează calcule atomice asupra datelor de intrare atunci când acestea sunt

disponibile. Conexiunile dintre module descriu fluxul de date de la module producător

la module consumator.

Execuție periodică (engl. time triggered). Componentele aplicației sunt reprezentate

de module a căror activare are loc periodic la apariția unor evenimente declanșate de

scurgerea unor intervale de timp cu perioadă fixă.

Bazate pe evenimente (engl. event triggered). Componentele aplicației sunt

reprezentate de module a căror activare are loc la apariția unor evenimente descrise de

o valoare și momentul apariției.

Automate finite (engl. finite state machines). Este un model computațional

secvențial. Execuția unui automat presupune o singură stare activă la un moment dat.

2.2.2 Caracteristici non-funcționale

Datorită integrării sistemelor dedicate ca elemente de comandă ale unor sisteme mai

complexe care au cerințe severe de eficiență a funcționării, sistemele dedicate trebuie să prezinte

următoarele atribute non-funcționale (Avizienis, Laprie, & Randell, 2004):

disponibilitate: proprietatea sistemului de a fi capabil să ofere serviciul la un anumit

moment de timp;

fiabilitate: proprietatea sistemului de a fi capabil să ofere serviciul pentru un anumit

interval de timp;

siguranță: proprietatea sistemului de a nu provoca daune mediului, oamenilor sau

alte pierderi materiale;

integritate: proprietatea sistemului de a nu manifesta alterări;

mentenabilitate: proprietatea sistemului de a suporta reparații sau modificări.

Considerate împreună, toate aceste atribute formează noțiunea de eficiență globală (engl.

dependability). Pentru a realiza unele dintre componentele eficienței globale s-au dezvoltat diverse

tehnici:

prevenirea defectelor – prevenirea apariției sau introducerii de defecte;

tolerarea defectelor – funcționarea în prezența defectelor;

îndepărtarea defectelor – reducerea numărului și severității defectelor;

prevederea defectelor – estimarea numărului curent, a incidenței și a consecințelor

probabile ale defectelor.

15

3 Sisteme de calcul dedicate cu microcontroler

3.1 Automate finite

O definiție formală a unui automat finit (engl. Finite State Machine - FSM) este prezentată

în continuare. Un automat finit este un 6-uplu (Q, 𝛴, ∆, δ, 𝛌, q0) în care:

Q este o mulțime nevidă, finită – mulțimea stărilor;

𝛴 este o mulțime nevidă, finită – alfabetul de intrare;

∆ este o mulțime nevidă, finită – alfabetul de ieșire;

δ funcția de tranziție δ : Q x 𝛴 → Q;

𝛌 funcție de generare a ieșirii:

o automat finit Moore – 𝛌 : Q → ∆;

o automat finit Mealy – 𝛌 : Q x 𝛴 → ∆;

q0 starea inițială.

Implementarea unui automat finit implică exprimarea elementelor sale componente: stări,

tranziții, intrări (e.g. evenimente sau condiții) și ieșiri (e.g. acțiuni) cu mijloace specifice mediului

de implementare.

Pentru o implementare hardware sunt proiectate structuri logice combinaționale pentru

funcțiile δ și 𝛌. Pentru stocarea valorii stării curente sunt utilizate registre. Dacă un automat are Ni

intrări binare și No ieșiri binare, atunci alfabetul de intrare și cel de ieșire sunt spații Bool cu Ni,

respectiv Nb dimensiuni.

Implementările software ale automatelor finite permit o mai mare flexibilitate în modelarea

elementelor componente ale automatelor.

Utilizarea automatelor finite este una dintre metodele de bază pentru dezvoltarea aplicațiilor

software executate pe sisteme dedicate oferind suport pentru etapele de proiectare și implementare

din ciclul de dezvoltare al aplicațiilor. Automatele finite sunt folosite pentru a exprima dinamica

unei aplicații software. Pentru a proiecta un automat finit utilizat în aplicații software pentru sisteme

dedicate este necesar să se stabilească din punct de vedere funcțional componentele care fac parte

din sistem și cele care sunt externe sistemului.

3.1.1 Opțiuni de implementare

Pentru implementarea în software a automatelor finite există câteva abordări principale

(Williams, 2006). Se are în vedere utilizarea limbajului de programare C, acesta fiind cel mai

utilizat în dezvoltarea de aplicații pentru sistemele dedicate.

cod secvențial direct;

instrucțiuni SWITCH-CASE multiple;

instrucțiuni GO-TO și etichete;

Sisteme de calcul dedicate cu microcontroler

16

metode bazate pe tabele;

model de dezvoltare orientat obiect.

Deosebirile cele mai importante între aceste modele de implementare sunt date de modurile

de:

reprezentare ale intrărilor, ieșirilor și evenimentelor automatului finit;

monitorizare a intrărilor și evenimentelor automatului finit;

generare a ieșirilor automatului finit.

3.1.2 Model de automat finit pentru sisteme dedicate

Automatele finite sunt printre cele mai folosite modele computaționale utilizate (Harel,

2009) în sistemele de calcul dedicate pentru a crea aplicații (i.e. engl. firmware) de calitate.

Implementarea particularizată pentru o aplicație anume a automatelor finite necesită timp și este

predispusă la erori. O abordare mai eficientă este proiectarea unui module sau nucleu abstract

(kernel sau core) care, pe baza unei descrieri adecvate, execută un model al unui automat finit. Prin

utilizarea unui astfel de nucleu, un proiectant de sisteme dedicate trebuie să specifice numai

acțiunile, verificările și tranzițiile, ca simple funcții și tabele și să lase nucleul să se ocupe de

ansamblul operaţiilor de gestiune internă necesare pentru a executa automatul finit.

În continuare se prezintă și se descriu etapele de implementare și evaluare ale unui nucleu de

automat finit cu scopul de a-l utiliza în procesul de dezvoltare al aplicațiilor software pentru sisteme

de calcul dedicate (Stan, Botezatu, Panduru, & Lupu, 2009).

3.1.2.1 Implementare

Modelul propus pentru un nucleu de automat finit este compus din stări, evenimente sau

condiții, tranziții și funcții de acțiune. Fiecare dintre aceste componente precum și modurile de

implementare sunt abordate în manieră detaliată în cele ce urmează.

Fiecare stare este descrisă de structura tip FSME_STATE prezentată în Figura 3.1.1.

Structura conține informații despre funcția de acțiune care este executată în această stare, numărul

de tranziții din starea respectivă și o referință la un tabel care descrie tranzițiile posibile către alte

stări. Informația funcției acțiune este reprezentată printr-un pointer la funcție, având în vedere faptul

că acesta este un model de automat finit de tip Moore – funcția de acțiune este generată atunci când

se ajunge într-o stare – depinde doar de stare și nu de intrările în automatul finit.

// function pointer type – for action (output) functions

typedef void (*FSME_PF) (void);

// state type

typedef struct {

FSME_PF Action;

uint8 TransNO;

FSME_TRANS * Trans;

} FSME_STATE;

Figura 3.1.1 Structura de date care descrie o stare pentru un automat finit

(Stan, Botezatu, Panduru, & Lupu, 2009)

Tranzițiile sunt reprezentate de structura tip FSME_TRANS prezentată în Figura 3.1.2.

Această structură conține un pointer la o funcție care returnează o valoare booleană asociată cu

evaluarea unei condiții sau cu apariția unui eveniment. Structura FSME_TRANS conține, de

asemenea, codul stării în care va ajunge automatul finit dacă condiția testată este adevărată sau

evenimentul a avut loc. Prin implementarea condiției sau evenimentului cu o funcție se obține un

grad ridicat de flexibilitate pentru implementare, permițând adaptarea cu ușurință a automatului finit

la cerințele aplicației.


17

// function pointer type – for event update functions

typedef uint8 (*FSME_PF_EV) (void);

typedef struct {

FSME_PF_EV Event;

uint8 NextState;

} FSME_TRANS;

Figura 3.1.2 Structura de date care descrie o tranziție pentru un automat finit


Ultima structură specifică pentru acest model este structura FSME_FSM prezentată în

Figura 3.1.3. Ea cuprinde câmpuri care descriu o instanță a unui automat finit care este executat pe

un sistem dedicat. Structura FSME_FSM conține un indicator care arată dacă automatul finit este

oprit sau dacă este validată execuția acestuia, unul care indică o schimbare a stării automatului finit

și câmpuri care stochează starea curentă, numărul total de stări al automatului finit și o referință la o

tabelă care conține descrierile stărilor și tranzițiilor automatului finit.

// FSM type

typedef struct {

uint8 Enable;

uint8 CurrentState;

uint8 StatesNO;

uint8 StateChanged;

FSME_STATE * States;

uint8 TransNO;

FSME_TRANS * Trans;

} FSME_FSM;

Figura 3.1.3 Structura de date care descrie un automat finit


Un automat finit este format dintr-o mulțime de tabele FSME_TRANS, care conțin

informații despre tranzițiile din fiecare stare și o tabelă FSME_STATE, care conține toate stările

automatului finit și referințele către tabelele de tranziții. De asemenea, o variabila de tip

FSME_FSM este utilizată pentru a memora toate datele și toate referințele necesare ale unui

automat finit (Figura 3.1.4).

Enable CrtState StatesNOState

ChangedStates(table)

Trans(table)

Action TransNOTrans(table)

Action TransNOTrans(table)

…...

TransNO

Event NextState …... Event NextState

Figura 3.1.4 Relațiile structurilor de date care descriu un automat finit

Funcția pentru actualizarea stării curente a automatului finit este principala funcție a

nucleului și este prezentată în Figura 3.1.5. Funcția este apelată cu o referință la o instanță de tip

FSME_FSM a unui automat finit. Se parcurge șirul de tranziții asociat stării curente și se verifică

condițiile asociate cu tranzițiile. Dacă o condiție este adevărată atunci starea curentă a automatului

finit este actualizată în concordanță cu valorile din tabela tranzițiilor aferente sării curente iar

schimbarea de stare este semnalizată prin poziționarea indicatorului StateChanged. Imediat ce o

condiție determină o schimbare de stare, funcția își încheie execuția chiar dacă există și alte condiții

care pot fi adevărate. Această particularitate poate fi folosită în automatele finite complexe pentru a


18

implementa o prioritizare între tranziții, funcție de nevoile aplicației: tranzițiile prioritare sunt

trecute pe poziții cu index mic în tabelă.

/* verificare îndeplinire a condițiilor sau apariție a evenimentelor corespunzătoare tranziției curente*/

(FSME_EVENT_TRUE == _t[ _i ].Event())

/*parcurgere tranziții din starea curentă*/

(; _i < _n ; _i++)

/*actualizare stare curentă*/F->CurrentState = _t[_i].NextState

/*fixare pointer către starea curentă*/_s = &(F->States[F->CurrentState])

/*actualizare tabelă tranziții corespunzătoarestării curente*/

F->Trans = _s->Trans

/*actualizare număr tranziții corespunzător stării curente */

F->TransNO = _s->TransNO

/*actualizare indicator schimbare stare*/F->StateChanged =

FSME_STATE_CHANGED

/*folosire variabilă pentru a indica spre tabela de tranziții din starea curentă*/

_t = F->Trans

/*folosire variabilă pentru stocarea numărului de tranziții din starea curentă */

_n = F->TransNO

start(FSME_UpdateState)

stop(FSME_UpdateState)

TRUE

FALSE

FALSE

TRUE

Figura 3.1.5 Funcția de actualizare a stării curente a unui automat finit


19

În Figura 3.1.6 sunt prezentate: funcția principală a nucleului de automat finit și funcția de

acțiune. FSME_Action execută funcția de acțiune asociată. FSM_Run apelează cele două funcții

prezentate anterior, numai în cazul în care indicatorul Enable al instanței de automat finit F este

setat.

void FSM_Run( FSME_FSM * F ) {

if ( FSME_DISABLE == F->Enable ) {

// may reset the FSM into initial state and deactivate outputs

return;

}

FSME_UpdateState( F );

FSME_Action( F );

}

static void FSME_Action( FSME_FSM * F ) {

F->States[F->CurrentState].Action();

}

Figura 3.1.6 Funcția de execuție a unui automat finit


Funcția FSM_Run poate fi introdusă într-o buclă infinită (i.e. engl. super-loop) pentru

verificarea condițiilor asociate stării curente sau poate fi integrată într-un task executat de către un

sistem de operare în timp real în funcție de nevoile aplicației.

Figura 3.1.7 prezintă două funcții auxiliare ale nucleului: Enable (Activare) și Disable

(Dezactivare). Apelul acestor funcții setează sau resetează în mod corespunzător indicatorul Enable

al instanței F cu care sunt apelate aceste funcții.

void FSM_Enable( FSME_FSM * F ) {

F->Enable = FSME_ENABLE;

}

void FSM_Disable( FSME_FSM * F ) {

F->Enable = FSME_DISABLE;

}

Figura 3.1.7 Funcțiile de activare și dezactivare ale unui automat finit


Aceste funcții oferă posibilitatea activării sau dezactivării de automate finite individuale în

cadrul aplicațiilor software pentru sisteme dedicate. În acest fel este posibilă realizarea unei

proiectări eficiente cu mai multe automate finite, spre exemplu, un model cu automate finite dispuse

și activate ierarhic.

Avantajul acestei abordări nu constă numai în simplitatea și organizarea fluxului execuției

programului, care este bazată pe tabele, ci de asemenea oferă posibilitatea de a completa, șterge sau

actualiza descrierea fiecărei stări, fără a afecta semnificativ alte stări.

Nucleul automatului finit dezvoltat ocupă doar 230 octeți de memorie de cod. Fiecare stare

ocupă 5 octeți de memorie, iar fiecare tranziție consumă 3 octeți de memorie. Structura automatului

finit ocupă 9 octeți de memorie.

3.1.2.2 Evaluarea modelului propus

Pentru a evalua modelul propus al unui automat finit a fost creat un mediu adecvat. Mediul

de evaluare este definit pentru microcontrolere pe 8 biți: familia de microcontrolere ATMega de la

Atmel (Atmel Inc., 2011).

Mediul de evaluare utilizează următoarele componente: un modul de automat finit construit

pe baza modelului propus, un compilator C pentru microcontrolerul ATMega, și simulatorul

integrat în IDE (IAR Systems, IAR Embedded Workbench for Atmel AVR, 2011).

Un automat detector de secvență este implementat prin utilizarea modelului de automat finit

propus. Acest tip de sistem secvențial este o abstractizare folosită în numeroase probleme practice


20

care pot fi rezolvate utilizând modelul automatului finit. Acest automat finit este unul simplu:

implementarea sa, utilizând modelul propus, cuprinde funcții simple pentru verificarea intrării și

generarea acțiunilor corespunzătoare stărilor (i.e. ieșirile automatului). Acestea sunt funcții mai

simple în comparație cu funcția principală FSM_Run a modelului propus. Acest fapt permite o mai

bună estimare a complexității, măsurată în numărul ciclurilor necesare pentru execuția sa, a funcției

FSM_Run, comparativ cu restul codului.

O diagramă a sistemului detector de secvență este prezentată în Figura 3.1.8.

Figura 3.1.8 Automat finit pentru detecția secvenței (0,0,1)

Detectorul de secvență este proiectat să recunoască secvența valorilor binare {0, 0, 1},

prezentă la aplicată secvențial la intrarea sa. Dacă această secvență este prezentă la intrare,

automatul generează valoarea 1 la ieșirea sa. În caz contrar ieșirea are valoarea 0. Graful de fluență

pentru detectorul de secvență este prezentat în Figura 3.1.9.

Figura 3.1.9 Graful de fluență al automatului finit pentru detecția secvenței (0,0,1)

Pentru fiecare stare din graful de fluență este definită o tabelă a tranzițiilor ca în Figura

3.1.10. Fiecare element al acestei tabele are două câmpuri: un pointer la o funcție care evaluează o

condiție sau verifică un eveniment, și starea în care trece automatul finit, dacă condiția este

adevărată sau dacă evenimentul s-a produs.

// state transitions for each state

static __flash FSME_TRANS FSM1_S0_TRANS[] =

{ { FSM1_EventsUpdate0, FSM1_S1 } };


{ { FSM1_EventsUpdate0, FSM1_S2 },

{ FSM1_EventsUpdate1, FSM1_S0 } };


{ { FSM1_EventsUpdate1, FSM1_S3 } };


{ { FSM1_EventsUpdate0, FSM1_S1 },

{ FSM1_EventsUpdate1, FSM1_S0 } };

Figura 3.1.10 Structurile de date care descriu tranzițiile automatului finit

utilizat în detectarea secvenței (0,0,1)

În cazul automatului finit detector de secvență, funcțiile care verifică valoarea variabilei de

intrare sunt prezentate în Figura 3.1.11.

static uint8 FSM1_EventsUpdate0( void ) {

return ( in == 0 );

}

static uint8 FSM1_EventsUpdate1( void ) {

return ( in == 1 );

}

Figura 3.1.11 Funcțiile de verificare ale intrărilor automatului finit


21

Tabela stărilor pentru detectorul de secvență este ilustrată în Figura 3.1.12. Fiecare stare este

descrisă de propria funcție de acțiune, de numărul de tranziții către alte stări și de o tabelă care

conține tranzițiile sub formă de perechi, alcătuite din funcția de verificare a condiției și codul pentru

următoarea stare. // state outputs and transitions; entire table

static __flash FSME_STATE FSM1_STATES[] =

{ { FSM1_ActionClr, 1, FSM1_S0_TRANS},

{ FSM1_ActionClr, 2, FSM1_S1_TRANS},

{ FSM1_ActionClr, 1, FSM1_S2_TRANS},

{ FSM1_ActionSet, 2, FSM1_S3_TRANS}

};

Figura 3.1.12 Structurile de date care descriu stările automatului finit

care detectează secvența (0,0,1)

Funcțiile de acțiune pentru detectorul de secvență sunt prezentate în Figura 3.1.13. Fiecare

funcție de ieșire are două căi de control. Una este pentru acțiuni care sunt executate o singură dată,

la schimbarea stării. Cealaltă cale de control este pentru acțiuni care sunt executate în mod

continuu, atât timp cât automatul finit rămâne în aceeași stare.

static void FSM1_ActionClr( void ) {

if ( FSM1.StateChanged == FSME_STATE_CHANGED ) {

//actions to be executed only once in this state at the state change

out = 0;

// reset state changed flag

FSM1.StateChanged = FSME_STATE_NOT_CHANGED;

}

else { /* actions to be executed continuously in this state */ }

}

static void FSM1_ActionSet( void ) {

if ( FSM1.StateChanged == FSME_STATE_CHANGED ) {

// actions to be executed only once in this state at the state change

out = 1;

// reset state changed flag

FSM1.StateChanged = FSME_STATE_NOT_CHANGED;

}

else { /* actions to be executed continuously in this state */ }

}

Figura 3.1.13 Funcțiile de activare (ale ieșirilor) ale automatului finit


Instanța din automatul finit care implementează detectorul de secvență este prezentată în

Figura 3.1.14.

Câmpurile automatului finit sunt inițializate astfel: automatul finit este activat

(FSME_ENABLE), starea inițială este FSMI_S0, numărul de stări este setat la

FSM1_STATES_NO, indicatorul destinat schimbării de stare este setat la

FSME_STATE_CHANGE, cu scopul de a determina executarea funcției de acțiune pentru starea

inițială și, în cele din urmă, tabelul stărilor este setat la FSM1_STATES. Ultimele două câmpuri

rețin numărul de tranziții din starea inițială (1) și tabelul tranzițiilor pentru starea inițială.

FSME_FSM FSM1 = {

FSME_ENABLE,

FSM1_S0,

FSM1_STATES_NO,

FSME_STATE_CHANGED,

FSM1_STATES,

1,

FSM1_S0_TRANS

};


22

Figura 3.1.14 Structura de date care reprezintă automatul finit


Pentru a evalua performanța implementării au fost proiectate și create multiple configurații

ale aplicației. În acest fel, se poate evalua impactul unor factorilor care țin de mediul de dezvoltare

supra performanței execuției aplicației.

Aplicația care conține automatul finit este creată și compilată în patru configurații diferite:

configurația 1: structurile de date care descriu automatul finit sunt memorate în

SRAM și optimizările compilatorului sunt setate la nivel scăzut;


SRAM și optimizările compilatorului sunt setate la nivel ridicat;


FLASH și optimizările compilatorului sunt setate la nivel scăzut;


FLASH și optimizările compilatorului sunt setate la nivel ridicat.

Cantitatea de memorie utilizată obținută după procesul de compilare al fiecărei configurații

este prezentată în Figura 3.1.15.

Memoria SRAM a microcontrolerului, folosită în aplicațiile software este o resursă

valoroasă. Mărimea sa este, în general, mai mică decât mărimea memoriei FLASH. În diverse

modele se va alege stocarea informației automatului finit în memoria SRAM sau în memoria

FLASH, în funcție de nevoile specifice ale aplicației. Impactul acestei decizii de utilizare a

memoriei asupra detectorului de secvență este prezentată în Figura 3.1.15.

Figura 3.1.15 Resursele de memorie utilizate de implementarea automatului finit


Pentru a putea evalua timpul de execuție al modelului de automat finit s-a dezvoltat un script

pentru simulatorul IAR. Script-ul numără ciclurile scurse între două apeluri succesive ale funcției

FSM_Run (&FSM1). Secvența de intrare utilizată în procesul de simulare are valori care activează

toate tranzițiile posibile ale acestui automat finit.

Media numărului de cicluri obținută după procesul de simulare pentru fiecare configurație

este prezentată în Figura 3.1.16. Numărul de ciclurilor este ușor mai mare în cazul configurațiilor

care au stocat informația automatului finit în memoria FLASH. Acest lucru se întâmplă deoarece

este nevoie de un număr mai mare de cicluri pentru a citi datele din memoria FLASH, în comparație

cu numărul de cicluri necesare pentru a citi datele reținute în memoria SRAM.


23

Figura 3.1.16 Timpul de execuție a implementării automatului finit


Script-ul de simulare evaluează și numărul de cicluri necesare fiecărei tranziții realizate în

decursul procesului de simulare. Numărul de cicluri pentru fiecare tranziție din configurația 2 este

prezentat în Tabelul 3.1.1 și pentru cei din configurația 4 este prezentat în Tabelul 3.1.2.

Tabelul 3.1.1 Numărul de cicluri pentru tranzițiile automatului finit în configurația 2


Stare curentă /

Stare următoare S0 S1 S2 S3

S0 156 202 0 0

S1 239 0 202 0

S2 0 0 156 203

S3 239 202 0 0

Tabelul 3.1.2 Numărul de cicluri pentru tranzițiile automatului finit în configurația 4


Stare curentă /

Stare următoare S0 S1 S2 S3

S0 160 216 0 0

S1 255 0 216 0

S2 0 0 160 217

S3 255 216 0 0

Această particularitate poate fi utilizată în validarea tabelei de tranziții pentru un automat

finit. În tabelele anterioare, valoarea zero semnifică absența execuției tranziției respective, iar o

valoare diferită de zero denotă că tranziția respectivă s-a realizat în timpul procesului de simulare și

durata sa este egală cu numărul de cicluri notat în tabel. Valorile timpilor de execuție pot fi folosite

ca o informație despre execuția corectă a automatului finit. Valorile acestea pot fi utilizate ulterior

la implementarea unor mecanisme de verificare a corectitudinii execuției automatului finit.

3.1.3 Automat finit cu mecanism de siguranță

3.1.3.1 Implementare

Se continuă dezvoltarea modelului anterior prin modificarea modelului de automat finit cu

implementarea unui mecanism de siguranţă (Stan, Botezatu, & Vieriu, 2009). Operarea sigură este

un aspect esenţial în sistemele de calcul dedicate complexe. Pentru a atinge un nivel ridicat de

siguranţă, o metodă este validarea temporală a valorilor intrărilor în automatul finit şi a ieșirilor


24

generate de automat. Implementarea propusă include o verificare a timpului pe care un automat îl

petrece în fiecare stare, ceea ce previne ca automatul finit să aştepte la nesfârşit o condiţie pentru a

realiza o schimbare de stare şi să menţină ieşirile active mai mult decât este necesar sau decât este

sigur.

Implementarea trebuie să fie eficientă din punctul de vedere al încărcării memoriei şi al

timpului de execuţie.

Modelul de nucleu propus pentru un automat finit cu mecanism de siguranță este definit de

stările, evenimentele sau condiţiile care declanşează tranziţia dintre stări, de funcţiile care activează

sau dezactivează ieșirile şi de valorile timpului maxim de staționare în fiecare stare.

Fiecare stare este descrisă de tipul de date FSME_STATE, prezentat în Figura 3.1.17 , care

conţine informaţii despre funcţia de activare, tranziţiile din această stare şi o valoare de temporizare

care limitează intervalul de timp pentru care automatul finit poate rămâne în starea curentă.

Informaţiile pentru funcţia de activare sunt reprezentate de un pointer la funcţie asociat unei stări,

având în vedere faptul că modelul de automat finit este pentru automate de tip Moore.

// function pointer type – for action (output) functions

typedef void (*FSME_PF) (void);

// function pointer type – for transition checking

typedef uint8 (*FSME_PF) (void);

// state type - describes a FSM state using the following fields:

// Action – a pointer to an action (output) function

// Event – a pointer to function that checks the conditions that may

trigger a transition from the current state;

// TimeOut – the maximum ammount of time that the FSM is allowed to stay

in the current state

typedef struct {

FSME_PF Action;

FSME_PF_EV Event;

uint16 TimeOut;

} FSME_STATE;

Figura 3.1.17 Structura de date care descrie starea unui automat finit

cu mecanism de siguranță (Stan, Botezatu, & Vieriu, 2009)

Tranziţiile din starea curentă sunt determinate de câmpul Event al structurii FSME_STATE.

Acest membru este un pointer la o funcţie care verifică toate evenimentele şi condiţiile care pot

declanşa o tranziţie din starea curentă. Dacă se declanşează o tranziţie prin apariţia unui eveniment

sau a unei condiţii adevărate, funcţia Event schimbă codul stării curente cu codul pentru următoarea

stare în care va ajunge automatul finit.

Tipul de structură pentru modelul de automat finit este FSME_FSM prezentată în Figura

3.1.18. Structura constă dintr-un indicator care semnalează o schimbare în starea automatului finit şi

din câmpuri care descriu: starea curentă, starea de siguranţă în care ajunge automatul finit în cazul

expirării timpului de staționare într-o stare, o referință la o tabelă care conţine stările automatului

finit şi un index pentru un timer folosit pentru contorizarea timpului petrecut în starea curentă.

// FSM type - describes a FSM using the following fields:

typedef struct {

uint8 Enable;

uint8 StateChanged;

uint8 CurrentState;

uint8 SafeState;

FSME_STATE * States;

uint8 TimerIdx;

} FSME_FSM;

Figura 3.1.18 Structura de date care descrie un automat finit cu mecanism de siguranță

(Stan, Botezatu, & Vieriu, 2009)


25

/*verificare schimbare de stare*/_n != FSME_NO_STATE_CHANGE

/*actualizare stare curentă*/F->CurrentState = _n

/*fixare variabilă cu noua stare a automatului finit*/

_n = F->States[F->CurrentState].Event();

start(FSME_Run)

stop(FSME_Run)

FALSETRUE

/*actualizare indicator schimbare stareg*/F->StateChanged =

FSME_STATE_CHANGED

/*repornire a contorului de timp*/timer_RestartTimer10ms(

F->TimerIdx,

F->States[ F->CurrentState ].TimeOut );

/*verificare contor de timp pentru starea curentă*/TRUE == timer_CheckTimer10ms( F->TimerIdx )

/*actualizare stare curentă*/F->CurrentState = F->SafeState

/*actualizare indicator schimbare stare*/F->StateChanged =

FSME_STATE_CHANGED

/*repornire a contorului de timp*/timer_RestartTimer10ms(

F->TimerIdx,

F->States[ F->CurrentState ].TimeOut );

/*Apelare funcție de acționare (ieșire) corespunzătoare stării curente*/

F->States[ F->CurrentState ].Action()

FALSE

TRUE

Figura 3.1.19 Funcția de execuție pentru un automat finit cu mecanism de siguranță

Orice apelare a funcţiei FSME_Run, prezentată în Figura 3.1.19, verifică mai întâi dacă

automatul finit este activat sau nu. Dacă este activat, funcţia FSME_Run verifică apoi dacă starea

s-a schimbat prin apelarea funcţiei Event pentru starea curentă. Dacă starea automatului finit s-a

schimbat, starea curentă este actualizată în consecinţă şi contorul (engl. timer) pentru măsurarea

timpului petrecut în starea curentă este resetat la valoarea corespunzătoare noii stări. Dacă starea

automatului finit rămâne neschimbată, funcţia FSME_Run verifică dacă valoarea de contorului

pentru starea curentă indică o depășire. În acest caz automatul finit intră într-o stare de siguranţă. În

această stare se poate iniţia un ciclu de oprire în siguranță a sistemului dedicat. La sfârşitul funcţiei

FSME_Run este apelată funcţia Action pentru starea curentă.

3.1.3.2 Evaluarea modelului propus

Pentru a evalua modelul de automat finit propus s-a creat un mediu special pentru acest

scop. Mediul de evaluare este pentru microcontrolere pe 8 biţi: familia de controlere ATMega de la

Atmel.


26

Mediul de evaluare foloseşte următoarele componente: un modul de automat finit construit

cu modelul propus, un compilator C pentru microcontrolerele ATMega (IAR Systems, IAR

Embedded Workbench for Atmel AVR, 2011), şi simulatorul integrat în IAR IDE.

Un detector de secvenţă (pentru secvența 0,0,1), prezentat în Figura 3.1.20, este implementat

folosind modelul de automat finit propus. Revenirea în ciclul normal de funcționare din starea S4 de

eroare (în care se ajunge după depășirea timpului maxim de staționare într-una din stările S0, …,

S3) se poate face după scurgerea unui interval de timp, sau după intervenția explicită a operatorului

sistemului controlat de acest automat.

Figura 3.1.20 Graful de fluență al automatului finit cu mecanism de siguranță

pentru detecția secvenței (0,0,1)

Scenariul de simulare calculează de asemenea numărul de cicluri necesare pentru fiecare

tranziţie care a apărut în timpul operării procesului de simulare. Numărul de cicluri pentru fiecare

tranziţie a automatului finit este prezentat în Tabelul 3.1.3. Acest tabel poate fi folosit de asemenea

pentru a verifica corectitudinea implementării.

Modulul implementat ocupă doar 156 octeți din memoria de cod. Pentru implementarea

detectorului de secvenţă memoria folosită este de 147 octeți memoria de cod (plus 156 octeți pentru

bibliotecă) şi 7 octeți de memorie date.

Tabelul 3.1.3 Numărul de cicluri pentru tranzițiile automatului finit cu mecanism de siguranță

(Stan, Botezatu, & Vieriu, 2009)

Stare curentă /

Stare următoare S0 S1 S2 S3 S4

S0 126 146 0 0 179

S1 147 0 146 0 0

S2 0 0 126 147 0

S3 147 146 0 0 0

S4 0 0 0 0 121


27

3.2 Bibliotecă de funcții pentru criptare

Securitatea este necesară pentru un număr tot mai mare de sisteme dedicate. Progresul

tehnologic care a dat naştere acestor sisteme electronice a impus şi o tendinţă de creştere a

complexităţii atacurilor pentru subminarea securităţii. Numărul tot mai mare de încercări de

exploatare a lacunelor din sistemele de asigurare a securității informaţiilor, a motivat creşterea

efortului de securizare a sistemelor electronice. Sistemele dedicate folosite la achiziţia, stocarea,

manipularea şi procesarea datelor de o natură sensibilă, ridică câteva provocări unice şi interesante

din punct de vedere al securităţii. Securitatea a făcut subiectul cercetării în domenii precum

criptografia şi ştiinţa calculatoarelor şi a reţelelor de calculatoare. Cu toate acestea, securitatea este

de obicei omisă sau interpretată ca o funcţie anexă în procesul de proiectare al sistemelor dedicate.

În realitate, securitatea ar trebui sa reprezinte o nouă metrică în procesul de proiectare alături de

cost, performanţe şi puterea consumată.

Pentru aceste sisteme există câţiva factori care translează considerentele de securitate dintr-o

perspectivă central-funcţională spre o problemă de proiectare arhitecturală (hardware și software):

Un sistem dedicat trebuie să fie sigur chiar şi când poate fi accesat fizic sau logic de

entităţi neautorizate. Rezistenţa la astfel de atacuri poate fi asigurată doar dacă

sistemul a fost proiectat pentru asemenea cazuri.

Posibilităţile de procesare ale multor sisteme dedicate sunt uşor depăşite de nevoile

computaţionale ale modulelor de securitate, acest lucru ducând la compromisuri

indezirabile între securitate şi cost sau securitate şi performanţă.

Sistemele alimentate de la baterie (şi dispozitivele cu constrângeri de dimensiuni) în

general operează cu resurse limitate, precum capacitatea bateriei, spaţiul de stocare,

capacitatea de procesare, acestea fiind suprasolicitate de cerinţele impuse prin

securitate.

Sistemele dedicate trebuie să fie suficient de flexibile pentru a se adapta evoluţiei

rapide a mecanismelor de securitate.

Proiectarea sistemelor care iau în considerare eficienţa energetică reprezintă o provocare

pentru arhitecturile de sisteme de calcul dedicate (De Bosschere, et al., 2007).

3.2.1 Metode de criptare

Pentru modelul de securizare propus există două tipuri de metode pentru securizarea

informațiilor transferate:

metoda de generare a cheii de sesiune;

metoda de transfer de date.

Figura 3.2.1 prezintă generarea cheii de sesiune şi metoda de schimb. O sesiune este iniţiată

atunci când sistemului i se adaugă un nou nod. De asemenea, atunci când nodul adăugat schimbă

dinamic metoda de criptare folosită, pe baza cerinţelor de energie, este necesară o nouă cheie de

criptare, care necesită în consecinţă o nouă sesiune de generare a cheii de criptare. Schimbarea

frecventă a cheii de criptare pentru sesiunile de comunicație poate să crească rezistența la atacuri a

comunicațiilor de date dintre sisteme.


28

Figura 3.2.1 Metoda de generare a cheii de criptare pentru o sesiune de comunicație

(Stan & Botezatu, 2009)

Nodurile sistemului au o cheie iniţială (K). Această cheie este setată o dată la prima utilizare

a sistemului şi poate fi resetată în mod regulat de către administratorul de sistem. Atunci când este

iniţiată o nouă sesiune, nodul master (Nodul A) creează două chei: K1 şi K2. Aceste chei pot fi

numere aleatorii pe 64 de biţi calculate folosind un algoritm de generare și o sămânță dedusă dintr-o

expresie care include valori provenite de la o intrare neconectată a unui modul ADC, temperatura

mediului ambiant şi ceasul de timp real.

Prima etapă a metodei de schimb constă în criptarea valorii lui K1 cu cheia inițială K; datele

codificate obţinute (C1) vor fi transmise nodului B printr-un canal de comunicație nesecurizat. În a

doua etapă, K2 este criptat cu cheia K şi datele codificate rezultate (C2) sunt codificate cu cheia K1

generată anterior. Datele rezultate (C3) sunt, de asemenea, transmise receptorului prin intermediul

unei conexiuni nesecurizate. Ultimele două etape ale procesului se desfăşoară pe nodul B. După ce

are loc recepţionarea datelor C1, se iniţiază etapa a treia. Această etapă constă în decriptarea lui C1

cu ajutorul cheii K, rezultând cheia K1. Apoi, în ultima etapă, datele C3 recepţionate sunt decriptate

folosindu-se cheia K1; datele rezultate, C2, sunt decodificate cu cheia K pentru a obţine cheia K2.

Toate datele transmise ulterior în cadrul sesiunii sunt criptate şi decriptate cu cheia de sesiune K2.

Figura 3.2.2 Metoda pentru schimbul de date


Initial known Key Initial known Key

EK(K1)=C1

EK1(C2)=C3

EK(K2)=C2

Key generation

System administrator

DK(C1)=K1

DK1(C3)=C2

DK(C2)= K2

Session key: K2

K1

K2

KK

C2

C1

C3

C2

K

KK1

Node A (Master) Node B (Slave)

Initial known Key Initial known Key

EK(K1)=C1

EK1(C2)=C3

EK(K2)=C2

Key generation

System administrator

DK(C1)=K1

DK1(C3)=C2

DK(C2)= K2

Session key: K2

K1

K2

KK

C2

C1

C3

C2

K

KK1


Session key: K2 Session key: K2

EK(d)=Cd1

DK2(Cd2)=d2

Data

DK2(Cd1)=d1

EK2(d2)=Cd2

Data

d1

K2Cd1

Cd2

d2

K2


K2

K2Session key: K2 Session key: K2

EK(d)=Cd1

DK2(Cd2)=d2

Data

DK2(Cd1)=d1

EK2(d2)=Cd2

Data

d1

K2Cd1

Cd2

d2

K2


K2

K2


29

Metoda schimbului de date este prezentată în Figura 3.2.2. Cele două noduri de comunicație

au aceeaşi cheie de sesiune, K2, generată conform pașilor descriși anterior. Procesele de criptare și

decriptare au la bază această cheie, deoarece datele care traversează canalul nesecurizat sunt

codificate la sursă şi decodificate la sistemul destinaţie prin folosirea cheii K2.

3.2.2 Algoritmi de criptare

Algoritmii de criptare reprezintă fundamentul metodelor de criptare. Metodele de criptare

propuse folosesc algoritmii de criptare pentru managementul datelor sensibile.

Codificarea datelor este procesul care transformă reprezentarea din text simplu a valorilor

într-o reprezentare prin text codificat, utilizând un algoritm de criptare selectat şi o cheie secretă

folosită de algoritm.

Managementul datelor sensibile se referă îndeosebi la procesul de management al cheii,

incluzând: generarea cheii, protocolul de schimbare a cheii şi algoritmul de codificare folosit pentru

criptarea cheii.

În scopurile menţionate, au fost selectați şi implementați doi algoritmi de criptare: FEAL

(Fast Data Encipherment Algorithm – Algoritm de Criptare Rapidă a Datelor) şi DES (Data

Encryption Standard – Standard de Criptare a Datelor). Ambii algoritmi sunt algoritmi de criptare

simetrici cu cheie privată care operează pe blocuri de date

Pentru multe aplicații, acest tip de algoritmi de criptare corespund necesităţilor de

comunicație a sistemelor dedicate datorită structurii orientate pe blocuri a datelor comunicate. De

asemenea, lungimea blocului pentru algoritmii de criptare este un bun echivalent al (sau un mic

număr de multipli ai) volumului de date comunicate.

3.2.3 Evaluarea implementării algoritmilor de criptare

Implementarea algoritmilor de criptare se desfăşoară potrivit următoarelor reguli pentru

minimizarea consumului de resurse: se evită lucrul cu şiruri de octeți, folosindu-se în schimb tipuri

de date întregi suportate de arhitectură (e.g. întregi pe 32 de biţi) şi de compilator (e.g. întregi pe 64

de biţi); se evită utilizarea multor funcţii: se evită transmiterea parametrilor şi secvenţele frecvente

de apel și revenire din funcție.

Pentru implementarea şi evaluarea algoritmilor de criptare, s-a folosit o platformă de

dezvoltare cu un microcontroler ARM Coretx-M3 STM32F103RB (ST Microelectronics, 2011) şi

compilatorul CrossWorks pentru ARM (Rowley Associates, 2011).

Numărul de cicluri pentru execuția algoritmilor de criptare este prezentat în Tabelul 3.2.1 şi

în Tabelul 3.2.2. Valorile pentru numărul de cicluri sunt calculate pentru diferite lungimi ale datelor

criptate şi pentru numere diferite de runde pe care algoritmul le execută pentru criptarea datelor.

După cum s-a specificat anterior, algoritmii de decriptare şi cei de criptare sunt identici, cu

deosebirea că subcheile sunt aplicate etapelor interne în ordine inversă. Acest aspect face ca

algoritmii de decriptare să aibă acelaşi număr de cicluri pentru operațiile de criptare și decriptare. Tabelul 3.2.1 Numărul de cicluri pentru execuția algoritmului de criptare DES (Stan & Botezatu, 2009)

Lungimea blocului

de date

Numărul de runde de criptare

2 4 8 16

64 bit 2040 31652 54152 99152

128 bit 40745 63681 109552 201296

256 bit 81147 126179 216244 396372

Tabelul 3.2.2 Numărul de cicluri pentru execuția algoritmului de criptare FEAL (Stan & Botezatu, 2009)

Lungimea blocului

de date

Numărul de runde de criptare

8 16 32

64 bit 1818 3615 6765

128 bit 3696 7032 13536

256 bit 7315 13870 27242


30

Calcularea numărului ciclurilor permite măsurarea directă a timpului de execuţie. Aceste

tabele conţin informaţii pe care o aplicaţie le poate utiliza pentru a estima timpul de execuţie

necesar pentru un algoritm de criptare şi, prin urmare, energia necesară pentru execuţia algoritmului

respectiv. Prin utilizarea informaţiilor din tabelele anterioare, o aplicaţie poate selecta dinamic

algoritmul pe care să-l lanseze în execuţie pentru a cripta sau decripta date. Selecţia se face în baza

bugetului de energie al sistemului, astfel încât să se asigure o perioadă de funcţionare cât mai

îndelungată.

Tabelele prezentate anterior conţin informaţii care stau la baza implementării sistemelor care

monitorizează consumul de energie pe durata perioadei de execuție.

Au fost măsurați, de asemenea, timpii de execuţie pentru diferite versiuni de algoritmi de

criptare DES şi FEAL (i.e. diferite lungimi ale blocului de date procesat) în condițiile utilizării unei

frecvenţe a ceasului de 72MHz pentru microcontroler. Pentru măsurarea acestor valori s-a utilizat

un timer intern al microcontrolerului. Valorile timpului de execuţie sunt calculate pentru diferite

lungimi de date criptate şi pentru diferite numere de runde pe care algoritmul le execută în vederea

codificării datelor. Valorile măsurate sunt prezentate în Figura 3.2.3 şi Figura 3.2.4.

Figura 3.2.3 Timpul de execuție pentru criptarea unui bloc da date cu algoritmul DES


Figura 3.2.4 Timpul de execuție pentru criptarea unui bloc de date cu algoritmul FEAL


În continuare este prezentat un scenariu tipic de consum de energie bazat pe metodele

descrise. Acesta implică folosirea algoritmului DES16 în procesul de criptare sau decriptare a cheii

de sesiune şi transmiterea unei secvenţe de date pe 16 biţi criptate cu FEAL8. Cele trei etape de

decriptare necesare la începutul sesiunii solicită 297456 de cicluri pentru a fi executate.

Următoarele date pe 128 de biţi necesită 3696 de cicluri pentru realizarea criptării. La un consum, în

starea normală de funcționare (i.e. nu în moduri de consum redus de energie), de 38,1 mA @ 3,3V


31

pentru ARM Cortex-M3 (cu funcţionare la o frecvență de 72MHz), energia folosită pentru

generarea cheii de sesiune este de 126 mW în 4,14 ms, față de cele 56 de microsecunde necesare

pentru codificarea propriu-zisă a datelor.

3.2.4 Arhitectură pentru securizarea sistemelor dedicate

În figura Figura 3.2.5 este descris un model de arhitectură pentru securizarea sistemelor

dedicate (Botezatu, Manta, & Stan, 2010). Arhitectura are la bază trei blocuri funcţionale: Detecţie

(engl. Sensing), Analiză (engl. Analysis) şi Execuţie (engl. Enforcement). Seturile de date de intrare

sunt reprezentate de Starea sistemului (engl. System status - SS), Descriptorii sistem (engl. System

descriptors - SD) şi Scopurile sistem (engl. System goals - SG).

BLOCURI

FUNCȚIONALE

Detecție Analiză

Execuție

Stare SistemScopuri

Sistem

Descriptori

Sistem

HW SW

Mediu

Reacție

Securitate adaptivă

Cerere de

reevaluare

Cerere de

reconfigurare

Figura 3.2.5 Blocurile componente ale arhitecturii de securitate

(Botezatu, Manta, & Stan, 2010)

Modul de funcţionare este următorul: când blocul de detecţie identifică o schimbare la

nivelul parametrilor definiţi în seturile de date, acesta semnalează blocul de analiză, care la rândul

lui încearcă să determine ce modificări trebuie aduse la nivelul securităţii pentru a satisface cerinţele

definite de către SG. Apoi, blocul de execuţie aplică modificările necesare sistemului.

3.2.4.1 Starea sistemului

Starea sistemului poate fi privită ca o valoare unică, definită de un set specific de parametri.

Aceştia pot fi clasificaţi ca parametrii interni, respectiv externi, unde cei interni sunt specifici

configuraţiei hardware a sistemului (e.g. blocuri funcţionale ale sistemului care pot influenţa starea)

şi aplicaţiilor care se execută pe acesta (e.g. cerinţele hardware ale aplicaţiei).

3.2.4.2 Descriptorii sistem

Descriptorii sistem sunt reprezentaţi de o colecţie de date care descriu componentele

hardware şi software ale sistemului. Datele sunt organizate ierarhic, pe baza unei colecţii de clase

care descrie şi grupează elementele sistemului funcţie de proprietăţile de consum şi de securitate.

Modelul de bază pentru această ierarhie este prezentat în Figura 3.2.6. Primele trei nivele realizează

o clasificare generală a componentelor sistemului, de la nivelul patru, în jos, fiind derivate clase

care descriu componentele (e.g. de pe ramura surselor de energie – engl. energy suppliers – pot fi

derivate noi clase care să descrie baterii, celule fotovoltaice etc.).

Clase specifice

Clase de bază

Descriptori HW Descriptori SW

Consumatori de

energie (EC)

Surse de

energie (ES)

Aplicațiile

sistemului (SA)

Primitivele de

securitate (SP)

EC1 ... ECx ES1 ... ESy SA1 ... SAz SP1 ... SPt

Obiecte care descriu

componentele

sistemului

Figura 3.2.6 Ierarhia descriptorilor sistem

(Botezatu, Manta, & Stan, 2010)


32

3.2.4.3 Scopurile sistem

Scopurile sistem sunt determinate pe baza corelaţiilor dintre resursele energetice ale

sistemului şi necesarul de securitate. Pe baza discrepanţei dintre cererea de resurse şi

disponibilitatea lor în sistemele dedicate, scopurile sistemului sunt determinate ţinând seama de

costul de implementare al securităţii (exprimat în energie consumată) şi de gradul de flexibilitate al

implementării (cât mai multe primitive şi metode de securitate). Scopurile sistem trebuie descrise ca

o maximizare a timpului de operare prin menţinerea unui nivel adecvat de securitate în sistem.

3.2.4.4 Blocul de detecţie

Blocul de detecţie monitorizează starea sistemului. Stările în care se poate afla sistemul sunt

definite ca elemente ale unui set finit S = {s1, s2, …, sn}, acestea fiind determinate pe baza

combinaţiilor şi corelaţiilor dintre parametrii de mediu (starea sistemului) şi descriptorii sistem.

Când apare o tranziţie de stare, acest bloc decide dacă trebuie trimisă o cerere de reevaluare a

securităţii către blocul de analiză.

3.2.4.5 Blocul de analiză

Acest bloc primeşte cereri de reevaluare a securităţii de la blocul de detecţie, pe baza

modificărilor stării sistemului. Funcţie de SG şi de noua stare a sistemului, acesta decide care

componente ale securităţii trebuie modificate.

3.2.4.6 Blocul de execuţie

Acest bloc primeşte cereri de reconfigurare a securităţii de la modulul de analiză şi încearcă

să aplice modificările necesare. Rezultatul (succes sau eşec) este transmis blocului de analiză. Dacă

cererea de reconfigurare nu poate fi satisfăcută, blocul de analiză trebuie să propună alte alternative

de securitate.

3.2.5 Exemplu de utilizare a metodei propuse

Pentru a demonstra eficiența unei arhitecturi adaptive pentru securizarea unui sistem dedicat

s-a realizat următorul experiment.

Platforma hardware utilizată are un microcontroler ARM Coretx M3 alimentat de la baterii

NiMH de capacitate 2000mAh. Microcontrolerul reprezintă principalul consumator de energie al

sistemului dedicat. Metrica utilizată pentru estimarea consumului de energie a sistemului dedicat

este reprezentată de gradul de descărcare al bateriei (engl. DoD – Depth of Discharge) exprimat în

procente.

Fiecare aplicație utilizează un anumit algoritm de criptare funcție de modul de operare (unde

este cazul) și de DoD. Algoritmii folosiți pentru acest experiment sunt DES8, DES16 și FEAL.

Stările în care se poate găsi sistemul la un moment dat sunt prezentate în Tabelul 3.2.3.

Pentru acest experiment, procesul de securizare al aplicațiilor executate constă în criptarea a

80 de octeți de date de către fiecare aplicație într-o fereastră de timp de 29 milisecunde. Timpul care

rămâne din această fereastră după efectuarea tuturor operațiilor de criptare este petrecut de

microcontroler într-un mod de consum scăzut de energie. Caracteristicile relevante pentru evaluarea

consumului de energie ale algoritmilor de criptare sunt prezentate în Tabelul 3.2.4.

Tabelul 3.2.3 Stările sistemului (Botezatu, Manta, & Stan, 2010)

Aplicație

Executată

Stare baterie

(DoD)

Stare

sistem

Cerințe

de securitate

A1m1 - S1 A1 → DES16

A1m2 - S2 A1 → DES

A1m1

&

A2

< 50% S3 A1 → DES16

A2 → DES8

≥ 50% S4 A1 → DES16


33

A2 → FEAL

A1m2

&

A2

< 50% S5 A1 → DES

A2 → DES8

≥ 50% S6 A1 → DES

A2 → FEAL

Tabelul 3.2.4 Caracteristicile algoritmilor de criptare (Botezatu, Manta, & Stan, 2011)

Algoritm de

criptare

Durată execuție

algoritm criptare

64 bit data (µsec)

Grad de utilizare

al microprocesorului(%)

Putere

(mW)

DES16 1380 47,57 22,05

DES8 775 26,72 15,67

FEAL 53 1,83 8,05

În Figura 3.2.7 este prezentată variația consumului de energie a sistemului pentru o perioadă

de 60 de minute. Sistemul trece prin toate stările posibile. În primele 16 minute și 15 secunde este

executată doar aplicația 1, apoi este executată și aplicația 2. După încă 15 minute și jumătate nivelul

DoD crește peste 50% determinând schimbarea stării sistemului.

În Figura 3.2.8 este prezentată energia consumată de sistem pe durata celor 60 de minute ale

experimentului. Se constată o scădere cu 31% a energiei consumate de arhitectura adaptabilă față de

situația în care s-ar fi utilizat doar cel mai sigur și cel mai complex algoritm de criptare (DES16)

pentru securizarea întregului sistem.

Pu

tere

(m

W)

Timp (minute)

Figura 3.2.7 Variația consumului de energie pentru scenariul propus (Botezatu, Manta, & Stan, 2010)

Ener

gie(

J )

Timp (minute )

Securitate adaptivă DES16

Figura 3.2.8 Energia consumată de sistem (Botezatu, Manta, & Stan, 2010)

Adaptarea nivelului de securizare al sistemelor dedicate la condițiile de mediu și la

necesarul aplicațiilor poate conduce la reducerea semnificată a necesarului de energie pentru

îndeplinirea funcțiilor sistemului.


34

3.3 Conversie de cod în virgulă mobilă în cod în virgulă fixă

Operațiile cu numere reprezentate în virgulă mobilă nu sunt executate în mod eficient pe

sistemele dedicate. Capabilitățile de calcul ale microcontrolerelor folosite în sisteme dedicate sunt

în general reduse şi, în cele mai multe cazuri, nu este prezent în sistem nici un suport hardware

pentru operaţiile în virgulă mobilă. Pentru a depăşi această problemă, funcţia matematică conţinută

în codul cu virgulă mobilă trebuie să fie exprimată folosind codul în virgulă fixă. Făcând acest lucru

manual – adică, rescrierea funcţiei cu virgulă mobilă într-o secvenţă de operaţii cu numere în

virgulă fixă poate fi o sarcină dificilă și predispusă la erori.

Este prezentată în continuare o metodă de conversie (i.e. transformare) a expresiilor

aritmetice cu operanzi reprezentați în virgulă mobilă în expresii echivalente cu operanzi reprezentați

în virgulă fixă. Metoda poate fi utilizată în programe pentru procesarea digitală a semnalelor (engl.

DSP – Digital Signal Processing) sau în aplicațiile pentru sisteme dedicate (Bârleanu, Băitoiu, &

Stan, 2011). Înlocuirea expresiilor cu operanzi reprezentați în virgulă mobilă cu operaţii specializate

cu numere reprezentate în virgulă fixă (i.e. numere întregi) poate îmbunătăţi foarte mult

performanţa aplicaţiilor pentru sisteme DSP sau sisteme dedicate. Aceasta este o abordare nouă și

metoda este dezvoltată numai pentru expresii care descriu filtre Direct-Form I cu coeficienţi

constanţi şi variabile de intrare ale căror limite de variație inferioare și superioare sunt cunoscute.

Metoda prezentată poate construi soluţii multiple în virgulă fixă pentru acelaşi cod inițial în

virgulă mobilă: de la „complexitate-ridicată-acurateţe-ridicată” la „complexitate-scăzută-acurateţe-

scăzută”. O funcţie de cost conduce deciziile de transformare ale fluxului de date. Prin schimbarea

coeficienţilor funcţiei de cost se pot obţine forme diferite ale expresiei în virgulă fixă.

Transformarea fluxului de date nu este costisitoare ca timp de transformare. Codul în virgulă fixă

generat este testat pe microprocesoare de 8 biţi (AVR ATmega), 16 biţi (MSP430) şi 32 biţi (ARM

Cortex-M3). Acesta oferă, în toate cazurile, o viteză de execuţie mai bună decât dacă utilizarea

codul în virgulă mobilă.

3.3.1 Proiectarea aplicației de conversie a codului

Metoda prezentată este proiectată să transforme produsele scalare cu coeficienţi constanţi

(i.e. literali) reprezentați în virgulă mobilă şi variabile reprezentate în virgulă fixă a căror intervale

de variație sunt cunoscute:

∑

Un flux de date este reprezentat sub forma unei structuri arborescente. Următoarele tipuri de

noduri sunt utilizate pentru a reprezenta fluxul de date:

noduri independente (i.e. noduri terminale – noduri frunză) : noduri ale căror valori

nu depind de valorile altor noduri. Nodurile independente sunt utilizate pentru a

reprezenta constante și variabile: ai, și xi;

operatori (i.e. operații): adunare, înmulţire, deplasare (i.e. scalare) şi schimbarea

semnului. Un operator are unul sau mai mulţi operanzi (i.e. noduri fiu). Aceştia pot fi

noduri independente sau alţi operatori.

Un nod are un interval asociat şi o lungime a părții fracționare a cuvântului pe care îl

reprezintă (engl. FWL – Fractional Word Length). Intervalul reprezintă valorile întregi extreme la

execuție a nodului pe care îl descrie (e.g. variabilă în memorie sau într-un registru al

microcontrolerului).

Scalarea unui nod este o operaţie frecventă întâlnită în procesul de optimizare. FWL-ul unui

nod este o valoare în virgulă fixă. O operație de scalare nu schimbă valoarea în virgulă fixă (sau

reală) a unui nod. Intervalul nodului este întotdeauna alterat împreună cu FWL a nodului.

Un nod poate fi reprezentat în cod ca o valoare întreagă de 16 sau 32 biţi. Valorile care sunt

procesate la nivelul unui nod (i.e. „trec prin nod”) trebuie să aibă cât mai mulţi biţi semnificativi

pentru a oferi precizie, dar, pe de altă parte, trebuie să fie limitate la un interval specific pentru a


35

evita apariția depășirilor în nodul curent sau ulterior în alte noduri ale fluxului de date. FWL-ul nu

este în mod necesar acelaşi pentru fiecare nod.

Metoda proiectată pentru transformarea codului este implementată într-o aplicație Java

datorită suportului pe care îl oferă limbajul Java pentru programarea orientată pe obiecte şi a IDE-

urilor avansate disponibile.

3.3.2 Transformarea fluxului de date

3.3.2.1 Dificultatea problemei

Forma iniţială a fluxului de date reprezintă o imagine fidelă a expresiei produsului scalar în

virgulă mobilă. Există un operator de adunare cu N noduri fiu de tipul un operator de multiplicare

pentru fiecare termen aixi cu două noduri fiu, câte unul pentru fiecare operand.

Manipularea intervalului unui nod care reprezintă un coeficient al filtrului este simplu și se

poate realiza la momentul conversiei fluxului de date.

Manipularea intervalului unui nod care reprezintă un operator este mai complicată. De

exemplu: într-un nod de multiplicare nu există depășire, dar se dorește micșorarea intervalului

deoarece în nodul imediat de mai sus (i.e. nodul părinte) există depășire. Se poate micșora intervalul

din nodul de înmulțire pe două căi:

se poate renunța la un LSB din constanta k (Figura 3.3.1);

se poate introduce un operator de scalare (i.e. deplasare) între mul și add (Figura

3.3.2).

Figura 3.3.1 Modificarea fluxului de date

prin ajustarea unei constante la momentul transformării

Figura 3.3.2 Modificarea fluxului de date

prin inserarea unui operator de deplasare (scalare)

Fiecare soluţie are propriul său impact asupra complexităţii computaţionale a fluxului de

date şi asupra acurateţei.

Tabelul 3.3.1 Caracteristici ale modificărilor fluxului de date

Tip modificare Complexitate Interval eroare (SQNR)

Figura 3.3.1 Deplasare efectuată la momentul

conversiei fluxului de date

Nu introduce operații suplimentare la

Deplasare aplicată coeficienților (literali)

Provoacă pierderi mari de precizie


36

execuție

Figura 3.3.2 Deplasare la execuție

Introduce operații suplimentare la

execuție

Deplasare aplicată operatorilor

Provoacă pierderi mici de precizie

Din Tabelul 3.3.1 se constată că fiecare modificare are avantaje și dezavantaje. Alegerea

aplicării uneia sau alteia dintre modificări se face utilizând o funcție de cost prezentată ulterior în

acest capitol.

3.3.2.2 Complexitatea computaţională

Un nod al fluxului de date are o complexitate computaţională asociată. Aceasta este un

estimator al efortului de calcul necesar pentru obţinerea valorii nodului în timpul execuției. La

momentul proiectării este dificilă evaluarea complexităţii computaţionale exacte. Aplicaţia

proiectată numără pur şi simplu operațiile conţinute în suprafaţa fluxului de date de sub nodul ţintă.

Aceasta este o aproximare destul de bună. O aproximare mai bună se poate obține dacă se asociază

un cost fiecărui tip de operație la execuție. O metrică potrivită pentru acest cost poate fi considerată

numărul de cicluri necesari pentru efectuarea respectivei operații.

3.3.2.3 Intervalul erorii de nod

Fiecare nod al fluxului de date reprezintă o valoare cu virgulă fixă care poate varia în cadrul

unui interval specific. Acest interval face referire la valoarea nodului la execuție, care este în esenţă

o valoare întreagă apropiată de valoarea ideală cu precizie infinită. Astfel, fiecare nod are o eroare

specifică. Intervalul valorii cu precizie infinită care poate „trece prin” nod, şi intervalul întreg

corespunzător de la execuție, pot fi calculate la momentul conversiei, ceea ce înseamnă că, pentru

fiecare nod, intervalul erorii poate fi obţinut fără a executa efectiv codul.

Intervalul erorii pentru nodul unui operator poate fi calculat prin utilizarea unui interval

întreg propriu şi intervalul erorii pentru fiecare nod fiu (Kearfott, 1996). Spre exemplu, intervalul

erorii unui nod de adunare poate fi calculat prin sumarea erorii intervalului pentru fiecare nod fiu.

Valorile limitelor inferioară și superioară pentru un interval de eroare sunt considerate a fi

valori absolute; nu valori relative (engl. ulps – units in last place) (Goldberg, 1991).

3.3.2.4 Căutare multiobiectiv

Cea mai simplă metodă de scădere sau de creştere a intervalului întreg al unui nod este de a

realiza o operaţie de deplasare. Aceasta poate fi realizată la momentul transformării dacă nodul

reprezintă o valoare constantă sau la execuție dacă nodul reprezintă un operator şi, foarte important,

intervalul întreg nu generează depășire pentru oricare tip de dată (e.g. short, int sau long). Dar

acestea nu sunt cazuri frecvente. Situaţia cea mai frecventă este atunci când un operator generează

depăşire iar intervalul său întreg trebuie scăzut. Problema este că intervalul întreg al unui operator

nu poate fi schimbat în mod direct – intervalele întregi ale nodurilor fiu trebuie să fie alterate.

Pentru a forţa intervalul întreg al unui nod de adunare este necesară forţarea intervalului întreg al

fiecărui nod de tip fiu (AND logic). Pentru a forţa intervalul întreg al unui nod de multiplicare este

necesară forţarea unuia sau a mai multor noduri de tip fiu (OR logic).

Pentru a compara diferitele soluţii simultane este necesară combinarea, pentru fiecare

soluţie, a complexităţii şi a intervalului de eroare într-un singur indicator. Pentru a face acest lucru,

se utilizează o funcţie liniară de cost :

Variind coeficienţii funcţiei de cost este ca şi când, spre exemplu, ar fi favorizate soluţii care

introduc operații suplimentare la execuție, dar care dau rezultate de precizie mare în locul soluţiilor

de tip „complexitate-scăzută-acurateţe-scăzută”.

În Figura 3.3.3, costul unei soluţii este direct proporţional cu cea mai scurtă distanţă până la

linia funcţiei de cost. Coeficientul de complexitate (k1) şi coeficientul de eroare (k2) determină


37

împreună panta liniei funcţiei de cost. Sunt utilizaţi doi coeficienţi deoarece altfel ar fi imposibil să

se reprezinte linia verticală (panta + INF). Pentru simplitate, suma coeficienţilor de cost este

menţinută constantă:

k1 + k2 = 1

Funcție de cost

Complexitate

Eroare

«

« Soluție 1 (optimă)

Soluție 2

Figura 3.3.3 Spațiul soluțiilor (Bârleanu, Băitoiu, & Stan, 2011)

Complexitatea și eroarea (i.e. intrările în funcția de cost) calculate în timpul conversiei

fluxului de date sunt mărimi obținute pe cale analitică (Figura 3.3.4). Alți autori estimează eroarea

prin simulare obținând valori mai precise dar timpul de conversie crește foarte mult. Metoda

propusă folosește doar estimări analitice. Acest lucru nu influențează negativ rezultatele deciziilor

luate pe parcursul conversiei deoarece valorile analitice reflectă relațiile dintre valorile reale.

Mărime

interval eroare

Număr

operatori

Valori analitice

Număr de

cicli

SQNR,

Distribuția erorii

Valori reale

Figura 3.3.4 Intrări în funcția de cost

3.3.2.5 Exemplu de transformare

Figura 3.3.5 arată două structuri de flux de date extreme obţinute pentru un produs scalar cu

9 termeni.

a. b.

Figura 3.3.5 Fluxuri de date obținute pentru o expresie cu 9 termeni

a. „complexitate-scăzută-acurateţe-scăzută” şi b. „complexitate-ridicată-acurateţe-înaltă”


38

3.3.3 Tehnici folosite în proiectarea aplicației

3.3.3.1 Informaţii cache ale nodurilor

Procesul de optimizare utilizează în mod intensiv unele atribute ale nodurilor precum

intervalul întreg şi intervalul erorii. Pentru nodurile operator, aceste informaţii depind de nodurile

tip fiu (i.e. operanzi) şi trebuie calculate. Timpul necesar pentru acest lucru poate fi semnificativ

pentru fluxurile mari de date – nodurile de pe nivelele superioare pot genera foarte multe apeluri

ulterioare către noduri de pe nivelele inferioare pentru a obţine informaţiile necesare. În acest scop,

fiecare nod operator este proiectat cu propriul cache.

Figura 3.3.6 arată timpul de execuţie pentru procedura de optimizare a produselor scalare cu

diferite lungimi (se utilizează informaţiile din cache ale nodului).

Ordinul filtrului

mili

secu

nd

e

Timpul necesar pentru transformarea unui filtru FIR

Complexitate scăzută, acuratețe scăzută

Complexitate ridicată, acuratețe ridicată

Figura 3.3.6 Timpi de transformare pentru fluxuri de date generate aleator

3.3.3.2 Căutarea automată a fluxurilor de date

Variația coeficienţilor funcţiei de cost conduce la structuri diferite ale fluxului de date.

Coeficienţii pot fi setaţi manual dar acest lucru nu este foarte practic, deoarece coeficienţii în sine

nu poartă foarte multe informaţii, exceptând cazurile extreme. Într-o situaţie concretă, ar fi de dorit

să se genereze toate fluxurile de date posibile, crearea de coduri pentru toate şi mai târziu selectarea

funcţiei care este cea mai convenabilă.

3.3.4 Generarea codului

Generarea codului C în virgulă fixă pentru un flux de date particular este, în esenţă, simplă.

Cu toate acestea, există două aspecte importante: declararea variabilelor intermediare şi conversiile

de tip explicite.

Codul C poate fi generat în două forme diferite: ca o secvenţă lungă de operații scurte (i.e. o

operație pe fiecare parte dreaptă) şi o mulţime de variabile intermediare sau ca o singură expresie

aritmetică, foarte lungă şi o mulţime de paranteze. Deşi ambele forme de cod sunt echivalente ca

rezultat calculat, prima variantă poate fi utilizată în scopuri de depanare, deoarece toate variabilele

intermediare sunt declarate şi pot fi urmărite pas cu pas.

3.3.5 Evaluarea metodei propuse

3.3.5.1 Acurateţe

Când este generată o funcţie C în virgulă fixă, intervalul de eroare al rezultatului său este

deja cunoscut. Acesta este indicatorul cazului celui mai defavorabil calculat la transformare –

intervalul erorii nodului rădăcină a fluxului de date.


39

Eroarea este considerată ca diferenţa dintre valoarea în virgulă mobilă obţinută cu expresia

originală în virgulă mobilă (i.e. valoarea de referinţă) şi valoarea întreagă obţinută cu codul generat

în virgulă fixă.

Un indicator de precizie relevant este raportul semnal zgomot (SQNR) calculat cu media

valorilor de referinţă absolute (S) şi cu media valorilor de eroare absolute (N) (Cilio & Corporaal,

1999):

(

)

Figura 3.3.7 ilustrează acurateţea şi complexitatea soluţiilor care sunt găsite (automat)

pentru un produs scalar cu 24 termeni. Acurateţea este reprezentată ca diferenţa dintre SQNR cel

mai mare posibil (ideal) şi SQNR al codului generat. SQNR cel mai mare posibil este definit ca

SQNR al unei funcţii care ar returna întregul cel mai apropiat de valoarea ideală în virgulă mobilă.

Complexitate (număr de operatori)

Alt

erar

e SQ

NR

(d

B)

Figura 3.3.7 Soluţiile găsite pentru un produs scalar cu 24 termeni,

coeficienţi aleatorii în intervalul [-1, 1] şi variabile în intervalul [0,4095] (Bârleanu, Băitoiu, & Stan, 2011)

SQNR se micşorează pe măsură ce numărul de termeni ai produsului scalar creşte şi, în mod

special, coeficientul complexității crește în funcția de cost.

3.3.5.2 Timpul de execuție

Timpul de execuţie al codului generat în virgulă fixă depinde de mai mulţi factori:

Structura filtrului. Numărul nodurilor fluxurilor de date este direct proporţional cu

dimensiunea filtrului. Acest lucru este valabil înainte şi după ce fluxul de date este

optimizat.

Funcţia de cost. Variaţia coeficienţilor de cost conduce la decizii de transformare

specifice a fluxurilor de date.

Generarea codului. Dacă codul în virgulă fixă este generat ca o expresie foarte

lungă (i.e. pe o singură linie), atunci cele mai multe valori intermediare sunt alocate

în registre şi, de fapt, numărul operaţiunilor de transfer (engl. load/store) este

micşorat. Acest lucru este în mod special important atunci când nu se aplică nici o

optimizare în procesul de compilare.

Compilatorul. Activarea optimizărilor compilatorului poate accelera foarte mult

codul în virgulă fixă. Acest lucru merită să fie luat în considerare mai ales atunci

când sunt declarate variabile intermediare.

Microprocesorul. Capacităţile microprocesorului nu sunt considerate în detaliu,

deoarece scopul principal este generarea codului independent de platformă. Singura

ipoteză considerată este că nu există unităţi de virgulă mobilă, fapt caracteristic

microprocesoarelor din sisteme dedicate. Unele seturi de instrucţiuni includ

împărțirea întreagă (operația de împărțire se poate utiliza în locul deplasării la

dreapta pe biți), dar nu este o caracteristică generală şi nu este considerată.


40

În Tabelul 3.3.2 este prezentat raportul timpilor de execuție dintre niște fluxuri de date

transformate față de expresiile originale în virgulă mobilă.

Tabelul 3.3.2 Factorul de creștere al performanțelor funcție de microcontroler, compilator și

dimensiunea expresiei produsului scalar (Bârleanu, Băitoiu, & Stan, 2011b)

Microcontroler/

Compilator

Dimensiune produs scalar (număr de termeni)

4 5 8 10

ATMega16/IAR 14,97 14,99 14,60 14,66

STM32/gcc 11,44 10,96 11,25 11,59

LPC1768/IAR 9,51 10,01 10,37 10,86

LM3S3748/IAR 7,15 7,42 7,55 7,76

Factorul de creștere al performanțelor dintre codul în virgulă fixă și codul în virgulă mobilă

poate varia într-un interval larg. O cauză foarte importantă este funcţia de cost folosită în întreaga

optimizare a fluxului de date. Pentru soluţiile de tip „complexitate-ridicată-acurateţe-ridicată”,

viteza poate fi crescută de cel puţin 3 ori. Rezultatele prezentate sunt obţinute cu produsele scalare

cu virgulă fixă cu 4-10 termeni generaţi în mod aleatoriu.

3.3.5.3 Utilizarea memoriei

Codul cu virgulă fixă necesită în general puţin mai mult spaţiu de memorie de cod (e.g.

memorie Flash) decât codul în virgulă mobilă dacă nu sunt utilizate iterații.

Utilizarea SRAM (memorie de date) este determinată în principal de spațiul necesar

variabilelor locale (i.e. alocate pe stivă). Codul în virgulă fixă, dacă este generat ca o singură

expresie aritmetică (i.e. fără variabile intermediare) nu utilizează aproape nici un spaţiu de stocare

pe stivă. Codul în virgulă mobilă necesită un anumit spațiu de stocare deoarece apelează funcții ale

compilatorului pentru emularea operațiilor cu virgulă mobilă.

3.4 Concluzii

În acest capitol au fost prezentate trei module software utilizate pentru dezvoltarea de

aplicații pentru sisteme de calcul dedicate.

Modulul pentru implementarea unui model computațional de tip automat finit este proiectat

pentru a fi generic și ușor de adaptat la cerințele specifice automatelor finite dintr-o aplicație

concretă. Modelul de automat finit este augmentat și cu un mecanism de siguranță care

monitorizează timpul petrecut într-o stare și realizează o tranziție către o stare de siguranță în cazul

depășirii unui interval de timp.

Modulul pentru implementarea de metode se securizare a sistemelor dedicate este proiectat

pentru a folosi un număr de algoritmi de criptare cu diverși parametri de funcționare (e.g. număr de

runde de criptare). Utilizarea diferiților algoritmi de criptare în funcție de nevoile de securizare și

parametrii mediului de operare (e.g. gradul de descărcare al bateriei) ai unui sistem dedicat poate

conduce la o creștere a autonomiei (i.e. perioada de funcționare fără schimbarea bateriei) sistemului.

Aplicația pentru conversia implementării unei expresii aritmetice din utilizarea reprezentării

în virgulă mobilă în reprezentare în virgulă fixă este proiectată având în vedere o funcție de cost

care exprimă compromisul între complexitatea implementării și acuratețea rezultatului obținut.

Toate modulele au fost evaluate cu privire la eficiența implementării, considerându-se

metrici precum dimensiunea memoriei utilizare, numărul ciclurilor necesare execuției sau energia

consumată în diverse scenarii de utilizare.

41

4 Sisteme de calcul dedicate cu circuite digitale reconfigurabile

4.1 Sisteme reconfigurabile

Sistemele de calcul pot rezolva problemele de calcul prin două implementări diferite ale

algoritmilor: în hardware sau în software (Bobda, 2007). Alegerea unei variante de implementare se

face considerând criterii potrivite și relevante pentru aplicația particulară considerată: costul

sistemului, posibilitatea de reprogramare sau reconfigurare după producție, mediul în care este

integrat sistemul și altele.

Criteriile care pot fi avute în vedere conduc la câteva tipuri de arhitecturi, fiecare optimizată

pentru a oferi performanțe într-un anumit sens:

Arhitecturi de uz general (engl. general purpose) (e.g. microprocesoare,

microcontrolere);

Arhitecturi proiectate pentru un anumit domeniu (clasă de probleme) (engl. domain

specific) (e.g. DSP – Digital Signal Processor);

Arhitecturi specifice proiectate pentru o singură aplicație (engl. application specific)

(e.g. ASIC – Application Specific Integrated Circuit).

Dacă se cunoaște a priori clasa de algoritmi care urmează să fie executată, este posibilă

modificarea arhitecturii sistemului de calcul astfel încât să existe o potrivire mai bună între

implementările algoritmilor și resursele de calcul ale arhitecturii. În acest caz se obține o arhitectură

de sistem de calcul potrivită pentru un anumit domeniu (sau clasă de probleme). Calea de date a

unei astfel de arhitecturi este modificată pentru a implementa în mod optim un set de operații

comun aplicațiilor din domeniul respectiv. DSP-urile sunt exemple de arhitecturi de

microprocesoare din această categorie. DSP-urile sunt proiectate pentru sarcini de calcul repetitive

și intensive întâlnite în procesarea semnalelor și sunt utilizate în telecomunicații, aplicații

multimedia și alte aplicații. Cea mai frecvent menționată caracteristică arhitecturală a unui circuit

DSP este capacitatea acestor microprocesoare de a executa una sau mai multe operații de tip

multiplicare-adunare într-un singur ciclu. De asemenea, datorită caracterului repetitiv al calculelor

aplicațiilor de procesare de semnale, circuitele DSP folosesc îmbunătățiri arhitecturale care permit

execuția eficientă a buclelor de program.

Dacă un sistem de calcul execută doar o singură aplicație cunoscută a priori atunci este

posibilă proiectarea arhitecturii sistemului de calcul astfel încât să permită o execuție foarte

eficientă a aplicației respective și numai a acestei aplicații. Această variantă de arhitectură poate fi

descrisă ca adaptarea hardware-ului la aplicația executată. Spre exemplu, în procesările multimedia

este necesară codarea respectiv decodarea semnalelor procesate conform cu standarde bine definite.

Aceste procese trebuie implementate eficient (cu viteză de execuție mare și cu latență mică) și ca

atare s-au proiectat circuite de tip codec special proiectate pentru acest tip de procesare.

Microprocesoarele care realizează doar un anumit tip de procesare se numesc ASIP (engl.

Application-specific instruction-set processor) și sunt implementate în mod uzual cu circuite de tip

ASIC (engl. Application Specific Integrated Circuit).

Sisteme de calcul dedicate cu circuite digitale reconfigurabile

42

Pentru o anumită aplicație, la un moment dat, structura spațială a sistemului se modifică

pentru a permite implementarea și folosirea celor mai potrivite resurse pentru execuția aplicației.

Circuitele FPGA reprezintă baza tehnologică pentru implementarea arhitecturilor de calcul

reconfigurabile, oferind premizele pentru construirea de sisteme de calcul evolutive (Sekanina,

2003). Flexibilitatea circuitelor FPGA poate fi exploatată și prin implementarea de sisteme capabile

să detecteze sau să tolereze defectele (Bolchini, Miele, & Sandionigi, 2011).

4.2 Spatial computing

Există astăzi multe arhitecturi de circuite integrate digitale care includ în structura lor un

microprocesor fix cuplat la o structură reconfigurabilă. Acest fapt oferă mai multe opțiuni pentru

alocarea sarcinilor de calcul sau de control pe una dintre cele două infrastructuri existente. Sarcinile

de control pot fi alocate pe microprocesor deoarece poate implementa decizii complexe și

neregulate (i.e. neuniforme) iar sarcinile de calcul care sunt mai uniforme și au nevoie de viteză de

procesare mai ridicată pot fi alocate pe structura reconfigurabilă (Steiner, Shenoy, Isaacs, &

Pellerin, 2006).

Codul original executat pe microprocesor poate fi partiționat pentru a fi executat fie pe

microprocesor, fie pe structura reconfigurabilă la diverse nivele de granularitate: funcție, buclă sau

bloc de instrucțiuni. Nivelul de granularitate se alege funcție de resursele structurii reconfigurabile,

de costul interconectării și al comunicațiilor dintre microprocesor și structura reconfigurabilă.

4.3 Structură pentru monitorizarea timpului de execuție al subprogramelor

Multe sisteme dedicate sunt folosite pentru a implementa aplicații critice din punct de

vedere al siguranței și care trebuie să răspundă la cerințe de timp real. Cerințele de timp real sunt

derivate din caracteristicile funcționale ale sistemului fizic controlat de aplicație.

Se prezintă în continuare proiectarea unui modul digital (denumit watchdog), care poate fi

inclus în microprocesoare din sisteme dedicate sau în sisteme cu resurse reconfigurabile pentru a

asigura o mijloc de detecție și semnalare a nerespectării caracteristicilor de timp a aplicațiilor

executate (Stan, Panduru, & Ungureanu, 2010). Monitorizarea comportamentului temporal este

realizată prin măsurarea timpului de execuție a subprogramelor (i.e. rutinelor, funcțiilor) și

compararea rezultatelor cu valori de referință. Modulul implementat nu presupune modificări ale

structurii interne a arhitecturii microprocesoarelor din sisteme dedicate și poate fi de asemenea

folosit în sisteme fără cerințe stricte de timp real. În aceste sisteme se pot implementa mecanisme de

verificare a securității funcționării prin care se detectează diverse condiții anormale de operare care

sunt observabile prin alterarea timpului de execuție al subprogramelor (e.g. inserția codului unui

virus sau apariția de întreruperi externe prea frecvente).

4.3.1 Studii similare

Există numeroase preocupări de cercetare care prezintă metode de verificare a corectitudinii

execuției codului pe microprocesoare prin utilizarea de diverse îmbunătățiri arhitecturale.

În lucrarea (Mahmood & McCluskey, 1988), autorii prezintă conceptul de microprocesor

watchdog și evidențiază unele implementări disponibile la momentul respectiv. Un microprocesor

watchdog este un coprocesor care prin monitorizarea comportamentului procesorului primar

realizează detectarea de erori la nivelul sistemului. Informația utilizată de microprocesorul

watchdog pentru a detecta erorile de funcționare poate fi: modelul de accesare al memoriei, fluxul

de control al execuției aplicațiilor, semnalele de control, sau plauzibilitatea rezultatelor calculate.

Funcționarea unui microprocesor watchdog are două faze. În prima fază, procesorului watchdog îi


43

sunt furnizate niște informații despre care descriu funcționarea corectă a procesorului care urmează

să fie verificat iar în cea de-a doua fază acesta colectează informațiile relevante concomitent cu

funcționarea procesorului primar. Detectarea erorilor este realizată prin compararea informațiilor

obținute în timpul execuției cu informația de referință furnizată inițial.

Pentru structura de monitorizare propusă este utilizată aceeași bază teoretică dar, informația

despre corectitudinea operării este furnizată de timpul de execuție al subprogramelor.

Pentru ca arhitectura originală să poată utiliza mecanismele adăugate pentru detectarea

erorilor, toate soluțiile prezentate anterior includ un model sau metodologie de proiectare (engl.

design flow) dedicată.

4.3.2 Arhitectura structurii de monitorizare

Modulul de monitorizare (watchdog – WDT) este conectat la magistrala de adresă și la

magistrala de instrucțiuni ale microprocesorului, așa cum se arată în Figura 4.3.1. Operarea

anormală este semnalată prin generarea unor semnale de control precum reset, întrerupere sau NMI

(întreruperi nemascabile) sau prin generarea unor coduri de instrucțiuni adecvate pe magistrala de

instrucțiuni.

INT/

NMI

MCUMEMEORIE

DE COD

WATCHDOG

M

U

X

MAGISTRALA

ADRESE

INSTRUCȚIUNE

INS

TR

UC

ȚIU

NE

WD

T

SE

LC

ȚIE

RST

Figura 4.3.1 Arhitectura structurii de monitorizare (Stan, Panduru, & Ungureanu, 2010)

Modulul de monitorizare este construit prin utilizarea următoarelor structuri de date și

algoritmi.

Stiva watchdog (WS) este o structura de date de tipul ultimul intrat - primul ieșit care

memorează adresele de început ale subprogramelor apelate. Vârful stivei watchdog conține adresa

de start a ultimului subprogram apelat. Această structură de date este folosită pentru a extrage cu

ușurință adresa de start a ultimului subprogram accesat atunci când este detectată pe magistrala de

instrucțiuni o instrucțiune de revenire din funcție (i.e. return).

Măsurarea timpului de execuție este realizată cu ajutorul unui tablou de contoare (engl.

timers); fiecare contor poate fi selectat individual cu scopul de a-i reseta valoarea sa internă, sau de

a-i activa sau dezactiva funcționarea (i.e. de contorizare). Fiecărui subprogram monitorizat îi

corespunde un contor pentru măsurarea timpului de execuție. Numărul de contoare implementate

limitează numărul de subprograme monitorizate simultan, dar se poate alege convenabil pentru a se

potrivi cerințelor aplicației.

Modulul watchdog folosește un tabel, numit tabelul cu informații despre monitorizare (engl.

MIT – Monitoring Info Table) care conține informații despre comportamentul temporal anticipat,

pentru toate subprogramele, sau, numai pentru cele critice, funcție de cerințele aplicației. Tabelul

conține adresa de start a subprogramelor monitorizate, indexul timer-ului din tabloul de contoare

utilizat pentru a monitoriza comportamentul temporal și valorile pentru patru parametri care descriu

comportamentul temporal al subprogramului, așa cum este prezentat în Figura 4.3.2:


44

0 time

Limita inferioară

Timp execuție

pentru cazul cel

mai favorabil

Limita superioară

Timp execuție

pentru cazul cel

mai defavorabil

Variația timpului de

execuție

Toleranța pentru

cazul cel mai

favorabil

Toleranță pentru

cazul cel mai

defavorabilTÂRZIUDEVREME

Interval acceptabilInacceptabil Inacceptabil

Figura 4.3.2 Parametrii de timp monitorizați, (Stan, Panduru, & Ungureanu, 2010)

Aceste valori definesc cinci posibile intervale de timp pentru execuția unui subprogram, așa

cum se arată în Figura 4.3.2. Intervalul de timp acceptabil pentru execuție este definit de diferența

dintre UTB și LTB. Toate celelalte valori pentru timpul de execuție mai mari decât UTB sau mai

mici decât LTB sunt inacceptabile pentru sisteme cu cerințe de timp real sau pot indica un

comportament temporal anormal.

Modulul watchdog monitorizează magistrala de adrese pentru memoria cod și instrucțiunea

extrasă din memoria cod. Modulul decodează instrucțiunea cu scopul de a detecta instrucțiunile de

apel de subprograme și instrucțiunile de revenire corespunzătoare.

Atunci când se detectează o nerespectare a intervalului de timp, se declanșează un mecanism

de tratare a acestei situații. Există trei posibile mecanisme de gestionare:

Resetarea microprocesorului – acesta este metoda uzuală pe care o utilizează un

modul watchdog clasic;

Emiterea unei întreruperi NMI sau INT spre microprocesor – această metodă poate fi

utilizată dacă un mecanism de tratare este implementat în software ca o rutină de

tratare pentru întreruperea NMI sau INT;

Inserarea unei instrucțiuni sau a unei secvențe de instrucțiuni în microprocesor –

instrucțiunile inserate pot fi un apel sau un salt la o rutină de gestionare.

Modulul watchdog utilizează un automat finit pentru a controla operațiile necesare

funcționării sale. Intrările automatului finit sunt semnale de condiție generate de operații logice între

valorile WS, MIT, magistrala de adrese, magistrala de instrucțiuni, așa cum este explicat în

continuare. Ieșirile automatului finit sunt semnale de control. Funcționarea automatului finit de

control al modului watchdog este ilustrată în Figura 4.3.3

IDLETMR

STA

EXP

TMR

STP

Condiții

C1 Detecție adresă rutină

monitorizată în instrucțiunea CALL

C2 Pornire timer

C3 Instrucțiune RET pentru cea

mai recent apelată rutină

C4 Oprire timer

C5 Timer expirat SAU

Instrucțiune RET prea devreme

C6 Excepție executată

C1

C2

C3

C4

C5 C6

Figura 4.3.3 Automatul finit pentru controlul structurii de monitorizare

(Stan, Panduru, & Ungureanu, 2010)

Dezvoltarea unei aplicații care folosește această arhitectură de monitorizare trebuie să

urmeze un anumit model de dezvoltare. Prima dată se proiectează și implementează software-ul.

Pentru generarea modulului de monitorizare, subprogramele critice trebuie să fie determinate iar

apoi trebuie calculate caracteristicile lor cu privire la timpul de execuție. Acestea pot fi obținute

utilizând analiza statică sau prin testări repetate (Wilhelm, et al., 2008). Cu ajutorul informațiilor

din această fază, modulul de monitorizare poate fi generat, și, împreună cu aplicația, se

implementează arhitectura finală. Etapele procesului de proiectare sunt reprezentate în Figura 4.3.4.


45

Proiectare și

implementare

aplicație SW

Determinare

rutine critice

Estimare timp

execuție

Simulare Testare

Compilare

aplicație SW

Generare modul

de monitorizare

Generare

arhitectură

Figura 4.3.4 Proiectarea unui sistem care utilizează structura de monitorizare


4.3.3 Evaluarea structurii de monitorizare

Modulul de monitorizare implementat oferă un mecanism care permite verificarea dinamică

a comportamentului temporal al subprogramelor.

Pentru a evalua modulul de monitorizare, s-a utilizat o platformă de dezvoltare cu circuitul

FPGA Spratan3E de la Xilinx și un microprocesor soft-core cu structură simplă (Figura 4.3.5),

PicoBlaze (Xilinx Inc., PicoBlaze 8-bit Embedded Microcontroller User Guide, 2011). Acesta este

realizat și optimizat de Xilinx pentru FPGA-urile sale. S-au creat două scenarii: în primul s-a

sintetizat doar PicoBlaze-ul și în al doilea s-a extins primul scenariu cu includerea modulului

watchdog. Costul pentru implementarea celor doua scenarii este prezentat în Tabelul 4.3.1.

Figura 4.3.5 Schema bloc pentru microcontrolerul Picoblaze (Xilinx Inc., PicoBlaze 8-bit Embedded

Microcontroller User Guide, 2011)

S-a observat că modulul de monitorizare implementat utilizează substanțial mai multe

resurse în comparație cu microprocesorul. Acest fapt poate fi explicat de simplitatea procesorului

soft-core și prin faptul că acesta este puternic optimizat pentru implementare în FPGA-ul folosit.

Modulul de monitorizare utilizează numeroase resurse de memorie pentru a implementa stiva,

pentru a stoca informațiile relevante cu privire la timpul de execuție pentru fiecare subprogram

monitorizat, și, de asemenea, pentru contoarele de timp. Modulul utilizează resurse logice cu scopul

de a implementa comparatoare mari și numeroase pentru logica de comparație a adreselor de pe

magistrala de adrese cu adresele de început a funcțiilor monitorizate stocate în modulul watchdog.


46

Tabelul 4.3.1 Resursele utilizate de structura de monitorizare


Resurse Picoblaze Picoblaze cu modul WDT

Slice Flip Flops 76 129

4 input LUTs 176 411

Occupied slices 98 236

Frecvență (MHz) 116.136 93.092

Poate fi de asemenea observată degradarea frecvenței maxime de operare. Acest fapt este o

consecință a existenței unei căi critice în implementarea modulului de monitorizare. Aceasta poate

fi eliminată prin reproiectarea stivei sau prin specificarea unor constrângeri adiționale în procesul de

sinteză sau chiar prin schimbarea instrumentelor de sinteză.

În cazul procesoarelor mai complexe, este de așteptat ca resursele suplimentare necesare

pentru implementarea modulului de monitorizare să fie mai puțin semnificative relativ la resursele

logice necesare implementării procesorului.

4.4 Structură pentru monitorizare a execuției aplicațiilor pe un MPSoC

MPSoC (engl. MultiProcessor System on Chip) sunt arhitecturi de calcul care utilizează

unități de procesare multiple în acelaşi circuit integrat pentru a furniza nivelul dorit de performanţă

şi disipare de putere pentru aplicaţiile executate. Structurile de tip MPSoC sunt atractive deoarece

permit executarea de aplicaţii complexe, formate din mai multe procese. Procesele sunt executate

simultan pe unitățile de procesare disponibile ale structurii MPSoC şi realizează schimbul de date

utilizând resursele de memorie care pot fi organizate ca zone tampon (engl. buffer) cu model de

acces de tip FIFO. Aplicaţiile pot avea constrângeri de timp real, iar în acest caz orice abatere de la

timpul de procesare alocat pentru un proces poate afecta negativ calitatea serviciului furnizat de

sistem.

Este prezentată o metodă care poate fi utilizată pentru a detecta abateri de la timpul de

procesare alocat proceselor într-un MPSoC (Stan, Valachi, & Bârleanu, 2011). Unitățile de

procesare ale structurii MPSoC sunt augmentate cu o structură de monitorizare care urmăreşte

evenimentele din infrastructura de comunicație din interiorul MPSoC. Toate transferurile de date

sunt monitorizate, iar parametrii lor de timp sunt comparați cu un comportament de referinţă

aşteptat.

Complexitatea unui MPSoC şi a aplicaţiilor executate fac dificilă analiza comportamentului

în timp a sistemului şi a predictibilităţii în momentul proiectării. Fluxul datelor dintr-o aplicaţie de

procesare a datelor este descris folosind grafuri de fluență aciclice, așa cum este prezentat în Figura

4.4.1.

Aplicație 2

Aplicație 1

Task 1 Task 2

Task 1 Task 2

Task 3

intrare ieșire

intrare ieșire

Figura 4.4.1 Model de descriere a aplicațiilor executate pe un MPSoC

prin grafuri aciclice (Stan, Valachi, & Bârleanu, 2011)


47

Aplicaţiile pot interfera din cauza resurselor partajate ale unui MPSoC şi astfel pot apărea

conflicte la accesul resurselor. Interferenţa poate cauza modificarea comportamentului temporal al

aplicaţiilor. Pentru a elimina aceste conflicte pot fi furnizate mai multe resurse . Această soluţie ar

mări costul părții hardware a sistemului.

Comportamentul în timp al aplicaţiilor poate de asemenea fi modificat de către variaţiile

frecvenţei ceasului (e.g. cauzate de către variaţiile de temperatură din diverse părți ale circuitului)

sau de către unele defecte hardware.

Ţinând cont de motivele menţionate anterior, este necesară proiectarea unei structuri de

monitorizare pentru monitorizarea comportamentului temporal al aplicaţiilor executate pe o

platformă de calcul de tip MPSoC.

4.4.1 Arhitectura sistemului MPSoC

4.4.1.1 Hardware

În Figura 4.4.2 este prezentată arhitectura modulului microprocesor pe o platformă MPSoC.

Un modul al unui sistem MPSoC are mai multe componente. Modulul microprocesor execută codul

aplicaţiilor. Este utilizat microprocesorul Microblaze de la Xilinx (Xilinx Inc., MicroBlaze Soft

Processor Core, 2011), întreaga platformă MPSoC fiind implementată într-un circuit FPGA Xilinx

Virtex6 .

Microprocesor

Monitor

Timer

Rețea de interconectare NoC

PLB

EDI

Modul

microprocesor

Domeniu de clock al

modulului microprocesor

Variable

processor

clock domain

FSL

INT

Domeniu de clock al NoC

DMAs

Memorie

LocalăVFCU

FSL

clk

DTL DTL

LMB

DTL

Figura 4.4.2 Arhitectura modulului microprocesor pe o platformă MPSoC

(Stan, Valachi, & Bârleanu, 2011)

Memoria locală este utilizată pentru stocarea codului și a datelor proceselor locale. Memoria

are un port LMB (Xilinx Inc., Local Memory Bus, 2011) pentru realizarea de tranzacţii cu

microprocesorul. Memoria are două zone: una este accesibilă doar pentru microprocesor prin LMB,

iar cealaltă zonă este utilizată ca memorie de comunicație (CMEM). Această zonă a memoriei este

mai departe împărţită în memorie de comunicație pentru fluxul de ieșire (CMEM OUT) şi memorie

de comunicație pentru fluxul de intrare (CMEM IN), după cum este detaliat în Figura 4.4.3.

Memoria de comunicație este accesibilă pentru tranzacţiile DMA care transferă datele între nodurile

de procesare ale unui MPSoC. Fiecare aplicaţie care are alocate procesele pe un modul

microprocesor are o unitate DMA şi o zonă de memorie de comunicație. Modulele DMA sunt

conectate la magistrala PLB (Xilinx Inc., Processor Local Bus, 2011) a microprocesorului. DMA-

urile sunt capabile să deruleze transferuri utilizând protocolul DTL (Device Transaction Level)

(Philips Semiconductor Inc., 2002).


48

Sistemul utilizează un contor de timp (engl. timer) care este folosit de un nucleu de sistem

de operare pentru planificarea proceselor denumit COMPOSE (Hansson, et al., 2011).

O unitate pentru controlul a frecvenţei și voltajului (engl. VFCU – Volatge Frequency

Control Unit) este utilizată pentru gestionarea puterii consumate de un modul microprocesor.

Aceasta este conectată la microprocesor utilizând o magistrală de comunicație de tip FSL (Xilinx

Inc., Fast Simplex Link, 2011) a microprocesorului Microblaze. Unitatea este responsabilă de

setarea frecvenţei de operare a microprocesorului şi de asemenea de validarea sau invalidarea

ceasului pentru o perioadă de timp specifică şi programabilă.

Modulul de monitorizare este un sistem care urmăreşte tranzacţiile pe magistrala de

comunicație PLB şi implementează structura de monitorizare. Detaliile implementării şi operării

sale sunt descrise în paragrafele următoare.

Toate modulele sistemului MPSoC sunt conectate prin rețeaua de interconectare Aethereal

NoC (engl. NoC – network on chip) (Goossens, Dielissen, & Radulescu, 2005). Această rețea este

proiectată pentru a furniza aplicaţiilor un nivel garantat de performanţă și servicii de comunicații.

Rețeaua are porturi DTL pentru tranzacţii de date şi de asemenea porturi EDI (engl. EDI – Event

Distribution Interconnect) (Vermeulen , Goossens , & Umrani , 2008) care sunt folosite pentru

difuzarea de evenimente la viteză ridicată între structurile de monitorizare.

Modulele cu microprocesoare şi rețeaua de interconectare sunt implementate în domenii de

ceas distincte. Fiecare zonă are propriul ei ceas şi de aceea sunt utilizate module pentru trecerea

semnalelor dintr-un domeniu de ceas în altul (Cummings, 2002).

4.4.1.2 Infrastructura de comunicație

Comunicația datelor între procesele alocate pe modulele microprocesor ale MPSoC este

implementată folosind protocolul C-HEAP (Nieuwland, et al., 2002) şi structuri de tip FIFO.

Detaliile infrastructurii de comunicație sunt prezentate în Figura 4.4.3.

Task

Producător

Task

Consumator

Microprocesor

DLMB

CMEM IN

CMEM OUT

RC

WC

INDICATOR CITIRE

INDICATOR SCRIERE

BUFER FIFO

STRUCTURĂ DE

DATE FIFO

DL

MB

DL

MB

PL

B

PL

B

DMAMON

DT

L

DT

L

Copie a RCWC

TOK Bufer

DT

L

Aethereal NoC

ED

I

TOK

MODULUL 1 EXECUTĂ

TASKUL PRODUCĂTOR

Alocarea resurselor hardware

Model de comunicație între taskuri

CMEM IN

CMEM OUT

Copie a WCRC

TOK

TOK

PLB

Microprocesor

DLMB

DL

MB

DL

MB

PL

B

PL

B

DMAMON

DT

L

DT

L

DT

L

ED

I

MODULUL 2 EXECUTĂ

TASKUL CONSUMATOR

PLB

Figura 4.4.3 Resursele alocate comunicațiilor dintre două module microprocesor al unui MPSoC


Modelul de comunicație dintre procese este unul de tip producător-consumator care

utilizează o structură de date de tip FIFO cu un buffer circular pentru memorarea datelor şi două

indicatoare (i.e. pointeri) de date care indică poziţia de citire (RC) şi cea de scriere (WC) în buffer.


49

Pentru două procese care sunt alocate pe două module microprocesor distincte, buffer-ul

circular este alocat în memoria locală a modulului microprocesor pe care se execută procesul

consumator. În acest fel, numai operaţiile de scriere transferă pachetele de date prin rețeaua de

interconectare NoC de la modulul consumator către modulul producător.

Informaţia de control FIFO este reprezentată de indicatorii de citire şi scriere din modulele

consumatorului şi ai producătorului. Acest lucru este realizat pentru a mări viteza execuţiei în caz că

sistemul de operare verifică starea unui buffer circular pentru a testa disponibilitatea datelor de

intrare pentru procese. Un proces este activat de către planificatorul sistemului de operare numai

dacă există suficiente pachete de date în buffer-ul de intrare pentru acel proces.

Infrastructura de monitorizare urmăreşte accesele memoriei care sunt emise către adrese

care corespund buffer-ului circular sau informaţiilor de control ale buffer-elor. În acest fel,

infrastructura de monitorizare se leagă în mod non-invaziv de sistemul monitorizat. Astfel,

infrastructura de comunicație furnizează datele principale de intrare în cadrul structurii de

monitorizare.

Într-o platformă MPSoC, infrastructura de comunicație este un punct potrivit de observaţie

pentru funcţionarea internă a sistemului pentru că operarea acestuia utilizează din plin infrastructura

de comunicație. Corectitudinea operării poate fi evaluată analizând parametrii de timp ai

comunicației dintre procesele din cadrul unui MPSoC.

4.4.2 Arhitectura structurii de monitorizare

Structura de monitorizare este implementată ca un dispozitiv periferic alocat (engl. mapped)

în spaţiul de adresare al modului microprocesor. Arhitectura de nivel înalt a structurii de

monitorizare este prezentată în Figura 4.4.4.

ED

I

Registre cu

parametri

programabili

Nucleu de

monitorizare

Registre de

control

Registre de

stare

PL

B

Interfața cu

microprocesorul

Figura 4.4.4 Arhitectura structurii de monitorizare (Stan, Valachi, & Bârleanu, 2011)

Structura de monitorizare implementează un mecanism de tip watchdog cu fereastră (engl.

window watchdog) care înregistrează numărul de evenimente apărute pe magistralele de

comunicație apărute înaintea unei limite de timp (TooEarly Counter), între două limite de timp

(Event Counter) sau după o limită de timp (TooLate Counter). Limitele intervalelor de timp utilizate

pentru urmărirea unui anumit eveniment al magistralei de comunicație sunt stocate în registre cu

parametri programabili şi setați de către aplicaţii la valori adecvate. Aceste valori sunt calculate la

timpul proiectării şi verificate prin experimente (Wilhelm, et al., 2008).

Comportamentul temporal corect şi preconizat al aplicaţiilor care rulează pe o platformă

MPSoC poate fi determinat experimental prin executarea şi caracterizarea aplicaţiei într-un mediu

sigur și fără interferențe.

Structura de monitorizare are două module. Modulul de interfață cu microprocesorul

implementează o interfaţă pentru un dispozitiv slave PLB şi conține registrele de control, date (i.e.

parametri) şi stare.

Registrele de control conţin câmpuri cu biţi care sunt utilizaţi pentru pornirea sau oprirea

operării structurii de monitorizare şi de asemenea pentru a porni sau opri cronometrarea

evenimentelor care sunt detectate prea devreme sau prea târziu. Aceste setări sunt efectuate de

aplicaţii conform necesităţilor lor şi oferă un mod flexibil de monitorizare a evenimentelor.


50

Registrele de stare ai structurii de monitorizare sunt încărcaţi cu valorile contoarelor de

evenimente. Aceste registre pot fi citiţi de către aplicaţii sau de către sistemul de operare care pot

acţiona adecvat atunci când sunt detectate condiţii de operare anormale. Valorile acestor registre pot

declanșa excepţii care sunt tratate într-o manieră adecvată aplicaţiei.

Figura 4.4.5 prezintă detalii de implementare ale structurii de monitorizare. Modulul

Detector al magistralei PLB compară datele programate din registrele cu parametri programabili cu

valorile curente ale magistralei PLB. Daca este detectată o potrivire, este activat un semnal care este

intrare pentru nucleul de monitorizare FSM (engl. Finite State Machine). Acest modul este un

mecanism de tip watchdog cu fereastră care verifică dacă un semnal de intrare este activat între

două valori programate ale unui contor de timp. Cele două valori definesc un interval de timp.

Contorul din interiorul FSM-ului utilizează ca semnal de ceas, ceasul NoC-ului. Această sursă a

semnalului de ceas este utilizată de către toate structurile de monitorizare dintr-un MPSoC. Această

alegere asigură o sursă de timp consistentă pentru toate structurile de monitorizare.

Modul de monitorizare

(Automat finit pentru un

Watchdog cu fereastră)

Modul detector de

evenimente pe magistrala

PLB PLB_ABus

PLB_wrDBus

PLB_RNW

SL_AddrAck

Enable

PLB_PAValidREF_ABus

REF_wrDBus

Enable

EnableHi

EnableLo

Event Counter

Event

Nucleu de monitorizare

TooLate Counter

TooEarly Counter

LimLate

LimEarly

Event Counter

TooLate Counter

TooEarly Counter

ED

I

EDI

Signals

Detector local de evenimente

Monitorizare a evenimentelor din alte

module

D

E

C

Sta

re

D

E

C

Monitorizare a evenimentelor locale

Figura 4.4.5 Structura de monitorizare (Stan, Valachi, & Bârleanu, 2011)


51

Graful de fluență pentru mecanismul window watchdog FSM este prezentat în Figura 4.4.6.

Două dintre intrări (Early şi Late) pentru FSM sunt generate de către două comparatoare ale valorii

curente a contorului cu cele ale limitelor programate din registrele parametrilor programabili. A

treia intrare (Event) este generată de modulul Event Detector şi reprezintă apariția evenimentului

monitorizat. FSM-ul are o ieşire (RST) utilizată pentru resetarea valorii contorului. FSM-ul conţine

o stare de resincronizare pentru reluarea monitorizării după evenimente apărute ulterior ferestrei

normale de apariție.

IDLE

RST

RUN

nRST

TooEarly

RST

TooLate

RST

OnTime

RST

ReSynch

RST

0 0 0

Enable

1 - -

0 - -

0 - 1

1 - -

0 - -

Event AND Early AND Late

Conditions

1 0 0 0 - -

1 - -

1 1 -

1 - -

0 - -

!Enable

Enable

!Enable

Figura 4.4.6 Graful de fluență pentru controlul structurii de monitorizare


Evenimentele magistralei PLB detectate şi contorizate local de către un modul

microprocesor sunt de asemenea difuzate către celelalte module utilizând interfaţa EDI. Această

interfaţă este una cu latenţă joasă, comparativ cu cele DTL ale NoC-ului. Semnalele interfeţei EDI

nu sunt rutate conform politicii de rutare din cadrul NoC. Ele sunt implementate ca simple

conexiuni care trec prin router-ele interne NoC. Utilizarea inițială a interfeţei EDI este pentru

testare şi verificare post-silicon (Larsson, Vermeulen, & Goossens, 2010), (Goossens, Vermeulen,

& Nejad, 2009). Acum este propusă o altă utilizare a acestei interfeţe: este folosită pentru a

semnala evenimente între module în momentul execuției, permiţând astfel verificarea execuției

aplicaţiilor. Folosind această interfaţă de comunicație simplă, utilizarea acestei resurse crește până

la 100% de-a lungul ciclului de viaţă al unui produs: în fazele de proiectare, testare şi utilizare.

Având în vedere faptul că structura de monitorizare utilizează intensiv contoare, iar

evaluarea corectitudinii depinde de valorile contoarelor, este recomandată folosirea unei

implementări robuste a contoarelor, precum cea prezentată în (Papadomanolakis, Kakarountas,

Sklavos, & Goutis, 2002).

4.5 Arhitectură pentru transformarea dinamică a codului în module hardware

Implementarea unui sistem de calcul după un set de specificații – funcții pe care sistemul

trebuie să le îndeplinească, poate lua una dintre următoarele forme:

Alocarea statică a funcțiilor sistemului pe componente hardware și software. Odată

ce s-a făcut această alocare, sistemul capătă o anumită structură hardware fixă care

este utilizată fără modificări pe întreaga durată de viață a sistemului. Acesta este


52

modul cel mai uzual de implementare, care nu implică utilizarea de componente

reconfigurabile (e.g. circuite FPGA).

Alocarea dinamică a funcțiilor sistemului pe componente hardware și software.

Acest mod de implementare este posibil prin utilizarea de componente

reconfigurabile (e.g. circuite FPGA): se implementează o mare parte a funcțiilor

sistemului în componente software executate de microprocesoare incluse în

circuitele FPGA (engl. soft-core processors), apoi se realizează o analiză a execuției

printr-un proces de evaluare a performanțelor (engl. profiling). Această abordare se

bazează pe detectarea nucleelor de calcul existente în software (e.g. nuclee repetitive

care realizează diverse sarcini de calcul precum procesări de semnale). Informaţiile

extrase după procesul de analiză dau posibilitatea implementării în hardware a unor

porțiuni de software care pot beneficia în acest fel de o scădere a timpului de

execuție (i.e. o accelerare a execuției). În acest fel, o parte a sarcinilor de calcul sunt

executate de către module hardware dedicate, fără utilizarea microprocesorului

(Singh, 2011).

4.5.1 Arhitectura sistemului reconfigurabil

Etapele funcționării unui sistem reconfigurabil capabil de transformarea dinamică a unor

porțiuni de software în module hardware (Popa & Stan, 2010) sunt ilustrate în Figura 4.5.1.

SINTEZA HARDWARE

&COMPILARE SOFTWARE

EXECUȚIE SISTEMIMPLEMENTARE SOFTWARE

COLECTARE INFORMAȚIIDESPRE EXECUȚIE

GENERARE MODUL HARDWARE

SINTEZA MODUL HARDWARE&

INSTRUMENTARE COD

RECONFIGURARE SISTEM

EXECUȚIE SISTEMIMPLEMENTARE SOFTWARE &

HARDWARE

Figura 4.5.1 Funcționarea unui sistem reconfigurabil, după (Popa & Stan, 2010)

Pe baza informațiilor extrase prin monitorizarea execuției este generat un modul hardware

(sau mai multe) a cărui funcționalitate este identică cu blocul de instrucțiuni pe care îl va înlocui

ulterior în funcționarea sistemului. Modulul hardware generat este sintetizat în elementele

structurale specifice circuitului FPGA folosit (e.g. LUT – look up tables, multiplexoare, bistabile) și

apoi implementat (i.e. execuția proceselor de plasare și rutare - place an route). Simultan cu acest

proces este necesară și instrumentarea codului aplicațiilor care sunt executate de sistem pentru a


53

folosi noul modul hardware. Porțiunile aplicațiilor (i.e. blocurile elementare) care au fost folosite

pentru a genera modulul hardware sunt înlocuite în codul aplicațiilor cu secvențe de cod care

realizează interfațarea cu modulul hardware prin care se realizează transferul datelor de intrare,

respectiv ieșire dintre microprocesor și modulul hardware.

Sistemul este reconfigurat cu noua structură care conține modulul hardware precum și

aplicațiile software instrumentate (i.e. modificate). Din acest moment, execuția aplicațiilor

utilizează atât vechea infrastructură (i.e. cea clasică) cu microprocesor cât și noul modul hardware.

În Figura 4.5.2 este prezentată structura propusă pentru un sistem reconfigurabil care este

alcătuit din două module:

Sistem cu microprocesor: este un modul cu structură clasică pentru un sistem de

calcul și care este proiectat pentru execuția de aplicații software. Este alcătuit dintr-un

microprocesor împreună cu memoria necesară stocării datelor și codului aplicațiilor.

Aplicațiile software executate de acest modul sunt monitorizate de sistemul de

reconfigurare pentru a detecta și extrage acele porțiuni care pot fi implementate în

module hardware.

Sistem de reconfigurare: este un modul care monitorizează execuția aplicațiilor de

către microprocesor și sintetizează un modul hardware (sau mai multe) cu

funcționalitate identică, cu porțiuni cu structură de execuție secvențială (i.e. fără

ramificații) ale aplicațiilor executate. Structurile decizionale, care sunt frecvente în

aplicații (e.g. instrucțiuni de salt sau apel de funcție), pot implementa structuri de

control foarte diverse și complexe a căror decodare este dificilă și necesită resurse

însemnate pentru o implementare a unui algoritm pentru un sistem reconfigurabil.

Pentru unele cazuri particulare și simple se poate realiza o decodare eficientă.

MICROPROCESOR(PICOBLAZE)

MEMORIE DE COD MEMORIE DE DATE

MODUL HARDWARE GENERAT

MODULPROFILER

MODULCONFIGURATOR

MAGISTRALA DATE/INSTRUCȚIUNI

MAGISTRALA ADRESE

SISTEM CU MICROPROCESOR

SISTEM DE RECONFIGURARE

Figura 4.5.2 Structura propusă a sistemului reconfigurabil, după (Popa & Stan, 2010)

Sistemul de reconfigurare este alcătuit din cele trei module prezentate în Figura 4.5.2.

Modulul PROFILER este conectat la magistralele sistemului și monitorizează execuția aplicațiilor

pentru a extrage informații despre execuție. Modulul PROFILER este cuplat la sistemul monitorizat

(i.e. la magistralele microprocesorului) deoarece trebuie să funcționeze la aceeași frecvență cu

acesta pentru a putea observa și înregistra evenimentele declanșate de microprocesor. Informațiile

extrase sunt comunicate către modulul CONFIGURATOR care generează un modul hardware a

cărui funcționare este determinată de informațiile primite de la modulul PROFILER. De asemenea,

modulul CONFIGURATOR realizează și reconfigurarea sistemului prin includerea modulului

hardware nou generat în sistem. Acest modul poate fi plasat în alt domeniu de ceas decât sistemul

monitorizat.

Modulul hardware generat este interfațat cu sistemul cu microprocesor prin conectarea la

magistralele acestuia și de asemenea la memoria de date. Conectarea la magistralele

microprocesorului este necesară pentru a putea sincroniza funcționarea modulului hardware cu


54

funcționarea microprocesorului. Modulul hardware fiind un modul periferic, este necesar ca

microprocesorul să controleze prin operații de scriere de cuvinte de comandă activitatea modulului

hardware. Transferul datelor de intrare către periferic precum și preluarea rezultatelor se poate

efectua de către microprocesor prin scrierea și citirea de cuvinte de date la și de la periferic.

Conectarea la memoria de date este necesară modulului hardware pentru a putea citi sau scrie direct

date în memorie.

Sistemul prezentat în Figura 4.5.2 poate fi implementat în întregime pe un circuit

reconfigurabil de tip FPGA. Deoarece funcționarea acestui sistem presupune reconfigurarea

dinamică a unei porțiuni din circuit este necesar ca circuitul FPGA folosit să ofere posibilitatea de

reconfigurare dinamică parțială (engl. dynamic partial reconfiguration). Această caracteristică nu

este implementată în toate circuitele FPGA ci doar în familiile mai avansate (e.g. Virtex5, Virtex6,

Virtex7 de la Xilinx). În cazul utilizării unui circuit FPGA pentru care este absentă această

caracteristică este necesară reconfigurarea integrală a circuitului. În acest caz, care a fost și cel

utilizat în efectuarea de experimente cu arhitectura propusă, unele module ale arhitecturii au fost

alocate pe alte sisteme de calcul așa cum este prezentat în Figura 4.5.3.

Pentru experimentele realizate, modulul CONFIGURATOR este implementat în întregime pe

un calculator sub forma unei aplicații. În acest fel, se pot folosi programe puternice (e.g.

generatoare de cod, programe de sinteză logică) pentru generarea de module hardware din

informațiile extrase de modulul PROFILER.

Transferul informațiilor dintre cele două sisteme (i.e. PC și platforma reconfigurabilă) este

realizat prin două interfețe de comunicație. Interfața UART este folosită pentru transferul

informațiilor colectate de modulul PROFILER către aplicația de pe calculator. Interfața USB este

utilizată pentru reconfigurarea circuitului FPGA cu noua configurație care include și noul modul

hardware generat.

MICROPROCESOR(PICOBLAZE)

MEMORIE DE COD MEMORIE DE DATE

MODUL HARDWARE GENERAT

MODULPROFILER

MODULCONFIGURATOR

MAGISTRALA DATE/INSTRUCȚIUNI

MAGISTRALA ADRESE

PC

DISPOZITIV RECONFIGURABIL

UART

USB

Figura 4.5.3 Alocarea modulelor sistemului reconfigurabil, după (Popa & Stan, 2010)

4.5.2 Algoritmii de funcționare pentru sistemul reconfigurabil

Funcționarea sistemului reconfigurabil presupune proiectarea și implementarea algoritmilor

care să realizeze: monitorizarea execuției codului de către microprocesorul din sistem, extragerea și

stocarea informațiilor din fluxul de execuție necesare construirii modulelor hardware cu

funcționalitate identică, sintetizarea pe baza acestor informații a modulelor hardware și actualizarea

structurii sistemului cu noile module hardware sintetizate.

Modulul PROFILER implementează următoarele funcții:

monitorizarea execuției codului prin conectarea la magistralele de adrese și

instrucțiuni ale microprocesorului;

memorarea într-o memorie locală a secvențelor de instrucțiuni executate de

microprocesor;


55

comunicarea către modulul CONFIGURATOR a informațiilor memorate anterior.

Modulul CONFIGURATOR implementează următoarele funcții:

preluarea de la modulul PROFILER a informațiilor care descriu o secvență de

instrucțiuni executată de microprocesor;

generarea de module hardware care au funcționalitate identică cu secvența de

instrucțiuni primită de la modulul PROFILER;

sintetizarea modulelor hardware anterior generate pentru tehnologia folosită (i.e.

FPGA);

reconfigurarea sistemului cu noua structură care include și modulele hardware

generate.

Modulul PROFILER realizează decodificarea instrucțiunilor aritmetice, logice și de transfer

care sunt transferate pe magistrala de instrucțiuni a microprocesorului. Pentru fiecare astfel de

instrucțiune este construită o înregistrare care este memorată într-o memorie locală modulului

PROFILER (denumită execution memory – EM). Pentru fiecare înregistrare sunt memorate

următoarele informații:

adresa instrucțiunii sau o parte a biților mai puțin semnificativ ai adresei

instrucțiunii;

tipul instrucțiunii (e.g. ADD, SUB, etc.);

informații care descriu operanzii sursă și/sau destinație;

adresa ultimei instrucțiuni sau o parte a biților mai puțin semnificativi ai adresei

instrucțiunii care a modificat operandul sursă;

tipul instrucțiunii (e.g. ADD, SUB, etc.) care a modificat operandul sursă;

adresa ultimei instrucțiuni sau o parte a biților mai puțin semnificativi ai adresei

instrucțiunii care a modificat bitul CARRY.

Pentru memorarea tipului și adreselor instrucțiunilor care modifică valorile registrelor (e.g.

execută operații de scriere în registre) este utilizat un alt modul de memorie locală cu un număr de

locații egal cu numărul registrelor microprocesorului (denumit register memory -RM).

Modulul PROFILER are două moduri de funcționare:

modul de monitorizare și memorare a secvenței de execuție;

modul de comunicare a informațiilor memorate către modulul CONFIGURATOR.

Tranziția între cele două moduri de funcționare se face după ce a fost adunată o anumită

cantitate de informație despre execuția sistemului.

Algoritmul de funcționare pentru modulul PROFILER în modul de monitorizare și

memorare este prezentat în Figura 4.5.4.

foreach fetch cycle

instr_crt = instruction_bus

addr_crt = address_bus

if instr_crt is arith_logic or register transfer then

if instr_crt writes to a register then

RM[ DEST_REG_FIELD ] = addr_crt

endif

if instr_crt reads a regsiter then

source_reg = instr_crt[ SOURCE_REG_FIELD ]

addr_last = RM[ source_reg ]

instr_last = RM[ source_reg ]

append addr_crt, instr_crt, addr_last, instr_last

else // instr_crt operates with a constant

konst = instr_crt[ CONST_FIELD ]

append addr_crt, instr_crt, konst

endif

endif

endfor

Figura 4.5.4 Algoritmul modulului PROFILER


56

Modulul CONFIGURATOR primește de la modulul PROFILER informația stocată de

acesta în EM și generează modulul hardware în limbaj de descriere hardware Verilog HDL, prin

instanțierea repetată de module hardware corespunzătoare fiecărei instrucțiuni din EM și conectarea

acestor module conform informațiilor din EM.

Algoritmul după care funcționează acest modul este prezentat în Figura 4.5.5.

foreach record from EM

define connection wires

select HW module according to record

instantiate and connect the HW module

endfor

Figura 4.5.5 Algoritmul modulului CONFIGURATOR

După generarea modulului hardware se execută procesul de sinteză a modulului generat

împreună cu celelalte elemente ale sistemului. Noul modul care implementează aceeași

funcționalitate ca și o porțiune de program este conectat ca un periferic la microprocesorul din

sistem. În locul execuției secvenței de program care este înlocuită de modulul hardware,

microprocesorul execută o secvență de instrucțiuni prin care:

sunt transmise datele de intrare către modulul periferic;

este sincronizată execuția cu momentul terminării efectuării operațiilor de către

modulul periferic;

sunt citite rezultatele de la modulul periferic.

Implementarea modului de interfațare dintre microprocesor și modulul hardware face

obiectul direcțiilor viitoare de cercetare. O variantă de implementare avută în vedere este

instrumentarea codului binar al aplicației executate de către microprocesor astfel încât să suporte

noul periferic inclus în sistem și utilizarea lui atunci când este cazul conform fluxului de execuție

(Lysecky , Stitt, & Vahid, 2006).

De asemenea, codul generat în urma transformării expresiilor, prezentat în Capitolul 3.3,

poate beneficia de sporirea performanțelor (e.g. creșterea vitezei de execuție) dacă este implementat

în hardware folosind metoda prezentată în acest capitol. Acest lucru este posibil deoarece codul

generat are o structură liniară fără ramificații (i.e. este un bloc elementar).

4.6 Concluzii

În acest capitol a fost prezentată proiectarea de sisteme de calcul dedicate cu circuite

reconfigurabile de tip FPGA. Flexibilitatea structurii acestor circuite prezintă multiple oportunități

de proiectare și implementare pentru sisteme de calcul dedicate.

S-au prezentat două arhitecturi pentru monitorizarea corectitudinii execuției aplicațiilor de

către microprocesoarele softcore incluse în circuitele FPGA. Arhitecturile prezentate folosesc un

model de redundanță spațială prin implementarea unor mecanisme de tip watchdog care

monitorizează apariția unui anumit tip de evenimente în sistem. Pentru evenimentele monitorizate

sunt comparați parametrii de timp ai declanșării evenimentelor la execuție cu parametrii de timp

calculați în etapa de proiectare. Nepotrivirile dintre valorile parametrilor conduc la declanșarea unui

mecanism de tratare potrivit aplicației (e.g. reset micropocesor).

S-a prezentat o arhitectură pentru un sistem reconfigurabil capabil să transforme în mod

dinamic funcționalitatea implementată prin execuția unor secvențe de cod în module hardware cu

funcționalitate identică. Arhitectura folosește module hardware suplimentare care evaluează codul

executat, extrag caracteristicile codului și generează module hardware care au aceeași


57

funcționalitate cu a codului evaluat. Modulele hardware generate sunt sintetizate și apoi incluse în

sistem (e.g. prin reconfigurare parțială).

Folosirea arhitecturilor prezentate în proiectarea de sisteme dedicate are consecințe în

creșterea siguranței în funcționare a aplicațiilor sau a performanțelor de calcul.

59

5 Structură autotestabilă pentru memoriile RAM

5.1 Defecte de memorie

Dezvoltarea rapidă a tehnologiei circuitelor integrate a condus la o creştere continuă a

capacităţii circuitelor de memorie. Odată cu creşterea densităţii de integrare şi rata defectelor de

fabricaţie este mai mare. În plus, sunt tot mai frecvente defectele complicate, greu de modelat şi de

detectat. Cu densităţi în creştere, anumite tipuri de defecte, precum defectele de cuplaj între trei

celule de memorie, care sunt mai greu de detectat, devin din ce în ce mai importante. În plus, este

necesar mai mult timp pentru testarea memoriilor datorită dimensiunilor lor crescânde, astfel este

necesară identificarea testelor mai eficiente, care au capacitatea de a detecta defecte complexe, teste

care necesită timp de testare de ordinul n. Calitatea testelor utilizate, în termeni de acoperire a

defectelor şi lungimea testului, este puternic dependentă de modelele de defecte utilizate.

5.2 Notaţii folosite în descrierea testelor de memorie

În testarea circuitelor de memorie nu se operează cu defecte fizice propriu-zise în număr

foarte mare, ci cu modele de defecte care reflectă modul lor de manifestare (i.e. care descriu modul

în care acestea afectează funcţionarea circuitului).

Numeroase modele de defecte funcţionale (engl. FFM – Fault Functional Model) pentru

memorii au fost introduse în trecut; unele FFM-uri foarte cunoscute care datează de dinainte de

1999 sunt: defectul de tip blocaj (engl. stuck-at), defect de decodor, defect de păstrare a datelor,

defect de tip read stuck open, defect destructiv la citire, defect de tip deceptive read destructive şi

defect de cuplaj (Van de Goor A. J., 1998). În 1999, rezultatele experimentale obținute prin

aplicarea unui număr mare de teste la un număr mare de cipuri (Van de Goor & De Neef, 1999) au

indicat că multe teste funcţionale detectează într-adevăr defecte în memorii, dar care nu pot fi

explicate folosind setul binecunoscut de FFM-uri. Acest lucru a condus la introducerea de noi FFM-

uri, pe baza injectării defectelor şi simulării circuitelor (Van de Goor & Al-Ars, 2000): defect de tip

write disturb, defect de citire incorectă, defect la cuplare de tranziţie, defect de cuplare de tipul read

destructive etc.

O secvenţă de operaţii care conduce la observarea unei diferenţe între valoarea observată şi

cea aşteptată a unei celule de memorie se numeşte secvenţă de activare (engl. sensitizing operation

sequence – S). Comportamentul observat al celulei de memorie care se abate de la funcţionarea

corectă se numeşte comportament eronat (engl. faulty behavior – F). Pentru a specifica o anumită

eroare, trebuie precizate condiţia de activare a erorii şi modul de manifestare al acesteia (i.e.

comportamentul în cazul existenţei erorii), iar dacă operaţia este una de citire se prezintă şi

rezultatul acestei operaţii (R). Ansamblul S, F, R pentru o anumită eroare se numeşte defect primitiv

(engl. Fault Primitive – FP) şi este notat astfel: <S|F|R|>. Conceptul de defect primitiv permite

Structură autotestabilă pentru memoriile RAM

60

construirea unui cadru de studiu pentru toate erorile (Caşcaval & Bennett, 2001), (Caşcaval,

Bennett, & Huţanu, 2004).

Dacă se notează cu #O numărul de operaţii diferite care apar în S, atunci FP se pot împărţi

în:

erori statice, pentru #O ≤1;

erori dinamice, pentru #O≥2.

Exemple de erori statice sunt cele de tip blocaj la 1 sau la 0 (#O = 0) sau atunci când o

operaţie de citire cauzează complementarea valorii unei celule de memorie (#O = 1). Un exemplu

de eroare dinamică este atunci când două operaţii de citire succesive determină complementarea

valorii unei celule de memorie (#O = 2); însă o singură citire nu va determina acest comportament.

Următoarele notaţii sunt uzual folosite pentru a descrie operaţii asupra memoriilor RAM:

r semnifică o operaţie de citire, iar valoarea aşteptată în urma citirii nu este

specificată;

r(0) sau r(1) semnifică citirea unui 0 sau a unui 1 dintr-o celulă de memorie;

0w0 sau 1w1 semnifică o operaţie de scriere a valorii unei celule care conţine 0 sau 1

fără a modifica valoarea memorată în celulă;

0w1 sau 1w0 (sau pe scurt wc) semnifică o operaţie de scriere a valorii unei celule

care conţine 0 sau 1 cu modificarea valorii memorate în celulă;

↑ sau ↓ semnifică o tranziţie a valorii memorate datorită unei anumite condiţii de

activare.

În concluzie, un defect primitiv este exprimat prin <S|F|R>, unde:

S descrie valoarea sau operaţia de activare a defectului; S{0, 1, r0, r1, 0w0, 1w1,

0w1, 1w0};

F descrie valoarea celulei de memorie afectată de eroare (i.e. celulă victimă);

F{0, 1 , ↑, ↓};

R descrie valoarea care apare la ieşirea memoriei în cazul în care operaţia de activare

este o citire; R{ 1, 0, -}. Simbolul - semnifică faptul că nu se poate preciza o

valoare pentru R deoarece operaţia nu este una de citire. De exemplu, dacă S = 0w0

atunci la ieşirea memoriei nu va fi disponibilă nici o informaţie, caz în care R va

avea valoarea -.

După modul în care se manifestă FP, acestea pot fi clasificate în:

Erori simple (engl. simple faults). Acestea sunt erori care nu pot fi influenţate de alte

erori. Acest lucru înseamnă că comportamentul unei erori nu poate modifica

comportamentul alteia; deci nu poate apare fenomenul de mascare al erorilor.

Erori conectate (engl. linked faults). Acestea sunt erori care se pot influenţa

reciproc, astfel încât poate apare fenomenul de mascare. De menţionat este faptul că

aceste erori au la bază două sau mai multe erori simple.

Erorile memoriilor RAM se pot clasifica în erori la nivelul unei singure celule (engl. single-

cell faults) sau erori care implică mai multe celule (engl. multi-cell faults). Pentru erorile care

implică mai multe celule studiul este limitat la erorile de cuplaj între două celule. Această clasă

reprezintă o clasă importantă de erori.

Un defect primitiv pentru două celule este reprezentat astfel: <S|F|R> = <Sa;Sv|F|R>, în care

Sa şi Sv sunt operaţiile de activare executate asupra celulelor de memorie agresor şi victimă. Celula

agresor este aceea asupra căreia trebuie executată operaţia de activare a erorii, iar celula victimă

este aceea care prezintă comportamentul eronat.


61

5.3 Testul de memorie MarchS2C

Testele March sunt teste din clasa de complexitate O(n). Odată cu creşterea capacităţii de

memorie testelor March li s-a acordat o atenţie deosebită, fiind singurele care pot asigura o testare

eficientă într-un timp scurt. În prezent sunt testele cele mai folosite în practică.

Se prezintă în continuare algoritmul MarchS2C (Cașcaval & Stan, 2007) împreună cu

notaţiile aferente. În mod uzual, un test MARCH este delimitat printr-o pereche de acolade `{...}` în

timp ce un element March este delimitat de o pereche de paranteze rotunde `(...)`. Elementele

March sunt separate prin punct şi virgulă, iar operaţiile dintr-un element sunt separate prin virgulă.

Toate operaţiile dintr-un element March sunt efectuate succesiv asupra unei adrese înainte de a se

trece la adresa următoare. Întreaga memorie este verificată în mod omogen în una din cele două

ordini de parcurgere a adreselor: în ordine ascendentă a adresei (⇑) sau în ordine descendentă a

adresei (⇓). Când ordinea de parcurgere nu este relevantă se utilizează simbolul ⇕.

Testul de memorie MarchS2C este prezentat în Figura 5.3.1. Acest test March are o lungime

de 22n şi este capabil să descopere toate erorile din modelul pentru două celule cuplate. Testul este

alcătuit din şase elemente March, identificate prin indecşii marcaţi cu (x), unde x{0,1,2,3,4,5}. Un

test similar este propus în (Hamdioui, van de Goor, & Rodgers, 2002)

{

⇕ (w0) (0);

⇑ (r0,w1,r1,r1,w1) (1) ; ⇑ (r1,w0,r0,r0,w0) (2) ;

⇓ (r0,w1,r1,r1,w1) (3) ; ⇓ (r1,w0,r0,r0,w0) (4) ;

⇕ (r0) (5) ;

}

Figura 5.3.1 Testul de memorie MarchS2C (Cașcaval & Stan, 2007)

MarchS2C este capabil să detecteze toate FFM-urile cu 2 celule. Tabelul 5.3.1 indică prin

care element March este detectat fiecare FP. În acest tabel, au fost puse în evidență două cazuri:

celula v are o adresă mai mare decât celula a (i.e. v > a);

celula v are o adresă mai mică decât celula a (i.e. v < a ).

Perechea i, j denotă operația j a elementului March Mi; (e.g. 1, 1 denotă prima operație – r0

– a M1). Mai mult decât atât, pentru modelul de defecte de cuplaj dintre două celule, testul

MarchS2C este un test optim.

Testul de memorie MarchS2C este unul minimal relativ la operațiile de citire și scriere cu

memoria. Se arată în continuare că testul de memorie realizează un număr minimal de operaţiuni de

scriere. Tabelul 5.3.1 Acoperirea defectelor de către testul de memorie MarchS2C (Cașcaval & Stan, 2007)

# FFM a<v v<a

1 <0;0/1/-> 1,1 1,1

2 <0;1/0/-> 2,1 1,3

3 <1;0/1/-> 1,1 2,3

4 <1;1/0/-> 1,3 2,1

5 <0w0;0/↑/-> 1,1 3,1

6 <0w1;0/↑/-> 2,1 2,1

7 <1w1;0/↑/-> 2,3 1,1

8 <1w0;0/↑/-> 1,1 2,3

9 <0w0;1/↓/-> 2,4 4,4

10 <0w1;1/↓/-> 4,4 2,4

11 <1w1;1/↓/-> 2,3 1,1

12 <1w0;1/↓/-> 1,1 2,3


62

13 <r0;0/↑/-> 1,1 3,1

14 <r1;0/↑/-> 2,1 2,1

15 <r0;1/↓/-> 2,1 1,3

16 <r1;1/↓/-> 1,3 2,1

17 <0;0w1/0/-> 3,4 1,4

18 <1;0w1/0/-> 1,4 3,4

19 <0;1w0/1/-> 2,1 1,3

20 <1;1w0/1/-> 1,3 2,1

21 <0;0w0/↑/-> 5,1 3,1

22 <1;0w0/↑/-> 2,1 4,1

23 <0;1w1/↓/-> 3,1 5,1

24 <1;1w1/↓/-> 5,1 3,1

25 <0;r0/↑/1> 1,1 3,1

26 <1;r0/↑/1> 4,1 2,1

27 <0;r1/↓/0> 4,1 2,1

28 <1;r1/↓/0> 2,1 4,1

29 <0;r0/↑/0> 1,1 3,1

30 <1;r0/↑/0> 4,1 2,1

31 <0;r1/↓/1> 3,3 1,3

32 <1;r1/↓/1> 1,3 3,3

33 <0;r0/0/1> 5,1 3,1

34 <1;r0/0/1> 2,1 4,1

35 <0;r1/1/0> 2,3 4,3

36 <1;r1/1/0> 4,3 2,3

Figura 5.3.2 prezintă o diagramă de stare cu toate operaţiunile de scriere posibile pentru

două celule, ci şi cj, în care cj are o adresă superioară lui ci (i.e. ci < cj).

Figura 5.3.2 Diagrama stărilor pentru două celule de memorie ci și cj ( ci < cj ) și

toate operațiile de scriere efectuate de testul de memorie MarchS2C (Cașcaval & Stan, 2007)

Figura arată prin care element March se realizează fiecare operație de scriere, perechea i, j

denotă operația j de scriere a elementului March Mi. Se observă că orice operaţie de scriere

efectuată de către MarchS2C este reflectată în diagrama de stare. Pe de altă parte, fiecare arc din

acest grafic este străbătut o singură dată şi numai dată. Cu alte cuvinte, MarchS2C acoperă graficul

Eulerian în întregime cu un număr minim de operaţiuni de scriere. În mod analog, se poate dovedi

că MarchS2C realizează un număr minim de operaţiuni de citire pentru a activa defecte precum

CFds, CFrd, CFdrd sau Cfir şi pentru a detecta orice defect activat.


63

Abilitatea testului MarchS2C de a detecta orice defect de cuplare cu 2 celule a fost de

asemenea verificată în simulare.

5.4 Comparație cu alți algoritmi de testare March

Pentru a compara performanțele algoritmului MarchS2C s-au considerat algoritmii de testare

March prezentați în următorul tabel.

Tabelul 5.4.1 Gradul de acoperire al erorilor de tip cuplaj între două celule (Cașcaval & Stan, 2007)

# Test memorie Lungime test Acoperire defecte

(%)

1 Algoritm A 30n 72,22

2 March G 24n 69,44

3 MarchS2C 22n 100

4 March LA 22n 77,78

5 March B 17n 57,14

6 March LR 14n 66,67

7 March SR 14n 72,22

8 March U 13n 66,67

9 PMOVI 13n 73,61

10 March C 10n 66,67

5.5 Structuri autotestabile

BIST (engl. Built In Self Test) este o tehnică de proiectare a circuitelor digitale orientată spre

testabilitate, prin care logica de testare este plasată pe circuit alături de blocurile testate. Schema

bloc pentru un astfel de sistem este prezentată în Figura 5.5.1. În modul normal de operare, circuitul

testat, preia intrările de la alte module şi realizează funcţia pentru care a fost proiectat. În modul de

testare, un generator de secvenţe de test aplică o serie de secvenţe de test la intrările sistemului

testat, iar un bloc de verificare evaluează răspunsul dat de circuit la o secvenţă de test.

MUX

Generator vectori de test

Modul de control

Monitorpentru ieșire

Circuit testat(CUT)

Intrare

Ieșire

Eroare

Modul autotestare

Secvență de test

Figura 5.5.1 Schema generală a unei arhitecturi de tip BIST (Cașcaval, Silion, & Stan, 2007)

Asigurarea unei acoperiri suficient de mari a erorilor şi a unui număr suficient de mic de

vectori de test sunt cele două mari probleme ale implementării unui modul BIST.

În cele ce urmează, se foloseşte modelul de erori statice de tip cuplaj între două celule de

memorie. Acesta este cel mai cuprinzător model pentru erori de tip cuplaj între două celule de


64

memorie. De asemenea este prezentată şi implementarea unui modul BIST pentru testarea acestor

erori.

5.6 Proiectarea logicii de testare

Pentru testul de memorie MarchS2C, o schemă bloc a modulului BIST (Cașcaval, Silion, &

Stan, 2007) este prezentată în Figura 5.6.1. Modulul BIST are trei elemente componente: logica de

generare a adresei, logica de generare a datelor şi de verificare, şi logica de control

microprogramată.

MUX

Buffer date

Comparator date

Contor Element March (MEC)

NumărătorAscend./Descend.

Modul de control

1

0

R/W RES UP MEC

ME

Modul de memorie

Result F/F

State F/F

InitZeroInitOne

UP/DNEOS

(End of Seq)

Semnale comandă( Data, RES, …)

DataError

Semnale de stare( EOS, Error, ME )

Start Test Result

End of Test

Test Result

End of Test

0 – fără eroare1 – eroare

0 – test în derulare1 – test încheiat

Generator de adresă

Generator de date &Verificare răspuns

Figura 5.6.1 Schema bloc a modulului BIST (Cașcaval, Silion, & Stan, 2007)

5.6.1 Logica de generare a adresei

Acest bloc este alcătuit dintr-un numărător cu posibilitate de numărare în ambele sensuri

crescător şi descrescător. Numărătorul de adrese poate fi inițializat cu 0 (InitZero) sau 1 (InitOne) în

toţi biţii. Memoria este testată atât în ordine ascendentă cât şi în ordine descendentă a adreselor

astfel încât, funcţie de elementul March (ME) curent, logica de control va incrementa sau va

decrementa numărătorul de adrese.

5.6.2 Logica de generare a datelor şi de verificare

Logica de generare produce datele care urmează a fi înscrise în memorie precum şi datele

aşteptate (i.e. de referinţă) pentru verificarea răspunsului memoriei. O logică unică pentru generarea

ambelor tipuri de date, cele pentru scriere şi cele pentru verificare, poate fi utilizată. Se observă că,

exceptând primul şi ultimul element March – prima iniţializare şi ultima citire, algoritmul de testare

efectuează operaţii similare notate (r,wc,r,r,w). Fiecare element March începe printr-o operaţie de

citire urmată de o operaţie de scriere (r,wc). Data folosită la operaţia de scriere este complementul

datei aşteptată a fi citită din celula de memorie. Următoarele operaţii de citire şi scriere (r,r,w)

folosesc aceleaşi valori ale datelor care au fost scrise anterior în memorie de către prima operaţie de

scriere a unui element March (wc). Generatorul de date este alcătuit dintr-un multiplexor şi

numărător pentru elementele March (engl. MEC – March element counter). Multiplexorul este

selectat în concordanţă cu valoarea datei aşteptate prezentate în Tabelul 5.6.1. Variabila Data este

utilizată pentru a comanda multiplexorul astfel încât să genereze data potrivită.


65

Tabelul 5.6.1 Data aşteptată la prima citire a unei celule pentru fiecare element March

(Cașcaval, Silion, & Stan, 2007)

Element March (0) (1) (2) (3) (4) (5)

Data așteptată 0 0 1 0 1 0

5.6.3 Logica de control microprogramată

Logica de control are rolul de a controla întreg procesul de testare. Schema unui bloc de

control microprogramat generic este prezentată în Figura 5.6.2. Adresa pentru memoria de

microprogram este generată de un registru numărător a cărui intrări de comandă pentru funcțiile de

numărare și încărcare sunt generate de o logică combinațională. Semnalele de intrare în acest circuit

combinațional sunt reprezentate de semnalele de condiție din sistem (e.g. EOS, ME, Error, Start) și

de semnale care provin de la două câmpuri ale registrului de microprogram: up/load și branch

condition.

MUX

0 Start EOS ME Error

Memoriemicrocod

UP/LD ADRESĂ COND SENMALE COMANDĂ

Numărător

UP LD

ADRESĂ

uIN

STR

UC

ȚIU

NE

R/W DataTest

Result...

Figura 5.6.2 Logica de control microprogramată (Cașcaval, Silion, & Stan, 2007)

Organigrama algoritmului de testare este prezentat în Figura 5.6.3, unde s-au notat cu

O(w0), O(rwcrrw) şi O(r) operaţii specifice efectuate asupra celulei de memorie curente de

elementele March (w0), (r,wc,r,r,w) şi (r).

Start

O(w0)

address = 0, ME = 0,State F/F = 1

address++

EOS

address=0, ME++

O(rwcrrw)

address++

EOS

ME<=2

Error

address=1, ME++

O(rwcrrw)

address--

EOS

ME<=4

Error

address=0, ME++

O(r)

address++

Error

EOS

Result F/F = 0,State F/F = 0

Result F/F = 1,State F/F = 0

A

AW

E

E

E

E

W

P

P

W

Figura 5.6.3 Organigrama de funcționare pentru unitatea de control a structurii BIST

care implementează algoritmul de testare MarchS2C (Cașcaval, Silion, & Stan, 2007)


66

În privinţa arhitecturilor MASB, o metodă de verificare este compararea ieşirilor biţilor

plasaţi simetric în matricele de memorie. Pentru aceste arhitecturi nu mai este necesară generarea

separată a răspunsului aşteptat în acest caz.

5.7 Concluzii

În acest capitol s-a prezentat problematica testării circuitelor de memorie RAM. S-a propus

un nou algoritm MARCH de testare a memoriilor RAM pentru defectele de tip cuplaj între două

celule de memorie. Testul propus este minimal relativ la operațiile de citire și scriere efectuate și

detectează toate defectele primitive considerate. Comparația cu alți algoritmi a arătat că algoritmul

propus este singurul care are un grad de acoperire al defectelor de 100%.

67

6 Concluzii

În această teză au fost abordate multiple aspecte din domeniul proiectării sistemelor de

calcul dedicate. Provocările la care trebuie să răspundă sistemele de calcul dedicate sunt generate de

mai multe surse: societatea umană contemporană (e.g. nevoi de asistență medicală personalizată),

caracteristicile aplicațiilor actuale (e.g. interacțiune dintre utilizator și sistemele de calcul, siguranța

utilizatorilor), constrângeri de natură economică și constrângeri tehnologice (e.g. puterea

consumată).

Sistemele de calcul dedicate reprezintă categoria de sisteme de calcul cu creșterea cea mai

rapidă și cu diversitatea de implementări cea mai mare. De asemenea, sistemele de calcul dedicate

au cea mai largă plajă pentru costuri relativ la puterea de calcul disponibilă. Acestea sunt proiectate

și construite pentru a îndeplini doar o anumită funcție sau un set restrâns de funcții înrudite oferind

astfel o oportunitate pentru optimizarea implementării lor. Aceste sisteme de calcul sunt incluse în

sisteme tehnice mai complexe și implementează cel mai adesea funcții de control, comunicație,

procesare de date, stocare de date sau interfață cu utilizatorul.

În capitolul 3 sunt prezentate și evaluate trei componente software frecvent utilizate în

dezvoltarea de aplicații pentru sistemele dedicate cu microcontroler.

Prima componentă software este un nucleu de automat finit. Sunt descrise etapele de

implementare și evaluare ale unui nucleu software de automat finit. Acest modul poate fi utilizat în

procesul de dezvoltare al aplicațiilor software pentru sisteme dedicate. Automatele finite sunt

printre cele mai folosite componente în crearea aplicațiilor software pentru sistemele dedicate.

Implementarea personalizată a automatelor finite necesită timp și este predispusă la erori. O

abordare eficientă este proiectarea unui nucleu care, pe baza unei descrieri adecvate, realizează

execuția unui automat finit. Prin utilizarea unui nucleu, un proiectant de sisteme dedicate trebuie să

specifice numai acțiunile, condițiile și tranzițiile, ca simple funcții și tabele și să lase motorul să se

ocupe de ansamblul operaţiilor interne necesare pentru a executa automatul finit.

Principalul avantaj al utilizării unui automat în proiectarea aplicațiilor software pentru

sisteme de calcul dedicate constă în flexibilitatea cu care se poate completa, șterge sau schimba

descrierea structurii automatului fără a genera un impact deosebit asupra restului aplicației. Nucleul

software de automat finit este evaluat folosind microcontrolere pe 8 biți ATMega de la Atmel. S-a

constatat un consum redus de resurse de memorie. De asemenea, s-au evaluat și timpii necesari

pentru execuția fiecărei tranziții a automatului finit.

Pentru nucleul software de automat finit s-a proiectat o nouă variantă care include un

mecanism de siguranţă. S-a propus utilizarea unei temporizări pentru fiecare stare pentru a se putea

detecta și evita staționarea într-o stare pentru o perioadă de timp nedefinită.

A doua componentă software prezentată este o bibliotecă cu funcții pentru criptare. Aceste

metode asigură diferite nivele de siguranţă pentru transferul datelor şi nivele asociate de consum de

energie, datorate complexităţii algoritmilor de criptare. Aplicațiile definesc o tabelă de nivele de

securitate cu care se poate realiza codificarea datelor. Fiecare combinaţie are un regim de consum

de energie care îi permite utilizatorului să aleagă cea mai adecvată soluţie care corespunde

necesităţilor aplicaţiei.

Concluzii

68

Implementarea rezultată a algoritmilor de criptare (DES și FEAL) permite o asociere

eficientă între necesităţile de siguranţă ale aplicaţiei şi cerinţele de consum de energie. În

consecinţă, durata de funcţionare a acumulatorului se prelungeşte. Acest aspect are un impact

pozitiv asupra autonomiei şi disponibilităţii sistemului.

Este propusă și o arhitectură autoadaptivă pentru securizarea aplicațiilor executate de

sistemele dedicate. Eficiența unei arhitecturi adaptive pentru securizarea unui sistem de calcul

dedicat este demonstrată prin proiectarea unui experiment. Se constată o scădere cu 31% a energiei

consumate de arhitectura adaptivă față de situația în care s-ar fi utilizat doar cel mai sigur și cel mai

complex algoritm de criptare (DES16) pentru securizarea întregului sistem.

A treia componentă este reprezentată de o metodă pentru conversia automată a expresiilor

aritmetice cu operanzi reprezentați în virgulă mobilă în expresii echivalente cu operanzi reprezentați

în virgulă fixă în aplicațiile pentru sisteme de calcul dedicate. Două obiective conflictuale sunt

considerate în mod simultan: complexitatea computaţională şi precizia calculelor și a rezultatelor.

Sunt vizate filtrele ne-adaptive Direct-Form I cu limite ale variabilelor de intrare predefinite.

Algoritmul prezentat utilizează o funcţie de cost parametrizabilă şi este capabil să producă soluţii

multiple în virgulă fixă pentru aceeaşi expresie dată în virgulă mobilă.

Codul în virgulă fixă generat este testat pe microprocesoare de 8 biţi (AVR ATmega), 16

biţi (MSP430) şi 32 biţi (ARM Cortex-M3). Acesta oferă, în toate cazurile, o viteză de execuţie mai

bună decât dacă s-ar utiliza codul în virgulă mobilă.

Capitolul 4 cuprinde prezentarea a trei metode de proiectare a sistemelor de calcul dedicate

care folosesc circuite digitale reconfigurabile.

Prima metodă prezintă proiectarea unui modul digital (watchdog), care poate fi inclus în

microprocesoare încorporate pentru a asigura detectarea și semnalarea nerespectării caracteristicilor

de timp ale codului care se execută. Monitorizarea comportamentului temporal este realizată prin

măsurarea timpului de execuție a subprogramelor și compararea rezultatelor cu valori de referință.

Comportamentul temporal al unei aplicații în execuție poate influența alte caracteristici ale

sistemului, în special calitatea serviciului oferit. Caracteristicile de siguranță și securitate ale unui

sistem de calcul dedicat pot depinde de comportamentul temporal al aplicației în faza execuție. Este

propus și un model pentru dezvoltarea unei aplicații care folosește această arhitectură de

monitorizare. Pentru a evalua modulul de monitorizare, s-a utilizat Spratan3E de la Xilinx și un

microprocesor soft-core PicoBlaze.

A doua metodă prezentată este utilizată pentru a detecta abateri de la timpul de procesare

alocat proceselor într-un sistem de tip MPSoC. La unitățile de procesare ale structurii MPSoC este

adăugată un modul de monitorizare care urmăreşte infrastructura de comunicație din interiorul

MPSoC. Toate transferurile de date sunt înregistrate, iar parametrii lor de timp sunt comparați cu un

comportament de referinţă aşteptat. Infrastructura de monitorizare urmăreşte accesele memoriei

care sunt emise către adrese ce corespund buffer-ului circular sau informaţiei de control ale buffer-

elor. În acest fel, infrastructura de monitorizare se leagă în mod non-invaziv de sistemul

monitorizat. Infrastructura de comunicație furnizează datele principale de intrare în cadrul structurii

de monitorizare.

Într-o platformă MPSoC, infrastructura de comunicație este un bun punct de observaţie

pentru funcţionarea internă a sistemului pentru că operarea acestuia utilizează din plin resursele de

comunicație. Corectitudinea operării poate fi evaluată analizând parametrii de timp ai comunicației

dintre procesele din cadrul unui MPSoC. Structura de monitorizare este evaluată pe o platformă

Xilinx Virtex6 într-un sistem MPSoC alcătuit din microprocesoare Microblaze și o rețea de

interconectare AEthereal.

A treia metodă prezintă implementarea unui sistem de calcul dedicat prin alocarea dinamică

a funcțiilor sale pe componente hardware și software. Acest mod de implementare este posibil prin

utilizarea de componente reconfigurabile (e.g. circuite FPGA): se implementează o mare parte a

funcțiilor sistemului în componente software executate de nuclee de microprocesoare incluse în

circuitele FPGA, apoi se realizează o analiză a execuției printr-un proces de evaluare a

performanțelor. Această abordare se bazează pe detectarea nucleelor de calcul existente în software

Concluzii

69

(e.g. nuclee repetitive care realizează diverse sarcini de calcul, precum procesări de semnale).

Informaţiile extrase după procesul de analiză dau posibilitatea implementării în hardware a unor

porțiuni de software care pot beneficia în acest fel de o scădere a timpului de execuție (i.e. o

accelerare a execuției).

În capitolul 5 este prezentată proiectarea și implementarea unui modul de testare a

memoriilor folosind tehnica BIST (engl. Built In Self Test). BIST este o tehnică de proiectare a

circuitelor digitale orientată spre testabilitate, prin care logica de testare este plasată pe circuit

alături de blocurile testate (supuse testării). Testul de memorie utilizat pentru implementarea

structurii BIST este MarchS2C. Acest test March are o lungime de 22n şi este capabil să descopere

toate erorile din modelul pentru două celule cuplate. Este realizată și o analiză comparativă cu alte

teste de memorie din care reiese eficiența testului propus. Modulul de testare care execută testul

MarchS2C este implementat ca un automat complex cu o cale de control microprogramată.

6.1 Contribuții personale

Datorită caracteristicilor pe care la au, sistemele de calcul dedicate prezintă multiple

oportunități de cercetare și de dezvoltare. În această teză au fost abordate următoarele aspecte din

domeniul proiectării de sisteme de calcul dedicate:

Proiectarea de sisteme de calcul dedicate cu microcontroler: implementarea și

evaluarea de module software folosite în dezvoltarea de aplicații pentru sistemele de

calcul dedicate

o Modul software pentru implementarea unui model computațional de tip

automat finit. Rezultatele au fost publicate în: (Stan, Botezatu, Panduru, &

Lupu, 2009), (Stan, Botezatu, & Vieriu, 2009).

o Modul software pentru algoritmi de criptare cu evaluarea consumului de

energie și o arhitectură autoadaptabilă pentru securizarea sistemelor dedicate.

Rezultatele au fost publicate în: (Stan & Botezatu, 2009), (Botezatu, Stan, &

Panduru, 2009), (Botezatu, Manta, & Stan, 2010)

o Modul software pentru conversia expresiilor cu operanzi în virgulă mobilă în

expresii cu operații și operanzi în virgulă fixă. Rezultatele au fost publicate

în: (Bârleanu, Băitoiu, & Stan, 2011b), (Bârleanu, Băitoiu, & Stan, 2011).

Proiectarea de sisteme de calcul dedicate cu circuite FPGA:

o Module hardware de verificare a corectitudinii execuției aplicațiilor pe

sisteme dedicate cu circuite FPGA. Rezultatele au fost publicate în: (Stan,

Panduru, & Ungureanu, 2010), (Stan, Valachi, & Bârleanu, 2011).

o Modul hardware pentru generarea de module hardware din evaluarea

execuției aplicațiilor pe microprocesoare softcore (i.e. microprocesoare

descrise în limbaje HDL și incluse în circuitul FPGA). Rezultatele au fost

publicate în: (Popa & Stan, 2010).

Proiectarea unei structuri autotestabile pentru module de memorie:

o Modul autotestabil de memorie RAM: proiectare algoritm de testare

MARCH pentru defecte de cuplaj între două celule și proiectarea logicii de

testare microprogramate. Rezultatele au fost publicate în: (Cașcaval & Stan,

2007), (Cașcaval, Silion, & Stan, 2006), (Cașcaval, Silion, & Stan, 2007).

Activitățile de cercetare și dezvoltare au fost complementate cu realizarea de sisteme de

calcul dedicate în cadrul unor granturi de cercetare. Aceste sisteme de calcul dedicate au făcut

obiectul următoarelor publicații: (Stan, Lupu, & Ciorap, 2010), (Stan, Panduru, & Lupu R, 2008),

(Lupu, Stan, & Ungureanu, 2008), (Lupu, Stan, & Ungureanu, 2009), (Ciorap, Carauleanu, Petcu,

Pomazan, & Stan, 2008).

Concluzii

70

6.2 Diseminare rezultate

Activitățile de cercetare și dezvoltate efectuate au condus la rezultate care au făcut obiectul

publicațiilor prezentate în continuare.

6.2.1 Sumar publicaţii

1 capitol de carte editura Springer

1 carte în editură naţională

2 articole în jurnale indexate ISI

1 articol în jurnal indexat BDI

4 articole în jurnale indexate B+

4 articole în conferinţe ISI Proceedings

2 articole în conferinţe BDI: IEEE Explore

11 Articole apărute în volumele conferințelor, congreselor, simpozioanelor

6.2.2 Detalii publicaţii

1 capitol de carte editura Springer

Robert G. Lupu, Andrei Stan, Florina Ungureanu, Patient Monitoring: Wearable device for patient

monitoring, Advances in Electrical Engineering and Computational Science, vol: 39, pp: 659-668,

Springer Netherlands, 2009, ISBN 978-90-481-2310-0 (Print), 978-90-481-2311-7 (Online),

1 carte în editură naţională

Al. Bârleanu, A. Stan, Sistem de dezvoltare cu microcontroler-ul 80C31, Ed. Performantica, Iaşi,

2003

2 articole în jurnale indexate ISI

Florina Ungureanu, Robert Gabriel Lupu, Andrei Stan, Ioan Craciun, Carmen Teodosiu, Towards

Real Time Monitoring of Water Quality in River Basins, Environmental Engineering and

Management Journal, September 2010, Vol.9, No. 9, Pages: 1267-1274, (revista ISI, Impact factor

0.885), ISSN: 1582-9596, http://omicron.ch.tuiasi.ro/EEMJ/

Al. Bârleanu, V. Baitoiu, A. Stan, Digital filter optimization for C language, Advances in Electrical

and Computer Engineering, Pages: 111 - 114, Volume 11, Number 3, 2011 (revista ISI, Impact

Factor: 0.688), ISSN: 1582-7445, http://www.aece.ro/index.php

1 articol în jurnal indexat BDI

R. Ciorap, D. Zaharia, C. Corciovă, M. Ungureanu, R. Lupu, A. Stan, Dispozitiv Wireless pentru

Monitorizarea Pacienţilor cu Afecţiuni Cronice, Revista Medico-Chirurgicală a Societăţii de

medici şi Naturalişti din Iaşi, vol. 112, nr. 4, octombrie – decembrie 2008

4 articole în jurnale indexate B+

P. Caşcaval, R. Silion, A. Stan, MARCHS2C: A Test for All Static 2-Cell RAM Coupling Faults,

Buletinul Institutului Politehnic din Iaşi, Tomul LII (LVI), Fasc. 1 – 4, 2006

A. Stan, N. Botezatu, L. Panduru, R. Lupu, A finite state machine model used in embedded systems

software development, Buletinul Institutului Politehnic din Iaşi, Tomul LV(LIX), Fasc. 2, 2009

http://omicron.ch.tuiasi.ro/EEMJ/

http://www.aece.ro/index.php

Concluzii

71

N. Botezatu, A. Stan, Low Power Embedded System Used In Healthcare Systems, Buletinul

Institutului Politehnic din Iaşi, Tomul LV(LIX), Fasc. 1, 2009

C. Popa, A. Stan, Mach Speed Processing. Dynamic Cloning of Software Functionality in

Hardware, Buletinul Institutului Politehnic din Iaşi, Tomul LVI(LX), Fasc. 2, 2010

4 articole în conferinţe ISI Proceedings

Robert G. Lupu, Andrei Stan, Florina Ungureanu, Wireless Device for Patient Monitoring, Lecture

Notes in Engineering and Computer Science Pages: 1687-1691, Published: 2008 (proceedings of

World Congress on Engineering 2008, Imperial Collage London, London, England, july 02-04,

2008). (ISI proceedings) ISBN: 978-988-98671-9-5,

Stan A, Panduru L, Lupu R, Low Power Devices for Gestural Human - Computer Interaction,

Annals of DAAAM for 2008 & Proceedings of the 19th International DAAAM Symposium -

Intelligent Manufacturing & Automation: Focus on Next Generation of Intelligent Systems and

Solution, Pages: 1287-1288, Published: 2008, 19th International Symposium of the Danube-Adria-

Association-for-Automation-and-Manufacturing Trnava, SLOVAKIA, OCT 22-25, 2008, ISSN:

1726-9679, ISBN: 978-3-901509-68-1,

N. Botezatu, A. Stan, L. Panduru, Power-Aware Framework For Encrypted Communications, 20th

International Danube-Adria-Association-for-Automation-and-Manufacturing Symposium, Vienna,

Austria, 25-28th November 2009, Pages: 825-826, ISSN: 1726-9679 ISBN: 978-3-901509-70-4

A. Stan, N. Botezatu, G. Vieriu, The Design Of A Finite State Machine Engine With Safe Operation

Used In Embedded Systems Design, 20th International Danube-Adria-Association-for-Automation-

and-Manufacturing Symposium, Vienna, Austria, 25-28th November 2009, Pages: 1507-1508,

ISSN: 1726-9679 ISBN: 978-3-901509-70-4

2 articole în conferinţe BDI: IEEE Explore

A. Stan, Al. Valachi, Al. Bârleanu, The design of a run-time monitoring structure for a MPSoC,

15th

International Conference on System Theory and Control, October 14-16, 2011, Sinaia,

Romania

Al. Bârleanu, V. Baitoiu, A. Stan, Floating-point to fixed-point code conversion with variable

trade-off between computational complexity and accuracy loss, 15th

International Conference on

System Theory and Control, October 14-16, 2011, Sinaia, Romania

11 Articole apărute in volumele conferințelor/congreselor/simpozioanelor

2007

P. Caşcaval, A. Stan, March Test for All Static 2-Coupling Faults in Random-Access Memories, 9th

International Symposium on Automatic Control and Computer Science, Iaşi, Romania, November

16-17, 2007

P. Caşcaval, R. Silion, A. Stan, A Logic Design for MarchS2C Memory BIST Implementation, 9th

International Symposium on Automatic Control and Computer Science, Iaşi, Romania, November

16-17, 2007

2008

R. Ciorap, A. Cărăuleanu, L. Petcu, V. Pomazan, A. Stan, E-Health Solution for Monitoring the

Evolution of the Chronically Disease at the Pregnant Women, UPB BIOINGTEH – Exploratory

Concluzii

72

Workshop, Advanced Materials & Technologies in Biology and Medicine, Poiana Braşov,

Romania, September 2008

R. Lupu, A. Stan, F. Ungureanu, A Low Power Device for ECG Monitoring, 9TH International

Carpathian Control Conference, Sinaia, Romania May 25-28, 2008

2009

D. T. Bălănescu, C-tin E. Hriţcu, A. Stan, Upgrade of the Power Adjustment system of a 24 kW

Wall-mounted Condensing Combination Boiler, 3rd

International Conference on Thermal Engines

and Environmental Engineering, Galaţi, Romania, June 4-6, 2009

A. Stan, N. Botezatu, Data Encryption Methods for Power Aware Embedded Systems Used in

Patient Monitoring, International Carpathian Control Conference ICCC2009, Zakopane, Poland,

May 24-27, 2009

2010

A. Stan, R. Lupu, M. Ciorap, R. Ciorap, Biosignal Monitoring and Processing for Management of

Hypertension, 12th

Mediteranean Conference on Medical and Biological Engineering and

Computing, May 27-30, Chalkidiki, Greece

A. Stan, L. Panduru, Fl. Ungureanu, Architectural Support for Subroutine Execution Time

Monitoring in Embedded Microprocessors, 14th

International Conference on System Theory and

Control, October 17-19, Sinaia, Romania

N. Botezatu, V. Manta, A. Stan, Self Adaptable Architecture for Power-Aware Embedded Systems,

14th

International Conference on System Theory and Control, October 17-19, Sinaia, Romania

2011

Botezatu, N. Manta, V. and Stan, A., 2011. Self-adaptability in Secure Embedded Systems: an

Energy-performance Trade-off. In: Proceedings of the World Congress on Engineering, The 2011

International Conference of Information Security and Internet Engineering, Hong Kong:

Newswood Limited, pp. 495-499.

Botezatu, N. and Stan, A., 2011. Denial of Service resistant MAC for wireless mesh networks.

Pending acceptance at the 22nd DAAAM International World Symposium, 23-26 November,

Vienna, Austria.

Membru în 5 granturi de cercetare

PNII 11-067/18.09.2007 Sistem integrat de telemonitorizare în timp real a pacienţilor şi

persoanelor în vârstă, membru în echipa de cercetare

PNII 11-070/ 18.09.2007 Soluţie integrată e-health de monitorizare a parametrilor vitali la

pacienţii cu afecţiuni cronice, membru în echipa de cercetare

CNCSIS type A, code 231, 2006-2007, RAM memory tests for coupling static and dynamic faults.

membru în echipa de cercetare

56 – CEEX II03/27.07.2006 Sistem pentru terapia personalizată a tulburărilor de expresie

lingvistică, membru în echipa de cercetare

131 – CEEX II02/02.10.2006 Interacţiunea gestuală cu sistemele informatice şi robotice, membru

în echipa de cercetare

Concluzii

73

6.3 Direcții viitoare de cercetare

Temele abordate în această teză aparțin domeniului proiectării arhitecturilor de sisteme de

calcul dedicate și deschid multiple oportunități de cercetare ulterioară. Subiectele tratate acoperă o

plajă largă a proiectării de sisteme de calcul dedicate de la proiectarea de module software până la

proiectarea de module hardware.

Capitolul trei prezintă proiectarea de biblioteci și module software utilizate în dezvoltarea

aplicațiilor pentru sistemele de calcul dedicate. Modulul software pentru implementarea de

automate finite poate fi extins prin adăugarea de câmpuri cu ajutorul cărora să se modeleze și

implementeze diverse funcționalități complexe impuse de aplicații (e.g. suport pentru metastări și

automate ierarhice, validări suplimentare pentru tranziții și acțiuni în scopul măririi siguranței

operării). Modelul poate face obiectul refactorizării codului în vederea eficientizării execuției pentru

cazul cel mai comun. Acest lucru se poate obține prin analiza atentă a caracteristicilor aplicațiilor

care fac uz de acest nucleu. O altă direcție de dezvoltare este proiectarea de aplicații (cu interfață

grafică) care să genereze în mod automat structurile de date utilizate de nucleul pentru automate

finite pe baza descrierii oferite de utilizatori este. Biblioteca de algoritmi de criptare poate fi extinsă

cu noi algoritmi cu performanțe de securizare și necesar de resurse diferite. De asemenea se are în

vedere dezvoltarea de componente (frameworks) pentru adaptarea dinamică a necesarului de

securizare al aplicațiilor la condițiile de mediu în care operează sistemele dedicate. Modulul pentru

conversia expresiilor din virgulă mobilă în expresii în virgulă fixă poate fi extins cu alte tipuri

întregi (e.g. 48 biți, 24 biți) sau poate fi orientat spre generarea de cod în limbaje de descriere

hardware care să permită implementarea expresiilor în circuite reconfigurabile. Toate bibliotecile și

modulele software pot beneficia de exprimarea la momentul proiectării a unor particularități ale

arhitecturii hardware pe care urmează să fie executate (e.g. prezența unor instrucțiuni de divizare,

prezența unor moduri de adresare speciale).

Capitolul patru prezintă proiectarea de sisteme dedicate folosind circuite reconfigurabile.

Sunt proiectate structuri pentru monitorizarea corectitudinii execuției aplicațiilor pe astfel de

sisteme. Aceste structuri de monitorizare pot fi folosite pentru implementarea de sisteme autonome

care să-și poată ajusta parametrii de funcționare sau structura funcție de condițiile curente de

execuție sau ale mediului astfel încât să mențină calitatea serviciilor oferite în situațiile de alterare a

funcționării unor componente ale sistemului. Pe lângă creșterea nivelului de încredere în

funcționarea corectă a sistemelor pe care aceste mecanisme de monitorizare îl oferă, ele pot fi un

element dintr-un lanț decizional cu care să se implementeze sisteme de calcul autonome: detecție,

cuantificare, verificare, raportare și gestionare. Sistemele reconfigurabile pot fi folosite în

transformarea dinamică a implementării funcțiilor unui sistem de calcul dedicat din implementare

software în implementare hardware. Această transformare necesită un studiu mai aprofundat pentru

a dezvolta metode și algoritmi performanți și generali (e.g. să poată gestiona eficient complexitatea

codului executat de aplicații).

Capitolul cinci propune o metodă de implementare a unui algoritm de testare a integrității

unui modul de memorie prin utilizarea unei structuri autotestabile microprogramate. Acest tip de

structură poate fi folosită și pentru execuția altor teste de memorie proiectate pentru detectarea altor

tipuri de defecte sau pentru memorii cu alte moduri de organizare. Structurile autotestabile cu

control microprogramat sunt structuri flexibile care pot fi utilizate în testarea corectei funcționări a

componentelor unui sistem de calcul.

74

Bibliografie

Ahuja, S., Gurumani, S., Spackman, C., & Shukla, S. (2009). Hardware Coprocessor Synthesis

from an ANSI C Specification. IEEE Design & Test of Computers, Vol. 6(No. 4), 58 - 67.

doi:10.1109/MDT.2009.81

Arora, D., Raghunathan, A., & Jha, N. K. (2006). Architectural Support for Safe Software

Execution on Embedded Processors. Proceedings of the 4th international conference on

Hardware/software codesign and system synthesis (pg. 106 - 111). New York: ACM.

doi:10.1145/1176254.1176281

Arora, D., Ravi, S., Raghunathan, A., & Jha, N. (2005). Secure Embedded Processing through

Hardware-assisted Run-time Monitoring. Proceedings of Design, Automation and Test in

Europe (pg. 178 - 183 Vol. 1). IEEE. doi:10.1109/DATE.2005.266

Atmel Inc. (2011). Atmel megaAVR Microcontrollers. Preluat de pe

http://www.atmel.com/dyn/products/devices.asp?category_id=163&family_id=607&subfam

ily_id=760

Avizienis, A., Laprie, J., & Randell, B. (2004). Dependability and its threats - A taxonomy. IFIP

Congress Topical Sessions (pg. 91-120). Kluwer.

Balanescu, D., Hritcu, C., & Stan, A. (2009). Upgrade of the Power Adjustment system of a 24 kW

Wall-mounted Condensing Combination Boiler. 3rd International Conference on Thermal

Engines and Environmental Engineering. Galati, Romania.

Bapatla, S., & Chandramouli, R. (2004). Battery power optimized encryption. IEEE International

Conference on Communications, (pg. 3802 - 3806). doi:10.1109/ICC.2004.1313264

Bârleanu, A., & Stan, A. (2003). Sistem de dezvoltare cu microcontroler-ul 80C31, ISBN 973-8048-

35-4. Iași: Ed. Performantica.

Bârleanu, A., Băitoiu, V., & Stan, A. (2011). Floating-point to fixed-point code conversion with

variable trade-off between computational complexity and accuracy loss. 15th International

Conference on System Theory and Control. Sinaia, Romania.

Bârleanu, A., Băitoiu, V., & Stan, A. (2011b). Digital filter optimization for C language. Advances

in Electrical and Computer Engineering, ISSN: 1582-7445, (revista ISI, Impact Factor:

0.688), Vol. 11(Nr. 3), 111 - 114.

Bobda, C. (2007). Introduction to reconfigurable computing - Architectures, algorithms and

applications. Dordrecht, The Netherlands: Springer.

Bolchini, C., Miele, A., & Sandionigi, C. (2011). A Novel Design Methodology for Implementing

Reliability-Aware Systems on SRAM-Based FPGAs. IEEE Transactions on Computers,

Vol. 60(No. 12), 1744 - 1758. doi:10.1109/TC.2010.281

Botezatu, N., & Stan, A. (2009). Low Power Embedded System Used In Healthcare Systems.

Buletinul Institutului Politehnic din Iasi, Tomul LV(LIX)(Fasc. 1).

Botezatu, N., & Stan, A. (2011). Denial of Service resistant MAC for wireless mesh networks. 22nd

DAAAM International World Symposium. Vienna, Austria.

Botezatu, N., Manta, V., & Stan, A. (2010). Self Adaptable Architecture for Power-Aware

Embedded Systems. 14th International Conference on System Theory and Control. Sinaia,

Romania.

Botezatu, N., Manta, V., & Stan, A. (2011). Self-adaptability in Secure Embedded Systems: an

Energy-performance Trade-off. Proceedings of the World Congress on Engineering The

2011 International Conference of Information Security and Internet Engineering, (pg. 495 -

499). Hong Kong.

Bibliografie

75

Botezatu, N., Stan, A., & Panduru, L. (2009). Power-Aware Framework For Encrypted

Communications. 20th International Danube-Adria-Association for Automation and

Manufacturing Symposium, (pg. 825 - 826). Vienna, Austria.

Caşcaval, P., & Bennett, S. (2001). Efficient march test for 3-coupling faults in random access

memories. Microprocessors and Microsystems, Vol. 24(No. 10), 501 - 509.

doi:10.1016/S0141-9331(00)00103-4

Cașcaval, P., & Stan, A. (2007). March Test for All Static 2-Coupling Faults in Random-Access

Memories. 9th International Symposium on Automatic Control and Computer Science. Iasi,

Romania.

Caşcaval, P., Bennett, S., & Huţanu, C. (2004). Efficient March Tests for a Reduced 3-Coupling

and 4-Coupling Faults in Random-Access Memories. Journal of Electronic Testing, Vol.

20(No. 3), 227 - 243. doi:10.1023/B:JETT.0000029457.21312.23

Cașcaval, P., Silion, R., & Stan, A. (2006). MARCHS2C: A Test for All Static 2-Cell RAM

Coupling Faults. Buletinul Institutului Politehnic din Iasi, Tomul LII (LVI)(Fasc. 1 – 4).

Cașcaval, P., Silion, R., & Stan, A. (2007). A Logic Design for MarchS2C Memory BIST

Implementation. 9th International Symposium on Automatic Control and Computer Science.

Iasi, Romania.

Cilio, A., & Corporaal, H. (1999). Floating Point to Fixed Point Conversion of C Code.

Proceedings of the 8th International Conference on Compiler Construction (pg. 229 - 243).

Amsterdam, The Netherlands: Springer.

Ciorap, R., Carauleanu, A., Petcu, L., Pomazan, V., & Stan, A. (2008). E-Health Solution for

Monitoring the Evolution of the Chronically Disease at the Pregnant Women. UPB

BIOINGTEH – Exploratory Workshop, Advanced Materials & Technologies in Biology and

Medicine. Poiana Brasov, Romania.

Ciorap, R., Zaharia, D., Corciova, C., Ungureanu, M., Lupu, R., & Stan, A. (2008). Dispozitiv

Wireless pentru Monitorizarea Pacientilor cu Afectiuni Cronice. Revista Medico-

Chirurgicala a Societatii de medici si Naturalisti din Iasi, Vol. 112(No. 4).

Cummings, C. (2002). Simulation and synthesis techniques for asynchronous FIFO design. SNUG.

San Jose.

Cypress Inc. (2011). Programmable System-on-Chip. Preluat de pe

http://www.cypress.com/?id=1353

De Bosschere, K., Luk, W., Martorell, X., Navarro, N., O'Boyle, M., Pnevmatikatos, D., . . .

Temam, O. (2007). High-Performance Embedded Architecture and Compilation Roadmap.

În P. Stenstrom (Ed.), LNCS 4050, Transactions on High Performance Embedded

Architectures and Compilers I (pg. 5-29). Berlin: Springer-Verlag.

De Jonge, J., & Smeulders, A. (1976). Moving Inversion Test Pattern is. Computer System Desig,

Vol. 19(No. 5), 169 - 173.

Duranton, M., Yehia, S., De Sutter, B., De Bosschere, K., Cohen, A., Falsafi, B., . . . Valero, M.

(2010). THE HIPEAC VISION. European Network of Excellence on High Performance and

Embedded Architecture and Compilation.

Goldberg, D. (1991). What Every Computer Scientist Should Know About Floating-Point

Arithmetic. ACM Computing Surveys, Vol. 23(No. 1). doi:10.1145/103162.103163

Goossens, K., Dielissen, J., & Radulescu, A. (2005). AEthereal network on chip: concepts,

architectures, and implementations. IEEE Design & Test of Computers, Vol. 22(No. 5), 414-

421. doi:10.1109/MDT.2005.99

Goossens, K., Vermeulen, B., & Nejad, A. (2009). A high-level debug environment for

communication-centric debug. Design, Automation & Test in Europe Conference &

Exhibition, 2009 (pg. 202-207 ). Nice: IEEE.

Hamdioui, S., & Van De Goor, A. (2000). An experimental analysis of spot defects in SRAMs:

realistic fault models and tests. Proceedings of the Ninth Asian Test Symposium (pg. 131 -

138). Taipei , Taiwan: IEEE. doi:10.1109/ATS.2000.893615

Bibliografie

76

Hamdioui, S., van de Goor, A., & Rodgers, M. (2002). March SS: A Test for All Static Simple

RAM Faults. IEEE International Workshop on Memory Technology, Design and Testing

(pg. 95 - 100). IEEE. doi:10.1109/MTDT.2002.1029769

Han, K. (1996). Automating transformations from floating-point to fixed-point. Austin: Faculty of

the Graduate School of the University of Texas at Austin.

Hansson, A., Ekerhult, M., Molnos, A., Milutinovic, A., Nelson, A., Ambrose, J., & Goossens, K.

(2011). Design and implementation of an operating system for composable processor

sharing. Microprocessors and Microsystems, Vol. 35(No. 2), 246-260.

doi:10.1016/j.micpro.2010.08.008

Harel, D. (2009). Statecharts in the making: a personal account. Communications of the ACM, Vol.

52(No. 3), 67-75. doi:10.1145/1467247.1467274

Hauck, S., & Dehon, A. (2008). Reconfigurable computing. Burlington: Mogran Kaufmann.

Hennessy, J., & Patterson, D. (2007). Computer Architecture: A Quantitative Approach, 4th

Edition. Morgan Kaufmann.

IAR Systems. (2011). IAR Embedded Workbench for Atmel AVR. Preluat de pe

http://www.iar.com/en/Products/IAR-Embedded-Workbench/AVR/

IAR Systems. (2011). IAR Visual State. Preluat de pe http://www.iar.com/en/Products/IAR-

visualSTATE/

IEC 60730. (2000). Automatic electrical controls for household and similar use. IEC Standard.

IEC 61508. (2002). Functional safety of electrical/electronic/programmable electronic safety-

related systems. IEC Standard.

Kearfott, R. (1996). Interval Computations: Introduction, Uses, and Resources. Euromath Bulletin,

Vol. 2(No. 1), 95-112.

Kim, V., & Chen, T. (1999). On Comparing Functional Fault Coverage and Defect Coverage for

Memory Testing. IEEE Transactions on CAD, Vol. 18(No. 11), 1676 - 1683.

doi:10.1109/43.806812

Klein, R., & Moona, R. (2004). Migrating software to hardware on FPGAs. Proceedings of IEEE

International Conference on Field-Programmable Technology (pg. 217 - 224). IEEE.

doi:10.1109/FPT.2004.1393271

Kocher, P., Lee, R., McGraw, G., & Raghunathan, A. (2004). Security as a New Dimmension in

Embedded System Design. Proceedings of the 41st annual Design Automation Conference

(pg. 753-760). New York, USA: ACM. doi:10.1145/996566.996771

Kum, K., Kang, J., & Sung, W. (2000). AUTOSCALER For C: An Optimizing Floating-Point to

Integer C Program Converter For Fixed-Point Digital Signal Processors. IEEE Trans. on

Circuits and Systems II: Analog and Digital Signal Processing, Vol. 47(No. 9), 840-848.

Larsson, E., Vermeulen, B., & Goossens, K. (2010). A distributed architecture to check global

properties for post-silicon debug. 15th IEEE European Test Symposium (ETS), 2010 (pg.

182 - 187). Praha: IEEE. doi:10.1109/ETSYM.2010.5512760

Lee, E. (2002). Embedded software. În Advances in Computers (Vol. 56, pg. 55-95). Elsevier.

doi:10.1016/S0065-2458(02)80004-3

Lee, G., & Milne, G. (2005). Programming paradigms for reconfigurable computing.

Microprocessors and Microsystems, 435-450. doi:10.1016/j.micpro.2005.01.002

Lupu, R., Stan, A., & Ungureanu, F. (2008). Wireless Device for Patient Monitoring. Proceedings

of World Congress on Engineering, (pg. 1687-1691). London.

Lupu, R., Stan, A., & Ungureanu, F. (2009). Patient Monitoring: Wearable device for patient

monitoring. În Advances in Electrical Engineering and Computational Science (pg. 659 -

668). Springer Netherlands.

Lysecky , R., Stitt, G., & Vahid, F. (2006). Warp Processors. Proceedings of the 41st annual Design

Automation Conference (pg. 659 - 681). New York: ACM. doi:10.1145/996566.1142986

Lysecky, R., & Vahid, F. (2009). Design and implementation of a MicroBlaze-based warp

processor. ACM Transactions on Embedded Computing Systems, Vol. 8(No. 3), 22 - 43.

doi:10.1145/1509288.1509294

Bibliografie

77

Mahmood, A., & McCluskey, E. (1988). Concurrent Error Detection Using Watchdog Processors –

A Survey. IEEE Transactions on Computers, Vol. 37(No. 2), 160 - 174.

doi:10.1109/12.2145

Menard, D., Chillet, D., Charot, F., & Sentieys, O. (2002). Automatic Floating-point to Fixed-point

Conversion for DSP Code Generation. International Conference on Compilers,

Architecture, and Synthesis for Embedded Systems (pg. 270 - 276). New York: ACM.

doi:10.1145/581630.581674 ISBN:1-58113-575-0

Menezes, A., van Oorschot, P., & Vanstone, S. (1996). Handbook of Applied Cryptography (ed. 1).

Boca Raton: CRC Press.

Microchip Inc. (2011). Configurable Logic Cell. Preluat de pe

http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en552961

Micronsemi Inc. (2011). SmartFusion: Intelligent Innovative Integration. Preluat de pe

http://www.actel.com/products/smartfusion/

Naeser, G., Asplund, L., & Furunäs, J. (2005). SafetyChip: a time monitoring and policing device.

Annual ACM SIGAda international conference on Ada: The Engineering of Correct and

Reliable Software for Real-Time & Distributed Systems using Ada and Related Technologies

(pg. 63 - 68). New York: ACM. doi:10.1145/1104011.1103856

Nair, R., Thatte, S., & Abraham, J. (1978). Efficient Algorithms for Testing Semiconductor

Random-Access Memories. IEEE Transactions on Computers (pg. 572 - 576). IEEE.

doi:10.1109/TC.1978.1675150

Nieuwland, A., Kang, J., Gangwal, O., Sethuraman, R., Busá, N., Goossens, K., . . . Lippens, P.

(2002). C-HEAP: A Heterogeneous Multi-Processor Architecture Template and Scalable

and Flexible Protocol for the Design of Embedded Signal Processing Systems. Design

Automation for Embedded Systems, Vol. 7(No. 3), 233 - 270. doi:10.1023/A:1019782306621

Papadomanolakis, K., Kakarountas, A., Sklavos, N., & Goutis, C. (2002). A fast Johnson-Mobius

encoding scheme for fault secure binary counters. Design, Automation and Test in Europe.

Philips Semiconductor Inc. (2002). Device Transaction Level (DTL) Protocol Specification. Preluat

de pe Device Transaction Level (DTL) Protocol Specification.

Popa, C., & Stan, A. (2010). Mach Speed Processing. Dynamic Cloning of Software Functionality

in Hardware. Buletinul Institutului Politehnic din Iasi, Tomul LVI(LX)(Fasc. 2).

Ragel, R., Parameswaran, S., & Mohammad Kia, S. (2005). Micro Embedded Monitoring for

Security in Application Specific Instruction-set Precessors. Proceedings of the 2005

international conference on Compilers, architectures and synthesis for embedded systems

(pg. 304 - 314). New York: ACM. doi:10.1145/1086297.1086337

Ravi, S., Raghunathan, A., Kocher, P., & Hattangady, S. (2004). Security in embedded systems:

Design challenges. ACM Transactions on Embedded Computing Systems, Vol. 3(No. 3), 461

- 491. doi:10.1145/1015047.1015049

Rowley Associates. (2011). CrossWorks for ARM. Preluat de pe

http://www.rowley.co.uk/arm/index.htm

Salewski, F., & Taylor, A. (2007). Fault Handling in FPGAs and Microcontrollers in Safety-Critical

Embedded Applications: A Comparative Survey. 10th Euromicro Conference on Digital

System Design Architectures, Methods and Tools, 2007 (pg. 124-131). IEEE.

doi:10.1109/DSD.2007.4341459

Samek, M. (2009). Practical UML Statecharts in C/C++, Second Edition: Event-Driven

Programming for Embedded Systems. Newnes (imprint of Elsevier).

Sekanina, L. (2003). Towards Evolvable IP Cores for FPGA. NASA/DoD Conference on Evolvable

Hardware, 2003. Proceedings. (pg. 145-154). IEEE. doi:10.1109/EH.2003.1217659

Shi, C., & Brodersen, R. (2003). An Automated Floating-point to Fixed-point Conversion

Methodology. Proc. of IEEE International Conf. on Acoustics, Speech, and Signal

Processing vol.2 (pg. II - 529-32). Hong Kong: IEEE Xplore.

doi:10.1109/ICASSP.2003.1202420

Bibliografie

78

Sima, M., Coțofană, S., Vassiliadis, S., van Eijndhoven, J., & Vissers, K. (2001). A Reconfigurable

Functional Unit for TriMedia/CPU64. A case study. Systems, Architectures, Modeling, and

Simulation Workshop – SAMOS (pg. 224 - 241). Springer-Verlag.

Singh, S. (2011). Computing without processors. Communications of the ACM, Vol. 54(No. 8), 46-

54. doi:10.1145/1978542.1978558

Sorin, D. (2009). Fault Tolerant Computer Architecture. Morgan & Claypool.

ST Microelectronics. (2011). STM32 - 32-bit ARM Cortex MCUs. Preluat de pe

http://www.st.com/internet/mcu/class/1734.jsp

Stallings, W. (2010). Computer organization and architecture - Designing for performance (8th

edition). Upper Saddle River, New Jersey: Pearson Education.

Stan, A., & Botezatu, N. (2009). Data Encryption Methods for Power Aware Embedded Systems

Used in Patient Monitoring. International Carpathian Control Conference. Zakopane,

Poland.

Stan, A., Botezatu, N., & Vieriu, G. (2009). The Design Of A Finite State Machine Engine With

Safe Operation Used In Embedded Systems Design. 20th International Danube-Adria-

Association for Automation and Manufacturing Symposium, (pg. 1507-1508). Vienna,

Austria.

Stan, A., Botezatu, N., Panduru, L., & Lupu, R. (2009). A finite state machine model used in

embedded systems software development. Buletinul Institutului Politehnic din Iasi, Tomul

LV(LIX)(Fasc. 2).

Stan, A., Lupu, R., & Ciorap, R. (2010). Biosignal Monitoring and Processing for Management of

Hypertension. 12th Mediteranean Conference on Medical and Biological Engineering and

Computing. Chalkidiki, Greece.

Stan, A., Panduru, L., & Lupu R. (2008). Low Power Devices for Gestural Human - Computer

Interaction. 19th International DAAAM Symposium - Intelligent Manufacturing &

Automation: Focus on Next Generation of Intelligent Systems and Solution, (pg. 1287-

1288). Trnava, SLOVAKIA.

Stan, A., Panduru, L., & Ungureanu, F. (2010). Architectural Support for Subroutine Execution

Time Monitoring in Embedded Microprocessors. 14th International Conference on System

Theory and Control. Sinaia, Romania.

Stan, A., Valachi, A., & Bârleanu, A. (2011). The design of a run-time monitoring structure for a

MPSoC. 15th International Conference on System Theory and Control. Sinaia, Romania.

Steiner, G., Shenoy, K., Isaacs, D., & Pellerin, D. (2006, November). Accelerate algorithms with

FPGA processors. Electronic Engineering Times-Asia, 1-4.

Stroustrup, B. (2011, July 4). Bjarne Stroustrup's FAQ. Preluat de pe

http://www2.research.att.com/~bs/bs_faq.html

Suk, D., & Reddy, S. (1981). A March Test for Functional Faults in Semiconductor Random Access

Memories. IEEE Transactions on Computers, Vol. C-30(No. 12), 982 - 985.

doi:10.1109/TC.1981.1675739

Sukittanon, S., & Dame, S. (2006). Algorithm – Embedded State Machine Design for PSoC using C

Programming. Preluat pe 9 1, 2011, de pe http://www.psocdeveloper.com/docs/appnotes/an-

mode/detail/an-pointer/an2329/an-file/125.html

Thiele, L., & Wilhelm, R. (2004). Design for Timing Predictability. Journal of Real Time Systems,

157-177.

Tong, J., & Khalid, M. (2008). Profiling Tools for FPGA-Based Embedded Systems: Survey and

Quantitative Comparison. Journal of Computers, Vol. 3(No. 6). doi:10.4304/jcp.3.6.1-14

Tudor, D., & Marcu, M. (2009). Designing a power efficiency framework for battery powered

systems. Proceedings of SYSTOR 2009: The Israeli Experimental Systems Conference.

ACM. doi:10.1145/1534530.1534537

Ungureanu, F., Lupu, R., & Stan, A. (2011). Towards Real Time Monitoring of Water Quality in

River Basins. Environmental Engineering and Management Journal, ISSN: 1582-9596,

(revista ISI, Impact factor 0.885), Vol. 9(No. 9), 1267 - 1274.

Bibliografie

79

Van de Goor, A. J. (1993). Using march tests to test SRAMs. IEEE Design & Test of Computers,

Vol. 10(No. 1), 8 - 14. doi:10.1109/54.199799

Van de Goor, A. J. (1998). Testing Semiconductors Memories. Theory and Practice. John Wiley &

Sons Inc.

Van de Goor, A. J., & Al-Ars, Z. (2000). Functional Faults Models: A Formal Notation and

Taxonomy. Proceedings VLSI Test Symposium, 2000, (pg. 281 - 289).

doi:10.1109/VTEST.2000.843856

Van de Goor, A. J., & Gaydadjiev, G. N. (1997). March U: A Test for All Unlinked Memory Faults.

IEEE Proceedings Circuits, Devices and Systems, 144, pg. 155 - 160. doi:10.1049/ip-

cds:19971147

Van de Goor, A. J., Gaydadjiev, G. N., Mikitjuk, V. G., & Yarmolik, V. N. (1996). March LR: a

test for realistic linked faults. Proceedings of 14th VLSI Test Symposium, (pg. 272 - 280).

doi:10.1109/VTEST.1996.510868

Van de Goor, A., & De Neef, J. (1999). Industrial Evaluation of DRAMs Tests. Proceedings of

Design Automation and Test in Europe, (pg. 623 - 630). Munich.

Van de Goor, A., Gaydadjiev, G. N., Yarmolik, V. N., & Mikitjuk, V. G. (1997). March LA: a test

for linked memory faults. Proceedings of European Design and Test Conference, (pg. 627 -

634). doi:10.1109/EDTC.1997.582440

Vassiliadis, S., Wong, S., & Cotofana, S. (2003). Microcode processing: Positioning and directions.

IEEE Micro, Vol. 23(No. 4), 21 - 30. doi:10.1109/MM.2003.1225960

Vermeulen , B., Goossens , K., & Umrani , S. (2008). Debugging Distributed-Shared-Memory

Communication at Multiple Granularities in Networks on Chip. Proceedings of the Second

ACM/IEEE International Symposium on Networks-on-Chip (pg. 3-12). IEEE.

Wilhelm, R., Engblom, J., Ermedahl, A., Holsti, N., Thesing, S., Whalley, D., & Bernat, G. (2008).

The Worst-Case Execution Time Problem – Overview of Methods and Survey of Tools.

ACM Transactions on Embedded Computing Systems, Vol. 7(No. 3), 36 - 53.

doi:10.1145/1347375.1347389

Williams, R. (2006). Real-Time Systems Development. Oxford: Elsevier.

Wolf, W. (2003). A decade of hardware/software codesign. IEEE Computer, Vol. 36(No. 4), 38-43.

doi:10.1109/MC.2003.1193227

Wolf, W. (2007). High-Performance Embedded Computing - Architectures, Applications and

Methodologies. San Francisco: Morgan Kaufmann.

Xilinx Inc. (2011). Fast Simplex Link. Preluat de pe

http://www.xilinx.com/support/documentation/ip_documentation/fsl_v20.pdf

Xilinx Inc. (2011). Local Memory Bus. Preluat de pe

http://www.xilinx.com/support/documentation/ipembedprocess_memoryinterface_lmb.htm

Xilinx Inc. (2011). MicroBlaze Soft Processor Core. Preluat de pe

http://www.xilinx.com/tools/microblaze.htm

Xilinx Inc. (2011). PicoBlaze 8-bit Embedded Microcontroller User Guide. Preluat de pe

http://www.xilinx.com/support/documentation/ip_documentation/ug129.pdf

Xilinx Inc. (2011). Processor Local Bus. Preluat de pe

http://www.xilinx.com/support/documentation/ip_documentation/ds531.pdf

Xilinx Inc. (2011). Zynq-7000 Extensible Processing Platform. Preluat de pe

http://www.xilinx.com/products/silicon-devices/epp/zynq-7000/index.htm

Zhang, T., Zhuang, X., & Pande, S. (2005). Anomalous Path Detection with Hardware Support.

Proceedings of the 2005 international conference on Compilers, architectures and synthesis

for embedded systems (pg. 43 - 54). New York: ACM. doi:10.1145/1086297.1086305

Documents

Contribuții în proiectarea unităților centrale utilizate ... Andrei rezumat.pdf · 5.6 Proiectarea logicii de testare ... servicii, convergența funcționalității dispozitivelor