Aanpassen processorkern voor superscalaire werking, ter ...

Faculteit Toegepaste WetenschappenVakgroep Electronica en Informatiesystemen

Voorzitter: Prof. J. Van Campenhout

Aanpassen processorkern voor superscalaire werking,ter voorbereiding op MORF

doorJef Laurijssen & Bruno De Maesschalck

Promotor: Prof. dr. ir. Dirk StroobandtScriptiebegeleiders: Dr. ir. Mark Christiaens

Ir. Benjamin Schrauwen

Scriptie ingediend tot het behalen van de academische graad vanburgerlijk ingenieur computerwetenschappen en licenciaat

informatica

Academiejaar 2004-2005

ii

Aanpassen processorkern voor superscalaire werking,

ter voorbereiding op MORF

door

Jef Laurijssen & Bruno De Maesschalck

Scriptie ingediend tot het behalen van de academische graad van burgerlijkingenieur computerwetenschappen en licenciaat informatica

Academiejaar 2004-2005Universiteit GentFaculteit Toegepaste WetenschappenVakgroep Electronica en InformatiesystemenVoorzitter: Prof. J. Van CampenhoutPromotor: Prof. dr. ir. Dirk StroobandtScriptiebegeleiders: Dr. ir. Mark ChristiaensIr. Benjamin Schrauwen

Samenvatting

De laatste jaren is er meer en meer aandacht voor programmeerbare logica. Doorrecente verbeteringen en uitbreidingen in de FPGA technologie zijn er mogelijkhe-den onstaan die onbestaande zijn in andere technologieen. Een tot de verbeeldingsprekende technologie, partiele dynamsiche herconfiguratie ziet sinds enkele jarenhet levenslicht. Deze technologie laat toe om een bepaald deel van een chip teherconfigureren terwijl de rest van de chip zijn functie bewaart en blijft werken.

Deze thesis gaat aanvankelijk over het onderzoek naar het ontwikkelen van eenprocessor architectuur, die gebruik makend van de nieuwe mogelijkheden van partieledynamishe herconfiguratie, een optimalere configuratie kan aanbieden. De techno-logie zou ons in staat kunnen stellen om theoretisch op ieder moment de meestoptimale hardware aan te bieden, zonder dat alle mogelijke configuraties ten allentijden vast aanwezig moeten zijn in de chip.

In een eerste fase wordt een overzicht gegeven van de technologie en zijnmogelijkheden, waarna een uiteenzetting wordt gegeven over welke mogelijkhedendit creeert voor een implementatie van een processor. In een tweede fase besprekenwe een gekozen benadering en worden een aantal softcore processoren vergelekenom als mogelijke basis te dienen voor onderzoek. In een derde fase wordt eenoverzicht gegeven van gedaan onderzoek.

trefwoorden:superscalair,VHDL,FPGA,MORF,leon3

Inhoudsopgave

Overzicht iii

Inhoudsopgave v

Lijst van figuren vi

Lijst van tabellen vii

Lijst van afkortingen viii

Voorwoord 1

1 Inleiding 21.1 Situering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Doel van de thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Structuur van het werk . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 FPGA-technologie en VHDL 52.1 FPGA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3 Designflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.4 Partiele en dynamische herconfiguratie van FPGA’s . . . . . . . . . 10

3 MORF 113.1 MORF: herconfigureerbare processor . . . . . . . . . . . . . . . . . . 113.2 Mogelijke architectuur en principiele werking . . . . . . . . . . . . . 123.3 Snelheid herconfiguratie . . . . . . . . . . . . . . . . . . . . . . . . . 15

4 Softcores 164.1 Wat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.2 Waarvoor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

INHOUDSOPGAVE iv

4.3 Gewenste voorwaarden . . . . . . . . . . . . . . . . . . . . . . . . . . 174.4 Gevonden processoren . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.4.1 STM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.4.2 DLX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.4.3 MicroBlaze . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.4.4 Leon3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.5 Afweging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.5.1 Superscalariteit . . . . . . . . . . . . . . . . . . . . . . . . . . 204.5.2 Moderne softcores . . . . . . . . . . . . . . . . . . . . . . . . 214.5.3 DLX vs. Leon3 . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5 superscalariteit en LeonS 235.1 Beschrijving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.1.1 Parallellisme . . . . . . . . . . . . . . . . . . . . . . . . . . . 235.1.2 LeonS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.2 Afhankelijkheden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275.2.1 Data-afhankelijkheden . . . . . . . . . . . . . . . . . . . . . . 275.2.2 Structurele afhankelijkheden . . . . . . . . . . . . . . . . . . 325.2.3 Controle-afhankelijkheden . . . . . . . . . . . . . . . . . . . . 35

5.3 Uitzonderingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.3.1 Wat zijn uitzonderingen? . . . . . . . . . . . . . . . . . . . . 395.3.2 SPARC en uitzonderingen . . . . . . . . . . . . . . . . . . . . 405.3.3 Precieze uitzonderingen . . . . . . . . . . . . . . . . . . . . . 425.3.4 Problemen bij superscalair ontwerp . . . . . . . . . . . . . . . 425.3.5 Mogelijkheden voor implementatie . . . . . . . . . . . . . . . 43

5.4 Geheugenstructuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.4.1 Lokaliteit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.4.2 Registerbestand . . . . . . . . . . . . . . . . . . . . . . . . . 455.4.3 Caches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.5 Opbouw pijplijn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

6 Besluit 51

A Schema’s en structuur 53A.1 Leon3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

A.1.1 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53A.1.2 Registers van de pijplijn . . . . . . . . . . . . . . . . . . . . . 57A.1.3 Pijplijn procedures en functies . . . . . . . . . . . . . . . . . 61A.1.4 Connectie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

A.2 LeonS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80A.2.1 Pijplijn structuur . . . . . . . . . . . . . . . . . . . . . . . . . 81

INHOUDSOPGAVE v

A.2.2 Registers van de pijplijn . . . . . . . . . . . . . . . . . . . . . 81A.2.3 Connectie van de pijplijn . . . . . . . . . . . . . . . . . . . . 82A.2.4 Pijplijn procedures en functies . . . . . . . . . . . . . . . . . 83

B Gaisler, grlib en Leon3 84B.1 Gaisler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84B.2 Grlib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84B.3 Leon3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85B.4 Bestandsstructuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

B.4.1 Verduidelijking . . . . . . . . . . . . . . . . . . . . . . . . . . 87B.4.2 Overzicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

C Inhoud CD 91C.1 Leon3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93C.2 STM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93C.3 LeonS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Index 96

Bibliografie 96

Lijst van figuren

2.1 Algemene architectuur FPGA . . . . . . . . . . . . . . . . . . . . . . 52.2 Designflow ontwerp met HDL en FPGA. . . . . . . . . . . . . . . . . 8

3.1 Blokschema MORF processorarchitectuur. . . . . . . . . . . . . . . . 123.2 Superscalaire pijplijn. . . . . . . . . . . . . . . . . . . . . . . . . . . 14

5.1 De pijplijn van Leon3. . . . . . . . . . . . . . . . . . . . . . . . . . . 245.2 Werking van de pijplijn van Leon3. . . . . . . . . . . . . . . . . . . . 255.3 Twee parallelle pijplijnen. . . . . . . . . . . . . . . . . . . . . . . . . 255.4 Een superscalaire pijplijn met vier functionele eenheden. . . . . . . . 265.5 RAW afhankelijkheden en Forwarding. . . . . . . . . . . . . . . . . . 285.6 Niet door forwarding oplosbare RAW-afhankelijkheden. . . . . . . . 295.7 RAW afhankelijkheid, opgelost d.m.v. een pijplijnbel. . . . . . . . . 295.8 WAW-afhankelijkheid door verschil in uitvoertijd instructies. . . . . 315.9 WAW-afhankelijkheid in multiple issue superscalaire pijplijn. . . . . 315.10 Gebruik van schuifregisters voor controle afhankelijkheden. . . . . . 345.11 Controle-afhankelijkheden in de pijplijn. . . . . . . . . . . . . . . . . 365.12 Terugdringen kost branch door stall en vroege controle conditiecodes. 375.13 Registervensters in de SPARC architectuur. . . . . . . . . . . . . . . 415.14 Gebruik van een reorder buffer. . . . . . . . . . . . . . . . . . . . . . 445.15 Gebruik van een history file. . . . . . . . . . . . . . . . . . . . . . . . 445.16 3-poorts registerbestand . . . . . . . . . . . . . . . . . . . . . . . . . 465.17 6-poorts registerbestand . . . . . . . . . . . . . . . . . . . . . . . . . 475.18 Blokschema pijplijn LeonS. . . . . . . . . . . . . . . . . . . . . . . . 49

A.1 Leon3 pijplijn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55A.2 Leon3 top down to the iu . . . . . . . . . . . . . . . . . . . . . . . . 78

B.1 Leon3 blokschema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

C.1 cd map structuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

Lijst van tabellen

4.1 softcores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Lijst van afkortingen

FPGA Field Programmable Gate ArrayHDL Hardware Description LanguageSOC System On a ChipVHDL Very high speed integrated circuit

Hardware Description LanguageVHSIC Very High Speed Integrated CircuitASIC Application Specific Integrated CircuitPCB Printed Circuit BoardRISC Reduced Instruction Set ComputerCISC Complex Instruction Set ComputerRTL Register Transfer LevelGNU GNU’s Not UnixGPL General Public LicenseIP Intellectual PropertyPLD Programable Logic DeviceCPLD Complex Programable Logic DeviceSCVE Statische Centrale VerwerkingsEenheidCLB Configurable Logic BlockFIFO First In First OutDCM Digital Clock ManagerSRAM Static Random Access Memory

Voorwoord

Deze thesis voldoet qua vorm zo goed mogelijk aan de richtlijnen zoals opgegevendoor de faculteit ingenieurs wetenschappen. Op plaatsen waar afgeweken is vande regels, is dit om de duidelijkheid te verbeteren of omdat de regels ontoereikendwaren voor de inhoud.We willen van de gelegenheid gebruik maken om wat meer uitleg te geven over hetgebruik van referenties in deze thesis. Elke referentie in de tekst bevat twee delen:de auteur(s) en het jaar van publicatie. Soms refereren we naar tekst of figuren vanwebsites. In dat geval is het jaar vervangen door de sleutel “WWW”, omdat veelwebsites geen jaar van publicatie vermelden.

DankwoordGraag zouden we de promotor bedanken ons de mogelijkheid te bieden aan ditboeiend onderwerp te werken, de begeleiders en assistenten voor hun raad, onzeouders voor hun steun gedurende onze gehele studie, de ontelbare liters cola om onsop de been te houden en de vele uren muziek om de sleur te verbreken. Veel dankgaat ook uit naar de luisterende oren en stilzwijgende monden van Liesbeth VanGorp en Jenni Lampinen.

Toelating tot bruikleenDe auteurs geven de toelating deze scriptie voor consultatie beschikbaar te stellenen delen van de scriptie te kopieren voor persoonlijk gebruik. Elk ander gebruikvalt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking totde verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultatenuit deze scriptie.

Jef Laurijssen & Bruno De Maesschalck, 31 mei 2005

Hoofdstuk 1

Inleiding

1.1 Situering

De laatste jaren is er meer en meer aandacht voor programmeerbare logica. Doorrecente verbeteringen en uitbreidingen in de FPGA technologie zijn er mogelijkhe-den onstaan die onbestaande zijn in andere technologieen. Een tot de verbeeldingsprekende technologie, partiele dynamsiche herconfiguratie ziet sinds enkele jarenhet levenslicht. Deze technologie laat toe om een bepaald deel van een chip teherconfigureren terwijl de rest van de chip zijn functie bewaart en blijft werken.

Binnen de vakgroep ELIS (electronica en informatiesystemen) is de onderzoeks-groep PARIS (parallelle informatiesystemen) actief in het onderzoek en ontwikkelingvan parallelle systemen onder andere gebaseerd op FPGA technologie. Een aantalthesisonderwerpen zijn specifiek gericht op de mogelijkheid tot partiele dynamischeherconfiguratie, dit om ermee vertrouwd te geraken en de nieuwe mogelijkheden teonderzoeken.

1.2 Doel van de thesis

Moderne processoren zijn ontwikkeld voor het gemiddelde algoritme. Hiermee be-doelen we dat een processor een bepaalde instructieset aanbiedt en een deel hardwaredie deze instructies kan uitvoeren. Hardware en software zijn in weze verwisselbaar,dingen die in software worden afgehandeld kunnen verschoven worden naar hardwareen omgekeerd, zolang er maar een basis hardware aanwezig is.

Een versnelling kan men bekomen door zaken in parallel uit te voeren. In eenmoderne superscalaire processor kunnen instructies in parallel uitgevoerd worden,maar is het aantal instructies dat in parallel kan worden uitgevoerd onder meerbeperkt door het aantal aanwezige functionele eenheden. Om er voor te zorgendat een processor potentieel twee keer zoveel instructies tegelijkertijd kan uitvoeren

1.3 Structuur van het werk 3

moeten we van elke functionele eenheid twee keer zoveel instanties aanbieden. Hetis duidelijk dat de grootte van zo’n chip enorm toeneemt wat niet kan voor tal vanredenen.

Het is juist hier waar partieel dynamisch herconfigureren nieuwe mogelijkhedencreeert. Misschien is het mogelijk om zo’n processor te ontwikkelen op een FPGAwaarvan het statische gedeelte vast in de FPGA aanwezig blijft en nooit verandert,terwijl een ander gedeelte in de FPGA een aantal functionele eenheden kan herber-gen. Dit gedeelte zou dynamisch herconfigureerbaar zijn, zodanig dat de verzamelingvan aangeboden functionele eenheden zou kunnen veranderen. De nieuwe processorkan dus virtueel meer functionele eenheden aanbieden dan zijn klassieke tegenhan-ger. Echter zal zijn grootte niet in dezelfde mate toenemen als bij een processorwaar men op een statische manier meer functionele eenheden aanbiedt. Deze dy-namische processor heeft als naam MORF gekregen, wat afgeleid is van het woordmetamorfose.

Stel dat een algoritme op een gegeven moment vier vermenigvuldigingen nodigheeft die allen theoretisch in parallel kunnen worden uitgevoerd. Een statische pro-cessor waar slechts een vermenigvuldiger aanwezig is zal dus vier maal de tijd nodighebben van de uitvoering van een enkele vermenigvuldiging. Een processor met al-le functionele eenheden verdubbeld, heeft slechts de helft van die tijd nodig, maarheeft wel twee maal zoveel plaats nodig op de chip voor de eenheden. MORF zoubijvoorbeeld alle functionele eenheden van de statische processor kunnen hebben endrie extra plaatsen voor extra functionele eenheden. Het is dus mogelijk voor MORFom zichzelf aan te passen en op een ogenblik maar liefst vier vermenigvuldigers aante bieden. Hierdoor kan hetzelfde bereikt worden in een vierde van de tijd dan dooreen statische processor en de grootte van de chip is slechts toegenomen met plaatsvoor drie functionele eenheden.

Het eigenlijke doel van deze thesis was initieel het onderzoeken en ontwerpenvan MORF, maar is gedurende het werk geevolueerd naar het voorbereiden van eenprocessor die verder onderzoek naar MORF kan vergemakkelijken.

1.3 Structuur van het werk

Na deze inleiding geeft hoofdstuk 2 een overzicht van de technologie die aan degrondslag ligt van dit werk, met zijn verschillende mogelijkheden. Er wordt ookuitleg gegeven over VHDL en de manier waarop FPGA gebaseerde systemen kunnenworden ontworpen, aan de hand van een design-flow.

Vervolgens geeft hoofdstuk 3 een beschrijving van MORF, waar men de nieuwemogelijkheden van de technologie uitbuit.

Hoofdstuk 4 duwt ons in de richting van een eigenlijke MORF implementatie,met een onderzoek naar softcore processors die ideaal zijn om MORF op te imple-

1.3 Structuur van het werk 4

menteren en een geargumenteerde keuze van zo’n processor voor verder onderzoek.In het vijfde en laatste hoofdstuk komen we tot de eigenlijke voorbereiding van

een softcore processor tot MORF. Verschillende facetten worden toegelicht en be-reikte resultaten worden uit de doeken gedaan.

Een besluit geeft een kritische kijk op ons werk.Op het einde van dit werk zijn enkele bijlagen gevoegd. Bijlage A geeft een

structureel overzicht van de Leon3 processor en in het bijzonder zijn pijplijn. Deinhoud is tot stand gekomen tijdens het eigen werk aan de pijplijn en vormt eenmogelijke bron van informatie voor verder onderzoek voor gelijk wie de hand willeggen op de pijplijn van Leon3.

In bijlage B plaatsen we Leon3 in zijn context: de bibliotheek grlib van GaislerResearch.

Tenslotte wordt in bijlage C uitleg gegeven over de inhoud van de bijgevoegdeCD-ROM.

Hoofdstuk 2

FPGA-technologie en VHDL

2.1 FPGA

Figuur 2.1: Algemene architectuur FPGA

Een FPGA, oftewel Field Programmable Gate Array, is een chip die bestaat uit eengroot aantal kleine, programmeerbare logische blokken die georganiseerd zijn in eengrote matrix. Deze blokken bevatten minimaal een geheugenplaats van een enke-le bit, in de vorm van een flipflop en enkele logische poorten of een lookup tabledie de inhoud van dat geheugentje bepalen. Al deze kleine blokjes zijn verbonden

2.2 VHDL 6

door een enorm netwerk van programmeerbare interconnecties, die van het geheeleen enorme programmeerbare component maken. Het verschil met ASIC’s is dat defunctionaliteit niet vastgelegd is bij de productie, maar achteraf door de gebruikerkan gespecifieerd en geprogrogrammeerd worden. De FPGA verschilt van micropro-cessoren doordat ze volledig parallel kunnen werken, waardoor ze ook inzetbaar zijnin andere toepassingsgebieden dan louter software. Door het feit dat op FPGA’sgrote digitale ontwerpen kunnen huizen, samen met hun programmeerbare karakter,worden deze chips veelal gebruikt voor het implementeren van testsystemen. Wan-neer het systeem echter klaar is voor productie, kan het ontwerp geımplementeerdworden op ASIC’s die betere prestaties kunnen leveren en minder stroom verbrui-ken. Door hun snellere time to market en hun lagere productiekosten (in beperkteoplagen) worden FPGA’s echter ook wel eens gebruikt bij de productie.

2.2 VHDL

FPGA’s maken het mogelijk erg grote en complexe systemen te realiseren. Omdathet manueel ontwerpen van digitale hardware moeilijk en tijdrovend is, heeft menernaar gestreefd deze vaardigheden te abstraheren en automatiseren.

In het midden van de jaren tachtig werd een programmeertaal ontwikkeld, ge-sponsord door het Amerikaanse leger, die de ontwerper in staat stelt een digitaalelektronisch circuit de beschrijven. Deze taal werd VHDL gedoopt, wat staat voorVery high speed integrated circuit Hardware Description Language. De specifieke ei-genschappen vinden hun oorsprong in zowel de wereld van de software, als de wereldvan de hardware.

Modulariteit Een ontwerp kan opgedeeld worden in verschillende eenheden. Elkvan deze eenheden heeft een welomschreven interface (definitie van de entiteit)en gedrag (beschrijving van de architectuur). Hierdoor zijn de voorwaardenvoor een modulaire ontwerpstrategie impliciet voldaan en kan hergebruik vande code georganiseerd worden.

Hierarchische decompositie De verschillende eenheden van het ontwerp kunnenop een hierarchische manier ingedeeld worden, teneinde verschillende abstrac-tieniveaus te creeren. Op die manier wordt de ontwerper een tweede hulpmid-del aangereikt om de complexiteit van zijn ontwerp te beheersen. Top down enbottom up implementaties zijn mogelijk, naargelang de smaak en de voorkeurvan de auteur.

Parallellisme en sequentialiteit Omdat VHDL hardware definieert, dient het opeen ondubbelzinnige wijze zowel parallellisme als sequentialiteit te kunnen be-schrijven. Alle ontwerpstrategieen uit het digitale ontwerpsspectrum zijn zo

2.3 Designflow 7

mogelijk, van volledig combinatorische tot gemicroprogrammeerde schakelin-gen.

Simulatie Verificatie van de werking van de ontworpen schakeling is mogelijk doormiddel van software. De schakeling hoeft niet in hardware geımplementeerdte worden om de kwaliteit van de geschreven code in de beginfase te evalue-ren. Verschillende software pakketten zijn voorhanden die toelaten de eerstecontroles uit te voeren op een overzichtelijke, vaak grafische manier. Dit kande ontwerpcyclus opmerkelijk inkorten.

Gedrags- en structuurbeschrijvingen De werking van een element kan men ini-tieel beschrijven met behulp van een algoritme. Dit noemt men een gedrags-beschrijving. Zo kan men de goede werking van elementen op een hoger hi-erarchisch niveau controleren, zonder de structuur van alle elementen die erdeel van uit maken reeds gespecifieerd te hebben. Om het geheel later echterin hardware te kunnen implementeren, dient uiteindelijk een volledige struc-tuurbeschrijving geschreven te zijn.

Tijdsgedrag Niet alleen de logische werking, maar ook het tijdsgedrag van de scha-keling kan gesimuleerd worden.

Hoewel het beschrijvende karakter van VHDL duidelijk interessante eigenschap-pen vertoont, werd het pas echt populair wanneer de eerste commerciele software-toepassingen voor synthese op de markt kwamen. Met deze applicaties kan mendaadwerkelijk hardware creeren vanuit de VHDL beschrijvingen, gaande van een-voudige combinatorische schakelingen tot ganse microprocessorsystemen.

2.3 Designflow

Om een goed inzicht te verkrijgen in de redenen die schuilgaan achter de populariteiten de opmars van het gebruik van de combinatie FPGA en VHDL, is het belangrijkde methodologie van een dergelijk ontwerp te schetsen.

1. Functionele decompositie:

Doordat VHDL de programmeur de mogelijkheid verschaft het ontwerp op tedelen in verschillende functionele eenheden, is het van belang vooraf reeds dearchitectuur in grote lijnen vast te leggen op het niveau van het blokdiagram.Zodoende kan men deelproblemen isoleren, ontwerpen en verificeren, alvorensover te gaan tot het testen van het systeem als geheel.

2.3 Designflow 8

Figuur 2.2: Designflow ontwerp met HDL en FPGA.

2. Coderen of samenstellen:

Voor elke module definieert men de interface en het gedrag doormiddel vaneen taal als VHDL. Het is echter ook mogelijk het ontwerp te maken doormiddel van een CAD programma. Hiermee selecteert en connecteert men ineen schematische weergave de bouwblokken waar de hardware uit zal bestaan.Deze bouwblokken worden ter beschikking gesteld in de vorm van bibliotheken.

3. Compilatie:

Eenmaal er code geschreven is, moet gecontroleerd worden of deze beantwoordtaan de syntaxregels die horen bij de gebruikte taal. Er wordt ook gecontroleerdof de gebruikte modules op een correcte manier verbonden zijn door middel vanhun interfaces. Informatie wordt verzameld die in de volgende fase gebruiktwordt door de simulator.

4. Simulatie en logische verificatie:

In deze fase kan men data aanleggen aan de inputs van het systeem en contro-leren of de uitgangen die je verwacht ook daadwerkelijk gegenereerd worden.Dit alles gebeurt zonder de hardware te maken. Dat is dan ook wat van desimulatie zulk een belangrijk onderdeel van de designflow maakt. De simulatie-software bootst de werking van de hardware na, waardoor men veel sneller degeschreven beschrijving kan controleren op fouten. Vaak schrijft men een ge-dragsbeschrijving in VHDL die de gewenste inputs automatisch aanlegt en deoutputs vergelijkt met de verwachtte waarden. Dit noemt men een testbench.Er dient opgemerkt te worden dat de keuze van de inputsignalen waarmee mensimuleert essentieel is. Men moet zich er van vergewissen dat de aangebodensignalen de werkelijkheid, waarmee de hardware geconfronteerd zal worden,zo goed mogelijk nabootsen. In het ideale geval zou men alle combinatiesvan inputs moeten verifieren. Erger nog, bij een sequentieel ontwerp moetmen ook alle paden doorheen de toestandsautomaat doorlopen om de moge-lijke fouten te kunnen identificeren. Zulks is in complexe systemen vaak niet

2.3 Designflow 9

mogelijk. Denk bijvoorbeeld maar aan de implementatie van een processorar-chitectuur met behulp van een HDL. Men kan aannemen dat het onmogelijk isalle mogelijke combinaties en sequenties van instructies aan te leggen om hetsysteem te testen. Men beperkt zich bij de keuze van de inputs dan ook toteen weloverwogen deelverzameling van de toestands- en inputruimte.

5. Synthese:

Wanneer de simulatie een bevredigend resultaat oplevert, kan de code omgezetworden naar een voorstellingsvorm die specifiek is aan de gebruikte technologie(ASIC/FPGA, PLD/CPLD,...). De VHDL beschrijving wordt vertaald naarprimitieven of componenten die in de hardware geladen kunnen worden. Ditnoemt men de synthese. Het resultaat kan bijvoorbeeld een verzameling lo-gische vergelijkingen of een verzameling logische poorten met een bijhorendenetlist zijn die de interconnecties beschrijft.

6. Passen, plaatsen en routeren:

De beschrijving, bekomen uit de synthese, wordt in de te gebruiken chip gepastdoor de vergelijkingen of componenten toe te wijzen aan de beschikbare poor-ten en interconnectiepaden. Dit wordt ook wel eens ‘plaatsing en routering’genoemd. De ontwerper kan in deze fase bepaalde beperkingen opleggen, zoalsde pin van de chip waarop een bepaalde uitgang geplaatst moet worden, ofwaar bepaalde componenten zich op de chip moeten bevinden. Het resultaatvan deze fase is wat men de ‘bitstream’ noemt, een binair bestand dat alleinformatie bevat die nodig is om de FPGA te configureren.

7. Timing verificatie:

Pas in deze fase zijn de exacte tijdseigenschappen van de schakeling gekend.Deze parameters gebruikt men om opnieuw de testen uit te voeren. Nu kun-nen we het circuit testen zoals het uiteindelijk zou worden gebouwd. Vaakkomen hier subtiliteiten aan het licht die bij de puur functionele simulatie nietopgemerkt konden worden.

8. Programmatie

In deze laatste fase komt men voor het eerst in contact met de hardware.Voorgaande stappen gebeurden telkens in een software omgeving, wat meteenook de kracht van deze procedure illustreert. De bitstream wordt gebruiktom de hardware daadwerkelijk te programmeren. Via een interface met deFPGA wordt de bitstream in de matrix, waaruit de harware bestaat, gela-den. Het vereiste interconnectienetwerk wordt ingesteld en de cellen wordengeconfigureerd om de nodige logica te bevatten. De FPGA is nu operationeel.

2.4 Partiele en dynamische herconfiguratie van FPGA’s 10

2.4 Partiele en dynamische herconfiguratie van FPGA’s

Zoals uit het verloop van dit werk zal blijken, is het niet de bedoeling hier eenvolledig overzicht te bieden van de bestaande technologieen, noch om de completetheoretische achtergrond te schetsen van het parieel en dynamisch herconfigurerenvan FPGAs. Wel is het van belang dat de lezer een notie heeft van voorgaandebegrippen. Voor meer informatie wordt verwezen naar de literatuur.

Partieel versus totaal Het verschil tussen een partiele en een dynamische hercon-figuratie manifesteert zich in het aandeel van de totale hoeveelheid hardwarein de FPGA die wordt gewijzigd. Bij een totale herconfiguratie zal de aan-wezige configuratie volledig gewist worden, alvorens de FPGA in zijn geheelopnieuw in te stellen. Een partiele herconfiguratie daarentegen, zal enkel eendeel van de configuratie aanwezig in de FPGA overschrijven. De snelheid vande configuratie is evenredig met de grootte van de gebruikte bitstream. Ditwil zeggen dat als de grootte van de bitstream afneemt, de snelheid van hetconfigureren stijgt. Vanzelfsprekend vraagt een partiele herconfiguratie danook minder tijd dan een totale.

Dynamisch versus statisch In tegenstelling tot een statische herconfiguratie kanmen een dynamische herconfiguratie doorvoeren, terwijl de FPGA operationeelis. Een partiele, dynamische herconfiguratie zal dus een deel van het apparaatwijzigen, terwijl de andere delen ongestoord verder werken. Deze eigenschapmaakt velerlei interessante toepassingen mogelijk. Men kan de configuratie vande FPGA en dus ook de aangeboden functionaliteit aanpassen aan de nodenvan de omgeving.

Hoofdstuk 3

MORF

3.1 MORF: herconfigureerbare processor

Een processor voert software uit in de vorm van instructies uit een welbepaaldeinstructieset. Om deze instructies uit te kunnen voeren, dient de processor zoge-naamde functionele eenheden te bevatten. Hieronder verstaan we een ALU, ver-menigvuldiger, deler, load/store eenheid, eventueel een floating point eenheid en/ofcoprocessor, enzovoort.

De precieze samenstelling van de verzameling functionele eenheden is afhanke-lijk van de architectuur van de processor en is dus een keuze die gemaakt is bij hetontwerp. Beoogde kosten, grootte, vermogenverbruik, instructieset, time to marketen snelheid zijn enkele van de factoren die de ontwerper beınvloeden bij het makenvan deze keuze. Zo zou men, met het oog op het realiseren van een hoge snelheid,graag meerdere load/store eenheden, ALU’s en een floating point eenheid plaatsen,maar dit gaat ten koste van verbruik, grootte en dus ook de kosten. Vandaar dathet eisenpakket dat de ontwerper vooropstelt in sterke mate bepaalt hoe de proces-sorarchitectuur eruit zal zien.

Echter is de ontwerper in een standaard processorarchitectuur niet enkel beperktdoor voorgaande eisen. Een processor moet in staat zijn alle mogelijke sequentiesvan instructies uit te voeren. Dit impliceert dat de ontwerper zijn processor zo moetontwerpen, dat deze – voorgaande eisenpakket indachtig – optimaal presteert voorhet gemiddelde algoritme. Het is moeilijk te bepalen hoe dit gemiddelde algoritmeer uit ziet. Bovendien kunnen ook binnen eenzelfde programma sterke variatiesoptreden inzake het type instructies dat uitgevoerd moet worden.

We kunnen samenvattend stellen dat, gedurende zijn levensduur, een processorgeconfronteerd wordt met een groot scala aan algoritmen en dat de ontwerper moetproberen hiervoor reeds op voorhand een passende architectuur te vinden.

De MORF processorarchitectuur gooit het echter over een andere boeg. Eerder

3.2 Mogelijke architectuur en principiele werking 12

dan op voorhand reeds alle beslissingen te nemen, tracht MORF de optimale setvan functionele eenheden te zoeken wanneer deze in bedrijf is. Gebruik makend vande mogelijkheid van een FPGA om zichzelf partieel en dynamisch te herconfiguren,kan op elk moment de geprefereerde configuratie actief zijn. Overbodige hardwarekan verwijderd worden, en plaats maken voor meer geschikte functionele eenheden.Op die manier worden de bronnen die voorhanden zijn in de FPGA beter benut enkan een hogere graad van parallellisme bereikt worden.

De processor zal de inkomende instructiestroom analyseren en bepalen of deaanwezige functionele eenheden toereikend zijn. Aan de hand van deze analyse kanal dan niet de beslissing genomen worden om een andere set in de FPGA te plaatsen.Hoe een dergelijke architectuur er in de praktijk zou kunnen uitzien, wordt in devolgende sectie besproken.

3.2 Mogelijke architectuur en principiele werking

Voor een groot deel wordt gebruik gemaakt van een standaard processorarchitectuur.Echter met een aantal wijzigingen. Zo worden de functionele eenheden bijvoorbeeldin een herconfigureerbaar deel geplaatst. De layouts van deze functionele eenhedenstaan beschreven in bitstreams, die ergens moeten worden opgeslagen. Een controllerzorgt voor de besturing van de herconfiguratie. Deze gedachtengang leidt op eennatuurlijke manier tot het blokschema uit figuur 3.1.

Figuur 3.1: Blokschema MORF processorarchitectuur.


SCVE De Statische Centrale VerwerkingsEenheid is een aangepaste softcore pro-cessor. Enkel de vaste delen zijn erin behouden, de functionele eenheden zijneruit verwijderd.

Herconfigureerbaar deel Daar waar de SCVE de toestand van de processor bij-houdt, wordt het eigenlijke rekenwerk uitgevoerd door de functionele eenhedenin het herconfigureerbaar deel. Deze functionele eenheiden worden omringddoor een interconnectie- en communicatienetwerk om op een uniforme wijzemet de SCVE te kunnen communiceren.

Herconfiguratie controller Om op de gepaste tijden de samenstelling van de ver-zameling functionele eenheden in het herconfigureerbaar deel te kunnen wij-zigen, wordt een besturingseenheid in het leven geroepen. Deze analyseert deinstructiestroom, initieert de herconfiguratie en houdt de nodige administratiebij.

Geheugen Hoe een bepaald stuk van het herconfigureerbaar deel moet geprogram-meerd worden om een functionele eenheid te bevatten, staat beschreven ineen bitstream. We moeten dan ook steeds voor elk type functionele eenheideen bijhorende bitstream voorhanden hebben. Deze worden opgeslagen in eengeheugen.

In figuur 3.2 worden de statische en herconfigureerbare delen van de architectuurgetoond in een zevendelige pijplijn. De fetch, decode, register access, memory, excep-tion en writeback fase van de pijplijn behoren tot het statische gedeelte, aangezienze gezamelijk worden gebruikt door de instructies. Ze behoren dus tot de SCVE. DeFunctionele eenheden in de superscalaire execute fase echter, zijn specifiek aan eeninstructie en zitten in het herconfigureerbare deel.

De SCVE haalt instructies op uit de cache en biedt deze aan de decode fasevan de pijplijn aan. Deze bepaalt uit de opcode van de instructie welke functioneleeenheid er nodig zal zijn voor deze instructie. De operandi worden opgehaald al-vorens de execute fase te betreden. Wanneer ze hun berekeningen voltooid hebben,rapporteren de functionele eenheden het resultaat aan de writeback fase en wordende resultaten tenslotte weggeschreven.

We laten de herconfiguratie controller beslissingen te laten nemen aan de handvan de reeds uitgevoerde instructies. Het principe van lokaliteit leert ons dat dezeoplossing zinnig kan zijn. Het grootste gedeelte van de tijd spendeert een processornamelijk aan het uitvoeren van lussen. De literatuur vermeldt een vuistregel diezegt dat 90% van de tijd 10% van het totale aantal instructies van een programmaworden uitgevoerd. Een implicatie hiervan is dat we met een redelijke nauwkeu-righeid kunnen voorspellen welke instructies zullen uitgevoerd worden in de nabijetoekomst aan de hand van de instructies uit het recente verleden.


Figuur 3.2: Superscalaire pijplijn.

De controller voorspelt aan de hand van een greep uit de reeds uitgevoerdeinstructies, welke functionele eenheden gewenst zijn. Er zijn nu twee mogelijkescenario’s, afhankelijk van de functionele eenheden die reeds aanwezig zijn:

1. Toereikend:

de controller besluit dat de huidige configuratie dicht genoeg aanleunt bij degewenste configuratie en herconfigureert niet. De controller houdt een tabel bijwaarin de locaties van de aanwezige eenheden in het herconfigureerbare deelstaan. De decoder kan dan in deze tabel opzoeken waar de passende eenheidzich bevind. Op die manier kan elke instructie naar de correcte plaats gestuurdworden.

2. Ontoereikend:

de controller beslist dat een andere set van functionele eenheden meer geschiktzou zijn om de uit te voeren instructies te verwerken. Op dit moment zijn erverschillende acties mogelijk, afhankelijk van de gekozen vervangstrategie ende tijd die een herconfiguratie vraagt. Een mogelijkheid zou kunnen zijn omde werking van de pijplijn te onderbreken totdat de herconfiguratie voltooid is.Indien de tijd nodig voor een herconfiguratie voorgaande strategie niet toelaat,kan men bijvoorbeeld ook slechts een deel van de functionele eenheden in hetherconfigureerbare deel vervangen. Op die manier zou de pijplijn actief kunnenblijven, terwijl de minst gebruikte functionele eenheden vervangen worden doormeer geschikte alternatieven.

3.3 Snelheid herconfiguratie 15

3.3 Snelheid herconfiguratie

Het succes van de MORF architectuur hangt in belangrijke mate af van de snelheidwaarmee FPGA’s zich kunnen herconfigureren. Indien we de tijd die nodig is voorhet herconfigureren delen door de periode van de processorklok, krijgen we eenruwe schatting van het aantal instructies dat uitgevoerd zou kunnen worden in dietijdspanne in een standaard architectuur. Indien dit aantal groter is dan het aantalinstructies die in een MORF architectuur meer in parallel uitgevoerd kunnen worden,is MORF geen succes.

In het verleden werden reeds FPGA’s op de markt gebracht die een herconfi-guratietijd hebben van ongeveer 30 ns. De grootte van de ontwerpen die men opdeze chips kon implementeren was echter beperkt door het geringe aantal cellen.De huidige FPGA’s kunnen meer logica bevatten, maar herconfigureren ook trager.Op het internet wordt melding gemaakt van herconfiguraties in grootteorden vanmilliseconden. Men is echter wel onderzoek aan het doen naar chips die veel snellerherconfigureren. Voor meer informatie wordt verwezen naar [11]

Hoofdstuk 4

Softcores

4.1 Wat

Wanneer hardware componenten worden beschreven in een HDL, hebben ze eensoftware karakter. Als deze componenten in hun HDL hoedanigheid worden aange-boden spreekt men van softcores. Het gaat dus over een hardware kern beschrevenop een softwarematige manier.

De softcore kan op tal van verschillende manieren gebruikt worden. Eerst envooral is het duidelijk dat door simpelweg de code aan te passen een andere functieof extra functies kunnen worden bekomen. De mogelijkheden op dat vlak zijn enkelbegrensd door verbeelding.

Het softwarematige karakter laat ook toe dat we op tal van verschillende ni-veaus kunnen simuleren, wat verder gebruik, aanpassen en debuggen gemakkelijkermaakt. Als de gewenste functie bereikt is kan men kiezen om het software karakterte laten vallen en de logica tot een ASIC te laten verwerken. Het is duidelijk datmen hierna niet meer kan spreken over een softcore. Een andere manier om delogica naar hardware te brengen is om de softcore te plaatsen in een FPGA. Deverschillende facetten en voordelen van een FPGA zijn reeds uitgebreid beschreven,echter is er nog een belangrijk voordeel. Het is door de FPGA technologie mogelijkom verschillende softcores te verzamelen in een chip en te interconnecteren, waardit anders hard geconfigureerd in een ASIC zou gebeuren of door middel van hetplaatsen van de verschillende componenten op een PCB. Zowel bij ASIC als bij PCBhangt er een prijskaartje aan het vastleggen van de interconnecties en een bepaaldeontwikkelingstijd. Een verkeerde keuze hierbij kan leiden tot heel wat extra kostenen opnieuw een lange ontwikkellingtijd. Vermits tijd ook geld is komt dit neer opzuiver verlies. Deze specifieke problemen heeft men bij FPGA technologie en sofco-res niet, omdat het herconnecteren louter een snelle sofware aanpassing vraagt ende wachttijd beperkt blijft tot het herconfigureren van de FPGA.

4.2 Waarvoor 17

4.2 Waarvoor

Om MORF te kunnen implementeren hebben we een basis nodig. Deze basis bestaatuit een softcore. Door deze softcore code aan te passen werken we verder op eerdergedaan onderzoek, zonder onnodig zaken opnieuw uit te voeren of te bedenken.In wat volgt gaan we op zoek naar een geschikte softcore processor als basis voorMORF. Hiervoor hebben we het internet gebruikt als zoekruimte.

4.3 Gewenste voorwaarden

Er is een ruim gamma aan softcores te vinden op het internet, van heel kleine micro-controllers tot volwassen microprosessors in alle geuren en kleuren. Om een gerichtekeuze te maken, hebben we een aantal voorwaarden voor de softcore opgesteld dieons gewenst leken om deze softcore als basis voor MORF te kunnen gebruiken.

Superscalair MORF wil superscalairiteit naar een ander niveau brengen. Eensoftcore processor die al superscalair is, leent zichzelf uiteraart beter om alsbasis voor MORF te dienen.

Voldoende goede prestaties MORF wil optimaler zijn met als netto resultaateen snellere verwerking van instructies. Men heeft er dus alle baat bij omzoveel mogelijk gebruik te maken van goed presterende moderne processorenen daar op verder te werken.

Bestaande compiler Bij het bestaan van een compiler voor de processor kan menhet programma schrijven in een hogere programeertaal, zoals C, wat ons toe-laat om gemakkelijker en sneller code te schrijven.

Om uiteindelijk een zinnige prestatiemeting te kunnen uitvoeren, moeten re-presentatieve programmas geschreven en uitgevoerd kunnen worden. Het be-schikbaar zijn van een compiler laat toe benchmark software te compilerennaar de juiste machinecode.

Modulaire opbouw Hierarchie van componenten maakt het mogelijk voor eenmens om complexe systemen te schrijven en aan te passen. Bij een goedeopsplitsing van delen en geschikt gekozen abstractielagen kan men structurenverkrijgen die eenvoudig zijn om te gebruiken, hanteren en aanpassen. Eensoftcore bestaande uit een goed opgedeelde modulaire structuur kan de stapnaar MORF vergemakkelijken. Als bijvoorbeeld de verschillende functioneleeenheden als aparte modules geımplementeerd zijn, kunnen deze eenvoudighergebruikt worden.

4.4 Gevonden processoren 18

Voldoende documentatie Goed gedocumenteerde code is nuttig en zelfs nood-zakelijk, om zich gemakkelijk een weg te banen tussen de verschillende lijnencode en in een zo kort mogelijke tijd een overzicht te krijgen van het geheel.

RISC Door de eenvoud van de RISC instructies is een RISC gebaseerde processoreenvoudiger qua architectuur dan een CISC. Omdat complexe instructies enkelextra moeilijkheden met zich meebrengen die ons afleiden van de kern van dezaak, hebben we geopteerd om naar een RISC gebaseerde softcore processorte zoeken.

FPGA bezetting FPGA bezetting is het percentage van alle beschikbare CLB’s ineen FPGA die bezet zijn. Om ruimte te laten voor toevoegingen in de FPGA,mag de softcore een niet al te hoge bezettingsgraad hebben.

Om een bezettingsgraad te kunnen uitdrukken gebruiken we in deze thesis deVirtex2P-30 FPGA van Xilinx op een test bord ML310 als referentie.

4.4 Gevonden processoren

Internet biedt een heel ruim aanbod aan softcores. Bij het toepassen van onzeopgestelde voorwaarden, komen we tot de volgende 4 meest interessante softcores.

4.4.1 STM

De STM [8] softcore is een vrije 32-bit processor en is superscalair met een ont-dubbelde pijplijn. Veel informatie valt er over de STM processor niet te vinden,het internet verschaft maar een website waar de processor kan gedownload worden.Tijdens het onderzoeken van de verschillende mogelijkheden, was de meest recenteversie van de STM processor V1.1. Bij het verder nagaan van de voorwaarden vandeze processor bleek dat de verschafte documentatie in het Japans is. Een eenvoudigvooronderzoek was dus niet mogelijk en de slaagkansen van deze keuze leken niet alte hoog te liggen.

Bij het neerschrijven van dit werk is gebleken dat ondertussen STM versie V1.2op het internet is geplaatst. Bij deze versie is al een heel summiere Engelstaligeversie van de documentatie voorhanden, wat de STM voor volgend onderzoek welweer op de kaart zet.

Omwille van dit laatste en omwille van het feit dat het een van de weinigesuperscalaire softcore processoren is die we hebben gevonden, wordt hij opgenomenin dit boek.

Het enkel beschikbaar zijn van de documentatie in het Japans op het moment vanbeschouwing van de V1.1 STM, heeft er voor gezorgd dat de aandacht voor verder

4.4 Gevonden processoren 19

onderzoek is gericht op de andere processoren. Dit mag in geen geval geınterpreteerdworden alsof de STM processor niet bruikbaar zou zijn.

4.4.2 DLX

De DLX [7] processor wordt beschreven door John Hennessy en David Patterson inhun boek “Computer Architecture: A Quantitative Approach”[2]. DLX wordt als“Deluxe” uitgesproken en de naam is afkomstig van het gemiddelde van de nummersvan alle processor architecturen waarop de DLX gebaseerd is en dit getal te schrijvenin Romijnse cijfers.

(AMD 29K, DECstation 3100, HP 850, IBM 801, Intel i860, MIPS M120A,IPS M1000, Motorola 88K, RISC I, SGI 4D60, SPARCstation-1, Sun-4110, Sun-4260)/13=560=DLX.

De DLX is geımplementeerd in de technische universiteit Darmstadt in Duits-land door Professor Doctor Ingenieur H. Eveking, voor onderwijs doeleinden en isgeschreven in een mix van gedrag en RTL code. Deze processor is superscalair. Hijis goed gedocumenteerd al is dit volledig in het Duits.

Er is zowel een DLX te vinden die modulair opgevat is en georganiseerd inverschillende bestanden, als een DLX volledig geschreven in een bestand. Bij hetsynthetiseren van deze processor op ons referentie bord bleek dat deze al gauw80% van onze referentie FPGA in beslag nam. Programmas voor de DLX kunnengeschreven worden in een voorziene assembler taal, maar een compiler is nog nietbeschikbaar.

4.4.3 MicroBlaze

Xilinx [9]is een bedrijf met een vaste waarde in de wereld van de programmeerbarelogica en beweert marktleider te zijn. Hun belangrijkste producten zijn hun FPGA’sen CPLD’s of in het algemeen herconfigureerbare chips. De bekendste zijn hunSpartan en Virtex reeksen, met als huidig vlaggenschip de Virtex-4.

Naast hun chips biedt Xilinx ook softcores aan. Als mogelijke softcore processorhebben we de MicroBlaze[1] onder de loep genomen. Deze softcore processor is eenniet superscalaire 32-bit processor. De MicroBlaze heeft een 3 stadia lange pijplijnen een RISC instructieset.

Er is en heel grote gebruikersbasis en wordt veelvuldig met success gebruikt inde industrie. Een groot geheel van professionele documentatie is voorhanden op hetinternet.

Om onderzoek te kunnen verrichten moet het mogelijk zijn om de broncode aante passen. Bij aanschaf van de MicroBlaze in code laat de licentie toe deze aan tepassen, echter bepaalt deze licentie dat deze aanpassingen niet mogen gepubliceerd

4.5 Afweging 20

worden, tenzij aan mensen of bedrijven die ook een licentie bezitten. Het is duidelijkdat deze situatie zich niet leent voor academisch onderzoek.

Gelijkaardige licenties bestaan voor de andere softcores van Xilinx, waardoorhun softcores zich niet lenen voor onderzoek.

4.4.4 Leon3

De Leon3[5] is een synthetiseerbare 32-bit processor, volledig comform met deSPARC V8 architectuur. Deze 7-stadia lange pijplijn processor is goed gedocu-menteerd en heeft een C compiler ter beschikking. Gaisler stelt de processor vrijonder een open source licentie. De Leon3 is zowel modulair in zijn VHDL source co-de, als in zijn processor configuratie die tijdens compile fase kan worden vastgelegd.Deze softcore is ook op de markt in ASIC vorm.

Meer informatie over de Leon3 is te vinden in de appendices.

4.5 Afweging

In deze sectie geven we een overzicht van de verschillende afwegingen tussen deverschillende processoren en hoe de uiteindelijke keuze tot stand is gekomen.

Tabel 4.1 geeft een beperkt overzicht van enkele voorwaarden van de geselecteerdesoftcore processoren.

DLX STM MicroBlaze Leon3instructie set RISC RISC RISC RISCsuperscalair ja ja neen neen

pijplijn ja ? ja jadocumentatie japans duits engels engels

prestatie - ? + +compiler neen neen ja ja

Tabel 4.1: softcores

4.5.1 Superscalariteit

Het internet biedt een heel scala aan diverse softcore processoren aan. De eerderopgestelde voorwaarde van superscalariteit in dachtig, zou men kunnen verwachtenenkel superscalaire softcore processoren aan te treffen in de selectie. Deze voorwaar-de is echter heel erg limiterend gebleken. Enkel de DLX en STM processoren zijnsuperscalair. Dit verklaard waarom de STM processor opgenomen is in de selectieook al was verder gebruik vrij snel afgewimpeld door de documentatie voorwaarde.

4.5 Afweging 21

In wat volgt houden we dus enkel nog rekening met de DLX van de superscalairevarianten.

4.5.2 Moderne softcores

De selectie duidt ook nog de Leon3 en de MicroBlaze aan, beiden opgenomen omdatze goed scoren op alle voorwaarden, buiten dan het superscalaire aspect. In onsvooronderzoek is gebleken dat de licentie van de MicroBlaze processor niet leentvoor academisch onderzoek.

Van deze categorie houden we dus enkel de Leon3 over.

4.5.3 DLX vs. Leon3

In de finale hebben we de DLX en de Leon3. Het vergelijken van deze twee processo-ren om een geargumenteerde keuze te maken is niet zo eenvoudig. Beide processorenzijn al toegelicht in het vooronderzoek. In deze sectie zullen we uitgaan van wat detekortkomingen zijn van beide processoren alvorens ze verMORFd kunnen worden.

DLX

Omdat de DLX voor educatieve doeleinden geımplementeerd is, zijn de verschillendeperiferieen met een gedragsbeschrijving geımplementeerd. Met periferieen bedoelenwe hoofdgeheugen, registerbestand, caches, debug eenheden, UARTs, interrupt con-trollers, etc... Ook heel veel van de werking van de DLX is als gedragsbeschrijvingopgevat. De DLX is eigenlijk niet meer dan een veredelde pijplijn. Dit is van geenbelang, zolang we de processor volledig in een simulatie-omgeving houden.

Omdat we bij MORF op hardware moeten werken om de dynamische partieleconfiguraties te kunnen uitvoeren, zal de DLX daar moeten draaien. De periferiemoet dan geheel herschreven worden om tot een synthetiseerbare vorm te komen. Deonbestaande caches en registerbestanden zullen dan ook van de grond af aan moetenworden opgebouwd. Ook is er geen enkele garantie dat een softcore die werkt ondersimulatie zal werken op hardware. Vaak vereist het enorme inspanningen en kennisom dit te verwezelijken. Een schatting van de inspanning en het aantal uren nodigom dit te verwezelijken is uiterst moeilijk.

Bij het aanpassen van de code van beschrijving naar RTL zullen we ook het extraeffect verkrijgen dat de ingenomen oppervlakte van de FPGA minder groot zal zijn.

Leon3

Leon3 is niet superscalair. Om te kunnen verMORFed worden moeten we hem dustransformeren naar een superscalaire variant.

4.5 Afweging 22

De vereiste aanpassingen aan de processor concentreren zich louter op de pijplijn.Het zijn voornamelijk de pijplijn en de componenten in directe interactie met depijplijn, zoals caches en registerbestanden, die aangepast zullen moeten worden. Eris weinig dat van de grond af aan moet worden opgebouwd. De volledige processorheeft bewezen te werken op hardware zodat we ook op dat vlak van een goede basiskunnen vertrekken. Een inschatting van de inspanning en het aantal uren nodigvoor deze aanpassingen is alweer heel moeilijk te voorspellen.

Keuze en argumentatie

Bij beide processoren is een aanzienlijke hoeveelheid werk vereist en is de inschattinghiervan heel moeilijk. In beide gevallen kan men tot een verMORFbare softcorekomen, echter op een heel verschillende wijze.

Het tussenresultaat kan op zichzelf op verschillende vlakken waardevol zijn. Mettussenresultaat bedoelen we dan een aangepaste softcore processor die klaar is omverMORFed te worden. Bijvoorbeeld kan er een hoge waarde gehecht worden aaneen DLX softcore processor die volledig op hardware werkt voor verdere educationeledoeleinden, of kan een superscalaire Leon3 omarmd worden door de industrie.

Als belangrijkste afwegingsfactor in onze uiteindelijke keuze hebben we gekekenin hoeverre de eigenlijke aanpassingen het dichtst verwant zijn met de eigenlijkeverMORFing. Hierbij is het duidelijk dat bijvoorbeeld een volledige cache schrijvenvoor de DLX niet zo verwant is.

Tijdens het aanpassen van de pijplijn van de Leon3 voor superscalaire werking,kunnen we de vereiste ontwerpskeuzes maken met MORF in het achterhoofd.

Dit laatste heeft er ons dan ook toe verleid om Leon3 aan te passen tot eengemakkelijk verMORFbare superscalaire softcore processor.

Hoofdstuk 5

superscalariteit en LeonS

5.1 Beschrijving

5.1.1 Parallellisme

De doorvoersnelheid van een processor kan sterk opgevoerd worden door meerdereinstructies tegelijk uit te voeren. Drie methodes zullen hier besproken worden.

1. pijplijnen

We kunnen de verwerking van een instructie door een processor opsplitsen inverschillende deeltaken. De eerste deeltaak is het ophalen van de instructie, detweede deeltaak het decoderen ervan enzovoort. Deze deeltaken worden dooreen klassieke, niet gepijplijnde processor sequentieel uitgevoerd binnen hettijdsbestek van een klokcyclus. Er wordt dus precies een instructie uitgevoerdin elke klokcyclus.

Echter heeft deze aanpak een nadeel. Wanneer een bepaalde deeltaak wordtuitgevoerd, wordt de hardware voor de andere deeltaken niet benut. Er wordtmet andere woorden niet optimaal gebruik gemaakt van het parallellisme endus ook niet van de rekenkracht, aanwezig in de hardware. Pijplijnen biedthiervoor een oplossing. De verschillende deeltaken bij de uitvoering van eeninstructie worden in parallel uitgevoerd. Elke deeltaak voert hierbij zijn bere-keningen uit op verschillende instructies. De delen worden verbonden in eenketting, waarin na iedere klokcyclus de resultaten doorgegeven worden aan devolgende deeltaak. De deeltaken in de pijplijn worden stadia (Eng. stages)genoemd.

Om de werking van een pijplijn te illustreren, wordt Leon3 als voorbeeld ge-bruikt. Figuur 5.1 geeft de 7-delige pijplijn van deze Leon3 weer. De verschil-lende deeltaken kunnen als volgt omschreven worden:

5.1 Beschrijving 24

Figuur 5.1: De pijplijn van Leon3.

Fetch (FE)Ophalen van instructies uit de instructiecache.

Decode (DE)Ontcijferen van de verschillende delen van de opcodes.

Register access (RA)Ophalen van de operandi uit het registerbestand.

Execute (EX)Uitvoeren van de bewerkingen met behulp van de aanwezige functioneleeenheden (ALU, Load/Store, Floating point unit,...). Het adres voor eenload, store of spronginstructie wordt hier berekend.

Memory (ME)Wegschrijven en uitlezen van data in de datacache.

Exception (XC)Controleren of er fouten of uitzonderingen zijn opgetreden in de pijplijn.

Writeback (WR)Wegschrijven van de resultaten naar het registerbestand.

In figuur 5.2 wordt het tijdsgedrag van de pijplijn geıllustreerd. In de eersteklokcyclus wordt instructie A opgehaald uit het cachegeheugen. In de tweedeklokcyclus wordt instructie A gedecodeerd, terwijl instructie B reeds wordt op-gehaald. Een klokcyclus later worden de operandi voor instructie A opgehaald,wordt instructie B gedecodeerd en instructie C opgehaald. Op die manier reistelke instructie als het ware door de ketting van stadia in de pijplijn, totdat zena zeven cycli de pijplijn verlaat. Zo wordt het resultaat van instructie A inklokcyclus 7 weggeschreven naar het registerbestand en is de uitvoering ervandus in klokcyclus 8 afgerond.

De doorlooptijd van de hardware in elk deel van de pijplijn is korter dan dedoorlooptijd in een klassieke processor. De klokfrequentie kan dan ook een stukhoger liggen. Aangezien in een gepijplijnde processor nog steeds een instructieper kloktik kan worden opgehaald, ligt de doorvoersnelheid hoger. Echterverhoogt ook de latentie van 1 klokcyclus in een klassieke processor naar nklokcycli in een processor met een n-delige pijplijn. In figuur 5.2 zien we

5.1 Beschrijving 25

bijvoorbeeld dat de uitvoering van een instructie pas na 7 klokcycli afgelopenis. Bij het verhogen van de doorvoersnelheid door middel van pijplijnen, moetdus steeds een afweging gemaakt worden tussen het verhogen van de latentieen het verkorten van de periode van de processorklok.

Figuur 5.2: Werking van de pijplijn van Leon3.

2. Meerdere pijplijnen

Om de hoeveelheid parallellisme in het ontwerp nog te verhogen, kan menverschillende pijplijnen naast elkaar plaatsen. In figuur 5.3 wordt een voorbeeldgegeven met twee pijplijnen. Er worden telkens twee instructies per klokcyclusopgehaald en elke instructie wordt aan een aparte pijplijn aangeboden. Dezeaanpak vraagt echter vrijwel twee keer meer hardware dan een enkele pijplijn.

Figuur 5.3: Twee parallelle pijplijnen.

3. superscalariteit

Een superscalaire processor heeft slechts een pijplijn, maar biedt verschillendefunctionele eenheden in parallel aan. Op die manier is geen verdubbeling vande hoeveelheid hardware vereist en kan toch een opmerkelijke verbetering van

5.1 Beschrijving 26

de prestaties bereikt worden. Deze aanpak heeft dan ook enorm veel navolginggekregen. Figuur 5.4 toont een typische superscalaire pijplijn.

Figuur 5.4: Een superscalaire pijplijn met vier functionele eenheden.

Indien de functionele eenheden allen op een klokcyclus hun taak kunnen uit-voeren en er elke klokcyclus slechts een instructie wordt aangeboden, is er opelk moment maximaal een functionele eenheid aan het werk. Het aanbiedenvan meerdere parallelle functionele eenheden zou dan weinig zin hebben. Ech-ter hebben een aantal functionele eenheden meer dan een klokcyclus nodig omtot een resultaat te komen. Voorbeelden hiervan zijn de load/store en floatingpoint eenheden, vermenigvuldigers en delers.

Een superscalaire processor kan reeds een volgende instructie uitvoeren, wan-neer een vorige instructie de execute fase van de pijplijn nog niet verlatenheeft. Op die manier kunnen de instructies sneller aangeboden worden aan defunctionele eenheden en wordt de doorvoersnelheid van de pijplijn verhoogd.

(a) Single issueIn een single issue superscalaire processor wordt slechts een instructieper klokcyclus afgeleverd aan de functionele eenheden. De verhogingvan de doorvoersnelheid berust louter op de aanwezigheid van de tragerefunctionele eenheden.

(b) Multiple issueIn een multiple issue superscalaire processor worden telkens meerdereinstructies uit de cache opgehaald en aangeboden aan de execute fase.Op die manier kan men nog meer instructies in parallel uitvoeren enwordt de doorvoersnelheid verder verhoogd. Bedenk bovendien dat hetenkel in een multiple issue processor nuttig is meerdere ‘snelle’ functionele

5.2 Afhankelijkheden 27

eenheden (uitvoeringstijd van 1 klokcyclus, zoals ALU) van het zelfde typein parallel te plaatsen. De pijplijn uit figuur 5.4 kan dus in feite enkelvan het multiple issue type zijn.

5.1.2 LeonS

Om gemakkelijk een onderscheid te kunnen maken tussen de Leon3 en zijn super-scalaire broertje, zullen we deze laatste de LeonS noemen. De ‘S’ staat natuurlijkvoor superscalair. Er is voor een multiple issue architectuur gekozen aangezien enkeldeze processoren meerdere ALU’s kunnen aanbieden. Buiten de grotere performan-tiewinst die mogelijk is, biedt een dergelijke architectuur meer vrijheid wanneer menLeonS wil gebruiken voor een implementie van MORF.

5.2 Afhankelijkheden

In een gepijplijnde processor zijn meerdere instructies tegelijk in uitvoering. Ditzorgt ervoor dat instructies afhankelijk kunnen zijn van andere instructies die in depijplijn zitten. In een superscalaire architectuur komt daar nog bij dat instructies depijplijn niet noodzakelijk in programmavolgorde verlaten. Indien een afhankelijkheidkan zorgen voor incorrecte resultaten spreken we van een “hazard”. In wat volgtwordt beschreven in welke situaties hazards kunnen ontstaan en hoe ze kunnenworden opgelost.

5.2.1 Data-afhankelijkheden

Soms is een instructie afhankelijk van het resultaat van een instructie die nog steedsin de pijplijn zit. Dit noemt men een data-afhankelijkheid. Vier mogelijke data-afhankelijkheden kunnen we onderscheiden:

1. Read after write

instr. A: IADD R1, R2, R3instr. B: IADD R4, R5, R1

Een instructie B leest data uit een geheugenadres dat door een voorgaandeinstructie A wordt beschreven. Indien echter het resultaat van A nog niet isweggeschreven wanneer de betreffende operand van B wordt opgehaald, zal deoperand van B en dus ook het resultaat foutief zijn. We zeggen dat er een readafter write (RAW) data-afhankelijkheid bestaat tussen A en B.

In het voorbeeld van figuur 5.5 zien we dat het resultaat van de optelling vaninstructie A gekend is aan het einde van de execute fase in klokcyclus 4. Dat


resultaat wordt echter pas weggeschreven naar doelregister R1 in de writebackfase in klokcyclus 7. Het register R1 wordt door de volgende instructies reedsals operand gebruikt voordat het resultaat van de eerste instructie er in weg-geschreven is. Dit is in de figuur weergegeven door middel van de vraagtekens.

Figuur 5.5: RAW afhankelijkheden en Forwarding.

Dit probleem kan opgelost worden door een techniek die forwarding wordtgenoemd. Het adres van het doelregister en het resultaat van de berekeningreizen mee doorheen de registers van de pijplijn. De resultaten worden vanuitde registers tussen de verschillende stadia teruggekoppeld naar het begin van deexecute stage. De pijlen in de figuur geven deze forwarding weer. Tijdens hetdecoderen van een instructie wordt gecontroleerd of een van de bronregistersvan die instructie hetzelfde is als het doelregister van een instructie die nogin de pijplijn zit. Afhankelijk van die controle wordt een multiplexer in deexecute fase bediend om te kiezen tussen de geforwarde data en de data uithet registerbestand.

Een load instructie introduceert RAW-afhankelijkheden die niet oplosbaar zijnmet behulp van forwarding. Bij een load instructie wordt het te laden adresin de execute fase bepaald en wordt de eigenlijke data pas in de memoryfase opgehaald. Het resultaat van de load instructie is dus pas aan het eindevan het memory stadium beschikbaar. Figuur 5.6 toont zo’n afhankelijkheid.Aangezien de load 2 klokcycli nodig heeft om de execute fase te verlaten, kande daarop volgende optelling niet meteen gestart worden. Forwarding kan hierniet toegepast worden. Het resultaat van instructie A kan immers niet, zoalsde pijl in de figuur aangeeft, teruggestuurd worden naar het verleden.


Figuur 5.6: Niet door forwarding oplosbare RAW-afhankelijkheden.

In dit geval moet dus een andere techniek worden toegepast. De pijplijn wordtonderbroken, tot de afhankelijkheid wel kan worden opgelost door middel vanforwarding. Het onderbreken van de pijplijn wordt ook wel eens ‘stalling’ ge-noemd, of het toevoegen van een pijplijnbel (Eng. bubble). Het ophalen vande operandi voor instructie B wordt door de decoder in klokcyclus 3 uitgesteldtot klokcyclus 4. Op dat moment is de correcte waarde voor register R1 voor-handen en kan forwarding toegepast worden. Dit staat weergegeven in figuur5.7.

Figuur 5.7: RAW afhankelijkheid, opgelost d.m.v. een pijplijnbel.

Superscalaire architecturen introduceren nieuwe RAW-afhankelijkheden, dieook door middel van een combinatie van pijplijnbellen en forwarding kunnenworden opgelost.

Ten eerste is het resultaat van sommige instructies pas berekend na meerdereklokcycli in de execute fase. Indien een instructie dit resultaat nodig heeft alsoperand, voordat de berekening voltooid is, moeten 1 of meer pijplijnbellenworden ingevoerd in de pijplijn.

Ten tweede kunnen in een multiple issue superscalaire processor meerdere in-structies tegelijk gestart worden, die onderling een RAW-afhankelijkheid ver-


tonen. Pijplijnbellen en forwarding brengen ook hier soelaas.

2. Write after read

inst. A: IADD R4, R5, R1inst. B: IADD R1, R2, R3

Een write after read (WAR) data-afhankelijkheid treedt op wanneer een in-structie B zijn bestemmingsregister wil beschrijven, alvorens een voorgaandeinstructie A uit dit register heeft kunnen lezen. Instructie A zou op die manierfoutief de nieuwe data inlezen.

Dit type van data-afhankelijkheden wordt impliciet opgelost door de struc-tuur van de pijplijn, ook in een superscalaire architectuur. Doordat het lezenvan de operandi in een vroeg stadium en het schrijven van het resultaat ineen laat stadium van de pijplijn gebeurt, worden fouten omwille van WAR-afhankelijkheden vermeden.

In sommige CISC processoren kunnen argumenten ook laat in de pijplijn gele-zen worden, zodat WAR-afhankelijkheden wel moeten gecontroleerd worden.Deze architecturen worden hier echter niet besproken.

3. Write after write


Men spreekt van een write after write (WAW) data-afhankelijkheid wanneereen instructie B zijn resultaat wil wegschrijven naar het zelfde doelregister alseen van zijn voorgangers A, voordat A de kans heeft gehad zijn resultaten wegte schrijven. De resultaten worden dus in de verkeerde volgorde weggeschreven,waardoor de resulterende data in het gemeenschappelijke doelregister ongeldigzijn.

In een superscalair ontwerp moet er op WAW-afhankelijkheden gecontroleerdworden, aangezien de instructies de writeback fase niet steeds in de program-mavolgorde bereiken.

Een eerste situatie waarin actie ondernomen moet worden, is afgebeeld infiguur 5.8. Instructie A is een vermenigvuldiging en spendeert 5 klokcycli inde execute fase, voordat het product berekend is. Wanneer A uiteindelijk dewriteback fase heeft bereikt, is er reeds een instructie B in parallel uitgevoerd,die zijn resultaat in hetzelfde doelregister als A heeft geschreven. Wanneer Anu zijn resultaat wegschrijft, is de inhoud van het registerbestand niet meercorrect.


Figuur 5.8: WAW-afhankelijkheid door verschil in uitvoertijd instructies.

Ook wanneer twee instructies met hetzelfde doelregister tegelijk de writebackfase betreden, dienen de resultaten in programmavolgorde te worden wegge-schreven. Deze situatie kan zich voordoen bij instructies met verschillendelatenties. Bovendien kunnen in een multiple issue superscalaire architectuurmeerdere instructies met gelijke latentie de pijplijn betreden. Dit wordt infiguur 5.9 getoond. Er moet worden verzekerd dat het resultaat van instructieB na klokcyclus 7 in register R1 van het registerbestand staat.

Figuur 5.9: WAW-afhankelijkheid in multiple issue superscalaire pijplijn.

Het afhandelen van deze hazards kan op 2 manieren gebeuren:

(a) uitstellen van instructie B totdat instructie A de memory fase bereiktheeft

(b) er voor zorgen dat de eerste instructie het resultaat niet wegschrijft (an-nulatie van de instructie, vervangen door een no operation)

Er dient opgemerkt te worden dat deze situatie enkel een WAW-hazard ople-vert indien er, tussen de twee instructies met gemeenschappelijk doelregister


in, geen instructie staat die dat zelfde register als bronregister heeft. Deze in-structie zou immers zorgen voor een RAW-afhankelijkheid, die een pijplijnbelzou veroorzaken.

Een situatie waarin 2 writes worden uitgevoerd zonder tussenliggende read,komt slechts zelden voor. Het afhandelen van een WAW-hazard kan dan ookbeperkt worden tot het stallen van een instructie die in de decodeerfase eenregister wil beschrijven dat ook beschreven wordt door een instructie die nogin de pijplijn zit. Op deze manier stallen we dus alle WAW’s die kort op elkaarvolgen (zelfs indien ze geen WAW-hazard zouden veroorzaken). Omdat desituatie waarin 2 writes kort op elkaar volgen zonder tussenliggende read zozelden voorkomt, zorgt dit niet voor een significant snelheidsverlies.

4. Read after read


Een read after read (RAR) data-afhankelijkheid kan geen hazard veroorzakenen hoeft dan ook niet behandeld te worden.

5.2.2 Structurele afhankelijkheden

Een structurele afhankelijkheid treedt op wanneer voor een bepaalde combinatie vaninstructies niet alle vereiste hardware beschikbaar of aanwezig is.

Volgende stukken hardware kunnen in een superscalaire architectuur voor struc-turele hazards zorgen:

1. Functionele eenheden

Wanneer de decoder merkt dat de gepaste functionele eenheid voor een be-paalde instructie niet voorhanden zal zijn in de execute fase, zal een pijplijnbelgeplaatst moeten worden. In een superscalaire pijplijn worden meerdere func-tionele eenheden in parallel aangeboden, zodat minder instructies op vrijgavevan een functionele eenheid moeten wachten.

Een structurele hazard kan optreden wanneer een bepaalde functionele een-heid niet gepijplijnd is. Een instructie kan dan deze hardware willen gebrui-ken, terwijl een voorgaande instructie deze gedurende enkele klokcycli bezethoudt. Wanneer meerdere instructies tegelijk worden opgehaald die dezelfdefunctionele eenheid willen gebruiken, kan een onderaanbod ook zorgen voorstructurele hazards. In beide gevallen bieden pijplijnbellen een oplossing.


2. Registerbestand

De instructies uit de SPARC instructieset hebben maximaal 2 operandi en 1bestemming. Indien een superscalaire processor per klokcyclus n instructiesophaalt uit de instructiecache, kunnen zich maximaal n instructies tegelijk inde register access fase bevinden. Het registerbestand vraagt dan ook 2 · nleespoorten.

Meerdere instructies kunnen zich tegelijk in de writeback fase bevinden. Omhet aantal benodigde schrijfpoorten van het registerbestand te beperken, moethet aantal instructies die zich gelijktijdig in de writeback fase kunnen bevinden,gelimiteerd worden. Voor meer informatie over de noodzaak van een beperktaantal poorten voor het registerbestand wordt verwezen naar sectie 5.4.2.

Het is de decoder die het aantal instructies die de execute fase tegelijk kunnenverlaten, zal beperken. Hiervoor wordt gebruik gemaakt van schuifregisters.Wanneer het registerbestand n schrijfpoorten heeft, zal de decoder n schuif-registers bijhouden. In figuur 5.10 wordt getoond hoe deze schuifregisters destructurele hazards die een gevolg zijn van een beperkt aantal schrijfpoortenaan het registerbestand kan oplossen.

De decoder berekent het aantal klokcycli dat een instructie nog in de pijplijnzal verblijven, alvorens die de writeback fase zal betreden. Vervolgens wordthet logische niveau op die plaats in de schuifregisters gecontroleerd. Indienin alle schuifregisters op die plaats een een staat, is een structurele hazardgedetecteerd en moet een pijplijnbel geplaatst worden. De instructie kan deregister access fase betreden indien er in een van de schuifregisters nog een nulstaat. Die nul wordt dan vervangen door een een. Het schuifregister wordtverschoven aan het zelfde tempo waaraan de instructies zich door de pijplijnbewegen.

De breedte van de schuifregisters kan worden bepaald aan de hand van depijplijndiepte en de maximale latentie van de functionele eenheden. Aangeziende decoder in de Leon3 het tweede stadium van de pijplijn is en er dus nogvijf stadia volgen, moeten de registers al minimaal 5 bits bevatten. Echterverblijven sommige instructies langer dan een klokcyclus in de execute fase,waardoor deze 5 bits niet volstaan. De functionele eenheid die de grootstelatentie heeft en die ook nog eens het registerbestand gebruikt is de deler 1

2. Deze deler verblijft gedurende 35 klokcycli in de execute fase, waardoor de1In de Leon3 hoeven niet alle bewerkingen in hardware geımplementeerd te zijn. Zo is het

mogelijk een processor samen te stellen zonder hardwarematige deler. De compiler moet een delingdan omzetten naar een sequentie bewerkingen die wel geımplementeerd zijn. In dat geval zal eenandere functionele eenheid de grootste latentie hebben.

2De floating point eenheid gebruikt een eigen, floating point registerbestand


schuifregisters in de decoder dus een lengte moeten hebben van 5+34=39 bits.

Figuur 5.10: Gebruik van schuifregisters voor controle afhankelijkheden.


3. Cache

Indien de data en de instructies in eenzelfde cache worden opgeslagen, treedteen structurele hazard op telkens er data wordt opgehaald uit de cache tengevolge van een load instructie. Op dat moment kan er immers geen instructieworden opgehaald. Een pijplijnbel dient op dat moment de pijplijn te onder-breken. Een Harvard architectuur, met een aparte data- en instructiecachezoals in de Leon3, biedt soelaas. De pijplijn moet dan niet meer onderbrokenworden bij het laden van data uit de datacache.

5.2.3 Controle-afhankelijkheden

Wanneer een instructie afhankelijk is van het verloop van de controlestroom, sprekenwe van een controle-afhankelijkheid.

De controlestroom kan worden gewijzigd door instructies die de programmatelleroverschrijven. Deze instructies noemen we spronginstructies. Wanneer het resultaatvan een spronginstructie zorgt voor het overschrijven van de programmateller spre-ken we van een genomen sprong.

Het verloop van een sprong in de Leon3 SPARC architectuur wordt getoond infiguur 5.11.

Eerst wordt een instructie uitgevoerd, instructie A in het voorbeeld, die eenconditieregister beschrijft. In dit register wordt aangegeven of er een deling doornul is gebeurd, of het resultaat gelijk is aan nul enzovoort.

De volgende instructie die uitgevoerd wordt is de eigenlijke spronginstructie B.Deze zal het conditieregister gebruiken om te bepalen of de sprong al dan nietgenomen moet worden. In het voorbeeld wordt gecontroleerd of de aftrekking vaninstructie A een nul heeft opgeleverd. Indien het resultaat inderdaad nul was, zalde sprong worden gemaakt naar adres i. Indien het resultaat verschillend was vannul, zal de sprong niet genomen worden.

Aan het eind van klokcyclus 5, na de berekeningen van de spronginstructie B dus,is geweten of de sprong gemaakt moet worden. Dit wordt in de figuur aangeduiddoor middel van een pijl met stippellijn. Op dat moment kan in de fetch fase even-tueel de programmateller overschreven worden en kunnen de instructies vanaf hetsprongadres worden opgehaald. Echter kunnen nog 3 instructies worden opgehaaldtussen het moment waarop de spronginstructie B wordt opgehaald en het momentwaarop het resultaat van de sprong gekend is.

Om dit aantal te beperken kunnen we de uitvoering van de spronginstructiesin een vroeger stadium van de pijplijn plaats laten vinden. Dit wordt in de Leon3verwezenlijkt door de conditiecodes die door instructie A worden geschreven reedsin de decoder te controleren. De decoder geeft dan meteen aan de fetch stage door


Figuur 5.11: Controle-afhankelijkheden in de pijplijn.


of de sprong moet worden genomen. Doordat instructie A eerst nog de registeraccess fase moet doorlopen alvorens de conditiecodes in de execute fase te kunnenschrijven, moet de pijplijn gedurende 1 klokcylus geblokkeerd worden. Dit alleswordt weergegeven in figuur 5.12.

Figuur 5.12: Terugdringen kost branch door stall en vroege controle conditiecodes.

Er blijft nu nog 1 instructie over die moet worden opgehaald tussen het momentwaarop de spronginstructie wordt opgehaald en het moment waarop het resultaatvan de spronginstructie gekend is. Deze lege plaats kan op verschillende maniereningevuld worden.

1. pijplijnbellen

Er wordt geen instructie uitgevoerd. We stoppen dus een pijplijnbel in de pijp-lijn. Deze strategie kan aantrekkelijk zijn omwille van zijn eenvoud. Aangeziensprongen veel voorkomen en de compiler de kosten voor een sprong niet kanbeperken, zorgt de pijplijnbel voor een degradatie van de prestaties.

2. voorspel sprong als ongenomen

Bij de voorspel-ongenomen strategie worden de instructies opgehaald alsofde spronginstructie een normale instructie was. In het voorbeeld zou dus


instructie B op het adres 12 worden opgehaald. Wanneer de sprong dan tochgenomen wordt, moet deze instructie geannulleerd worden. Wanneer echter desprong niet genomen wordt, hebben we een nuttige instructie uitgevoerd. Decompiler kan er voor zorgen dat in de meeste gevallen de sprong niet genomenwordt om op die manier de gemiddelde kosten van sprongen te verlagen.

3. voorspel sprong als genomen

Men kan ook de tegenovergestelde voorspelling maken en de spronginstructielaten volgen door de instructies vanaf het sprongadres. Wanneer de sprongdan echter niet genomen wordt, moeten deze instructies worden geannulleerden moet de uitvoering hervat worden vanaf de instructies die in het geheugende spronginstructie volgen. In het voorbeeld zou instructie 50 dus opgehaaldworden na de spronginstructie. Ook hier kan de compiler inspanningen doenom de sprongen meestal uit te laten voeren.

4. delayed branch

spronginstructiedelay slot 1delay slot 2...delay slot n

maak sprong indien nodig

Er kan ook voor gezorgd worden dat de sprong pas plaats zal vinden na deuitvoering van een aantal volgende instructies. Deze instructies worden “delayinstructies” of “delay slots” genoemd en worden steeds uitgevoerd, onafhan-kelijk van het resultaat van de spronginstructie. Het succes van deze strategieligt bij de compiler. Indien deze de slots kan vullen met nuttige instructies,die sowieso zouden moeten uitgevoerd, kunnen stalls vermeden worden.

Het vinden van nuttige instructies om de delay slots te vullen is geen sinecure.Een instructie die een data-afhankelijkheid vertoont met een andere instructie,mag niet zomaar worden verplaatst. Meestal wordt dan ook slechts 1 delayslot gebruikt.

5. annulerende sprongen

De tekortkomingen van voorgaande strategieen hebben geleid tot een vijfdevariant. Deze biedt een combinatie van delay slots en sprongvoorspelling doorde compiler. Op die manier wordt de compiler meer vrijheid gegeven bij hetoptimaliseren van de afhandeling van sprongen. Naast de gekende sprongin-structies met delay slot, wordt ook een sprong geıntroduceerd die het delay slot

5.3 Uitzonderingen 39

kan annuleren. Bij een annulerende instructie krijgt de hardware een voorspel-ling van de sprong aangeboden door de compiler. Wanneer deze voorspellingfoutief blijkt de zijn, wordt de instructie in het delay slot geannulleerd.

In de Leon3 wordt een variant op de annulerende sprongen gebruikt met een delayslot. De opcode van een sprong bevat een bit die de ‘a bit’ of de ‘annul bit’ wordtgenoemd. Wanneer deze bit een logische nul is, wordt de instructie in het delayslot steeds uitgevoerd. Wanneer echter de annul bit op 1 staat, wordt de sprongbehandeld als een annulerende sprong. Deze sprongen worden steeds voorspeld alsgenomen. Indien deze voorspelling fout blijkt wordt de instructie in het delay slotgeannulleerd.

In sterk gepijplijnde processoren zorgt het gebruik van 1 delay slot ervoor dat depijplijn gedurende 1 (zoals bij Leon3) of meerdere klokcycli moet gestalld worden.In een superscalaire architectuur die meerdere instructies per kloktik kan ophalen,moeten zelfs nog meer pijplijnbellen aangemaakt worden. Dit alles is een verspil-ling van het beschikbare parallellisme en komt de doorvoersnelheid van de processorniet ten goede. Om het afhandelen van sprongen in dergelijke architecturen meerte stroomlijnen, dient dan ook meer aandacht besteed te worden aan sprongvoor-spellingen. Een bespreking van strategieen voor sprongvoorspellingen in modernesuperscalaire en sterk gepijplijnde architecturen valt echter buiten het bestek vandit werk.

5.3 Uitzonderingen

5.3.1 Wat zijn uitzonderingen?

Normaal wordt het controleverloop van een programma opgelegd door de program-meur die sprongen en functie-oproepen plaatst. Het is dus de programmeur dievastlegt in welke sequentie de instructies moeten worden opgehaald. In sommige ge-vallen klopt voorgaande stelling niet. Dit worden uitzonderingen (Eng. exceptions)genoemd.

Uitzonderingen zijn dus wijzigingen in het controleverloop van de uitvoeringdie niet expliciet in de programmacode staan, maar die het resultaat zijn van eenuitzonderlijke toestand. We kunnen uitzonderingen als volgt onderverdelen:

Traps: gerelateerd aan de software in uitvoering

In deze categorie vinden we uitzonderingen die een gevolg zijn van bepaaldecondities die de bewerkingen in de pijplijn zelf kunnen veroorzaken, zoals hetoverlopen van resultaatregisters in de ALU, een deling door nul, een onge-implementeerde of ongekende instructie enzovoort.


Interrupts: veroorzaakt door externe gebeurtenissen

Wanneer input/output-apparaten om aandacht vragen, wordt ook een uitzon-dering gegenereerd.

Hardwarecontrole: te wijten aan ernstige fouten in de hardware

Indien een deel van de hardware niet goed werkt, er een stroomonderbrekingis enzovoort, noemen we dit eveneens een uitzondering.

Bij het optreden van een uitzondering wordt diens type bepaald en de gepasteroutine gestart om de uitzondering af te handelen. Deze routine wordt de uitzonde-ringsroutine genoemd. De toestand van de pijplijn, d.w.z. de programmateller en deregisters, wordt hierbij eerst opgeslagen. Nadat de instructies uit deze routine zijnuitgevoerd, dient de toestand van de processor voor de uitzondering terug hersteldte worden, waarna de uitvoering van de programmacode kan worden hervat.

Om de uitvoering van het programma niet te sterk te vertragen door de afhan-deling van de uitzonderingsroutines is het noodzakelijk de omschakeling naar en vandeze routines zo snel mogelijk te doen verlopen. In de SPARC architectuur wordthiervoor een bijzondere techniek toegepast.

5.3.2 SPARC en uitzonderingen

De registers uit het registerbestand worden in een SPARC processor opgedeeld invensters. Elk venster bestaat uit 3 delen: 8 in-registers, 8 out-registers en 8 localeregisters. Bovendien zijn op elk ogenblik 8 globale registers beschikbaar. Het aantalvensters is implementatie-afhankelijk en kan gaan van 2 tot en met 32.

De verschillende vensters overlappen. Elk venster deelt zijn in- en uit-registersmet de twee naburige vensters. De uit-registers van het vorige venster kunnen ge-adresseerd worden als in-registers in het huidige venster en de in-registers van hetvolgende venster kunnen worden beschreven door middel van de uit-registers vanhet huidige venster. De 8 lokale registers zijn uniek voor elk venster, de 8 globaleregisters zijn gemeenschappelijk. Figuur 5.13 illustreert dit.

Wanneer een oproep wordt gedaan naar een andere functie of routine, zoalswanneer een uitzondering optreedt, wordt overgeschakeld naar een ander venster.De argumenten die bij de oproep horen, staan in de uit-registers. Deze uit-registersvan het oproepende programmadeel kunnen via de in-registers worden gelezen in deopgeroepen routine. Op die manier wordt het opslaan van registers bij een oproep,alsook het herstellen van de originele waarden naar de registers na afhandeling vande opgeroepen routine vermeden.


Figuur 5.13: Registervensters in de SPARC architectuur.


Hoewel een goede compiler ook in staat is registers te delen over de grenzen vaneen oproep heen, kan de compiler onmogelijk voorspellen wanneer een uitzonderingoptreedt. De processor zou dan nog steeds vele registers moeten opslaan en laterherstellen. Vensters bieden hier soelaas.

5.3.3 Precieze uitzonderingen

Een uitzondering wordt precies genoemd indien er een enkele instructie of puntbestaat waarvoor geldt dat:

• alle voorgaande instructies hun resultaat hebben weggeschreven

• geen enkele volgende instructie de processortoestand heeft gewijzigd

Bij het gebruik van precieze uitzonderingen kan de hardware er voor zorgen datna het optreden en afhandelen van een uitzondering, het hervatten van de uitvoeringtot de correcte resultaten zal leiden. Bij vele architecturen is dit een vereiste, terwijlandere architecturen deze taak overlaten aan het besturingssysteem.

In een niet superscalaire SPARC processor worden precieze uitzonderingen ge-implementeerd door middel van het opslaan van zowel de huidige programmateller(PC) als de volgende programmateller (NPC of Next PC). Wanneer namelijk eenuitzondering optreedt vlak na een spronginstructie, tijdens het delay slot, moetopgeslagen worden of deze sprong genomen moet worden en naar waar er mogelijkgesprongen moet worden. In het geval van een niet genomen sprong zal het paar (PC,PC+4) worden opgeslagen. Wanneer de sprong echter wel genomen moet worden,zal het paar (PC, SPRONGADRES) worden gebruikt.

Wanneer dus een uitzondering optreedt, wordt de instructie die op dat momentin de execute fase zit volledig uitgevoerd, terwijl de volgende instructies wordengeannuleerd. Vervolgens wordt overgeschakeld op een ander registervenster, wordenPC en NPC opgeslagen in de lokale registers van het nieuwe venster en wordende instructies van de afhandelingsroutinge opgehaald en uitgevoerd. Wanneer dezeroutine is uitgevoerd, worden PC en NPC die opgeslagen werden in de lokale registersterug gebruikt om het onderbroken programma te hervatten. Bovendien wordt terugovergeschakeld op het vorige venster. De uitvoering van het onderbroken programmakan opnieuw worden aangevat.

5.3.4 Problemen bij superscalair ontwerp

Een superscalaire architectuur maakt het implementeren van preciese uitzonderingeneen stuk moeilijker. Instructies wijzigen dan immers de toestand van de processorniet langer in de programmavolgorde. Het bijhouden van PC en NPC zal hier danook niet meer volstaan. Veronderstel dat volgende sequentie van instructies wordtuitgevoerd en een uitzondering optreedt:


A: IMUL R1, R2, R3B: IADD R4, R4, R5C: ISUB R5, R6, R7

We weten dat een vermenigvuldiging 5 klokcycli duurt. Indien de vermenigvul-diging nu een uitzondering genereert wanneer het resultaat van instructie B reedsis weggeschreven, maar het resultaat van instructie A nog niet gekend is, wordt eenprecieze uitzondering onmogelijk. De optelling heeft namelijk een van zijn operandioverschreven, waardoor de processortoestand van voor instructie A niet kan wordenhersteld.

5.3.5 Mogelijkheden voor implementatie

1. Reorder buffer Door ervoor te zorgen dat de resultaten van de uitgevoerdeinstructies in de programmavolgorde naar het registerbestand geschreven wor-den, kunnen we precieze uitzonderingen implementeren, zelfs in een super-scalaire architectuur die de resultaten niet in de programmavolgorde berekent.We maken hierbij gebruik van een buffer, de reorder buffer (ROB) genaamd.

De decoder registreert de volgorde waarin hij de instructies verwerkt door voorelke instructie een plaats in de kop van het reorder buffer te reserveren. Vervol-gens worden de resultaten in de execute fase berekend. Door het parallellismein de execute fase van een superscalaire processor, zijn deze berekeningen nietlanger in de programmavolgorde voltooid. Wanneer een resultaat bekend is,wordt dit weggeschreven in de door de decoder in het ROB gereserveerdeplaats. Tevens wordt hier aangegeven dat het resultaat geldig is. Wat in hetROB zit, schuift telkens een plaats door. Na het doorschuiven, wordt gecon-troleerd of alle resultaten in de staart van het ROB geldig zijn. Indien datzo is, worden de resultaten weggeschreven naar het registerbestand. Indienze echter niet allemaal geldig zijn, wordt gewacht tot die resultaten door debetrokken functionele eenheden naar het ROB zijn weggeschreven. Op die ma-nier wordt dus telkens verzekerd dat de resultaten in de programmavolgordenaar het registerbestand worden weggeschreven.

Wanneer nu een uitzondering optreedt, wordt de inhoud van de ROB gene-geerd, en wordt de PC die overeenkomt met de eerste instructie in de staartvan het ROB gebruikt na het beeindigen van de afhandeling van de uitzonde-ringsroutine.

Bij het gebruik van een ROB moet zeer veel worden geforward. De resultatendie in het buffer zitten, kunnen immers nog als operand worden gebruikt doorvolgende instructies. De decoder moet dus telkens de bronregisters van elkeinstructie vergelijken met alle resultaatregisters in het ROB. Dit vraagt om


een complexe structuur van comparatoren. Hiervoor dient een intelligenteoplossing te worden gezocht.

Figuur 5.14: Gebruik van een reorder buffer.

2. History file Een oplossing die minder complexe forwarding vereist is het gebruikvan een history bestand (Ned. geschiedenisbestand). Bij het schrijven vandata naar het registerbestand worden de oude waarden van de te overschrijvenregisters opgeslagen in een FIFO buffer, de history file genaamd. Wanneer eenuitzondering optreedt, moeten alle waarden uit de history file terug naar hetregisterbestand worden geschreven.

Aangezien per klokcyclus slechts evenveel waarden uit de history file naar hetovereenkomstig register in het registerbestand kunnen worden geschreven als erschrijfpoorten aan dat registerbestand zijn, brengt dit veel overhead met zichmee. Bovendien moet het registerbestand meer leespoorten hebben, waardoorzijn omvang groeit. Echter vraagt een dergelijke implementatie minder hard-ware dan een reorder buffer, waardoor het toch een interessant alternatief is.

Figuur 5.15: Gebruik van een history file.

5.4 Geheugenstructuur 45

5.4 Geheugenstructuur

5.4.1 Lokaliteit

Het lokaliteitsbeginsel is een concept dat handelt over de statistische eigenschappenvan het meermaals bevragen van een enkele bron. Er zijn drie types te onderscheiden:

Lokaliteit in de tijd De kans is groot dat een bron die bevraagd wordt op eengegeven tijdstip, opnieuw zal worden bevraagd in de nabije toekomst.

Lokaliteit in de ruimte Het fenomeen dat het heel waarschijnlijk is dat data diewordt opgevraagd dicht bij recent opgevraagde data staat.

Sequentiele lokaliteit Het fenomeen dat veel data sequentieel wordt opgevragen.

5.4.2 Registerbestand

Een registerbestand is een verzameling registers die worden gebruikt als werkgeheu-gen. Een goede implementatie is belangrijk. Een registerbestand is dan ook vaakgeımplemteerd door middel van snel SRAM-geheugen met meerdere poorten. Hoedit geheugen is georganiseerd in een SPARC architectuur en hoe het wordt gebruiktwerd reeds beschreven in 5.3.2.

Leon3 en 3-poorts registerbestand

Leon3 heeft 1 instantie van de pijplijn. De instructies uit de SPARC instructiesetgebruiken maximaal twee operandi. Als beide operandi uit de registers moeten wor-den gehaald in de register access fase dan moet het registerbestand hierop voorzienzijn. Tevens moet het mogelijk zijn om op het einde van de pijplijn het resultaat wegte schrijven naar het doelregister in de writeback fase. Het registerbestand moet dustwee leespoorten en een schrijfpoort aanbieden. Er is een 3-poorts registerbestandvereist.

In een FPGA wordt echter enkel 2-poorts geheugen aangeboden. In de Leon3heeft men dan ook een manier gezocht om 3-poorts geheugen op te bouwen doorgebruik te maken van enkel 2-poorts geheugen. In het registerbestand plaatst mentwee geheugenblokken die even groot zijn en op elk moment exact dezelfde informatiebevatten. Bij het schrijven naar het registerbestand wordt dezelfde data in beidegeheugenblokken geschreven. Bij het lezen kan uit elk geheugenblok een ander woordworden opgevraagd.


Figuur 5.16: 3-poorts registerbestand

LeonS en 6-poorts registerbestand

Omdat de LeonS twee instructies per klokcyclus kan ophalen, heeft de LeonS tweekeer twee operandi nodig om goed te kunnen werken. Dit betekent dat vier regis-ters uit het registerbestand tegelijkertijd moeten kunnen gelezen worden. De tweeinstanties kunnen twee resultaten genereren die moeten worden opgeslagen in hetregister bestand. Hierdoor is het dus noodzakelijk dat er twee schrijfpoorten aan-wezig zijn. Het registerbestand voor de LeonS heeft dus vier leespoorten nodig entwee schrijfpoorten.

Het zespoorts registerbestand is opgebouwd uit twee driepoorts geheugens, eenmultiplexer en een DCM. Doordat er in feite 4 tweepoortsgeheugens worden ge-bruikt, kunnen vier woorden tegelijk worden opgevraagd. Om twee woorden weg tekunnen schrijven per klokcyclus wordt gebruik gemaakt van tijdsmultiplexing. Inhet eerste deel van de ingangsklokcyclus wordt het eerste woord weggeschreven naarhet SRAM-geheugen en in het tweede deel wordt het tweede woord geschreven. Omdit te bereiken is gebruik gemaakt van een DCM en een multiplexer. Op die manierbevatten beide driepoorts geheugens na elke klokcyclus de correcte data.


Figuur 5.17: 6-poorts registerbestand

5.4.3 Caches

Geheugenkloof en geheugenhierarchie

Een processor verdoet heel wat van zijn tijd met het wachten op data van hetgeheugen. Doordat de geheugentechnologie niet zo snel evolueert als processoren,worden de processoren alsmaar sneller ten opzichte van het geheugen. De klooftussen de snelheid van de processor en het geheugen wordt alsmaar breder. Om ditprobleem op te lossen, maakt men gebruik van caches. Dit zijn kleine maar snellegeheugens die reeds opgehaalde data bevatten. Het lokaliteitsbeginsel vertelt ons datde data die de processor nodig heeft zich vaak in de cache zal bevinden. Doordat decaches snel kunnen gelezen en geschreven worden moet de processor minder lang ophet geheugen wachten.

Caches in LeonS

Bij de overgang naar de LeonS is het noodzakelijk dat de prestaties van de cachesniet degraderen. Aangezien er slechts 1 load/store eenheid geımplementeerd is, kande datacache ongewijzigd gebruikt worden. De instructiecache moet in een multipleissue superscalaire pijplijn meerdere instructies tegelijk kunnen leveren. Dit vraagtom een aanpassing van de cache uit Leon3.

5.5 Opbouw pijplijn 48

Een eenvoudige implementatie maakt gebruik van een driepoorts geheugen ommeerdere leespoorten te realiseren, net als bij het registerbestand. Een groot nadeelvan deze aanpak is de verdubbeling van het benodigde SRAM geheugen om eenzelfde hoeveelheid instructies op te kunnen slaan. In moderne processoren wordengrote inspanningen gedaan om de oppervlakte die voorhanden is op de chip voorde cache zo groot mogelijk te maken. Een grotere cache kan namelijk de prestatiessterk verbeteren.

Het bedenken van een beter ontwerp van de caches voor LeonS is dan ook vanbelang. Een interessante eigenschap van het ophalen van instructies uit de cache ishet sequentiele karakter van de bevraagde adressen. Meestal moeten namelijk tweeinstructies worden opgehaald uit opeenvolgende adressen. We kunnen de cachelijnendie naar de cache worden weggeschreven opdelen in twee delen, en elk deel wegschrij-ven naar een apart geheugen. Deze twee geheugens kunnen worden opgebouwd uittweepoorts SRAM geheugen en kunnen dan ook twee leespoorten aanbieden. Wekunnen bijvoorbeeld de oneven adressen opslaan in het ene geheugen en de evenadressen in het andere. Door het sequentiele karakter van de op te halen adressen,is het ene adres meestal oneven terwijl het ander even is en kunnen beide geheugensaangesproken worden.

Indien tegelijk een instructie op een even en een oneven adres moeten wordenopgehaald, zal een structurele hazard ontstaan. Slechts 1 instructie zal dan kunnenworden opgehaald. In een superscalaire architectuur met n issues zullen de instruc-ties worden opgeslagen in n geheugens. Het correcte geheugen kan worden bepaalddoor een modulo n bewerking van het adres. Deze implementatie heeft het nadeeldat de doorstroming van instructies naar de pijplijn moeizamer zal verlopen doorde extra structurele hazards die worden geıntroduceerd.

Omwille van de korte ontwerptijd is enkel de cache met driepoortsgeheugen daad-werkelijk ontworpen. Het tweede ontwerp is slechts een voorstel.

5.5 Opbouw pijplijn

De logica die voor superscalaire werking moet worden toegevoegd aan de pijplijn,zorgt ervoor dat de decoder groeit. Dit deel van de pijplijn bevat het langste pad.Het toevoegen van functionaliteit aan de decoder zorgt dan ook voor het verlagen vande maximum haalbare klokfrequentie. Daarom is er voor gekozen de decoder op tesplitsen en het aantal delen van de pijplijn te verhogen tot 8 door een dispatcher fasetoe te voegen. De decoder is omgevormd tot een pre-decoder die reeds een gedeeltevan het decodeerwerk voor zijn rekening neemt. Het resultaat van deze pre-decoderwordt samen met de overeenkomstige instructie en programmateller opgeslagen inde instructiebuffer. Dit is een FIFO buffer met een configureerbare diepte van 2


Figuur 5.18: Blokschema pijplijn LeonS.


tot en met 16 lijnen. De dispatcher haalt deze resultaten, programmatellers eninstructies per twee uit de buffer, doet het resterende decodeerwerk en verdeelt deinstructies over de verschillende functionele eenheden. Hierbij worden de nodigecontroles uitgevoerd op eventuele hazards, uitzonderingen en fouten.

De instructiebuffer zorgt ervoor dat de nieuwe pijplijn in twee grote delen isopgesplitst:

• FE, DE

Het eerste deel, dat de decode en fetch fasen bevat, werkt aan het ritme vande instructiecache. Deze geeft aan wanneer de opgevraagde instructies be-schikbaar zijn. Pas dan zal de fetch nieuwe instructies opvragen en zal depre-decoder de beschikbare instructies decoderen en in de buffer plaatsen. Desnelheid van dit deel van de pijplijn is dus afhankelijk van het aantal cache-missers en dus ook van de cachegrootte.

• DI, RA, EX, ME, XC, WR

Het tweede deel bestaat uit de dispatch, register access, execute, memory,exception en writeback fasen. Het tempo van dit deel wordt bepaald doorde dispatcher. Een onderbreking kan optreden wanneer er geen instructiesmeer voorhanden zijn in de instructiebuffer, of wanneer onoplosbare hazardsof uitzonderingen gedetecteerd worden door de dispatcher. Wanneer deze on-derbrekingen kunnen optreden, staat omschreven in de secties 5.2 en 5.3.

Een gevolg van het gebruik van een instructiebuffer is dat de doorvoersnelheidvan de pijplijn stijgt. Wanneer de instructiebuffer namelijk voldoende gevuld is,zal de uitvoer van instructies in het tweede gedeelte van de pijplijn kunnen door-gaan, ondanks eventuele cachemissers. Wanneer geen cachemissers optreden, zalde instructiebuffer verder kunnen worden gevuld terwijl het tweede gedeelte van depijplijn onderbroken wordt.

Hoofdstuk 6

Besluit

Als we de titel van deze scriptie lezen zou men er van uit kunnen gaan dat degehele inspanning in het licht stond van het aanpassen van de softcore processorvoor superscalaire werking, echter niets is minder waar.

Het originele onderwerp was het onderzoeken en het implementeren van MORF.Een aanzienlijk deel van ons werk is dan ook te vinden in voorbereidend werk hiertoe.

Bij het ondezoek naar bestaande softcores was het duidelijk dat het implemen-tatie gedeelte van MORF niet bereikt zou kunnen worden.

Om het facinerende onderwerp MORF toch implementeerbaar te maken in detoekomst, hebben we ons verder werk gericht op het maken van een basis die voorMORF kan dienen. In het hoofdstuk softcores werd uiteengezet hoe we tot de keuzegekomen zijn en het is niet of moeilijk te zeggen of we door het maken van eenandere keuze, betere resultaten zouden zijn bekomen, al staat het wel vast dat hetandere resultaten zouden zijn.

Uit verschillende bronnen werd al spoedig duidelijk dat het implementeren vaneen superscalaire softcore processor erg veel werk vraagt. Jiri Gaisler, de ontwerpervan Leon3, voorspelde een volledige herziening van de pijplijn. Op de “FPGA CPU”site [6] werd de haalbaarheid van een implementatie een superscalaire processor opeen FPGA in vraag gesteld. Het onderzoek hiernaar leek ons dan ook een uitdaging.Op de geopperde problemen hebben we een antwoord geformuleerd.

Het aanpassen van de Leon3 tot superscalaire werking is gedeeltelijk succesvol,maar een complete implementatie werd niet gerealiseerd. Hiervoor was tijd een sterklimiterende factor.

Op dit moment zijn er een aantal broncodebomen aanwezig, elk met al delenvan een superscalaire processor geımplementeerd. De reeds geımplementeerde delenzijn allen ondergebracht op de meegeleverde CD-ROM, waarvan de inhoud wordtbeschreven in de bijlage C.

Het aanpassen van de processor is zeker en vast niet triviaal gebleken en niet enkel

52

door de complexiteit van een superscalaire processor. Extra inspanning is geleverdin het uitpluizen van de precieze werking van de pijplijn. Al is er documentatie overte vinden, deze is niet toerijkend om in een kleine tijdsspanne een goed inzicht tebieden in de code.

Om toch vooruit te geraken hebben we getracht de pijplijn tot op zekere hoogtete doorgronden en dit te documenteren zonder te beweren volledig te zijn. Dit istijdens verder werk aan de pijplijn van bijzonder nut gebleken. In deze scriptie werddeze informatie gebundeld in de bijlagen.

Bijlage A

Schema’s en structuur

A.1 Leon3

De pijplijn van Leon3 is volledig geımplementeerd in het VHDL bestand iu3.vhd.Deze bijlage poogt een overzicht te geven van zijn structuur en een beschrijving vande verschillende onderdelen.

A.1.1 Schema

Figuur A.1 geeft een schema van de pijplijn van de Leon3. Het schema toont dezeven stadia van de pijplijn, gescheiden door onderbroken lijnen en geıdentificeerddoor twee letters.[3]

FE de instruction fetch stageAls de instructie cache aanwezig is, wordt de instructie hieruit gehaald. An-ders wordt de ophaling overgelaten aan de geheugen controller. De opgehaaldeinstructie is geldig op het einde van deze stage en wordt gelatched in de pijp-lijnregisters.

DE de decode stageDe instructie wordt gedecodeerd en CALL en branch doeladressen gegenereerd.

RA de register access stageOperandi worden gelezen van het registerbestand of interne terugkoppelingvan data.

EX de execute stageAlu, logische en shift operaties worden uitgevoerd. Voor geheugen operatiesworden de adressen gegenereerd.

A.1 Leon3 54

ME de memory stageDe data cache wordt bevraagd en de data vanuit de execute stage wordt ge-schreven naar de data cache.

XC de exception stageTraps en interrupts worden afgehandeld. De data wordt goed gealigneerd bijcache bevragingen.

WR de write back stageHet resultaat van de ALU, logische-, shift-eenheid of cache operatie wordennaar het registerbestand geschreven.

Op de onderbroken lijnen bevinden zich kleine kadertjes. Deze kadertjes repre-senteren de verschillende pijplijn registers. De functie van deze verschillende registerswordt beschreven in de sectie “Pijplijn registers” A.1.2 op pagina 57.

Tussen de onderbroken lijnen bevindt zich de eigenlijke logica van elke stage. De-ze logica is in procedures en functies ondergebracht die onderling zijn geconnecteerd.De sectie “Pijplijn procedures en functies” A.1.3 op pagina 61 geeft een overzicht enbeschrijving van de verschillende procedures en functies in de pijplijn. De logischeblokken worden door middel van grotere kaders in het schema aangeduid. Elk kaderbevat de naam van de procedure of functie zoals in de broncode.

De lijnen tussen de verschillende pijplijn registers en de logische blokken in hetschema geven de interconnecties aan.

Het idee achter deze documentatie, ook al lijkt ze op het eerste zicht triviaal, isverder onderzoek op de pijplijn van de Leon3 te vergemakkelijken.

Het schema is zelf bijgevoegd op twee manieren. Enerzijds is het schemageıncorporeerd in de digitale versie en is volledig vectorieel. Hierdoor kan men bijhet raadplegen van de digitale versie heel sterk inzoomen. Omdat dit niet mogelijk isin de geprinte versie is er een uitvergroot schema meegebundeld op een gemakkelijkuitvouwbare manier.

A.1 Leon3 55

Figuur A.1: Leon3 pijplijn

A.1 Leon3 56

***schema***

A.1 Leon3 57

A.1.2 Registers van de pijplijn

De pijplijn bevat een groot aantal registers tussen de verscillende stages. Hierondergeven we een overzicht van alle pijplijnregisters met een korte omschrijving van hunfunctie.

In de broncode worden de registers per stage ondergebracht in een record.Er zijn dus zeven verschillende records elk met een naam van een letter. Voorde duidelijkheid geven we hier een mapping met de eerder gegeven namen:(f:FE,d:DE,a:RA,e:EX,m:ME,x:XC,w:WR).

Alle zeven de records worden op zich gebundeld in een record met als naam“registers”. De pijplijn heeft dus al zijn registers gebundeld in een signaal r van hettype registers.

Hieronder geven we een overzicht van de verschillende registers in de zeven ver-schillende records.

fetch stage registers

f.pc : program counterf.branch : branch address

decode stage registers

d.pc : program counterd.inst : instructiond.cwp : PSR CWP current window pointerd.set : indicates which instruction set out of array of

instruction setsd.mexc : memory exceptiond.cnt : counter

(is being used to implement general minor state machine)d.pv : used in combination with d.cntd.annul : annulate delayed slot instruction if branch

instruction was malpredictedd.inull : instruction nullify (is being assigned to ici.inull)d.step : being used by DEBUGUNIT, for stepping mode

register access stage registers

a.ctrl : pipeline controlea.rs1 : register address from instructiona.rfa1 : register file address 1a.rfa2 : register file address 2

A.1 Leon3 58

a.rsel1 : register select1 (input for op_mux multiplexer)a.rsel2 : register select2 (input for op_mux multiplexer)a.rfe1 : register file enable 1a.rfe2 : register file enalbe 2a.cwp : PSR CWP current window pointera.imm : immediate word for use by alua.ldcheck1 : generated by lock_gen but not used any further in iu3a.ldcheck2 : generated by lock_gen but not used any further in iu3a.ldchkra : load/icc interLock Detection RA stage,

generated by lock_gen, consumed by op_finda.ldchkex : load/icc interLock Detection EX stage,

generated by lock_gen, consumed by op_finda.su : PSR S supervisora.et : PSR ET enable trapsa.wovf : window overflow (wpr)a.wunf : window underflow (wpr)a.ticc : traps for ticc, TT_TICC (in ic_ctrl)

(when instruction is TICC and branch is set)a.jmpl : set if instruction is JMPL (in ic_ctrl)a.step : being used by DEBUGUNITa.mulstart : start multilya.divstart : start divide

execute stage registers

e.ctrl : pipeline controlee.op1 : (operand1)e.op2 : (operand2)e.aluop : alu operatione.alusel : alu result selecte.aluadd : is set as 1 for all operations safe for *SUB*e.alucin : alu carry ine.ldbp1 : generated by op_mux, used to multiplex between

sources for ex_op1 etc..e.ldbp2 : generated by op_mux, used to multiplex between

sources for ex_op2 etc..e.invop2 : invert op2e.shcnt : shift counte.sari : shift msbe.shleft : shift left/right

A.1 Leon3 59

e.ymsb : y (result register) msbe.rd : register destinatione.jmpl : jumpe.su : PSR S supervisore.et : PSR ET enable trapse.cwp : PSR CWP current window pointere.icc : PSR ICC integer condition codee.mulstep : multiply stepe.mul : multiply instructione.mac : multiply/accumulate

memory stage registers

m.ctrl : pipeline controlem.result : resultm.y : PSR Multiply/Devide registerm.icc : PSR ICC integer condition codem.nalign : memory not alignedm.dci : data cach inm.werr : write errorm.wcwp : write current window pointerm.irqen : irq enablem.irqen2 : irq enable 2m.mac : multiply accumulatem.divz : divide through zero

exception stage registers

x.ctrl : pipeline controlex.result : (result from alu & port)x.y : PSR Multiply/Devide register (result from mul/div)x.icc : PSR ICC integer conditio codex.annul_all: annuleer allx.data : datax.set : indicates which instruction set out of

array of instruction setsx.mexc : memory exceptionx.dci : data cache inputx.laddr : load addressx.rstate : run state

(run, trap, dsu1, dsu2, pwd1, pwd2, halt)

A.1 Leon3 60

x.npc : new program counterx.intack : used by irq unitsx.ipend : used by irq unitsx.mac : multiply accumulate?

writeback stage registers

w.s : special registerw.result : resultw.wa : write addressw.wreg : write register enabledw.except : exceptionw.trap : not used by iu3w.debug : not used by iu3

special registers

s.cwp : PSR CWP current window pointers.icc : PSR ICC integer condition codes

(PSR_negative n, PSR_zero z, PSR_overflow v, PSR_carry c)s.tt : TBR TT trap types.tba : TBR TBA trap base addresss.wim : WIM window invalid mask

(NWIM ==#windows holds valid bits for respective windows)s.pil : PSR PIL processor interrupt levels.ec : PSR EC enable coprocessors.ef : PSR EF enable floating point units.ps : PSR PS previous supervisor flags.s : PSR S supervisor flag (1==su, 0==user)s.et : PSR ET enable trapss.y : Multiply/Devide registers.asr18 : Ancillary state register

pipeline control registers

ctrl.pc : program counterctrl.inst : instructionctrl.cnt : counter

(is being used to implement general minor state machine)ctrl.rd : destination register?

A.1 Leon3 61

ctrl.tt : trap typectrl.trap : trapctrl.annul : annuleerctrl.wreg : write register enable

(determines if r.w.result should be written to reg file)ctrl.wicc : write integer condition codesctrl.wy : write mul/div?ctrl.ld : loadctrl.pv : -ctrl.rett : -

A.1.3 Pijplijn procedures en functies

In wat volgt geven we een overzicht van de verschillende procedures en functies,zoals gevonden in de broncode van de pijplijn. Elkeen is aangegeven door middelvan zijn naam en wordt gevolgd door een korte omschrijving van zijn functie als diegekend is.

Bij elke procedure geven we aan welke zijn ingangen en uitgangen zijn. Dit iseerder triviaal, maar is toch nuttig gebleken tijdens aanpassingen aan de pijplijn,simpelweg om dat de informatie gebundeld is.

Hetzelfde is gedaan met de verscillende functies, echter zijn de uitgangen danhier een enkel resultaat.

procedures

diagwr in

r : registers

dsur : dsu registers

ir : irestart register

dbg : l3 debug in type

wpr : watchpoint registers

out

s : special register type

vwpr : watchpoint registers

asi : std logic vector(7 downto 0)

pc : pctype

npc : pctype

A.1 Leon3 62

tbufcnt : std logic vector(TBUFBITS-1 downto 0)

wr : std ulogic

addr : std logic vector(9 downto 0)

data : word

tbufwr : std ulogic

fpcwr : std ulogic

diagread in

dbgi : l3 debug in type

r : registers


ir : irestart register


rfdata : std logic vector(31 downto 0)

dco : dcache out type

tbufo : tracebuf out type

out

data : word

itrace in

r : registers


vdsu : dsu registers

res : word

exc : std ulogic


error : std ulogic

wr : std ulogic

trap : std ulogic

out

tbufcnt : std logic vector(TBUFBITS-1 downto 0)

A.1 Leon3 63

di : tracebuf in type

dbg cache in

holdn :std ulogic


r : registers


mresult : word

dci : dc in type

out

mresult2 : word

dci2 : dc in type

fpexack in

r : registers

issue index : issue index type

out

fpexc : std ulogic

diagrdy determines wheter the diagnostic is ready to proceed, based on the debugunit(dsur) if it’s enabled(denable), the data and instruction cache and thememory data(dci and ico) strobe (mds) signal. in

denable : std ulogic


dci : dc in type

mds : std ulogic

ico : icache out type

out

crdy : std logic vector(2 downto 1)

regaddr calculate the absolute register file addres based on the relative address(reg) (address withing it’s window) and the current window pointer (cwp)in

A.1 Leon3 64

cwp : std logic vector

reg : std logic vector(4 downto 0)

out

rao : rfatype

su et select detect RETT instruction in the pipeline and set the local psr.su andpsr.etin

r : registers

xc ps : std ulogic

xc s : std ulogic

xc et : std ulogic

out

su : std ulogic

et : std ulogic

exception detect checks for illegal and privileged instructions a detection is beingsignaled by (trap) and it’s type is giving by (tt)in

r : registers



trapin : std ulogic

ttin : std logic vector(5 downto 0)

out

trap : std ulogic

tt : std logic vector(5 downto 0)

wicc y gen write instruction condition codes and y, using an instruction as input,the icc are written into (wicc) and the extended part of an operand (the MSBof a double word) in (wy)in

inst : word

A.1 Leon3 65

out

wicc : std ulogic

wy : std ulogic

cwp gen generates current window pointer, based on the current state of the re-gisters(r,v), the annulate (annull) and write cwp signals (wcwp) and the newcurrent window pointer(ncwp)in

r : registers

v : registers

annul : std ulogic

wcwp : std ulogic

ncwp : cwptype

out

cwp : cwptype

cwp ex generates the current window pointer write signal based on the currentregisters(r). The write signal is set for certain instructions and the used in-struction is the one out of the execute stage.in

r : in registers

out

wcwp : std ulogic

cwp ctrl generate next current window pointer(de cwp)& window under- and over-flow (wovf exc & wunf exc) traps as also the write current window pointer sig-nal (wcwp). The outputs are based on certain types of instructions in (inst).De calculated new cwp and the write signal are used by cwp gen.in

r : registers

xc wim : std logic vector(NWIN-1 downto 0)

inst : word

out

A.1 Leon3 66

de cwp : cwptype

wovf exc : std ulogic

wunf exc : std ulogic

wcwp : std ulogic

rs1 gen generates relative registerfile read address 1, based on the current regis-ters(r) and the instruction (inst) issued. This procedure is connected to re-gaddr.in

r : registers

inst : word

out

rs1 : std logic vector(4 downto 0)

lock gen loadicc interlock detection, based on the relative register addresses (rs2and rd) and the absolute ones (rfa1, rfa2, rfrd), the instruction and the floatingpoint, multiplier and divider (fpc lock, mulinsn, divinsn) units. The outputsignals (lldchkra and lldchkex) are used by op find.in

r : registers


rd : std logic vector(4 downto 0)

rfa1 : rfatype

rfa2 : rfatype

rfrd : rfatype

inst : word

fpc lock : std ulogic

mulinsn : std ulogic

divinsn : std ulogic

out

lldcheck1 : std ulogic

lldcheck2 : std ulogic

lldlock : std ulogic

A.1 Leon3 67

lldchkra : std ulogic

lldchkex : std ulogic

fpbranch detects branch in floating point unitin

inst : word

fcc : std logic vector(1 downto 0)

out

branch : std ulogic

ic ctrl controls signals depending on the type of instuction issued(inst), loadlock(ldlock) and branches. The produced signals will control how the piplinewill behave on a high level. For example starting the multiplier unit, etc..in

r : registers

inst : word

annul all : std ulogic

ldlock : std ulogic

branch true : std ulogic

fbranch true : std ulogic

cbranch true : std ulogic

fccv : std ulogic

cccv : std ulogic

out

cnt : std logic vector(1 downto 0)

de pc : pctype

de branch : std ulogic

ctrl annul : std ulogic

de annul : std ulogic

jmpl inst : std ulogic

inull : std ulogic

de pv : std ulogic

A.1 Leon3 68

ctrl pv : std ulogic

de hold pc : std ulogic

ticc exception : std ulogic

rett inst : std ulogic

mulstart : std ulogic

divstart : std ulogic

rd gen generation of the destination relative register address(rdo), based on thecurrent registers (r) and the instruction(inst). The write register signal(wreg)is also generated as well as the load(ld) signal which determines the differcebetween a load and a store in a LDST instruction. The calculated registeraddress(rdo) is send to regaddr.in

r : registers

inst : word

out

wreg : std ulogic

ld : std ulogic

rdo : std logic vector(4 downto 0)

alu op sets all signals for the execution unit to operate properly for the re-quested instruction. The calculated operands (aop1,aop2) are calculated be-fore they are send to op mux, (shcnt,sari,shleft) are signals determining howthe shift unit should behave, (aluop,aluadd) determine the alu’s behavior.(mulins,divins,macins) signal instructions for the multiplier, divider and macunit. (ymsb) tells, the extended part should be used, (invop2) indicate thatoperand 2 should be inverted before used. Because all operations are executedin parallell even if they aren’t used, the result of all will be multiplexed byalu select and controlled by the multiplexer signal (alusel).in

r : in registers

iop1 : word

iop2 : word

me icc : std logic vector(3 downto 0)

my : std ulogic

A.1 Leon3 69

ldbp : std ulogic

out

aop1 : word

aop2 : word

aluop : std logic vector(2 downto 0)

alusel : std logic vector(1 downto 0)

aluadd : std ulogic

shcnt : std logic vector(4 downto 0)

sari : std ulogic

shleft : std ulogic

ymsb : std ulogic

mulins : std ulogic

divins : std ulogic

mulstep : std ulogic

macins : std ulogic

ldbp2 : std ulogic

invop2 : std ulogic

op mux operandi multiplexer, switches between possible inputs such as de register-filedata (rfd), immediate data(im), forwarded data out of the pipeline stages(ed,md,xd) or the calculated operandi in the register access stage. The selec-tion is done by the rsel signal. The calculated operand is offered to alu op.in

r : registers

rfd : word

ed : word

md : word

xd : word

im : word

rsel : std logic vector(2 downto 0)

out

ldbp : std ulogic

A.1 Leon3 70

d : word

op find op find is the last part of the operand address creation in the decode stage.op find uses the lock signals(ldchkra, ldchkex) created by lock gen and therelative addresses. Most important it gnerates the multiplexer signal(osel) forthe op mux multiplers. in

r : registers

ldchkra : std ulogic

ldchkex : std ulogic


ra : rfatype

im : boolean

out

rfe : std ulogic

osel : std logic vector(2 downto 0)

cin gen generate carry-in for aluin

r : registers

me cin : in std ulogic

out

cin : std ulogic

logic op performs the logic operation part of the alu, it’s inputs are created byalu op. The result is brought to the result multiplexer alu sel.in

r : registers

aluop :std logic vector(2 downto 0)

xy : word

my : word

aluin1 : word

aluin2 : word

mey : word

A.1 Leon3 71

ymsb : std ulogic

out

logicres : word

y : word

misc op performs the miscelanous operation part of the alu, it’s inputs are createdby alu op. The result is brouht to the result multiplexer alu sel.in

r : registers

aluop :std logic vector(2 downto 0)


aluin1 : word

aluin2 : word

ldata : word

mey : word

out

mout : word

edata : word

alu select multiplexer between all the possible results from the alu, generatedby misc op, logic op and shift. The multiplexing signal(alusel) is created byalu op.in

r : registers

alusel : std logic vector(1 downto 0)

addout : std logic vector(32 downto 0)

op1 : word

op2 : word

shiftout : word

logicout : word

miscout : word

out

A.1 Leon3 72

res : word

me icc : std logic vector(3 downto 0)

icco : std logic vector(3 downto 0)

divz : std ulogic

dcache gen mainly determines the data size to be used in the data cache, basedon the issued instruction. in

r : registers

v : registers

out

dci : dc in type

link pc : std ulogic

jump : std ulogic

force a2 : std ulogic

load : std ulogic

fpstdata serves as a simple multiplexer, which chooses between normal data andthe floating point data when the floating-point unit is selected and such aninstruction is issued. in

r : registers

edata : word

eres : word

fpstdata : std logic vector(31 downto 0)

out

edata2 : word

eres2 : word

mem trap in

r : registers


annul : std ulogic

holdn : std ulogic

A.1 Leon3 73

out

trapout : std ulogic

iflush : std ulogic

nullify : std ulogic

werrout : std ulogic

tt : std logic vector(5 downto 0)

irq trap in

r : registers

ir : in irestart register

irl : in std logic vector(3 downto 0)

annul : in std ulogic

pv : in std ulogic

trap : in std ulogic

tt : in std logic vector(5 downto 0)

nullify : in std ulogic

out

irqen : std ulogic

irqen2 : std ulogic

nullify2 : std ulogic

trap2 : std ulogic

ipend : std ulogic

tt2 : std logic vector(5 downto 0)

sp write write special registersin

r : registers


out

s : special register type

vwpr : watchpoint registers

A.1 Leon3 74

mul res when the instruction issued is a mac,div or mul instruction, the result isfetched from the respective unit and signaled throug(result). The extendedMSB part is placed in(y) and the integer condition codes written to (icc).in

r : registers

asr18in : word

out

result : word

y : word

asr18 : word

icc : std logic vector(3 downto 0)

functies

dbgexc detects exception state from the debug unit when the debug unit is presentand enabledin

r : registers


trap : std ulogic

tt : std logic vector(7 downto 0))

returnstd ulogic

dbgerr detects error state from the debug unit when the debug unit is present andenabledin

r : registers


tt : std logic vector(7 downto 0))

returnstd ulogic

asr17 gen in

A.1 Leon3 75

r : registers

returnword

branch address calculates the branch address, based on the current instructi-on(inst) and the current program counter (pc). It’s result is offered to amultiplexer deciding the next new porgram counter.in

inst : word

pc : pctype

returnstd logic vector

branch true detects branch condition from the issued instruction(inst) and theinteger condition codes. The result is giving to the ic ctrl.in

icc : std logic vector(3 downto 0)

inst : word

returnstd ulogic

wphit detect watchpoint trapin

r : registers


debug : l3 debug in type

returnstd ulogic

shift 32-bit shifter part of the alu. it’s inputs are set by alu op. (shleft) determineswheter shifting is to the left or the right, (shiftcnt) gives the number of posi-tions to shift and (sari) states wheter the shift is logic or arithmeticin

aluin1 : word

aluin2 : word

A.1 Leon3 76

shleft : std ulogic

shiftcnt : std logic vector(4 downto 0)

sari : std ulogic

returnword

imm data immediate data generation. Simply gets the immediate part out of theissued instruction(inst). The result is given through registers to op mux forthe second operand.in

r : registers

inst : word)

returnword

get spr read special registersin

r : registers

returnword

imm select works together with imm data. Simply signals wheter the instructionissued uses immediate data. The signal is brought to op find who will use thisinformation to decide how multiplexing should be done.in

inst : word

returnboolean

ra inull gen in

v : registers

returnstd ulogic

ld align detects memory not alligned issuesin

A.1 Leon3 77

data : dcdtype

set : std logic vector(DSETMSB downto 0)

size : std logic vector(1 downto 0)

laddr : std logic vector(1 downto 0)

signed : std ulogic

returnword

npc find find next program counterin

r : registersr

returnstd logic vector

npc gen generate next program counterin

r : registers

returnword

powerdwn generate power down signal, based on a powerdown trapin

r : registers

trap : std ulogic

returnstd ulogic

A.1.4 Connectie

Bij werk aan de pijplijn is het nuttig om de context van bepaalde VHDL code teweten.

De softcore processor wordt samengesteld in een ontwerp specifiek bestand, indeze thesis is dat het leon3mp.vhd bestand. Deze entiteit kan men gebruiken in eentestbench of bij synthese. Figuur A.2 geeft de topdown afdaling weer in de VHDLentiteiten. Alle weergegeven namen zijn de VHDL bestandsnamen zonder de vhd

A.1 Leon3 78

leon3mp-|-leon3-

|-leon3s-

|-proc-

|-iu3

Figuur A.2: Leon3 top down to the iu

extentie. Let op dat leon3mp te vinden is in grlib/design/leon3mp, waar de anderebestanden allen te vinden zijn binnen grlib/lib/gaisler/leon3.

Hieronder geven we een beschrijving van de generics en poorten van de pijplijnzoals die geconnecteerd worden vanuit proc.vhd.

Generics

Algemeen beschrijft elke window een configuratie optie van de Leon3 op een hoogniveau. De integer range geeft de mogelijkheden weer en het getal op het einde dedefault optie als er niets wordt opgegeven vanuit proc.vhd.

nwin : integer range 2 to 32 := 8: number of register file windows

isets : integer range 1 to 4 := 1: number of instruction sets out of instruction cache

dsets : integer range 1 to 4 := 1: number of data sets out of data cache

fpu : integer range 0 to 2 := 0: floatig point unit type (0 - no fpu)

v8 : integer range 0 to 2 := 0: generate SPARC V8 MUL and DIV instructions

cp : integer range 0 to 1 := 0: existence of co-processor unit

mac : integer range 0 to 1 := 0: existence of MAC unit

dsu : integer range 0 to 1 := 0: existence of debug unit

nwp : integer range 0 to 4 := 0: number of watchpoints

A.1 Leon3 79

pclow : integer range 0 to 2 := 2: generate lower bits of program counter

notag : integer range 0 to 1 := 0: not used

index : integer range 0 to 15:= 0: identifies the processor in a multi processor configuration

lddel : integer range 1 to 2 := 2: load delay

irfwt : integer range 0 to 1 := 0: -

disas : integer range 0 to 1 := 0: print instruction disassembly in VHDL simulator

tbuf : integer range 0 to 64 := 0: trace buf size in kB (0 - no trace buffer)

pwd : integer range 0 to 2 := 0: power-down. 0 - disabled, 1 - area efficient, 2 - timing efficient.

svt : integer range 0 to 1 := 0: single-vector trapping

rstaddr : integer := 16#00000#: reset vector MSB address

Poorten

De verschillende in en uitgangen van de pijplijn (in en uit) geven de richting aan voorde pijplijn. De naamgeving van de verschillende delen hebben een (i of o) extentieom aan te geven of het om een ingang of uitgang type gaat. Voor gewone signalendie eindigen op n wil dit zeggen dat het omgekeerde logica is.

clk : in std_ulogic: clock input

rstn : in std_ulogic: reset signal

holdn : in std_ulogic: external signal to hold the pipeline

ici : out icache_in_type: instruction cache interface

ico : in icache_out_type: instruction cache interface

dci : out dcache_in_type: data cache interface

dco : in dcache_out_type

A.2 LeonS 80

: data cache interfacerfi : out iregfile_in_type

: 3p register file interfacerfo : in iregfile_out_type

: 3p register file interfaceirqi : in l3_irq_in_type

: interrupt request unit interfaceirqo : out l3_irq_out_type

: interrupt request unit interfacedbgi : in l3_debug_in_type

: debug unit interfacedbgo : out l3_debug_out_type

: debug unit interfacemuli : out mul32_in_type

: multiplier unit interfacemulo : in mul32_out_type

: multiplier unit intefacedivi : out div32_in_type

: divider unit interfacedivo : in div32_out_type

: devider unit interfacefpo : in fpc_out_type

: floating point unit interfacefpi : out fpc_in_type

: floating point unit interfacecpo : in fpc_out_type

: co-processor unit interfacecpi : out fpc_in_type

: co-processor unit interfacetbo : in tracebuf_out_type

: trace buffer unit interfacetbi : out tracebuf_in_type

: trace buffer unit interface

A.2 LeonS

LeonS is de superscalaire versie van de Leon3 in wording. Omdat er vertrokken isvan de pijplijn van Leon3 zijn er erg veel gelijkenissen tussen de twee. Daarom wordthieronder een overzicht gegeven van de aanpassingen.

Let op dat er niet een enkele boom van de broncode van de LeonS is. Omdat

A.2 LeonS 81

de LeonS nog in de maak is bestaat ze uit een vijftal verschillende codebomen. Deverschillende bomen zijn allen opgenomen op de CD en worden beschreven in bijlageC.

De aanpassingen hieronder zijn dan ook niet te vinden in alle verschillende delen.Zo zou het duidelijk moeten zijn dat de uitbreiding met dispatcher enkel te vindenis in die code waar effectief een dispatcher is aan toegevoegd.

Het moet ook nog vermeld worden dat de aanpassingen hieronder enkel in grotelijnen weergeven wat er anders is ten op zichte van wat we hierboven gedocumenteerdhebben van de Leon3. Er zijn nog tal van andere zaken die zijn aangepast, waaronderbijvoorbeeld de instructe cache en het register bestand. Beschrijvingen hiervan zijnte vinden in het hoofdstuk “Superscalairiteit en LeonS”, maar de code zelf vormthier ook een ideale bron van informatie.

A.2.1 Pijplijn structuur

De pijplijn bevat een extra stage:

DI de dispatcher stageInstructies geplaatst in de instructiebuffer worden hier uitgehaald op een on-afhankelijk ritme en worden verdeeld (dispatched) over de verschillende func-tionele eenheden.

A.2.2 Registers van de pijplijn

De extra stage introduceert een nieuw register record. Deze record heeft de naam igekregen naar analogie met de andere namen.

i.ctrl : pipeline controlei.rs1 : register address from instructioni.rfa1 : register file address 1i.rfa2 : register file address 2i.rsel1 : register select1 (input for op_mux multiplexer)i.rsel2 : register select2 (input for op_mux multiplexer)i.rfe1 : register file enable 1i.rfe2 : register file enalbe 2i.cwp : PSR CWP current window pointeri.imm : immediate word for use by alui.ldcheck1 : generated by lock_gen but not used any further in iu3i.ldcheck2 : generated by lock_gen but not used any further in iu3i.ldchkra : load/icc interLock Detection RA stage,

generated by lock_gen, consumed by op_find

A.2 LeonS 82

i.ldchkex : load/icc interLock Detection EX stage,generated by lock_gen, consumed by op_find

i.su : PSR S supervisori.et : PSR ET enable trapsi.wovf : window overflow (wpr)i.wunf : window underflow (wpr)i.ticc : traps for ticc, TT_TICC (in ic_ctrl)

(when instruction is TICC and branch is set)i.jmpl : set if instruction is JMPL (in ic_ctrl)i.step : being used by DEBUGUNITi.mulstart : start multilyi.divstart : start divide

Het beeld zoals hierboven is zoals de extra registers zijn toegevoegd in de origineleprocessor. In de dubbele issue processor zijn alle pijplijnregisters opgevat als arrays.Hiervoor zijn array typen aangemaakt voor alle mogelijke originele types bij depijplijnregisters.

Het gebruik van een array laat toe om zelfs meer dan twee issues te maken, doorsimpelweg de diepte van de array aan te passen. Het maken van deze stap vroegongelooflijk veel werkuren.

A.2.3 Connectie van de pijplijn

Ook bij de connectie van de pijplijn zijn enkele kleine toevoegginen.

Generics

Issues, bevat het nummer van de pijplijn issues. Tot op heden is dit enkel ge-test tot twee issues, maar het zou moeten meeschalen. Dit echter alleen voor depijplijn registers, de logische blokken en functionele eenheden zijn niet schaalbaargeımplementeerd. Ook de dispatcher moet er aan aangepast worden.

issues : integer range 0 to 4 := 1: number of pipeline issues

Poorten

Rf2 is toegevoegd aan de poorten van de pijplijn. Dit is de interface van het nieuwezespoorts registerbestand. Het originele registerbestand is nog steeds aanwezig inde pijplijn. Dit was tijdens de ontwikkeling nodig, maar wordt niet langer gebruikten kan verwijderd worden.

A.2 LeonS 83

rf2i : out iregfile2_in_type: 6p register file interface

rf2o : in iregfile2_out_type: 6p register file interface

A.2.4 Pijplijn procedures en functies

Alle procedures en functies zijn uitgebreid met een extra input (index), daar waaralle registers als input worden meegegeven. Dit om een onderscheid te kunnen makenbinnenin de procedure of functie van welke issue de registers gebruikt moeten worden.

Een andere manier is naar de procedures en functies enkel die signalen te latenlopen die echt worden gebruikt. In de Leon3 en tot op heden in de LeonS wordenheel veel connecties gelegd die niet worden gebruikt.

Bijlage B

Gaisler, grlib en Leon3

B.1 Gaisler

Gaisler Research [10] is een Zweeds bedrijf opgericht door Jiri Gaisler. Het bedrijflevert producten en oplossingen op het gebied van IP core ontwerp en SOC ontwerp.

Gaisler heeft GRLIB en de LEON processoren in het leven geroepen. Hiernaastbiedt Gaisler nog een breed gamma van producten en diensten aan, zoals ondermeer:

• VHDL-gebaseerd ASIC en FPGA ontwerp

• Cross-compilatie systemen en waretijds kernels

• Hoge prestatie simulatoren

• FPGA en ASIC ontwikkelingsborden

• CCSDS/AOS en afstandsgestuurde systemen

• Fout-tolerant computerontwerp

B.2 Grlib

De GRLIB[4] IP bibliotheek is een geıntegreerde set van herbruikbare IP cores, spe-ciaal ontworpen voor system-on-a-chip (SOC) ontwerp. De IP cores zijn verbondenmet een centrale gemeenschappelijke on-chip bus en gebruiken een coherente me-thode bij simulatie en synthese. De biblioteek wordt ondersteund door verschillendeCAD tools en technologieen. De verschillende IP cores kunnen op een plug&playmanier verbonden worden.

De bibliotheek heeft cores voor AMBA AHB/APB controle, de LEON3 SPARCprocessor, 32-bit PC133 SDRAM controllers, 32-bit PCI brug met DMA, 10/100

B.3 Leon3 85

Mbit ethernet MAC, 8/16/32-bit prom en sram controller, CAN controller, TAPcontroller, UART with FIFO, modulaire timer unit, interrupt controller en een 32-bit GPIO poort. Geheugen en pad generators zijn beschikbaar voor Virage, Xilinx,UMC, Atmel, Altera en Actel technologieen.

De bibliotheek heeft een GNU GPL licentie.Bij de start van de thesis was grlib-beta-0.15 te downloaden. Tijdens het aan-

passen van de softcore werd grlib-beta-0.16 ter beschikking gesteld en hebben wedaar mee verder gewerkt. Inmiddels bij het schrijven van deze tekst is grlib-eval-1.0te downloaden van de Gaisler site[10]. Deze is voor de volledigheid ook op de cdgebundeld, maar hier is nog geen werk op verricht al zou dit volgens de changelogniet veel werk vergen.

B.3 Leon3

De LEON3 is een synthetiseerbaar VHDL model van een 32-bit processor comform deSPARC V8 architectuur. Het model is uitermate configureerbaar en heel toepasbaarvoor system-on-a-chip (SOC) ontwerp. De volledige broncode is te verkrijgen met deGNU GPL licentie, wat vrij en ongelimiteerd gebruik voor onderzoek en onderwijstoelaat.

De LEON3 heeft de volgende eigenschappen:

• SPARC V8 instructie set met V8e extenties

• Geavanceerde 7 stadia lange pijplijn

• Hardware vermenigvuldiger, deler en MAC eenheid.

• Hoog performante, volledige gepijplijnde IEEE-754 FPU

• Gescheidden instructie- en datacache (Harvard architectuur)

• Configureerbare caches: 1 - 4 sets, 1 - 256 kbytes/set. Willekeurig, LRR orLRU vervang algoritmen.

• SPARC Referentie MMU (SRMMU) met configureerbare TLB

• AMBA-2.0 AHB bus interface

• Geavanceerde on-chip debug support met instructie en data volg buffer

• Multi-processor support (SMP)

• Power-down modus

B.4 Bestandsstructuur 86

• Robuuste en volledig synchrone enkele flank klok ontwerp

• tot 125 MHz in FPGA en 400 MHz op 0.13 um ASIC technologieen

• Uitermate configureerbaar

• Grote verscheidenheid aan software tools: compilers, kernen, simulatoren endebug monitoren

Figuur B.1 geeft een blokschema van de Leon3 op hoog niveau. De figuur toonteen aantal van Leon3 zijn componenten. Delen zoals de MAC, MUL, FPU en der-gelijke kunnen al dan niet aanwezig zijn naar gelang van de gekozen opties.

Figuur B.1: Leon3 blokschema

B.4 Bestandsstructuur

Omdat de GRLIB biblioteek heel wat IP cores ter beschikking heeft en we in dezethesis eigenlijk enkel op de Leon3 softcore processor willen verder werken, wordt


hieronder een overzicht gegeven van de directory structuur van GRLIB en aangeduidwelke delen relevant zijn.

Tevens werd aangeduid welke bestanden werden onderzocht en aangepasts.

B.4.1 Verduidelijking

bin -verschillende scripts en tools-

boards -support bestanden voor verschillende FPGA test borden-

designs -voorbeeld ontwerpen-In de designs map zijn een aantal ontwerpen te vinden, voor het aanpassenvan de Leon3 naar een softcore voor superscalaire werking zijn we vertrokkenvan de leon3mp design.

doc -informatie over de infrastructuur van grlib-

lib -VHDL bibliotheken en hun documentatie-Lib bestaat uit een hele reeks verschillende bibliotheek mappen, elk verderonderverdeeld in categorieen.

Degene van belang voor deze thesis is de bibliotheek van Gaisler en dan in hetbijzonder de categorie Leon3 en Memory.

netlists -fabrikant specifieke netlijsten-

software -software hulpprogrammas en testbanken-

B.4.2 Overzicht

De root map is hieronder aangeduid als grlib, zoals eerder gezegd gebruiken wegrlib-beta-0.16. De mapstructuur bij de andere versies is nagenoeg hetzelfde.

Een map wordt aangeduid door een minteken of een plussteken aan het einde.Bij een plus kan er verder worden afgedaald in de hierarchie, bij een min is de mapal geexpandeerd. Drie puntjes tonen aan dat er zich nog andere items bevindenbinnen die map, maar dat ze niet relevant zijn. Bestanden die werden aangepast oftoegevoegd werden respectievelijk aangeduid.


grlib-|-bin+|-boards+|-designs-| |-...| |-leon3mp+| |-...||-doc+|-lib-| |-contrib+| |-esa+| |-fpu+| |-gaisler-| | |-ambatest+| | |-arith+| | |-devices+| | |-doc+| | |-jtag+| | |-leon3-| | | |-acache.vhd| | | |-cachemem.vhd (aangepast)| | | |-cache.vhd| | | |-dcache.vhd| | | |-dsu3.vhd| | | |-grfpcw.vhd| | | |-icache.vhd (aangepast)| | | |-irqmp.in| | | |-irqmp.vhd| | | |-iu3.vhd (aangepast)| | | |-leon3.in| | | |-leon3s.vhd| | | |-leon3.vhd| | | |-libcache.vhd (aangepast)| | | |-libiu.vhd (aangepast)| | | |-libmmu.vhd| | | |-libproc.vhd (aangepast)| | | |-mfpcw.vhd| | | |-mmu_acache.vhd| | | |-mmu_cache.vhd


| | | |-mmuconfig.vhd| | | |-mmu_dcache.vhd| | | |-mmu_icache.vhd| | | |-mmuiface.vhd| | | |-mmulrue.vhd| | | |-mmulru.vhd| | | |-mmutlbcam.vhd| | | |-mmutlb.vhd| | | |-mmutw.vhd| | | |-mmu.vhd| | | |-proc3.vhd (aangepast)| | | |-tbufmem.vhd| | | |-vhdlsyn.txt| | | |-memctrl| | || | |-memory-| | | |-mem_actel_gen.vhd| | | |-mem_actel.vhd| | | |-mem_gen_gen.vhd| | | |-mem_gen.vhd| | | |-memory.vhd| | | |-mem_umc_gen.vhd| | | |-mem_umc.vhd| | | |-mem_virage_gen.vhd| | | |-mem_virage.vhd| | | |-mem_xilinx_gen.vhd| | | |-mem_xilinx.vhd| | | |-regfile_3p.vhd| | | |-regfile_6p.vhd (toegevoegd)| | | |-syncram_2p.vhd| | | |-syncram_dp.vhd| | | |-syncram.vhd| | | |-vhdlsyn.txt| | || | |-misc+| | |-net+| | |-pads+| | |-pci+| | |-sim+| | |-uart+


| | |-gleichman+| | |-grlib+| | |-micron+| | |-openchip+| | |-opencores+| | |-tech+| | |-tmtc+| | |-work+| || |-...|||-netlists+|-software+

Bijlage C

Inhoud CD

Bij dit boek is een CD gebundeld, met alle relevante informatie.Hieronder volgt een overzicht van wat er zich zoal op de CD bevindt.Alle presentaties en alle tekeningen zijn gemaakt met OpenOffice 2.0beta en zijn

ook in dat formaat aanwezig op de CD.

boek Deze scriptie is meegeleverd op de CD. De scriptie is meegegeven in pdf en texformaat alsook de gebruikte figuren en zijn ondergebracht in respectievelijkemappen.

doc Bevat wat relevante informatie en het schema van de Leon3 pijplijn in pdfformaat en het originele corel draw bestand.

presentaties Alle gegeven presentaties doorheen de thesis zijn gebundeld in dezemap. Elke submap heeft een map pdf en een map files, waar respectievelijk deeigenlijke presentatie is in terug te vinden en de originele werk bestanden.

processors Hier bevinden zich zowel de onderzochte processoren als de herwerkte,buiten de MicroBlaze.

De processoren zijn ondergebracht in vier submappen, STM, DLX, Leon3 enLeonS met gelijkaardige opbouw.

Zowel Leon3 en LeonS zijn nog verder onderverdeeld om de verschillende ver-sies te onderscheiden.

Bij elke processor is de volledige mapstructuur geplaatst als zowel een verpakteversie als tarball. Het eerste om eenvoudig op de CD te kunnen navigeren, hettweede om gemakkelijk te verspreiden.

Figuur C.1 geeft een overzicht van de hierarchische opbouw van de CD.

92

cd-|-boek-| |-figuren+| |-pdf+| |-tex+||-doc-| |-sparc-| | |-SparcV8.pdf| | |-UltraSparc.pdf| || |-schema+||-presentaties-| |-presentatie+| |-proefpresentatie1+| |-proefpresentatie2+||-processors-

|-DLX+|-Leon3-| |-grlib-beta-0.16+| |-grlib-eval-1.0+||-LeonS-| |-grlib-0.16-2instructions+| |-grlib-0.16-2issues+| |-grlib-0.16-disp-2instr+| |-grlib-0.16-disp-2instr-bis+| |-grlib-0.16-dispatcher+||-STM-

|-stm-1.1+|-stm-1.2+

Figuur C.1: cd map structuur

C.1 Leon3 93

C.1 Leon3

Bij de Leon3 zijn twee broncodebomen meegegeven. Aanvankelijk zijn we gestartmet de grlib bibliotheek V0.15, waarna het geevolueerd is tot V0.16. Hier hebbenwe de overstap gemaakt. Tijdens het schrijven van dit werk is de evaluatieversieV1.0 van grlib op het net verschenen. Voor volledigheid is deze dus ook opgenomen.

C.2 STM

Net zoals bij de Leon3 heeft de STM gedurende het thesisonderzoek vooruitganggeboekt. V1.2 is dan ook mee opgenomen op de CD, omdat de STM misschien welhernieuwde aandacht verdient.

C.3 LeonS

LeonS is de map waar zich het werk bevindt van de aanpassingen tot het bekomenvan een superscalaire softcore.

Er zijn vijf verschillende versies te vinden. Deze versies zijn niet allen opeenvol-gende versies. Een heel deel is ontwikkeld in parallel.

Alle delen zijn zo ontworpen zodanig dat de processor blijft lopen. Er is eendeel functionaliteit toegevoegd die er transparant is tussengevoegd of er in parallellnaast geplaatst is met alle mogelijke conflicten opgelost zodanig dat het origineledeel blijft werken.

Alle delen zijn geımplementeerd op zulk een wijze dat er niet te veel overlap-pende delen zijn zodanig dat op dat vlak geen extra problemen optreden bij hetsamenvoegen.

grlib-0.16-2instructions Deze processor werkt met een enkelvoudige pijplijn maarheeft al een uitbreiding zodanig dat twee instructies uit de instructie cacheworden opgehaald en in respectievelijke registers worden geplaatst. De voor-naamste aanpassingen zijn te vinden in de instructie cache.

grlib-0.16-dispatcher Deze processor heeft transparant een extra dispatcher stagetussengevoegd gekregen. De pijplijn is dus 8 stages diep en werkt nog perfect.Extra pijplijn registers werden op analoge wijze met de bestaande bijgevoegden extra controle en logica werd toegevoegd om de pijplijn werkende te houden.

grlib-0.16-disp-2instr Deze processor is een combinatie van de twee voorgaande.Het is de eerste Leon3 variant met 8 pijplijn stages en twee instructies in depijplijn.

C.3 LeonS 94

grlib-0.16-disp-2instr-bis Deze processor is gebaseerd op de voorgaande en isnog een werk in uitvoering. Aan de voordien quasie lege dispatcher stage isnu logica toegevoegd die nodig is in een superscalaire processor. Een volledi-ge werkende instructiebuffer werd geımplementeerd. Er werd gestart met deimplementatie van het eigenlijke dispatchen, maar dit werkt nog niet.

grlib-0.16-2issues Deze processor heeft twee instanties in zijn pijplijn. Bijna allepijplijn registers en logische blokken werden geımplementeerd aan de hand vanarrays om het aantal instanties gemakkelijk te kunnen bepalen. Maar er werdmaar afgewerkt naar twee. De twee instanties kunnen volledig onafhankelijkvan elkaar werken en instructies verwerken. Een belangrijke extra aanpassingbuiten de pijplijn zelf, is gebeurd aan het registerbestand.

De grlib-0.16-2issues processor vormt de basis voor de LeonS. De andere deelprocessoren moeten stelselmatig worden toegevoegd tot een geheel. De eerste stapmet het invoegen van de grlib-0.16-2instructions is reeds succesvol voltooid. Degrlib-0.16-2issues is dus meer dan wat de naam doet vermoeden: twee instructieskunnen worden opgehaald en volledig parallel worden afgewerkt. De eerstvolgendebelangrijke stap is het tussenvoegen van de dispatcher stage. Eenmaal dat succesvol,kan de eigenlijke dispatching code worden toegevoegd.

Index

afhaneklijkheden, 27ASIC, 5, 16

bitstream, 5, 12

cache, 47CISC, 17CLB, 17CPLD, 19

data-afhankelijkheden, 27DLX, 19dynamische herconfiguratie, 10

FPGA, 2, 5, 16, 19

geheugenhiearchie, 47geheugenkloof, 47

HDL, 16herconfiguratie, 10History file, 44

Leon3, 20lokaliteit, 45lokaliteitsbeginsel, 45

MicroBlaze, 19MORF, 2, 16, 17, 21

parallellisme, 23partiele herconfiguratie, 10PCB, 16pijplijn, 23

RAR, 27RAW, 27Registerbestand, 45Reorder buffer, 43RISC, 17RTL, 19

SCVE, 12softcore, 16SPARC, 20STM, 18superscalair, 17

VHDL, 6virtex, 19

WAR, 27WAW, 27

Xilinx, 19

Bibliografie

[1] Microblaze soft processor core. http://www.xilinx.com/ipcenter/processor_central/microblaze/, WWW.

[2] John Hennessy en David Patterson. Computer architecture a quantitative ap-proach. Morgan Kaufman, 1996.

[3] Jiri Gaisler. Gaisler research ip core’s manual. file://.../grlib/lib/gaisler/doc/grip.pdf, WWW.

[4] Jiri Gaisler. Grlib ip library. http://www.gaisler.com/products/grlib/grlib.html, WWW.

[5] Jiri Gaisler. Leon3 sparc v8 processor. http://www.gaisler.com/products/leon3/leon3.html, WWW.

[6] Jan Gray. Superscalar fpga cpu design. http://www.fpgacpu.org/usenet/superscalar.html, WWW.

[7] Joachim Horch. A superscalar version of the dlx processor. http://www.rs.e-technik.tu-darmstadt.de/TUD/res/dlxdocu/SuperscalarDLX.html,WWW.

[8] Eiki Ito. Stm - a free microprocessor. http://www.asahi-net.or.jp/~uf8e-itu/, WWW.

[9] j. Xilinx. http://www.xilinx.com/, WWW.

[10] Gaisler Research. Jiri gaisler. http://www.gaisler.com/, WWW.

[11] M. Vasilko. Dynamically reconfigurable hardware www library. http://dec.bournemouth.ac.uk/drhw_lib/, WWW.

http://www.xilinx.com/ipcenter/processor_central/microblaze/

http://www.xilinx.com/ipcenter/processor_central/microblaze/

http://www.gaisler.com/products/grlib/grlib.html

http://www.gaisler.com/products/grlib/grlib.html

http://www.gaisler.com/products/leon3/leon3.html

http://www.gaisler.com/products/leon3/leon3.html

http://www.fpgacpu.org/usenet/superscalar.html

http://www.fpgacpu.org/usenet/superscalar.html

http://www.rs.e-technik.tu-darmstadt.de/TUD/res/dlxdocu/SuperscalarDLX.html

http://www.rs.e-technik.tu-darmstadt.de/TUD/res/dlxdocu/SuperscalarDLX.html

http://www.asahi-net.or.jp/~uf8e-itu/

http://www.asahi-net.or.jp/~uf8e-itu/

http://www.xilinx.com/

http://www.gaisler.com/

http://dec.bournemouth.ac.uk/drhw_lib/

http://dec.bournemouth.ac.uk/drhw_lib/

Aanpassen processorkern voor superscalaire werking, ter ...

Documents

Transcript of Aanpassen processorkern voor superscalaire werking, ter ...