Embedded sistemi put projektanta do cilja

Kada se govori o projektovanju kompleksnog sistema ~esto se projektantima postavljaju sledea

pitanja: Koji pristup u toku rada treba da usvoje? Zatim na koji nain da se pone sa radom na projektu,
kako da se izvri validacija dizajna, i kako da se isprave greke u projektu? Najei odgovor koji moete
uti od iskusnijih je: Treba pristupiti re{avanju problema {to je mogu}e apstraktnije.
Uobiajena je praksa da projektant poinje od behavioral specifikacije sistema. Specifikacijom
se odredjuje kakvih i koliko ulaza i izlaza sistem poseduje, i kakvi odnosi postoje izmedju signala na
ulazima i signala na izlazima. Drugim reima, behavior specifikacijom se odredjuje na koji nain sistem
sam sebe predstavlja (vidljiv je) prema spoljnem svetu. Spoljni pogled sistema esto se naziva
arhitektura sistema. Sistem se posmatra kao crna-kutija. Za njega postoje brojne implementacije pri
emu sve njih karakterie isto ponaanje. S obzirom da je arhitektura jedan apstraktni pogled na sistem
ona specificira ta sistem moe da uradi, a ignorie pitanje kako sistem u sutini postie eljeno
ponaanje.
Naredni korak predstavlja implementacija. U toku ove faze arhitektura se deli na funkcije. Svakoj
funkciji, radi izvrenja, se dodeljuje hardver i vremenski-period za koji se ta funkcija mora obaviti. U
toku ovog koraka definie se komunikacija izmedju funkcija. Ponovo projektant vidi hardverske jedinice
kao crne kutije i ne vodi mnogo rauna o implementacionim detaljima. Sada projektant moe da
uporedjuje ponaanje (behavior) izabrane implementacije sa poetno zadatim arhitekturnim opisom. Ako
su oni kompatibilni, dizajnom se redukuje implementacija pojedinih hardverskih jedinica. Naravno, ove
jedinice se implementiraju u saglasnosti sa istom paradigmom abstrakcije: To znai da se funkcionalnost
deli na pod-funkcije, pri emu se svakoj dodeljuje deo hardvera i vremenski period za koji se ta funkcija
mora izvriti. Ova aktivnost se, produbljuje sve dok projektant ne dodje do saznanja da su dostupne sve
hardverske jedinice iz standardne biblioteke komponenata. U tom trenutku implementacija sistema je
zavrena.
Zadnji korak karakterie realiziacija sistema. U toku ove aktivnosti kreira se fizika
reprezentacija sistema. Tako na primer, ako sve komponente implementacije mogu da se smeste na jedan
ip, tada se realizacija odnosi na izradu layout-a ipa. Ako je za realizaciju sistema potreban vei broj
ipova tada realizacija ukljuuje i izradu layout-a tampane ploe na koju se postavljaju ipovi. Ako je za
realizaciju sistema potreban vei broj ploa tada realizacija ukljuuje i izradu mehanikih delova, kakvi
su konektori, kutija, i dr.

Efikasnost aplikaciono specifinog hardvera

Uobiajeno, aplikacikono specifina implementacija algoritma ini mikroprocesor, memorija i
koprocesor koji predstavlja aplikaciono specifini hardver (vidi Sliku 1). Kada program koji se izvrava
na mikroprocesoru naidje na deo koda koji se implementira od strane koprocesora, kolo arbitra (nije
prikazano na Slici 1) predaje pravo upravljanja nad magistralom koprocesoru. I dok koprocesor obavlja
izraunavanje, mikroprocesor ostaje u pasivno (idle) stanje. Konano kada koprocesor zavri, on
signalizira arbitru, koji sada ponovo vraa pravo upravljanja nad magistralom mikroprocesoru, a
koprocesor prelazi u pasivno stanje. Koprocesor operie nad podacima koje pribavlja iz memorije. On
smeta rezultate operacije u memoriju tako da program koji se izvrava od strane mikroprocesora moe da
ih koristi, tj. pristupa im.

koprocesor

mikroprocesor
magistrala

memorija
Slika 1. Uobiajena organizacija embedded sistema: mikroprocesor sa aplikaciono specifinim hardverom
Obuhvatnija organizacija embedded sistema, od one prikazane na Slici 1, koja ukljuuje etiri
klase aplikaciono specifinog hardvera, pri emu se svaka klasa razlikuje od druge u odnosu na nain
sprege hardvera i mikroprocesora, prikazana je na Slici 2.
VLIW ili
superskalarni

klasa 1

koprocesor

klasa 2

MIMD deljiva
memorija

klasa 3

MIMD slabo
spregnuti

klasa 4

registri

ke{

memorija

hijerarhija memorije
kod mikroprocesora

klase aplikaciono
specifi~nog hardvera

Slika 2. Klasifikacija aplikaciono specifinog hardvera u etiri kategorije

Napomena: Ako se ne moe programirati od strane mikroprocesora, hardver klase_3 se esto naziva "koprocesor".

klasa _1: ako aplikaciono specifini hardver (ASH) moe da pristupa registrima mikroprocesora tada
rezultantni sistem nazivamo VLIW ili superskalarni procesor.
klasa _2: ako ASH pristupa ke memoriji procesora tada kaemo da je rezultantni sistem koprocesorski
sistem

klasa _3: ako ASH moe da pristupa samo glavnoj memoriji tada kao rezultat imamo MIMD sistem sa
deljivom memorijom.
klasa _4: u ovom sluaju komunikacija se ostvaruje preko namenskih komunikacionih modula a ne
itanjem i upisom u deljivi memorijski prostor.
Uobiajeno, u praksi, projektanti sistema termin koprocesor koriste za identifikaciju hardvera iz
klase_2 kao i klase_3 pod uslovom da hardver klase _3 nema svoju sopstvenu programsku memoriju ali,
postoji jasna diferencijacija u odnosu na pristup masterslave koji postoji izmedju mikroprocesora i
hardvera klase _3.

Komunikacioni metodi
Kada se program izvrava od strane mikroprocesoru tada prenos upravljanja ka ASH-u mora da se
ostvari sa dosta predostronosti kako bi se efikasno pristupalo podacima koji se procesiraju. Pitanje koje
se sada postavlja je sledee: Koliko je, sa jedne strane, potrebno vremena koprocesoru da proita podatke,
Tr,cop, a sa druge strane, koliko je vremena potrebno mikroprocesoru da proita te iste podatke Tr, mp. Na
slian nain ovo pitanje se moe odnositi i na to koliko izinosi potrebno vreme da koprocesor ili
mikroprocesor upie konani rezultat u odredite. Tw,cop i Tw,mp, respektivno. Pri ovome, da bi koprocesor
bio efikasan, neophodno je da on mora da obavi svoj zadatak najmanje Tr,cop + Tw,cop - Tr,mp - Tw,mp
sekundi bre u odnosu na mikroprocesor.
Ukazaemo sada na razliite eme komuniciranja koje postoje izmedju mikroprocesora i koprocesora.
Svi savremeni mikroprocesori poseduju skupove instrukcija koje manipuliu nad podacima koji su
smeteni u on-chip registarskom polju (RF-Register File). Koprocesor ne moe pristupati RF-u. Zbog
ovoga, komunikacija izimedju hardvera koprocesora i programa koji se izvrava na mikroprocesoru
moe da se ostvari na jedan od sledea dva naina:
1. komuniciranje preko deljive memorije o ovom nainu komuniciranja smo ve govorili (vidi
Sliku 1 i 2). Treba ipak naglasiti da kod ovog pristupa postoje sledea tri nedostatka:
a) pristup memoriju kod savremenih mikroprocesora je za red veliine sporiji u odnosu na
pristup RF-u ili ke memoriji
b) ke koprocesora mora da ima ugradjen hardver koji podrava ke koherenciju i
implementira bus-snooping protokol
c) koprocesor mora da ima ugradjeno memorijski interfejs koji generie memorijske adrese
kao i da obavlja operacije mem_read i mem_write.
2. komunikacija tipa master-slave program koji se izvrava na mikroprocesoru vri direktno upis,
preko magistrale, u registre koprocesora. Kada koprocesor zavri svoje izraunavanje, program
ita rezultate iz registara koprocesora. Kao i kod komuniciranja preko deljive memorije, ovaj
pristup zahteva da koprocesor poseduje bus-interface logiku ali koja je u konkretnom sluaju
znatno jednostavnija jer koprocesor kao bus-slave jedinica nikad ne inicira prenos podataka. Ako
se podaci koji su potrebni koprocesoru nalaze u RF-u illi keu tada vreme potrebno da se oni
dobave u koprocesor je znatno krae u odnosu na pristup kod deljive memorije. U principu vreme
upisa podataka u koprocesorski registar je znatno krae u poredjenju sa vremenom pristupa
memorijskoj lokaciji. Sa druge strane, brzina sa kojom koprocesor pribavlja podatke iz glavne
memorije je sporija kod ovog pristupa u odnosu na komuniciranje preko deljive memorije.
Na projektantu je da odlui koji e komunikacioni pristup da koristi. U konanom rezultati simulacije
treba da pokau, ako se uzme u obzir i cena, da li treba odabrati bre ali skuplje komuniciranje preko
deljive memorije ili jevtinije ali sporije zasnovano na master-slave konceptu.

Redukcija komunikacija
Razmotriemo sada naine na osnovu kojih se moe smanjiti komunikacija izmedju koprocesora i
programa koji se izvrava na mikroprocesoru.
Sa ciljem da se minimizira komunikacioni overhead, neophodno je podeliti algoritam na deo koji
obavlja hardver i deo koji obavlja softver, ali pri tome deoba treba da bude takva da prenos podataka na
granici hardver/softver bude minimalan. Kao primer, razmotriemo programski segment pomou koga se
izraunava operacija oper ( ), za sve elemente vektora.
void func (vec,n)
{
i = n-1;
while (i >= 0)
{
vec [i] = oper (vec [i]);
i = i-1;
}
}
Ako je koprocesor izveden tako da izraunava oper( ) bre u odnosu na mikroprocesor, tada
particija koja rezultira tome da koprocesor bude to je mogue jednostavniji se izvodi na sledei nain. U
toku svake od n iteracija, mikroprocesor puni vrednost vec[i] u koprocesor, a zatim ita rzultat
oper(vec[i]). Ako usvojimo da cena komuniciranja iznosi h ciklusa po broju (elementu vektora),
tada e ukupni komunikacioni overhead iznositi 2nh ciklusa. Alternativno reenje se bazira na
implementaicji celokupne while petlje u formi func( ) koju e obavljati hardver koprocesora.
Komunikacioni overhead se sada redukuje na 2h ciklusa, pri emu se h ciklusa koristi za prenos adrese
vektora vec, a h ciklusa za prenos prema koprocesoru inicijalne indeksne vrednosti n-1.
Naalost, pomenuta particija takodje zahteva da se operacije i=0 i i=i-1 implementiraju od strane
hardvera koprocesora, a takodje da se implementiraju i operacije tipa izraunavanje adrese vec[i] kao i
Load i Store. Treba pri tome biti svestan da je mala verovatnoa da ove operacije koprocesor moe
efikasnije da izvrava u odnosu na mikroprocesor.
Ovaj zakljuak ukazuje da particija koja se karakterie najmanjim komunikacionim overhead-om
uslovljava projektanta da duplicira hardver mikroprocesora koji se ugradjuje u koprocesor. Ovakvim
poristupom poveava se cena koprocesora, kao i potronja sistema, a sistem je podloniji otkazima i
grekama.

Performanse koprocesora
Implicitno se podrazumeva da ASH znaajno bre radi od softverske implementacije. No da bi
potvrdili ovu predpostavku potrebno je tano proceniti koliko je to bre.
Kao prvo treba da se zna maksimalno vreme koje koprocesor moe da koristi da bi obavio
izraunavanje. Ovo vreme emo oznaiti kao Tmac,cop. Dalje je neophodno znati oekivano vreme ciklusa
koprocesora Tcycle,cop. Na osnovu ova dva vremena odredjuje se maksimalan broj ciklusa koja su
koprocesoru potrebni da bi obavio izraunavanje.
Nmax,cop = Tmax,cop / Tcycle,cop
Izbor Tcycle,cop je ogranien vremenskim specifikacijama komponenata koji su projektantu raspolo`ivi
iz hardverske biblioteke koje on koristi za implementaciju koprocesora. Vreme ciklusa je u principu

odredjeno zahtevom da koprocesor mora da komunicira sa mikroprocesorom. Najvei broj bus-protokola

koji se koriste za ovaj tip komunikacije zahtevaju da se bus-interfejsi obe komponente taktuju istom
frekvencijom. Imajui u vidu ovu konstataciju kaemo da vai Tcycle,cop = Tcycle,mp
Na slici 3 prikazana je jedna minimalna koprocesorska implementacija koju ine funkcionalna
jedinica, RF polje i kontroler tipa FSM.

Kontroler (Finite State Machine - FSM)

funcion
select

status

wr rd1 rd2
Register
File - RF

write

result

read1

operand1

read2

operand2

Funtional
Unit - FU

Slika 3. Minimalna koprocesorska implementacija

Neophodno je sada da za strukturu sa Slike 3 odrediti koliko e ista biti bra u odnosu na reenje
bazirano na mikroprocesoru. Kod ove procene poznavanje nekih parametara je od kljune vanosti. Jedan
od njih je vreme ciklusa koprocesora, Tcycle,cop, a drugi prosean broj ciklusa po instrukciji NCPI,mp koji je
potreban mikroprocesoru.
Ako se izvrenje programskog segmenta sa mikroprocesora prebaci na koprocesor performansni-gain
bie definisan slede}im izrazom:
Gaincop = (Vreme potrebno mikroprocesoru)/ (vreme potrebno koprocesoru)
=(Ninst,mp NCPI,mp Tcycle,mp + Tr,mp + Tw,mp) / ( Ninst,cop NCPI,cop Tcycle,cop + Tr,cop + Tw,cop)...............(1)
gde: Ninst,mp predstavlja broj instrukcija potreban mikroprocesoru da izrauna algoritam; Ninst,cop se
odnosi na broj upravljakih koraka potreban koprocesoru da izrauna isti algoritam.
Naravno da se sada postavlja pitanje koja je minimalna, a koja je maksimalna vrednost za Gaincop?
Jasno je da je NCPI,cop = 1 jer kod FSM-a ne postoje branch delay slotovi kao i neiskorieni load delay
slotovi. Dalje realno je oekivati da Ninstr,cop bude manje od Ninst,mp.
Definisa}emo prvo Pbranch kao verovatnou pojavljivanja instrukcije grananja u instrukcionom nizu
mikroprocesora. Zatim definiimo, za jedan mikorporocesor prosean broj ciklusa koji je potreban za
izvrenje non-branch instrukcije, kao NCPU, notbranch, mp. Neka zatim vrednost Nbrpen (tzv. Nazvana branch
penalty) predstavlja prosean broj ekstra ciklusa koji je potreban za izvrenje instrukcije branch u odnosu
na non-branch. Shodno prethodnoj diskusiji imaemo
Ninstr,cop = ( 1 - Pbranch) Ninstr,mp

...................................................................(2)

NCPI,mp = (NCPI,notbrnch,mp + PbranchNbrpen) NCPI,cop .............................................(3)

U Tabeli 1 prikazan je prosean Nbrpen kod RISC mikroprocesora

Tabela 1 Prosean broj Nbrpen kod RISC mikroprocesora

Strategija grananja

cena koja se plaa

(penalty)
0,52
0,28
0,12

Zakanjenja za jedan slot

512*2 branch-prediction bafer
512*2 entry branch target bafer

Kod savremenih RISC mikroprocesora NCPI,notbranch,mp je priblino 1. Ako za trenutak ignoriemo

komunikacioni overhead, tj. Tr,cop = Tw,cop = Tr,mp = Tw,mp = 0, tada dobiemo za
Gaincop (1 + Pbranch Nbrpen) / (1 - Pbranch) ....................................(4)
Ispitivanja su pokazala da je 0,1 Pbranch 0,3, i da je 0,1 Nbrpe 0,6, tako da je
1,1 Gaincop 1,7

.................................................................(5)

Implementacija sa veim brojem funkcionalnih jedinica

Kada ogranienja sa take gledita hardveskih resursa ne postoje tada koprocesor moe da ini vei
broj funkcionalnih jedinica koje rade paralelno (vidi Sliku 4), sve sa ciljem da se dobija vei Gaincop.

registri i spre`na mre`a

FU1

FU2

...

FUn

kontroler (FSM)

Slika 4. Koprocesor sa Nfu,cop simultano operativnih FU-a

Umesto da izvrna FU radi sekvencijalno (Slika 3), mogu}e je da se operacije izvravaju paralelno
(Slika 4). U tom slu~aju u jednani (1) vrednost Ninstr,cop se smanjuje jer jer u toku jednog upravljakog
koraka FSM-a aktivan vei broj FU-a. Sada se ponovo postavlja sledee pitanje: Da li projektant moe da
povea Gaincop onoliko koliko eli? Odgovor na ovo pitanje je ne, iz razloga to za svaki algoritam postoji

maksimalna vrednost Gaincop koja se ne moe poveati dodavanjem veeg broja FU-a. Postoje slede}a
dva razloga koji dovode do toga da dodje do pojave saturacionog efekta.
1. Postoji maksimalan iznos paralelizma koji je dostupan za svaki algoritam. Tako na primer, ako se
rezultat operacije op1 koristi kao operand za operaciju op2 tada je jasno da se op1 i op2 ne
mogu izvravati u istom koprocesorskom ciklusu, nezavisno od toga koliko je FU-ova dostupno
za izvrenje op1 i op2. Naime kaemo da postoji zavisnost po podacima izmedju operacija: op2
zavisi od op1.
2. Neki hardverski rezursi se ne mogu duplicirati. Dobar primer takvog resursa je magistrala sa Slike
1. Ako algoritam obavlja operacije Load i Store tada je ukupno potrebno m ciklusa magistrale, pri
emu je Ninstr,cop m, nezavisno od broja FU-a.
Konano, kod ovakvog pristupa, neophodno je odrediti Gaincop u funkciji broja Nfu,cop. Na alost
odgovor na ovo pitanje je teko precizno dati. U najboljem sluaju broj upravljakih koraka Ninst,cop
potreban da se izvri algoritam koprocesora deli se na Nfu,cop, ali zbog prethodno nabrojanih razloga ovo
je najbolji mogui sluaj. Ako sada definiemo Gainmulfu kao
Gainmulfu = ( [Ninstr,cop] koprocesor sa 1 FU-om)/ ([Ninstr,cop] koprocesor sa Nfu,cop FU-a
Tada se jed. (1) moe proiriti i definisati Gainmcop, tj pojaanje koje se dobija zbog korienja veeg
broja FU-a umesto korienja softverskog progrrama koji se izvrava na skalarnom RISC procesoru
Gainmcop = (Ninstr,mp NCPI,mp Tcycle,mp + Tr,mp + Tw,mp)/
/ ( Gain-lmulfu Ninstr,cop NCPI,cop Tcycle,cop + Tr,cop + Tw,cop ) .........................................(6)
Kada analiiziramo algoritam, radi nalaenja potencijalnog paralelizma, tada zakljuujemo da svi
delovi algoritma nisu pogodni za paralelizaciju. Definisaemo Dseq kao deo operacija koje se ne mogu
paralelizovati. U najoptimistinijem sluaju imaemo da je Qpar = 1-Qseq. Na alost ovo nije tano iz
razloga to se sve operacije u Qpar ne mogu izvravati paralelno iz nabrojanih razloga zavisnosti-popodacima i ogranienog broja resursa.
Amdahl-ov zakon kae da paralelno operativne FU-e ne mogu nikad da poboljaju performanse za
faktor vei od 1/Qseq. Imajui ovo u vidu moemo izraziti Gainmulfu u funkciji Qpar i broja FU-a Nfu,cop, na
sledei nain
Gainmulfu 1 / ( 1- Qpar + ( Qpar / Nfu,cop)) . ...........................................(7)
Kombinovanjem jednaina (6), (7), (2) i (3), ignoriui pri tome komunikacioni overhead, dobijamo
pojednostavljenu formulu za izraunavanje Gainmcop
Gainmulfu (1 + PbranchNbrpen) / (( (1 - Pbranch)(1- Qpar + (Qpar/Nfu,cop))) ......................................(8)

Akceleracija softvera
Alternativni pristup u odnosu na korienju koprocesorskog hardvera kojim se postie ubrzanje
algoritma ogleda se u ubrzanju softverske implementacije tog algoritma. U principu se mogu koristiti dve
komplementarne strategije. Kod prve, primenom tehnike za optimizaciju softvera mogue je poboljati
performanse, a kod druge sa brim mikroprocesorima mogue je za krae vreme izvravati program.
Tehnike za optimizaciju softvera su brojne ali se najee koriste sledee:

1. loop unrolling smanjuje overhead u toku izvrenja za najmanje jedne branch instrukcije po
iteraciji petlje
2. branch prediction dozvoljava da kompilator redukuje cenu koja se plaa zbog grananja
3. software pipelining redukuje broj ciklusa na koje mikroprocesor eka da bi FU zavrila pre
nego to se pone sa izvrenjem nove operacije (tzv. zastoji, tj. stalls).
4. trace scheduling poveava paralelizam na nivou instrukcija (ILP) preuredjenjem redosleda
instrukcija koje se nalaze izimedju dve instrukcije tipa branch, na taj nain to se ove spekulativno
izvravaju. Na ovaj nain obezbedjuje se bolje popunjavanje branch slotova kao i load delay
slotova.
Sve nabrojane tehnike se obavljaju od strane kompilatora. Drugi metod za ubrzavanje softvera bazira
se na kreiranje novog izvornog koda (programer pie kod koji poseduje bolji paralelizam).
Kada softverske optimizacije u dovoljnoj meri ne rezultiraju poveanju performansi koriste se bri
mikroprocesori i bre memorije. Brzina memorije se moe poveati ugradnjom brih memoriskih ipova
illi korienjem ke memorije veeg obima.