K1 - En pipelinet mikroarkitektur

Transkript

1 K1 - En pipelinet mikroarkitektur Mikkel Boje, di020168@diku.dk Ulrik Schou Jrgensen, di020545diku.dk Martin Damhus, di020162@diku.dk 25. november 2002 Indhold 1 Sammenfatning Indledning Ambitionsniveau - strategi for en eektiv pipeline Konklusion Lsevejledning Sprogbrug Notation Navngivningskonvention Skemaer Problemorienteret analyse - design af arkitektur Problem Byggeklodser Ydelse - generelle betragtninger Pipelinen, overordnet Hop Hazards Detektion af data hazards To lsninger af data hazards - forwarding og stalls Analyse af stall og forward Ordresttet Standsning af pipelinen Genveje i pipelinen Register 0 i forbindelse med forwarding og stalls Hvad skal forwardes, og hvorfra? J og JAL

2 JR, BEQ, BNE Hopforudsigelse Register STOP Arkitektur - implementation Kontrol PC PCC PCS Equal MEM ALU Pipelineregistre IFID-registret IDEX-registret EXMEM-registret MEMWB-registret FW (Forward) STALL HAW REG Afprvning Cache Datavejsanalyse Benchmarks Brugervejledning 26 A Figurer 28 A.1 Vores pipeline A.2 PCC A.3 PCS A.4 ALU A.5 MEM A.6 PC B Testkrsler af egne testler 39 B.1 Testkrsel af s0a.hex B.2 Testkrsel af s0b.hex B.3 Testkrsel af s1a.hex B.4 Testkrsel af s1b.hex

3 B.5 Testkrsel af s2a.hex B.6 Testkrsel af s2b.hex B.7 Testkrsel af s3a.hex B.8 Testkrsel af s3b.hex B.9 Testkrsel af s3c.hex B.10 Testkrsel af f2a.hex B.11 Testkrsel af f2b.hex B.12 Testkrsel af f2c.hex B.13 Testkrsel af f5a.hex B.14 Testkrsel af f5b.hex C Slackdiagrammer 45 C.1 ALU C.2 FW C.3 MEM D Kildekode 47 D.1 ALU D.2 CTRL D.3 DEC D.4 EXMEM D.5 FW D.6 IDEX D.7 IFID D.8 MEM D.9 MEMWB D.10 PC D.11 PCC D.12 PCS D.13 REG D.14 STALL D.15 K E Skemaer til forward og stall analyse 61 E.1 Skema E.2 Skema E.3 Skema E.4 Skema E.5 Skema F Afprvning af udleverede testler 66 3

4 1 Sammenfatning 1.1 Indledning Denne rapport er en besvarelse af K1-1-opgaven i Datalogi 1E ved Kbenhavns Universitet, stillet efteraret Opgaveformuleringen ndes i [1]. Opgaven gar overordnet ud pa at udvikle en pipelinet mikroarkitektur og implementere denne i sproget Kreds, som beskrives i [4]. Rapportens lsere br have datalogisk indsigt svarende til kurset Dat 1E's indhold. Vi vil i denne rapport referere til vores lsning [5] af G2-opgaven, hvori en enkeltcyklus mikroarkitektur blev udviklet, uden yderligere dokumentation. Genbrugte komponenter ndes i kildekoden D. 1.2 Ambitionsniveau - strategi for en eektiv pipeline Vi vil anvende de i 3.3 anfrte generelle observationer ang. ydelse af en mikroarkitektur under designet af arkitekturen. Vi har ambitioner om at udvikle en korrekt fungerende og hurtig arkitektur. Overblik og overskuelighed vil vi dog altid prioritere over eektivitet. 1.3 Konklusion Det er beklageligvis ikke lykkedes os at fa vores pipeline til at afvikle de udleverede test-ler. Vi har selv opbygget en "test-suite", der afprver samtlige stallog forward-typer, vi har fundet frem til i vores analyse. Disse ler afvikles fejlfrit - pa nr de to ler s2b.hex og f2b.hex (se nedenfor) - og tester samtidig en rkke af de nskede instruktioner. I teorien burde altsa ogsa visse af de mere komplicerede ler virke, idet mange problematiske instruktionssekvenser er gennemprvet. Det er ikke lykkedes os at nde og rette alle fejl indenfor den givne tidsramme. Testlerne ligger i kataloget ~/di020168/k11/ Resultaterne af testkrslerne er dokumenteret i B. Resultaterne af testkrsler af de udleverede programmer kan ses i F. Konsekvensen heraf er, at vi ikke har kunnet afvikle de udleverede benchmarks, se bemrkningerne herom i afsnittet 5.3. Konklusionen er, at de resterende fejl, som ikke er rettet, er enten yderst subtile i deres karakter og ekstremt vanskelige at spore (fx. fejl optrdende i clockcyklus ) eller skyldes logiske fejl i vores analyse af stall og forward. Vi har ikke nsket at ga pa kompromis og stalle undigt pa noget tidspunkt. Den komplekse kontrol af forward og stall, dette har resulteret i, er muligvis logisk fejlbehftet, muligvis implementeret uheldigt. 4

5 Vi har dog lokaliseret en fejl, som vi grundet tidspres ikke har kunnet na at rette. Det er en fejl i arkitekturen: Hvis en sw skal bruge forwardet data i memstadiet til skrivning i lageret, som ikke stammer fra en umiddelbart forudgaende instruktion, er den ndvendige genvej ikke implementeret. En lsning pa problemet ville vre forwarding fra registerbanken til mem-stadiet. Det er denne fejl, der far vores testl s2b.hex til at fejle. Fejlen i f2b.hex kan vi ikke forsta. Vores pipeline kom op pa 641,235 MHz og bruger transistorer. 5

6 2 Lsevejledning 2.1 Sprogbrug For at undga tvetydigheder prciserer vi her vores sprogbrug. "Instruktion"og "ordre"er helt ensbetydende. I arkitekturen kategoriserer vi ledninger i to typer: Kontrollinier, hvis signaler vil benvnes styresignaler eller kontrolsignaler, disse kontrollerer muxe, skriv/ls-tilladelser e.l. o.l. Datalinier, hvis funktion er overfrsel af data mellem komponenter. Disse ledninger vil vi ogsa benvne bitstrmme, signaler eller busser. De este ordrer gr brug af et eller ere registre til deres udfrelse. Sadanne registre vil benvne argumentregistre, registeroperander, operandregistre eller parameterregistre. Visse utvetydige forkortelser vil blive brugt i ng, fx. HAW for holdandwait. Ikke alle ledninger vil blive benvnt ved "fulde navn", se 2.3. Vi vil frit veksle mellem betegnelserne \forwarding" og \genveje", ligesom \stalls" og \standsning af pipelinen" betyder det samme. 2.2 Notation Vha. skrifttyper vil vi gruppere kategorier af beskrevet materiale: Kategori: Skrifttype-eksempel : Byggeklodser i Kreds MemIOSys Instruktioner addi Kode if.. then.. else Kontrolsignaler RegSrc Pipelinetrin ex 2.3 Navngivningskonvention Topnivau-komponenter (ikke-indlejrede) navngives med kortfattede blokbogstavsnavne, fx. CTRL. Indlejrede komponenter har navne begyndende med stort. Navngivne ledninger gar altid mellem to komponenter og flger konventionen N9K 1 2K 2 hvor N er navnet pa ledningen, K 1 er navnet pa den komponent, hvorfra ledningen gar og K 2 er navnet pa den komponent, hvortil ledningen gar. Kontrollinier er navngivet med lutter blokbogstaver, mens datalinier har stort bogstav, nar et nyt ord pabegyndes i navnet. 6

7 Omtale af linierne i rapporten og pa visse gurer vil ofte njes med at benytte N-delen af navnet. 2.4 Skemaer Beklageligvis ma vi i vores analyse henvise til en del skemaer placeret i bilag. Dette skyldes manglende L A TEX-skema-kodningsevner og er ikke et bevidst forsg pa at irritere lseren :-). 7

8 3 Problemorienteret analyse - design af arkitektur 3.1 Problem Vi skal implementere en delmngde (se gur nedenfor) af instruktionssttet mips i en pipelinet mikroarktitektur. Ordretype: Aritmetisk-logisk Immediate aritmetisk-logisk Hop Lagertilgang Stop mips-delmngde: add, sub, slt, and, or addi, slti, andi, ori j, jal, jr, beq, bne lw, sw stop Med henblik pa eektivitet skal forwarding og anden hazardafhjlpning implementeres. 3.2 Byggeklodser Det at pipeline en arkitektur ndrer ikke pa kontrollen af den eksisterende hardware, safremt ingen hardwareomrokeringer mellem pipestages foretages efter indlgning af pipelineregistrene. Vores kontrolenhed fra G2-opgaven [5] kan saledes nsten 1 undret genbruges, da denne netop disponerer over det nskede ordrest, se 4.1. Endvidere kan vores fastalu-komponent benyttes igen. Standardbyggeklodsen MemIOSys er een byggeklods, selvom den reprsenterer to forskellige lagerenheder, instruktionslageret og datalageret. Pa vores illustration af arkitekturen vil lagerenhederne derfor vre indtegnet som separate komponenter. 3.3 Ydelse - generelle betragtninger Lad os i det flgende benytte flgende betegnelser: Betegnelse Betydning # Antal I Instruktion s Sekund F clock-frekvens D Tid over lngste datavej CPI Clockcykler pr. instruktion 1 Pa nr signalet PCSrc (se 4.1) og det faktum, at vi agter at implementere funktioner, der understtter forwarding i kontrolenheden, se

9 Vi etablerer ydelsesmalet Y ved Y = #I=S = F=CP I = 1=(D CP I) Heraf kan vi se, at 2 faktorer er altafgrende for ydelsen af arkitekturen: D og CPI'en. Lad os frst kigge pa, hvorledes vi kan reducere D. D vil vre domineret af tunge komponenter. Den "tungeste"af disse vil stte en vre grnse for ydelsen af hele pipelinen, hermed menes, at hvis en ndvendig komponent K i et lukket mini-testkredslb giver en ydelse pa x MHz, vil vores pipeline aldrig kunne blive hurtigere end x MHz. Af sadanne kritiske komponenter har vi kun 2 kandidater: MeMIOSys og ALU. Vi har, for at understtte senere designbeslutninger (isr med henblik pa pipeline-trin), testet disse to komponenter i lukkede minikredslb 2 : Komponent Ydelse i MHz MemIOSys fastalu Komponenten MemIOSys er testet med standard-cache-parametre, og den anfrte ydelse er et groft gennemsnit af tests med disse standardparametre. Det fremgar af malingerne, at det er komponenten fastalu, der begrnser vores clock-frekvens opadtil. Vi skal altsa undga, at datavejen gennem beregningsenheden gres lngere end strengt ndvendigt. ALU'en har brug for data, som enten udlses af det foregaende pipelineregister, eller som er forwardet. Andet skal der slet ikke forega i det trin af pipelinen. Da nu vi har en vre grnse pa clock-frekvensen, er flgende rsonnement oplagt: 1. Hvert pipelinetrin skal vre hurtigere end det indeholdende ALU'en, hvis clock-frekvensen ikke skal snkes undvendigt 2. CPI'en hves undigt, hvis hver pipetrin ikke udnytter clock-lngden bedst muligt. 3. Det er altsa naturligt at lade hvert pipelinetrin have udfrelsels-tid nr beregningstrinnets.. Lagerkomponenten er tt pa at vre kritisk, men ellers kan vi roligt bygge omfattende pipelinetrin, da der skal meget hardware til at begrnse den pagldende hardwaredelmngde under ALU-grnsen. Pipelinetrin, der er hurtige i forhold til beregningstrinnet, br slas sammen, men vi har fastholdt den femdeling, der prsenteres i [3]. Mere herom om i Vi har ikke testet komponenten ALU, der indeholder forward-logik, men kun selve beregningsenheden der i kildekoden betegnes fastalu. 9

10 Derfor vil vi nu undersge, hvordan CPI'en kan mindskes. CPI er jo clockcykler pr. instruktion, sa jo frre cykler en instruktion benytter sig af, desto hurtigere. Der er forskellige metoder, hvormed CPI'en kan forbedres vsentligt; vi nvner dem her og beskriver detaljerne i separate afsnit: Forwarding (se 3.6) af data afhjlper stalls, der ellers ville gre udfrelsen af den enkelte instruktion lngere. Fa cache misses (se 3.4) snker ogsa CPI'en. Miss-raten afhnger direkte af cache-parametrene til MemIOSys. Tidligt placerede hop (se 3.5) mindsker ogsa CPI'en i hjere eller lavere grad, kommende an pa den konkrete implementation. Vores hovedmal er at implementere en eektiv forward- og stall-politik, saledes at der aldrig stalles undvendigt, da miss raten ikke er en absolut anvendelig eektivitetsmaler (CPI'en snkes ved lav miss rate, men med hj cache-associativitet (som mindsker miss raten) kan den generelle tilgangstid, vre uforholdsmssig hj og muligvis pa sigt udligne den mistede tid pa miss penalties). Lagerhierarkiets struktur er uafhngigt af arkitekturen i nrvrende tilflde og kan derfor optimeres separat, hvis nsket. 3.4 Pipelinen, overordnet Vi har valgt at implementere en pipeline med fem trin. Beslutningen hviler pa forskellige argumenter af forskellig vgt. Nar der lses eller skrives til datalageret, risikeres det, at data ikke bender sig i cachen. Nar det ndvendige data saledes ikke er klar, ma pipelinens reaktion vre at stoppe al aktivitet og vente pa, at cachen har hentet data fra lageret, dette sker ved at stte kontrolsignalet holdandwait. Der ndes alternativer til denne totale fastfrysning. Man kunne implementere en instruktionsk, pa hvilken man kunne arbejde i \ventetiden". Dette forudstter en mere eksibel lagerenhed end MemIOSys, og vi agter ikke at kaste os ud at programmere een selv (i strid med opgaveformuleringen). En anden mulighed er en superskalar arktiektur, hvori adskillige instruktioner indlses hver clockcyklus. MemIOSys tillader indlsning af en mngde instruktionsdata svarende til strrelsen af cache-blokkene, sa i realiteten ville vi kunne indlse mere end en instruktion ad gangen. Dette projekt falder dog uden for opgaveformuleringen, der fordrer en ordreportsstrrelse pa 4 bytes, og forekommer desuden for omfattende i forhold til den givne tidsramme. Dynamisk pipelining, hvor ordrenes rkkeflge omordnes optimerende for at udnytte fx. ventetid ved hopbeslutninger, lagertilgang o.a., er et job for maskinkodegeneratoren, og ikke noget vi vil bekymre os om her. Med implementationen af denne "almindelige"pipeline med en maksimalt en instruktion pr. pipelinetrin, ges naturligt nok laveste CPI til 1. Med hensyn til pipelinens inddeling og funktionaliteten i de enkelte trin, er det tydeligt, at beregningstrinnet ex (i kraft af sin beliggenhed pa den lngste datavej) skal vre et trin for sig selv. Lagerenheden tilgas bade pa lw og sw samt pa instruktionsindlsning. Lageret er ikke specielt hurtigt, og far derfor tildelt 10

11 separate pipelinetrin if (Instruction Fetch) og mem (Memory: ind- og udlsning af register-vrdier). Et mellemstadie id (Instruction Decode) til registeudlsning og dekodning af den indlste instruktion er ndvendigt. Sluttelig opretter vi, i trad med [3]-implementationen, et wb-stadie (Write Back), da dette ellers ville skulle slas sammen med et trin med lagertilgang. wb-stadiet vil vre det hurtigste stadie, idet det kun star for skrivning til registre. Saledes er vi altsa havnet pa en pipelineinddeling magen til den i [3]. Vi vil dog ndre lidt pa placeringen af visse komponenter. 3.5 Hop I principppet kan hopbeslutninger tages i alle pipelinetrin. Jo tidligere i pipelinen, beslutningen skal tages, desto ere stalls vil vi som flge af eventuelle dataafhngigheder (se 3.6) blive ndt til at gennemfre. Stalls hver CPI'en. Sen placering i pipelinen krver en gennemgribende implementation af ushing og helst tillige en hopforudsiger, da forkerte hop er meget dyre og tvinger hele pipelinen til at ushe de forkerte, delvist udfrte ordrer. Flushing hver ogsa CPI'en. Tidlig placering sikrer, at frre ordrer skal elimineres i forbindelse med hopbeslutninger, hvormed CPI-forvrringen er mindre end ved ushing. Endvidere skal ushing implementeres for frre pipelineregistre. Vi vedtager derfor, at hopbeslutninger skal tres sa tidligt som muligt. Det betyder, at de ubetingede hop-ordrer sc j og jal kan udfres allerede i if-stadiet, og CPI'en for disse to ordrer reduceres dermed til minimum. beq, sc bne og JR kan tidligst udfres i id, da registerudlsning sker her. I sa fald skal en passende sammenlingningsenhed til brug pa registeroperanderne i beq og bne introduceres. Da vi nsker at minimere CPI'en mest muligt, skal hoppene ligge tidligt, og vi vil derfor implementere hop-beslutninger for de betingede hop og jr i id. 3.6 Hazards Dataafhngigheder opstar, nar ordrer skal benytte indholdet af registre, hvis mest kurante vrdi endnu ikke er blevet skrevet i registerbanken. Vi vil kun have hazards af to typer: Data- og kontrol-. Strukturelle hazards opstar, nar ens arkitektur ikke kan implementeres vha. det tilgngelige hardware, og vil ikke forekomme, jfr. argumentationen [3] s Dataafhngigheder opstar i forbindelse med den delmngde af mips, vi skal implementere, kun for registerlsende ordrer, med andre ord ordrene jr, bnr, beq, R-type-ordrer, I-type-ordrerne addi, slti, andi ori, samt lw og sw 3. Da vi antager, at skrivning sker i starten af en clock-cyklus og lsning i slutningen af samme, far vi, at der ingen hazards opstar i stadiet WB. 3 Flgende ordrer lser ikke: j,jal,stop 11

12 Kodningen i assemblersprog vil antage, at registre opdateres fuldstndigt mellem hver instruktion. Betragt eksempelvis instruktionssekvensen... add $1, $2, $3 sub $3, $2, $1... Som programmr vil man forvente, at den korrekte sum $2+$3 gemmes i register 1. Herefter trkkes vrdien fra indholdet i register 2 og gemmes i register 3. Men indholdet af register 1 opdateres frst i wb, 2 cykler efter, at vrdien $2+$3 er beregnet. Problemet er, at sub-ordren bruge resultatet af additionen allerede cyklen efter beregningen Detektion af data hazards Dataafhngigheder af ovennvnte type skal opdages i pipelinesystemet, hvis det skal afvikle programmer korrekt. Derfor tilfjes en detektionsenhed til pipelinen. Ved at lade registeradresserne pa argumentregistre til en given ordre ledsage ordren pa dens vej gennem pipelinen, kan afhngigheder opdages allerede o [id]- stadiet. Hver cyklus kontrolleres nemlig ordren i [id]-trinnet: Hvilket register vil instruktionen heri gerne lse? Har en registeroperand her nemlig en opdatering liggende i pipelinen, som endnu ikke er skrevet til registerbanken? Dette forekommer netop i tilflde af lighed mellem registeradresserne To lsninger af data hazards - forwarding og stalls Der ndes to dataafhngighedsafhjlpningsmetoder at tage i brug, forwarding og stall vha. nop's (eller bobler): Stall Man kan forsinke pipelinens eksekvering af en ordre en / ere cykler ved at sende \tomme instruktioner", sakaldte nop 4 's gennem pipelinen. Dermed kan udfrelsen af en instruktion forsinkes, indtil de relevante registre er skrevet. Forwarding De nyeste registervrdier, som enmdnu ikke er skrevet til registerbanken, ligger tilgngelige i pipelinen i de senere piperegistrene. Forwarding er betegnelsen for den teknik til afhjlpning af data hazards, der lser disse endnu ikke skrevne registervrdier i sene pipelineregistre og frer dem op i tidligere pipelinetrin. Stalling hver CPI'en gevaldigt. Vi nsker at mindske CPI'en, sa en bedre lsning er forwarding. For hver afhngihed i instruktionssekvensen, der potentielt 4 Forkortelse for \No operation" 12

13 kan forwardes, ases et eller ere stalls af forwarding. Forwarding mindsker saledes CPI'en for en lang rkke ordresekvenser. Stalling kan undgas mod implementation af ekstra hardware, fx. kan en ALU eller lagertilgang kan indsttes tidligere i pipelinen, men vi tilstrber jo 2 modstridende ting: lav CPI og hj clockfrekvens. Jo mere hardware, jo lavere CPI og jo lavere clock. Jo ere pipetrin, desto hjere clock og desto lavere CPI. Derfor ville en ekstra ALU blot snke clocken undigt Analyse af stall og forward Vores pipeline er udviklet med 5 stadier: if-, id-, ex-, mem- og wb. Det vil i den kommende analyse vise sig nyttigt at tildele disse stadier hver en talvrdi: if = 1, id = 2, ex = 3, mem = 4, wb = 5 Standsning af pipelinen skal ske, nar der ikke kan indlses ny data fra vores hukommelse (pga. cache-misses). Endvidere skal pipelinen standses, nar der opstar en hazard i pipelinen, der ikke kan lses vha. forwarding. Kontrolhazards opstar, nar der skal tres beslutninger vha. data, der endnu ikke er tilgngeligt (i en opdateret udgave). Datahazards opstar, nar der skal foretages beregninger med data, der endnu ikke er tilgngeligt (i en opdateret udgave). Vi vil indledningsvis behandle kontrol- og datahazards samlet. Hvornar er data tilgngeligt? Givet en instruktion, der bliver frdig 5 i memstadiet (stadie 4), og som netop nu bender sig i id-stadiet (2) 6, vil dataen vre tilgngelig efter 4-2 = 2 clock-cykler. Dette antal af clock-cykler vil vi denere som dataafstanden for den instruktion, der opdaterer dataen 7. Ligeledes kan vi denere en dataafstand for den instruktion, der skal bruge dataen 8. Denne afstand vil vre det stadie, instruktionen bender sig i (instruktionens position) (eksempelvis id-stadiet (2)) trukket fra det stadie, hvori instruktionen skal bruge dataen 9 (eksempelvis ex-stadiet (3)). I det aktuelle eksempel vil dataafstanden for den instruktion, der skal bruge den opdaterede data vre 3-2 = 1 clock-cykler. Det er nu muligt at denere en hazardafstand, som er instruktion 1's dataafstand fratrukket instruktion 2's dataafstand: (instruktion 1's b-attribut - instruktion 1's position) - (instruktion 2's a-attribut - instruktion 2's position) 5 Ved frdig vil vi forsta, at instruktionens data er tilgngeligt vha. en genvej. Stadiet hvorfra genvejen kan konstrueres, vil vi kalde instruktionens b-attribut. 6 Som vi vil benvne instruktionens position 7 I det flgende vil denne instruktion blive benvnt instruktion 1. 8 I det flgende benvnt instruktion 2. 9 Som vi i det flgende vil benvne instruktionens a-attribut. 13

14 Denne hazardafstand vil netop angive, om der kan gres brug af en genvej i pipelinen, eller om det er ndvendigt at standse pipelinen. Hvis hazardafstanden er netop 0, kan man blot gre brug af en genvej: den opdaterede data kan forwardes fra instruktion 1 til instruktion 2. Hvis hazardafstanden er 1 eller derover, vil den opdaterede data frst vre tilgngelig en eller ere clock-cykli senere, og en standsning af pipelinen er derfor ndvendig. I ovenstaende eksempel far vi: (4 (mem) - 2 (id)) - (3 (ex) - 2 (id)) = 1 En standsning af pipelinen er derfor ndvendig. En hazardafstand pa mindre end 0 svarer til, at der ingen hazard forendes Ordresttet Hazards opstar, nar en instruktion skal benytte indholdet af et register, der er i gang med at blive opdateret. Da mips-ordrer kan gre brug af 0, 1 eller 2 registre vil det vre ndvendigt at indfre en attribut for 2. instruktion, sa vi kan vide, hvilke registre i instruktionen vi skal sammenligne med instruktion 1's registerdestination. Denne attribut, har vi valgt at kalde c-attributten. Dens vrdier fremgar af skema 1 i E instruktioner med 00 som c-attribut er tydeligvis ikke interessante for hverken standsninger eller genveje i arkitekturen. Det fremgar af 3.6.3, at vi har brug for instruktionernes a- og b-attributter samt deres position i pipelinen. Positionerne er givne, men a- og b-attributterne ma vi tildele instruktionerne. Skema 2 i E.2 10 viser netop attributterne for de relevante instruktioner i vores instruktionsst (bitvrdien for den enkelte attribut er skrevet i parentes.). Vi ser, at der ndes 4 forskellige muligheder for hver attribut, og begge attributter kan derfor implementeres med hver 2 bit. Et skema med kombinationer af a- og b-attributter og positioner for 1. og 2. instruktion er vist i E.3. Hazardafstanden er ligeledes taget med og en navngivning af standsninger og genveje er givet (instruktionens dataafstand er skrevet i parentes). Det skal i skemaet bemrkes, at kombinationer af attributter kan fortstte i pipelinen. Da stalls af pipelinen sker tidligst muligt (i vores arkitektur vil dette sige i id-stadiet), vil en kombination af attributter, der genererer en standsning af pipelinen, og som er en gentagelse af en attributkombination tidligere i pipelinen, ikke vre noget problem. Dette fremgar af navngivningen af standsninger. Ligeledes skal vi vre opmrksomme pa gentagelser af attributkombinationer, nar det glder genveje i pipelinen. Her glder der dog den simple regel, at en genvej kun kan etableres, hvis dataafstanden for bade instruktion 1 og 2 er netop I skemaet skal ex + mem forstas i sammenhng med sw, som bruger sit rs-register i ex-stadiet og rt-register i mem-stadiet. 14

15 3.6.5 Standsning af pipelinen Vi kan opstille et skema for kombinationer af b-attributter for instruktion 1 og a- og c-attributter for instruktion 2 og de to instruktioners position i pipelinen, der vil generere en standsning af pipelinen udfra E.2. Vi skal her huske pa hvilke c-attributter, der er mulige i kombination med hvilke a-attributter. Et optimeret skema over kombinationer er vist i E.4. Selve udfrelsen af standsningen afhnger af, om standsningen skyldes en hazard eller et cache miss. I sidstnvnte tilflde skal alle stadier fryses og instruktionen i if-stadiet indlses pa ny. Hvis der en hazard i pipelinen, der ikke kan lses vha. genveje, fastfryses id-stadiet, en boble indsttes i ex-stadiet, og instruktionen i if-stadiet indlses pa ny Genveje i pipelinen Som for standsninger i pipelinen kan man ogsa opstille et skema med b-attributter for 1. instruktion og a- og c-attributter for 2. instruktion og instruktionernes position i pipelinen. Njagtig som for standsninger kan man ogsa i skemaet for genveje foretage optimeringer. Visse attributkombinationer kan givet instruktionssttet ikke forekomme. Ydermere skal kun genveje, hvor dataafstanden for hver instruktion er 0, medtages (jf ). Et optimeret skema over genveje i pipelinen er givet i E Selve implementationen af forwarding sker ved at oprette genveje fra alle stadier 1. instruktion kan bende sig i til alle stadier 2. instruktion kan bende sig i. Ydermere tilfjes en enhed som udfra ovenstaende skema (der kan kodes som en PLA) afgrer, om forwarding af data skal ske. Det er her ndvendigt, at der sker en prioritering af forwardet data. 1. instruktions positions-vrdi kan direkte bruges som talvrdi for prioriteten af genvej Register 0 i forbindelse med forwarding og stalls Vi noterer os, at for bade forwarding og stalls i pipelinen kan der ikke ske skrivninger til register 0. Der skal derfor ikke ske standsninger eller fremsendelse af data, nar en instruktion skal bruge register 0, eller nar en instruktion prver at opdatere register Hvad skal forwardes, og hvorfra? Forwarding ma implementeres i det tidligste pipelinetrin, forwardet data skal bruges i, eller vre ekstern ift. pipelinetrin. Derfor kan forwarding ikke indsttes 11 Det manglende tjek med dette register skyldes, at 11 for en SW-instruktion (som er den eneste instruktion, der skal have fremsendt data til mem-stadiet) skal tydes som en 10-vrdi i mem-stadiet (og 01 i ex-stadiet). 15

16 i pipelinens ex-trin, som i [3], da vi med hop-ordrer som fx. jr kan have brug for forwardede registervrdier allerede i id. Vi skal altsa forwarde data til tre pipestages: id (her udfres jr, beq, og bne), ex (her sidder ALU'en), og mem (sw skriver til lageret). I mem-stadiet er det kun ordren sw, der benytter data. At tilgngeligt data i dette stadie ikke er opdateret er kun tilfldet, netop hvis den foregaende ordre var en lw. I alle andre tilflde vil det ndvendige data nemlig vre tilgngeligt fra et tidligere pipelinetrin end MEMWB, og dermed vre blevet forwardet tidligere i pipelinen. Der skal forwardes data i de tilflde, hvor registerindhold er blevet ndret og ikke skrevet i registerbanken endnu. Der ndres i registrene i tre tilflde: ved ALU-operationer, ved indlsning fra datalageret og ved skrivning af returadresse i register 31 pa en jal. Derfor skal der forwardes fra tre stadier: ex, mem og wb, eller med andre ord fra pipelineregistrene IDEX, EXMEM og MEMWB J og JAL Ubetingede hop er uden dataafhngigheder bagud og kan derfor umiddelbart udfres. Vi udfrer ubetingede hop allerede i if, sa vi ikke skal ushe. j har absolut ingen komplikationer, mens der pa en jal skal skrives PC+4 i register 31. Dette kan gres i alle pipelinetrin. Men vi skal passe pa, at returadressen ikke overskrives af tidligere instruktioner lngere nede i pipelinen ved fx. ordresekvensen... add $31, $1, $2 jal LABEL... hvor $31 overskrives med $1+$2 4 clockcykler efter, at vi i if opdager, at der skal jal'es. Derfor frer vi returadressen gennem piperegistrene og skriver den frst i wb. Det er med denne lsning ndvendigt at tilfje PC+4-ledningen til forwardenheden, sa register 31's vrdi kan forwardes til efterflgende instruktioner. Vi har valgt denne lsning frem for at introducere kompliceret logik til at holde styr pa rkkeflgen af ordrer, der skriver og benytter register 31. Prisen er den hardware, vi benytter til at trkke de 32 bits gennem adskillige pipeline-stadier JR, BEQ, BNE jr, beq og bne krver registerudlsning, sa hopbeslutninger for disse instruktioner kan tidligst tres i id-stadiet. Men med hopbeslutninger for betingede hop og jr skudt frem til id skal de tre nvnte ordrer saledes allerede i id skulle bruge indholdet af deres argumentregistre. Nyeste vrdi af disse registre er tilgngelige i senere pipelineregistre eller registerbanken. En ordresekvens af typen... 16

17 sub $2, $11, $4 add $1, $2, $3 bne $1, $2, LABEL... skal imidlertid bruge resultatet fra ALU'en i samme cyklus som det bliver beregnet. Principielt ville godt kunne forwarde resultaterne fra ALU'en i samme clockcyklus - men mod en kraftigt lavere clock, da ALU'en ligger pa den kritiske datavej, og det fra ALU'en forwardede resultat skal videre gennem sammenligningslogik efter bregningen. Clocken sttes jo efter lngste datavej, og denne er det malet at afkorte mest muligt. I gennemsnit vil det nok vre hurtigere at stalle 1 gang pa ordresekvenser af ovenstaende type end at forlnge samtlige clockcykli undigt. Alternativt kunne man udskyde hoppet til stadierne ex og mem; altsa lade den betingede hop-ordre fortstte gennem pipelinen til ex-stadiet og sa udfre hoppet (hvis det ellers skal udfres) derfra, idet ndvendig data da ville kunne forwardes (undtagen i de tilflde, hvor det betingede hop forudgas af en load-ordre - i disse tilflde kunne man sa propagere hop-ordren videre til mem). Herved spares 1 eller 2 clockcykler, hvis branchen ikke tages. Der er ingen besparelser at hente, hvis hoppet tages, da der sa skal ushes to ordrer. Dette er dog for omfattende i forhold til vores indledende design til at vi nsker at implementere det: Der fordres en massiv kopiering af hardware, og kontrollen kompliceres temmelig voldsomt (hvormed implementationen ville tage uforholdsmssig lang tid) - denne kunne endvidere nemt risikere at havne pa en kritisk datavej. Man kan forestille sig, at typisk mips-assemblerkode samler klumper af slt (samt slti) og beq/bne-instruktioner, da disse ofte vil sammenligne nogle vrdier med indholdet af register 0. slt benytter ALU'en, hvorfor beq og beq hyppigt vil skulle anvende resultater fra ALU'en. Da bliver regnestykket mht. stall vs. forlngelse af datavej mere kompliceret og afhngigt af instruktionssammenstningen. Men i instruktionssammenstningerne for de to sprog gcc og spice anfrt i [3] s. 189 gur 3.38 ses det, at hhv. 48 og 50 % af ordrerne er aritmetisk(-logisk)e - disse ordrer benytter altsa ALU'en. Ihh. til doktrinen \make the common case fast" ma vi altsa ubetinget afkorte den i kritiske datavej gennem ALU'en mest muligt, hvad vi har valgt at gre (se ogsa 5.2). Derfor stalles der pa ordresekvenser af ovenstaende type. Et tilsvarende problem gr sig gldende for registervrdier, der lses fra lageret i samme cyklus som de nyeste vrdier skal bruges til bne/beq-sammenligninger. Vi kan forwarde det indlste ord inden det skrives til MEMWB - og dermed mindske clock-frekvensen - eller stalle, og dermed ge CPI. Igen har vi valgt, at forwarding kun sker med resultater, der blev beregnet i sidste clockcyklus. En bemrkning, vi br tilfje i forbindelse med branch-ordrerne beq og bne er, at vi maksimalt kan hoppe 2 15 bits vk fra den nuvrende PC-adresse. Vi 17

18 har antaget, at dette problem falder uden for opgavens rammer at lse Hopforudsigelse En 2-bits-hopforudsiger (som omtalt i [3] s. 498.) kan medvirke til at snke at CPI'en ganske kraftigt, da der for hvert rigtigt gt spares 1 clockcyklus. I gennemsnit regnes maskinkode-lkker (som typisk er der, hop-instruktioner benyttes) for at blive gennemlbet 10 gange. Kan en prcision pa over 90 % opnas, vil hopforudsigeren derfor ubetinget vre vrd at implementere. I det indledende design har vi dog ikke overvejet muligheden for at implementere en hopforudsiger, og da dette ikke er stillet som et krav i [1], agter vi ikke at forflge denne mulighed yderligere. 3.7 Register 0 mips foreskriver, at vrdien af register nul altid skal vre 0. Med forward implementeret ville vi principielt kunne risikere at forwarde en ikke-nul vrdi til en instruktion, der bruger dette register, idet vi ikke kan afvise, at nogle instruktioner vil forsge at skrive i register 0. Vi lser problemet i to trin: For at undga at bekymre os om invarianten at register 0 indeholder 0, blokerer vi enhver skrivning af andet end 0 i register 0. Dette gres ved at sende RegDst gennem en 5-bits or-gate, og derefter and'e resultatet med REGWR. Samtidig vil vi i forward implementere, at ordrer, der benytter register 0, blot bruger det, de udlser fra REG komponenten. Den ovenfor viste logik sikrer jo netop, at registret ikke er opdateret med en forkert vrdi. Saledes vil ingen ordre kunne fa forwardet ikke-0-vrdier, en tidligere ordre forsger at skrive i register STOP STOP-signalet markerer afslutningen af simulationen og er at opfatte som en "pseudo-instruktion". Signalet er implementeret med den frdige byggeklods SimSys, der styres af vores kontrolenhed. Simulationen stoppes jeblikkeligt (i den pagldende clockcyklus), nar kontrolenheden opdager, at den lste instruktion er stop-ordren. Udfrsel af eventuelle instruktioner efter stop er sadan set ligegyldige, og vi bekymrer os ikke om disse. 18

19 4 Arkitektur - implementation Som udgangspunkt for vores pipeline vil vi dels benytte mikroarktitekturerne i [3] s. 470, 484, 498 (faktisk een arkitektur, illustreret pa forskellige udviklingstrin), dels vores egen enkeltcyklus-arkitektur fra G2, se [5]. Kontrol, stall-kontrolenheden og forwarding er implementeret i id, da dette er det tidligste stadie i pipelinen, hvortil vi skal kunne forwarde, og det stadie, hvori registre udlses - sa eventuelle stall-beslutninger kan tidligst tres her. Den store forskel fra de i [3] demonstrerede arkitekturer ligger altsa i if og id-stadierne. Arkitekturen er dokumenteret i A.1. I forklaringen af implementationen herunder vil vi referere til guren, men der gres opmrksom pa, at ikke samtlige navne stemmer overens med de, der ndes pa tegningen. Ledninger benvnes kun ved frste del af navnet. Adskillige komponenter er fremvist abstrakt, som byggeklodser. Disse komponenters indmad (evt. endnu et niveau af komponenter) er for de blot en smule kompliceredes tilflde dokumenteret i A pa separate gurer. Vi vil ogsa referere til disse i hj grad. De enkleste komponenter vil blot blive forklaret nedenfor. 4.1 Kontrol De kontrolsignaler i pipelinen, kontrolenheden skal stte, er alle - JRSELECT undtaget - direkte brugbare fra [5]-implementationen af ordresttet. Derfor genbruger vi PLA-implementationen. Denne udvides dog, idet kontrolenheden nu ogsa har til opgave at denere de tre attributtyper for instruktionen og distribuere denne information - til Stall, pipelineregistret IDEX og FW. Vores kontrolenhed kontrollerer de nedenfor opremsede signaler pa den speci- cerede made. Attributterne tildeles vrdier svarende til de i anfrte. ALUOP ALUOP afgr, hvilken operation ALU'en skal udfre. Overholder sandhedstabellen i [5] s. 6, i overensstemmelse med konventionerne vedtaget i opgave 6.2 i [4]. ALUSRC Sttes, hvis ALU'en skal bruge en immediate-operand, altsa pa ordrerne addi, slti, ori, andi, sw, lw BR Sttes pa br, nbr JRSELECT Sttes pa jr. I forbindelse med pipeliningen af arkitekturen er processen med at udvlge nste vrdi til PC blevet vsentligt vanskeligere, se 4.3. Det er ikke lngere muligt for kontrolenheden at afgre, hvilken adresse nste instruktion skal lses fra. Derfor er signaletpcsrc fra implementationen i [5] blevet reduceret til en indikator af, hvorvidt den i kontrolenheden kurante ordre en en jr. Komponenten PCC vil udfra dette og mange andre signaler producere den korrekte instruktionsadresse. Signalet er derfor blevet omdbt til JRSELECT. 19

20 MEMRD Sttes pa lw MEMWR Sttes pa sw NBR Sttes pa nbr REGDST Vlger mellem registeradresser til skrivning (udvlger bits fra instruktionens 32-bit ord). Sttes til 00 pa immediate-instruktionerne addi, slti, andi, ori samt lw, 01 pa jal (hvor returadressen altid skrives i register 31), og 10 pa add, sub, slt, and, or REGSRC Fres gennem pipelineregistrene og vlger i MEMWB-komponenten, hvilken data, der skal skrives i registerbanken. Sttes til 00 pa jal (returadressen skrives), 01 pa samtlige A.L. og I.A.L.-instruktioner (ALUresultatet skrives) og 10 pa lw (det indlste ord skrives). REGWR Sttes pa add, sub, slt, and, or, jal, addi, slti, ori, andi, lw STOP Sttes pa stop XTEND Sttes, nar der skal fortegnsforlnges pa immediate-operander, altsa pa ordrerne beq, bne, addi, slti, lw sw. 4.2 PC PC er vist pa A.6. I PC modtages den opdaterede instruktionsadresse fra PCC; denne lagres i en ipop. PC-adressen gives til MEM, og den nste adresse (PC+4) beregnes og gives til IFID-registret og PCC. De 4 verste af bits af PC+4 gives til PCS (benyttes til beregning af jump-adresser, se 4.4). 4.3 PCC Komponenten PCC er vist i A.2. Komponenten far PC-adresser ind fra PC og PCS, og benytter styresignaler til at vlge den korrekte - og er altsa dermed afgrende for, om instruktioner udfres sekventielt eller om der hoppes, stalles eller ushes. Flushes forekommer, hvis der skal branches pa en beq eller bne- dette afgres nemlig frst i id, og da er en forkert instruktion indlst i IF. Derfor kontrollerer PCC signalet FlushCtrl, som regulerer IFID-registret: Der indsttes 0'er i stedet for den forkerte instruktion i tilflde af branch (en boble indsttes). FlushCtrl kontrolleres af de signaler, der ogsa indikerer, hvorvidt der skal branches pa beq, bne eller jr. Ved at placere muxe i prioriteret rkkeflge internt i PCC vil den korrekte adresse altid "vinde"over de andre. Skal der saledes stalles, vil IFStallAdr blive valgt uafhngigt af eventuel forwarding af adresser, valg af branch-adresse frem for normal PC+4 etc. 20