Promotor: prof. dr. ir. Dirk Stroobandt Begeleiders: ir. Karel Bruneel, Fatma Mostafa Mohamed Ahmed Abouelella

Transcriptie

1 Herconfiguratie van LUT s via hun schuifregisterfunctionaliteit Brahim Al Farisi Promotor: prof. dr. ir. Dirk Stroobandt Begeleiders: ir. Karel Bruneel, Fatma Mostafa Mohamed Ahmed Abouelella Masterproef ingediend tot het behalen van de academische graad van Master in de ingenieurswetenschappen: computerwetenschappen Vakgroep Elektronica en informatiesystemen Voorzitter: prof. dr. ir. Jan Van Campenhout Faculteit Ingenieurswetenschappen Academiejaar

2 DANKWOORD ii Dankwoord Er zijn veel mensen die ik hoor te bedanken. Voor diegenen die ik hier niet vermeld: dank u! Ik bedank eerst en vooral mijn begeleider Karel voor zijn begeleiding, ideëen en sugesties. Wanneer ik ergens vastzat kon ik altijd bij u terecht. Ook mijn andere begeleiders Fatma en Harald en mijn promotor Prof. Stroobandt hebben me altijd bijgestaan met raad en daad, waarvoor dank! Ook wil ik Tom bedanken uit wiens thesis ik inspiratie heb kunnen opdoen om me in het begin van schrijfproces op gang te trekken. Ondanks de zeer interessante leesvoer die ik ze verschaft heb, bedank ik Karel, Harald (nogmaals) en Michiel om mijn thesis na te lezen. Dank u voor alle suggesties en ideëen! Ook wil ik al mijn vrienden bedanken voor hun steun door de jaren heen: Jorre, Tom, Bas, Jasper, Yannick, Sander, Michiel, Matias, Karim, Alex, Mouctar en Peet. Ook mag ik hier Daan en Stan niet vergeten voor hun tips en steun doorheen mijn gehele studieloopbaan. Zonder hen zou ik misschien niet tot aan de thesis geraakt zijn. Tenslotte vind ik dat ik mijn gehele familie bij naam moet bedanken. Mijn ouders en mijn broers en zussen: Saida, Mohamed, Yahya, Ali, Yamina, Ahmed en Naima. Ook mijn neven en nichten mogen in deze lijst niet ontbreken: Mohamed, Yassinne, Abdellah, Fatima Zohra, Mohamed Amin, Youssef en Hajar. Ze hebben mij doorheen mijn studies blijven steunen en daarvoor ben ik ze voor altijd dank verschuldigd. Brahim Al Farisi, augustus 2009

3 TOELATING TOT BRUIKLEEN iii Toelating tot bruikleen De auteur geeft de toelating deze scriptie voor consultatie beschikbaar te stellen en delen van de scriptie te kopiëren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze scriptie. Brahim Al Farisi, augustus 2009

4 Herconfiguratie van LUT s via hun schuifregisterfunctionaliteit door Brahim Al Farisi Masterproef ingediend tot het behalen van de academische graad van Master in de ingenieurswetenschappen: Computerwetenschappen Academiejaar Promotoren: Prof. Dr. Ir. D. Stroobandt Scriptiebegeleiders: Ir. K. Bruneel, F. Abouelella, Dr. Ir. H. Devos Faculteit Ingenieurswetenschappen Universiteit Gent Vakgroep Elektronica en informatiesystemen Voorzitter: Prof. Dr. Ir. J. Van Campenhout Samenvatting Onlangs werd aan de onderzoeksgroep PARIS een techniek ontwikkeld die op generieke wijze kwaliteitsvolle run-time herconfigureerbare (RTR) ontwerpen genereert met vaste routering. Enkel een deel van de LUT s moet run-time geherconfigureerd worden. Herconfiguratie van deze LUT s aan de hand van de herconfiguratie interface aangeboden door de FPGA fabrikant, de ICAP, is dan inefficiënt. Deze herschrijft namelijk een heel blok van configuratiebits tegelijk en dus ook veel data die niet verandert. In dit werk instantiëren we deze LUT s als LUT s met schuifregisterfunctionaliteit en verbinden we deze met scanpaden. De herconfiguratiebits kunnen dan via deze scanpaden ingeschoven worden. We onderzoeken de impact op het RTR ontwerp van het aantal scanpaden en de volgorde van de LUT s in de scanpaden. Trefwoorden FPGA, Run-Time Herconfiguratie, Parametriseerbare configuraties, schuifregisterfunctionaliteit van LUT s, SRL, HWICAP

5 Reconfiguring LUTs at run-time using their shiftregister functionality Brahim Al Farisi Supervisor(s): Dirk Stroobandt, Karel Bruneel, Fatma Abouelella, Harald Devos Abstract The technique of parametrizable configurations is a generic method for creating qualitative Run-Time Reconfigurable (RTR) applications with fixed routing. This opens the possibility for reconfiguring the runtime reconfigurable LUTs using their shiftregister functionality instead of using the ICAP. This speeds up the reconfiguration procedure significantly. Keywords FPGA, Run-Time Reconfiguration, parameterizable configurations, shiftregister functionality of LUTs, HWICAP I. INTRODUCTION THE technique of parametrizable configurations is a generic method for creating RTR designs at a higher abstraction level. It was developed within the research group PARIS at the University of Ghent[1]. It allows to create qualitative RTR implementations with fixed routing where a part of the LUTs, called TLUTs (Tunable LUTs), have to be reconfigured at runtime. The toolflow implementing parametrizable configurations uses the HWICAP (Hardware Internal Configuration Access Port) for the reconfiguration procedure. The shiftregister functionality of LUTs is a feature introduced by Xilinx that allows to instantiate a LUT as a shiftregister, which is called SRL (Shiftregister LUT). It is primarily used in signal processing applications for implementing shiftregisters. The aim of this work is to implement the reconfiguration procedure using the shiftregister functionality of LUTs. We do this by instantiating the TLUTs as SRLs and connecting them forming a bigger shiftregister which we call a scanpath. We compare this method with the reconfiguration procedure using the HW- ICAP. The impact on the RTR design of the number of scanpaths and the order in which the TLUTs are placed in the scanpaths is also analyzed. II. PARAMETRIZABLE CONFIGURATIONS Parametrizable configurations takes as a starting point the slowly varying signals in a design. These are called parameters. The hardware which takes these parameters as input is most of the time inactive, making the hardware inefficient. A toolflow, called TMAP, is developed to solve this problem using RTR. In a VHDL description of the design the slowly varying signals are denoted by the designer. The TMAP toolflow then generates a Master configuration and a set of Boolean function called Tuning functions. The Master configuration consists of a LUT circuit where some of the LUTs, called TLUTs, have to be reconfigured at run-time. The Tuning functions express how the truth tables of the TLUTs have to be changed when the parameters change. The routing is thus fixed. In the current implementation of the toolflow on the Xilinx Virtex2 Pro platform (using XPS) the tuning functions are evaluated using the embedded PPC. A partial reconfiguraton bitstream is generated and sent over the OPB bus to the HWICAP, which is used to reconfigure the TLUTs. This is inefficient since the HWICAP always reconfigures a group of configuration bits, called a frame, at once. This makes that a lot of unchanged configuration bits are overwritten with the same value. The partial configuration bitstream that the HWICAP uses also contains padding frames containing no information at all. III. RECONFIGURATION USING THE SHIFTREGISTER FUNCTIONALITY OF LUTS A LUT on a Virtex2 Pro FPGA can also be instantiated as a shift register. The SRAM cells that make up the truth table of the LUT are then interconnected and a shift in and shift out is provided, creating a 16-bit shiftregister (for a 4-input LUT). Longer shiftregister can be created by connecting the shift out of a LUT with the shift in of another LUT. It is important to note that an SRL still has the functionality of a LUT. By putting an address on the inputs the corresponding value in the truthtable is put on the output of the LUT. We implemented the reconfiguration of the TLUTs as follows. The TLUTs are instantiated as SRLs and their shift ins and shift outs are interconnected to create one scanpath which consist of the truth tables of the TLUTs. The shift in of the first SRL in the scanpath is connected to a self written piece of hardware called HWSRL. When the parameters change the PPC sends the evaluated Tuning functions, over the PLB bus, to the HWSRL, which is responsible for shifting the data in. We note that the HWSRL is connected to the PLB bus, which is faster than the OPB bus. The HWSRL contains a FIFO with different read and write clock, so the data can be shifted in at a clock rate different from the PLB clock. IV. RESULTS A. Comparison of the reconfiguration speed of the HWSRL and HWICAP We measured the time necessary to reconfigure a 32-TAP FIR filter with 768 TLUTs sending the reconfiguration data from the PPC. This time does not include the evaluation of the Tuning functions. For these measurements the reconfiguration data is available in the RAM of the PPC. In the case of the HWICAP the FIR filter was clocked at an OPB clock of 66 MHz. For the HWSRL this was a PLB clock of 100 MHz. The HWSRL shifted in the bits at a clock rate of 200 MHz. The HWICAP always works at 66 MHz. In the case of the HWICAP the TLUTs are placed in as less frames as possible, while still reaching a 66 MHz constraint. We also calculated the theoretical time necessary to reconfigure if the reconfiguration data would be available

6 on the FPGA. The results are shown in table I. TABLE I COMPARISON HWICAP AND HWSRL. HWICAP HWSRL With communication PPC 1600 µs 116 µs Without communication PPC 150 µs µs When communicating with the PPC the method using the HWSRL is more than 10 times better than the method using the HWICAP. In this case most of the reconfiguration time consists of sending the configuration data. Like we mentioned before the HWICAP uses a partial configuration bitstream with a lot of overhead, consisting of padding frames and LUTs which are overwritten with the same data. In the case of the HWSRL only the configuration bits of the TLUTs have to be sent. We can calculate the time it takes to reconfigure the FIR filter without communicating with the PPC, when the reconfiguration data would for example be available in a RAM block on the FPGA. For the HWSRL we know how many configuration bits have to be shifted in, since we know the number of TLUTs. Since we use a clock of 200 MHz to shift the data in, we know that every 5 ns a bit is shifted in. For the HWICAP we use the size of the partial reconfiguration bitstream since we know the HWICAP can process it byte wise at a clock rate of 66 MHz. Using this information we see that the reconfiguration using the HWSRL is more than two times faster. We also note that this is the reconfiguration time using only one serial scanpath. We could easily adjust the HWSRL to use more scanpaths and shift in the bits in parallel. B. Influence of the scanpath architecture on the RTR design It is very important to note that extra logic is introduced when using scanpaths to reconfigure, so there is a hardware cost, primarily routing, associated with their use. This is not the case with the HWICAP. Furthermore there will also be an influence on the RTR design. Adding scanpaths could for example cause routing congestion. We therefore analyzed if there is a difference between random scanpaths, where the TLUTs are placed in the scanpaths in a random way, and better chosen scanpaths. We studied the influence on the maximum clock frequency and hardware cost (number of slices and number of nets) of the FIR filter and the clock frequency of the scanpath. As a measure for the number of nets we took the number of unrouted nets in phase 1 of routing. In our case the better chosen scanpath was created ad hoc. It follows the structure of the FIR filter so that related logic is close to each other in the scanpaths. We also looked at the influence of the amount of logic on the FPGA and the number of scanpaths. We did this by implementing a 32-TAP, a 64-TAP and a 128-TAP FIR filter which were reconfigured with 1, 2, 4, 8, 16 or 32 scanpaths. These are only theoretical experiments since the FIR filters are implemented separately, without the HWSRL, PLB or the PPC. The results are very clear. Random scanpaths use more resources, operate at a lower clock rate and affect the maximum clock frequency more than the ad hoc constructed scanpaths. The difference becomes bigger when more logic on the FPGA is implemented. Finally the results indicate that adding scanpaths is cheap and hardly affects the maximum clock frequency, especially when not a lot of logic is implemented on the FPGA. Though these first results clearly indicate that one must choose the scanpaths wisely, more benchmarks have to be studied to gain insight in how the scanpaths effect the RTR design. C. Addressing the Xilinx tools When using the Xilinx tools to reconfigure LUTs using their shiftregister functionality we have to bare in mind that these were intended as regular shiftregisters. The synthesis reports for example indicate that the gate delay of the SRL is bigger than the gate delay of a LUT. This is normal since the tools think that during operation bits can be shifted in and these have to be available the next clock cycle. This is not the case in the way we are using the SRLs. During operation no bits are shifted in and the SRLs are used as normal LUTs. It is only when the LUTs are reconfigured that bits are shifted in. When placing and routing the design, the tool tries to globally optimize both the scanpath clock and the design clock, which results in inferior results. We therefore give the design clock a much higher priority than the scanpath clock. The design then easily meets its constraint of 100 MHz, while a scanpath clock of 200 MHz is possible. V. CONCLUSIONS In this work we showed that reconfiguration using the shiftregister functionality of LUTs is possible and can replace the HWICAP in the generic TMAP toolflow. This method is much more efficient in terms of reconfiguration speed. Though the scanpaths introduced in the design can affect it aversively, choosing the scanpaths wisely can minimize these effects. When using the Xilinx tools, special care has to be taken. Using constraints, one must indicate that during operation the SRLs are used as regular LUTs. VI. FUTURE WORK The current way of RTR design uses the hardware resources only for the RTR implementation and does the reconfiguration through an (external or internal) port to the configuration memory. We envision a new type of generic RTR design, where the hardware resources are shared between the RTR implementation and a specialized circuit that is responsible for the reconfiguration. Not only scanpaths for shifting in the configuration data are considered, hardware resources can also be used for generating the reconfiguration data. ACKNOWLEDGEMENTS The author would like to acknowledge the ideas and suggestions of Karel Bruneel, Harald Devos, Fatma Abouelella and Dirk Stroobandt. REFERENCES [1] Karel Bruneel, Dirk Sroobandt, Reconfigurability-aware structural mapping for LUT-based FPGA s, International Conference on Reconfigurable Computing and FPGAs, pp , 2008.

7 INHOUDSOPGAVE vii Inhoudsopgave Dankwoord Toelating tot bruikleen Overzicht Extended abstract Inhoudsopgave Gebruikte afkortingen ii iii iv v vii ix 1 Inleiding Probleemstelling Doelstelling Structuur Run-time herconfiguratie Basisconcepten FPGA Werking Toolflow Het herconfiguratieproces Run-time herconfiguratie (RTR) Klassieke methodes voor run-time-herconfiguratie Onderzoek naar het efficiënt run-time genereren van configuraties Parametriseerbare configuraties Inleiding Het automatisch genereren van parametriseerbare configuraties Theoretische resultaten Experimentele resultaten Proefopstelling

8 INHOUDSOPGAVE viii Resultaten Theoretische ondergrens Gebruik van de schuifregisterfunctionaliteit van LUT s voor run-time herconfiguratie Literatuurstudie De SRL16 component Beperkingen en mogelijkheden Aanpassing toolflow en architectuur Herconfiguratie van TLUT s aan de hand van de SRLC16E component Aanpassingen aan de TMAP-toolflow Ontwerp van de HWSRL Vergelijking met de HWICAP implementatie Een eerste analyse Afwegingen bij het ontwerp van de scanpadarchitectuur Proefopzet Genereren van randomscanpaden Onderzochte aspecten van het ontwerp Analyse van de resultaten Invloed op het aantal slices en netten Invloed op maximale klokfrequentie Invloed op de kloksnelheid van het scanpad Conclusies en Toekomstig werk Conclusies Toekomstig werk Methodologie om scanpaden aan te maken aan de hand van Xilinx tools Theoretische exploratie A Standaardafwijkingen van de willekeurige scanpaden 75 Bibliografie 77 Lijst van figuren 80 Lijst van tabellen 82

9 GEBRUIKTE AFKORTINGEN ix Gebruikte afkortingen ASIC CLB CM DAG FF FPGA FSM HDL HWICAP ICAP LUT MUX OPB PAR PLA PLB PPC RAM RTR SRL TIG Application-Specific Integrated Circuit Configurable Logic Block Configuration Manager Directed Acyclic Graph Flip-Flop Field Programmable Gate Array Finite State Machine Hardware Description Language HardwareICAP Internal Configuration Access Port Lookup Table Multiplexer On-Chip Peripheral Bus Placement And Routing Programmable Logic Array Processor Local Bus PowerPC Random Access Memory Run-Time Reconfiguration Shiftregister LUT Timing Specification Ignore

10 GEBRUIKTE AFKORTINGEN x TLUT V2Pro Tunable LUT Virtex 2 Pro

11 INLEIDING 1 Hoofdstuk 1 Inleiding Run-time herconfiguratie of Run-Time Reconfiguration (RTR) is een relatief recent onderzoeksdomein in de hardware wereld en wordt nu reeds toegepast bij FPGA s. Hierbij beschouwt men hardware niet langer als statisch, maar eerder als iets dynamisch, dat zich tijdens de werking kan aanpassen aan het probleem. Door de hardware telkens te specialiseren, kan men efficiënter gebruik maken van de hardware-middelen. We denken hierbij aan prestatiematen zoals snelheid, oppervlakte en vermogenverbuik. Er zijn 2 belangrijke aspecten bij RTR. De frequentie van het herconfigureren en de kosten om te herconfigureren (herconfiguratietijd, vermogen,...). Als we veel middelen nodig hebben, zullen we trachten niet al te vaak te herconfgureren, anders wordt de winst die gemaakt wordt door RTR genihilleerd, hetgeen voor veel toepassingen momenteel het geval is. Doordat het herconfiguratieproces veel tijd in beslag neemt is RTR enkel bruikbaar voor toepassingen waarbij het probleem niet al te vaak verandert. We kunnen het ook anders bekijken. Als we het herconfiguratieproces efficiënter maken, wordt RTR bruikbaar voor een breder veld van toepassingen. Het is net dit dat we pogen te doen in deze scriptie. De herconfiguratie via de interfaces voorzien door de FPGAfabrikant is niet altijd even efficiënt in termen van snelheid en vermogen. Momenteel is het bijvoorbeeld vaak zo dat ook configuratiedata die niet verandert herschreven wordt. We willen dit vermijden door gebruik te maken van een techniek die initieel bedoeld was voor signaalverwerkingstoepassingen, namelijk de schuifregisterfunctionaliteit van LUT s. Enkel de herconfiguratiedata wordt hierbij in de schuifregisters opgenomen. Zo krijgen we een eenvoudig, gespecialiseerd circuit dat de herconfiguratie op zich neemt en los staat van de herconfiguratieinterface en praktische beperkingen hiervan.

12 1.1 Probleemstelling 2 We willen hierbij meer specifiek onderzoeken wat de voor- en nadelen zijn van het gebruik van deze herconfiguratieschuifregisters, vergeleken met meer traditionele herconfiguratiemechanismen. Ook zoeken we naar een efficiënte manier om deze schuifregisters te introduceren. Er wordt onderzocht wat de impact is van de volgorde waarin de configuratiedata in het schuifregister wordt geplaatst. We doen dit aan de hand van een specifieke toepassing: een FIR-filter. Ten slotte vermelden we hier een ander belangrijk aspect, namelijk het ontwerp van RTRtoepassingen. Doordat dit vaak op laag niveau gebeurt, gaat dit gepaard met een hoge ontwerpskost. De techniek van parametriseerbare configuraties is hier een oplossing voor. Het brengt de ontwerpsbeslissingen nodig voor RTR-toepassingen naar een hoger abstractieniveau, waarna het enkel nog noodzakelijk is veranderingen aan te brengen in een textuele beschrijving van de hardware. De techniek werd ontwikkeld door Karel Bruneel binnen de onderzoeksgroep PARIS van de vakgroep ELIS aan de Uniersiteit van Gent. Deze werd geïntegreerd in de standaardtools voor FPGA-ontwerp en werd TMAP genoemd. Het is met deze tool dat we het herconfiguratieproces aan de hand van schuifregisters gaan integreren. Kort samengevat zullen we het herconfiguratieproces dat momenteel gebeurt aan de hand van een interface van de FPGA-fabrikant vervangen door één aan de hand van schuifregisters. 1.1 Probleemstelling Het herconfiguratieproces via de interface voorzien door de FPGA fabrikant verloopt niet altijd even efficiënt in termen van snelheid en vermogen. Het komt bijvoorbeeld vaak voor dat ook configuratiedata herschreven moet worden die niet verandert. Ook zijn er praktische beperkingen verbonden aan de herconfiguratieinterface op zich, zoals bvb. de kloksnelheid waaraan deze werkt. 1.2 Doelstelling Het einddoel van deze scriptie is het herconfigureren van de FPGA aan de hand van de schuifregisterfunctionaliteit van de LUT s. In deze schuifregisters wordt enkel de herconfiguratiedata opgenomen. Hierbij willen we onderzoeken wat het effect is van het aantal scanpaden en de volgorde waarin de configuratiedata in de schuifregisters is opgenomen.

13 1.3 Structuur 3 Hierbij wordt vooral de maximale kloksnelheid onderzocht die het ontwerp kan halen. We doen dit aan de hand van een voorbeeldtoepassing, namelijk een FIR-filter. 1.3 Structuur In hoofdstuk 2 en 3 wordt het algemeen kader geschetst van deze thesis. Hoofdstuk 2 behandelt run-time herconfiguratie in het algemeen en hoofdstuk 3 bespreekt de techniek van parametriseerbare configuraties voor het automatisch genereren van RTR-toepassingen. Hoofdstuk 4 gaat dieper in op het gebruik van de schuifregisterfunctionaliteit van LUT s voor herconfiguratie. Hier komt een literatuurstudie aan bod over onderzoek dat hieromtrent reeds gebeurd is. Ook wordt het herconfigureren aan de hand van schuifregisters vergeleken met het herconfigureren aan de hand de van de herconfiguratieinterface aangeboden door de FPGA-fabrikant, de zogenaamde ICAP. Hoofdstuk 5 bevat de aanpassingen die gedaan zijn geweest aan de huidige toolflow om het herconfigureren aan de hand van schuifregisters toe te laten. Ook wordt de nieuwe implementatie vergeleken met de versie met de ICAP. In hoofdstuk 6 onderzoeken we de impact van het aantal scanpaden en de volgorde van de configuratiedata in de schuifregisters. Hoofdstuk 7 sluit het geheel af met de conclusies die uit deze thesis kunnen getrokken worden. Ook wordt hier besproken welk toekomstig werk mogelijk is in dit gebied.

14 RUN-TIME HERCONFIGURATIE 4 Hoofdstuk 2 Run-time herconfiguratie Deze scriptie kadert in het onderzoek naar run-time herconfiguratie van FPGA s (Field Programmable Gate Array). Wat dit inhoudt, leggen we uit in 2.2. Eerst zullen we snel een aantal noodzakelijke basisconcepten overlopen. 2.1 Basisconcepten FPGA FPGA s vormen een type van herconfigureerbare hardware. Dit houdt in dat men op een FPGA chip de mogelijkheid voorziet om de geïmplementeerde logica aan te passen. Dit staat tegenover een ASIC, wat staat voor Application-Specific Integrated Circuit, waar we de geïmplementeerde logica niet meer kunnen veranderen. Als men bijvoorbeeld een mp3-speler implementeert op een ASIC dan kan deze achteraf niet aangepast worden. Bij een FPGA gaat dit wel. Men zou bijvoorbeeld kunnen beslissen om de FPGA later als video-speler te gebruiken. We werken in deze scriptie met een Virtex 2 Pro FPGA (V2Pro) van Xilinx. Onderstaande uitleg en afbeeldingen horen dan ook bij de V2Pro. We werken met de 30 versie van de V2Pro reeks, dit betekent dat de FPGA ongeveer LUT s bevat Werking Centraal in de werking van een FPGA staat het concept van een LUT of K-LUT. Dit staat voor Lookup Table en is een basiselement dat bestaat uit 2 K SRAM geheugencellen en een multiplexer(mux) met K selectie inputs. De waarden opgeslagen in de SRAM geheugen-

15 2.1 Basisconcepten FPGA 5 cellen worden de configuratiebits van de K-LUT genoemd. LUT s worden voorzien van een geheugenelement van 1 bit of flip-flop (FF). Zo kan men een LUT van een "geklokte" uitgang voorzien. Dit maakt sequentiële logica mogelijk, i.e. logica waarvan de toestand synchroon met een bepaalde klok verandert. De combinatie van een LUT en een FF wordt een Logic Cell genoemd. In figuur 2.1(b) wordt een Logic Cell afgebeeld met daarin een 3-LUT. In de meeste FPGA s wordt gebruik gemaakt van 4-LUT s. Door het gebruik van een MUX kan men de FF ook afzonderlijk gebruiken en niet enkel als geheugenelement voor de uitgang van de LUT. De selectie-ingang van deze MUX wordt ook in een SRAM geheugencel opgeslagen. Men kan eenvoudig zien dat een K-LUT een willekeurige boolese functie met K inputs en 1 output kan implementeren. Men stelt hiervoor de waarheidstabel op en slaat deze op in de geheugencellen van de LUT. In figuur 2.1(a) wordt een voorbeeld weergegeven van een logische functie met bijhorende waarheidstabel. a bc y (a) (b) Figuur 2.1: Een logische functie en bijhorende 3-LUT Aangezien FPGA s veelvuldig in signaalverwerkingstoepassingen gebruikt worden is er nood aan een efficiënte implementatie van schuifregisters. Men wil vermijden daarvoor FF s van verschillende Logic Cells te gebruiken. Daarom heeft FPGA-fabrikant Xilinx de

16 2.1 Basisconcepten FPGA 6 functionaliteit van een LUT uitgebreid, zodanig dat men deze kan configureren als een schuifregister (SR). Een 3-LUT kan dan een 8-bit schuifregister implementeren. In figuur 2.2(a) wordt dit afgebeeld. Men kan in hedendaagse FPGA s de 4-LUT s ook configureren als een 16x1 RAM geheugen. Dit is in deze scriptie minder belangrijk. In figuur 2.2(b) wordt de veelzijdigheid van een Logic Cell geïllustreerd. SHIFT IN SHIFT OUT (a) (b) Figuur 2.2: De veelzijdigheid van een Logic Cell geïllustreerd. In de FPGA s van Xilinx worden de Logic Cells per 2 gegroepeerd, dit noemt men een slice. De bovenste LUT in een slice noemt men een G-LUT, de onderste een F-LUT. Bovendien worden slices per 4 gegroepeerd, dit noemt men een CLB (Configurable Logic Block). In figuur 2.3 wordt een CLB afgebeeld. In een FPGA zijn de CLB s georganiseerd in een matrix - FPGA staat dan ook voor Field Programmable Gate Array. In figuur 2.4 wordt een voorbeeld weergegeven van een FPGA met 4 CLB s. We merken nogmaals op dat bovenstaande uitleg en afbeeldingen horen bij de V2Pro. Het aantal LUT s in een slice en het aantal slices in een CLB is in feite architectuurafhankelijk. Tussen de LUT s is configureerbare routering aanwezig. Door een SRAM geheugencel te verbinden met een doorlaattransistor kunnen we verbindingen maken of verbreken. Een 1 schrijven naar de geheugencel betekent dat de verbinding gelegd wordt, bij een 0 wordt geen

17 2.1 Basisconcepten FPGA 7 Figuur 2.3: CLB van een Virtex 2 Pro FPGA. Figuur 2.4: Een FPGA met 4 CLB s. verbinding gelegd. Dit wordt afgebeeld op figuur 2.5. De configureerbare routering bepaalt hoe de LUT s verbonden zijn met elkaar. De routering is net als de logische elementen hiërarchisch opgebouwd, van korte lokale verbindingen, tussen de slices van een CLB, tot lange globale lijnen, die van het ene uiteinde van de FPGA tot het andere lopen. Figuur 2.6 geeft dit weer. De configuratiebits van de LUT s, de selectie-ingangen van de MUX s en de configureerbare routering maken deel uit van het configuratiegeheugen van de FPGA. Een FPGA is dus generieke hardware die de gebruiker na aankoop kan programmeren om een bepaalde functie uit te voeren. Figuur 2.8 geeft reeds een beeld van hoe de te implementeren logica op de LUT s en routering wordt afgebeeld. De uiteindelijke programmering gebeurt door de SRAM geheugencellen in het configuratiegeheugen te schrijven. Zo programmeert men de LUT s en de routering tussen deze LUT s. Dit proces wordt in meer detail uitgewerkt in sectie

18 2.1 Basisconcepten FPGA 8 Figuur 2.5: Principe van configureerbare routering. Het configuratiegeheugen bevat nog andere data die hier niet besproken werd. Dit komt ondermeer doordat hedendaagse FPGA s gespecialiseerde stukken hardware bevatten zoals o.a. RAM-blokken, vermenigvuldigers en carry chains die een efficiënte optelling toelaten. De V2Pro bevat zelfs 2 ingebedde PowerPC s (PPC s). De figuren in dit onderdeel werden gehaald uit [1] en [2] Toolflow De standaard toolflow voor implementaties op een FPGA wordt schematisch weergegeven in figuur 2.7. Deze vertrekt van een HDL (Hardware Description Language) beschrijving van een digitale toepassing (bijvoorbeeld VHDL) en heeft als resultaat een configuratiebitstroom. De configuratiebitstroom bevat instructies die voor de herconfiguratie interface bedoeld zijn, samen met de configuratiedata die in het configuratiegeheugen moet komen. De eerste stap is de synthesestap. Hierin wordt de textuele representatie in de HDL beschrijving omgezet naar een beschrijving op logisch niveau, namelijk de netlijst. Dit kan bijvoorbeeld een beschrijving zijn met AND-, OR-, NOT-poorten en FF s. Bij de mapping wordt de logische netlijst "afgebeeld" op de specifieke basiselementen beschikbaar op de FPGA: LUT s, FF s, MUX s, RAM blokken, vermenigvuldigers, enz.. Het resultaat van deze stap is een netwerk van elementen die allemaal beschikbaar zijn op de FPGA, we noemen dit de circuitbeschrijving. Elk type FPGA heeft dan ook zijn eigen mapper. Een FPGA die bijvoorbeeld werkt met 5-LUT s zal een andere mapper

19 2.1 Basisconcepten FPGA 9 Figuur 2.6: Hiërarchische opbouw van de configureerbare routering. hebben dan een FPGA met 4-LUT s. In figuur 2.8 wordt een logisch netwerk afgebeeld op een netwerk van drie 4-LUT s. De mapping bestaat hoofzakelijk uit het zoeken van een optimale bedekking door LUT s. Er kan naar verschillende criteria geoptimaliseerd worden, zoals snelheid en oppervlakte of, zoals vaak het geval is, naar een evenwichtige combinatie van beide. Het kan hierbij gebeuren, zoals in het voorbeeld het geval is bij LUT3, dat niet alle inputs van een LUT gebruikt worden. De plaatsingsstap zal elk element van de circuitbeschrijving toewijzen aan een fysisch element op de FPGA. In de routeringsstap zullen tenslotte de verbindingen gelegd worden tussen deze fysische elementen. De plaatsing- en routeringsstap worden vaak samengenomen en PAR (Place And Route) genoemd. In de PAR stap moet vaak met restricties rekening gehouden worden. Een restrictie kan bijvoorbeeld zijn dat de kloksnelheid hoger moet zijn dan 100 MHz. Na de PAR fase weet men welke bitwaarden in welke SRAM geheugencellen van het configuratiegeheugen moeten komen. Uit deze informatie wordt de configuratiebitstroom gegenereerd. De verschillende manieren om de FPGA te herconfigureren worden in het volgende gedeelte besproken.

20 2.1 Basisconcepten FPGA 10 HDL Design Synthesis MAP PLACE AND ROUTE CONFIGURATION BITSTREAM Figuur 2.7: Toolflow voor FPGA ontwerp Het herconfiguratieproces Er zijn 3 manieren om een FPGA te herconfigureren. De meest traditionele manier is herconfiguratie via een externe poort. Recent is een nieuw herconfiguratiemechanisme geïntroduceerd dat vooral geschikt is voor partiële herconfiguratie, namelijk aan de hand van een interne interface. Partiële herconfiguratie houdt in dat een deel van de logica, geïmplementeerd op de FPGA, wordt geherconfigureerd, terwijl de rest gewoon doorwerkt. Partiële herconfiguratie laat efficiënte RTR toe. Een derde, minder conventionele, manier is het gebruik van schuifregisters. Deze laatste staat centraal in deze scriptie. Herconfiguratie aan de hand van een externe poort Dit is de meest gebruikte manier om een FPGA te herconfigureren. Deze wordt voornamelijk gebruikt om de gehele FPGA te configureren, bij start-up. Vaak wordt de configuratiebitstroom vanuit een EEPROM geheugen op het FPGA bord ingeladen in het configuratiegeheugen. De EEPROM wordt na het ontwerp van de applicatie geschreven vanuit een PC waarop de tools draaien. Deze manier is voor ons minder geschikt voor run-time herconfiguratie omdat de toegang tot het configuratiegeheugen vanuit een pin op het FPGA bord gebeurt. We instantiëren namelijk herconfigureerbare logica op de FPGA

21 2.1 Basisconcepten FPGA 11 LUT1 LUT3 LUT2 Figuur 2.8: Afbeelding van een logisch netwerk op een netwerk van 4-LUT s. die de herconfiguratieinterface aanspreekt. Herconfiguratie aan de hand van een interne poort In 2.9 wordt de interne herconfiguratieinterface schematisch weergegeven. Dit is de meest gebruikte methode bij partiële herconfiguratie. Het maakt gebruik van de Internal Configuration Access Port (ICAP). Dit is een stuk hardware dat bij het aanmaken van de FPGA-chip eraan wordt toegevoegd. Deze gebruikt dus geen herconfigureerbare logica. Hierbij wordt hetzelfde protocol gebruikt als bij de externe poort, alleen is deze herconfiguratie interface intern. Dit houdt in dat men logica op de FPGA kan zetten die deze interface aanspreekt. Deze methode wordt voornamelijk gebruikt in combinatie met een ingebedde processor (in ons geval een PPC). Zo verkrijgt men een zelfherconfigurerend platform, dat ook zonder (externe) PC in staat is aan run-time-herconfiguratie te doen. Het stuk logica tussen de PPC en de ICAP wordt de HWICAP genoemd. Deze bestaat uit een RAM blok, een 200-tal LUT s en een 150-tal FF s. De PPC spreekt de HWICAP aan via een bus, OPB (On-Chip Peripheral Bus) genaamd. De HWICAP werkt aan dezelfde klok als de OPB, deze klok moet in het geval van de V2Pro ingesteld worden op 66 MHz. De OPB gebruikt ook herconfigureerbare logica van de FPGA. Deze interface herconfigureert, net als de externe interface, een kolom van 1 bit breedte in

22 2.1 Basisconcepten FPGA 12 het configuratiegeheugen per keer. Zulk een kolom wordt een frame genoemd. In ons geval bestaat het configuratiegeheugen bijvoorbeeld uit 1756 frames van 6592 bits. Een frame per keer herconfigureren kan inefficiënt zijn aangezien het kan gebeuren dat maar een klein deel van het frame in het configuratiegeheugen moet aangepast worden. Een geheel frame wordt hierbij gekopieerd naar het RAM-blok van de HWICAP, waarna dit geheel door de HWICAP wordt gekopieerd naar het configuratiegeheugen. De configuratiebitstroom bevat de instructies en configuratiedata om deze acties uit te voeren en wordt door de HWICAP verwerkt, 1 byte per kloktik. In het geval van een 66 MHZ klok is dit dus 1 byte elke 15 nanoseconden (ns). De informatie in dit onderdeel en de figuur werden gehaald uit [3]. Figuur 2.9: De OPB HWICAP. Herconfiguratie aan de hand van schuifregisters In sectie werd reeds aangehaald dat LUT s ook als schuifregister kunnen ingesteld worden. Het is belangrijk hierbij op te merken dat de LUT functionaliteit hierbij nog aanwezig blijft. Het is net dit dat de herconfiguratie aan de hand van schuifregisters toelaat. Een LUT ingesteld als SR is zowel LUT als SR. Dit wordt geïllustreerd in figuur We herconfigureren de 3-LUT van een 3-input OR-poort naar een 3-input AND-poort. De adressering telt van 0 (000 binair) tot 7 (111 binair). Bij input 010 wordt dus het derde bit

23 2.2 Run-time herconfiguratie (RTR) 13 van boven naar buiten gebracht. We merken op dat er een overgangsverschijnsel optreedt dat 8 kloktikken duurt. Het is pas na 8 kloktikken dat de OR-poort geherconfigureerd is naar een AND-poort. Tijdens deze 8 kloktikken is de LUT onbruikbaar. De grootste beperking van herconfiguratie aan de hand van schuifregisters komt hier ook duidelijk aan het licht. Enkel de LUT inhouden zijn herconfigureerbaar. Deze techniek kan dus enkel toegepast worden bij run-time herconfiguratie waarbij de routering niet verandert. Deze methode wordt in meer detail uitgewerkt in sectie t=0 t=1 t=2... t=8 Figuur 2.10: LUT functionaliteit van een schuifregister. 2.2 Run-time herconfiguratie (RTR) Klassieke methodes voor run-time-herconfiguratie Partïele herconfiguratie werd initiëel vooral gebruikt voor het herstellen van fouten en voor updates en liet hierbij toe dat het systeem bleef doorwerken. Aangezien het herconfiguratieproces uiterst eenvoudig is het schrijven van SRAM geheugencellen is het ook mogelijk om tijdens de werking van de FPGA deze te herconfigureren. Zo kan men de hardware specialiseren voor de specifieke taak die in een bepaald tijdsinterval moet uitgevoerd

24 2.2 Run-time herconfiguratie (RTR) 14 worden. Dit noemt men run-time herconfiguratie (RTR). Hierdoor kan een FPGA een taak sneller, met minder oppervlakte en minder vermogen uitvoeren. Een RTR systeem bestaat uit de logica die geherconfigureerd wordt en een systeem dat de nieuwe configuratie berekent en de herconfiguratie uitvoert, dit noemt men de Configuration Manager (CM) en is meestal een CPU. De meest gebruikte manier om aan RTR te doen is door een module gebaseerde partiële herconfiguratie te hanteren [4], een techniek die ook buiten RTR gebruikt wordt. Dit wordt geïllustreerd in figuur Deze methode wordt ondersteund door de tools van Xilinx en houdt in dat men de FPGA opdeelt in slots. Men noemt de logica toegewezen aan een bepaald slot een module. Het komt er dan op neer op verstandige wijze het ontwerp op te delen in modules, waarvan sommige herconfigureerbaar zijn, en deze dan toe te wijzen aan een slot. In figuur 2.11 wordt een ontwerp afgebeeld met 4 modules, waarvan er 2 herconfigureerbaar zijn. Aan de grenzen van een herconfigureerbare module worden speciale stukken hardware geplaatst, busmacro s genaamd, dit om een interface aan te bieden waar de andere modules mee kunnen communiceren. Deze busmacro s worden ook gebruikt om de signaalintegriteit over de grenzen van de modules te garanderen. Men kan dan een module herconfigureren zonder gevolgen voor andere modules. Er wordt een partiële bitstroom gegenereerd die alle frames van het slot herconfigureert. Er moet aan veel voorwaarden voldaan worden en deze methode is dus zeer omslachtig. Dit komt waarschijnlijk door het feit dat deze methode niet specifiek voor RTR werd ontworpen, maar daar wel voor gebruikt wordt. Bovendien wordt in het midden gelaten hoe de verschillende configuraties op een snelle en efficiënte manier moeten gegenereerd worden. Bij een tweede methode voor partiële herconfiguratie vermeld in [4], die van kleine bitmanipulaties, verandert men het ontwerp een beetje, waarna een partiële bitstroom wordt gegenereerd waarin het verschil verwerkt zit. Enkel kleine veranderingen zijn hier interessant en heel de toolflow moet weer doorlopen worden, waardoor deze techniek maar weinig gebruikt wordt. Deze wordt hier dan ook niet verder besproken. Zoals hierboven reeds aangehaald, kunnen we door het run-time herconfigureren de middelen beschikbaar op een FPGA efficiënter gebruiken. De grootste voorwaarde hierbij is dat we de FPGA niet te vaak moeten herconfigureren. Voor toepassingen met een zo goed als statisch gedrag is reeds meermaals aangetoond dat run-time herconfiguratie de prestatie van een systeem kan verbeteren [5, 6, 7]. Wanneer het gedrag van de applicatie dynamis-

25 2.2 Run-time herconfiguratie (RTR) 15 Figuur 2.11: Module gebaseerde partiële herconfiguratie. cher wordt, is dit niet evident. Wanneer synthese, mapping, plaatsing en routering on-line moeten gebeuren met de traditionele tools dan gebruikt de CM enorm veel middelen (o.a. tijd), zodat de winst van het specialiseren van het circuit teniet wordt gedaan. Er is dus dringend nood aan nieuwe technieken die specifiek voor RTR zijn ontwikkeld Onderzoek naar het efficiënt run-time genereren van configuraties Onderstaande samenvatting van reeds gebeurd onderzoek naar het run-time genereren van configuraties werd overgenomen uit [8]. In de literatuur zijn verschillende mogelijke oplossingen voorgesteld. Sommigen proberen een eenvoudigere versie van de tools te gebruiken en ruilen dus kwaliteit van het ontwerp in voor een vermindering van het gebruik van middelen door de CM. De winst die gemaakt wordt is beperkt en de verminderde kwaliteit doet de positieve effecten van RTR meestal teniet.

26 2.2 Run-time herconfiguratie (RTR) 16 Een tweede optie werd voorgesteld voor applicaties die maar een beperkt aantal configuraties hebben waartussen aan de hand van RTR moet worden gewisseld. Alles wordt off-line berekend en in een geheugen opgeslagen. De CM moet dan enkel nog de juiste configuratie uit het geheugen selecteren [9, 10]. Voor veel applicaties is dit niet mogelijk omdat een zeer groot aantal configuraties bestaat. Men kan de tweede optie verbeteren door een generieke netlijst te construeren en deze partieel te evalueren wanneer een herconfiguratie moet gebeuren [5, 11]. Het probleem blijft dan nog dat alles geplaatst en gerouteerd moet worden, wat te veel tijd in beslag neemt. Men heeft ook reeds geprobeerd de plaatsings- en routeringsinformatie te hergebruiken [12, 13]. Hierdoor vermindert de tijd nodig om de configuratie te berekenen, maar de vermindering van de kwaliteit is meestal onaanvaardbaar. Anderen concentreren zich dan weer op een specifieke toepassing. Bijvoorbeeld een vermenigvuldiging waarvan één van de factoren niet vaak verandert [14]. Dit leidt tot zeer efficiënte oplossingen, maar we zijn hier minder in geïnteresseerd. Dit brengt namelijk een zeer hoge ontwerpskost met zich mee, aangezien de methode niet generiek is en dus heel de procedure terug handmatig uitgevoerd moet worden bij gelijkaardige problemen. Er is dus duidelijk nood aan een generieke methode, die bovendien toelaat, zeer snel, nieuwe kwaliteitsvolle configuraties te genereren. Een methode op maat van run-time herconfiguratie. Deze methode, de zogenaamde techniek van parametriseerbare configuraties, wordt besproken in hoofdstuk 3.

27 PARAMETRISEERBARE CONFIGURATIES 17 Hoofdstuk 3 Parametriseerbare configuraties 3.1 Inleiding Het gehele hoofdstuk 3 is een samenvatting van [8, 15, 16] en de bijhorende presentaties. Ook de figuren en tabellen werden hieruit overgenomen. We vertrekken in dit hoofdstuk van een statisch ontwerp waarbij een deel van de inputs signalen zijn die traag variëren, de zogenaamde parameters. De parameterinputs van het statische ontwerp zullen gedurende relatief lange tijd dezelfde waarde aanhouden, waardoor het stuk hardware dat afhankelijk is van deze parameters ook niet verandert. We gebruiken onze hardware middelen dus niet efficiënt aangezien een deel van de hardware het grootste deel van de tijd inactief is. Enkel wanneer de parameters veranderen zal het stuk hardware dat hiervan afhankelijk is van toestand veranderen. Run-time herconfguratie (RTR) kan hier een oplossing bieden door de parameters naar de inputs van de Configuration Manager (CM) te verplaatsen. Die moet dan telkens voor de verschillende parameterwaarden een gespecialiseerd circuit genereren met enkel snel variërende inputs. In figuur 3.1 wordt het statisch ontwerp weergegeven samen met de efficiëntere implementatie aan de hand van RTR. De vraag blijft dan hoe we het best zo n RTR systeem kunnen opzetten. Een eerste mogelijke oplossing noemt men data folding of constantenpropagatie. Dit houdt in dat de CM in het ontwerp de parameterwaarden invult (in bijvoorbeeld de VHDL beschrijving) en heel de tijdsverslindende toolflow van synthese, mapping, plaatsing en routering hier weer op loslaat. Het circuit dat hierdoor verkregen wordt heeft vaak een

28 3.1 Inleiding 18 S P snel variërende inputs Statisch Circuit traag variërende inputs of parameters S RTR P Gespecialiseerd Circuit voor P CM Figuur 3.1: Een RTR systeem. kleinere oppervlakte en hogere snelheid. Ondanks de mogelijke optimalisaties besproken in sectie 2.2 blijft het probleem dat dit proces veel tijd vergt en het genereren van een nieuwe configuratie dus te lang duurt (in de grootte orde van tientallen seconden) waardoor deze oplossing niet bruikbaar is voor meer dynamische toepassingen. Bovendien is deze methode niet efficiënt aangezien ook delen van het ontwerp die niet afhankelijk zijn van de parameters tijdens de werking van het toepassing door de gehele toolflow verwerkt worden. Dit is dus een naiëve oplossing die niet op maat gemaakt is van RTR. De techniek van parametriseerbare configuraties lost het probleem eleganter op. Het is bedacht door Karel Bruneel, binnen de onderzoeksgroep PARIS van de vakgroep ELIS van de Universiteit van Gent, in het kader van zijn doctoraat omtrent runt-time herconfiguratie en wordt uitvoerig besproken in [8, 15, 16]. Aan de hand van de techniek kan men het gedeelte van het ontwerp dat afhankelijk is van de parameters op een efficiënte manier extraheren. Het resultaat is een parametriseerbare configuratie, dit is een configuratie waarvan de bits in sommige LUT s uitgedrukt worden als boolese functies van de parameters. De boolese functies van de parameters noemen we Tuningfuncties. Een LUT waarvan de bits uitgedrukt zijn als Tuningfuncties noemen we

29 3.1 Inleiding 19 een Tunable LUT (TLUT). In figuur 3.2 wordt een TLUT-circuit afgebeeld. Dit is een circuit waarvan sommige LUT s TLUT s zijn. TLUT TLUT TLUT TLUT Figuur 3.2: Een TLUT-circuit met 4 TLUT s en 5 gewone LUT s. Aangezien de verbindingen tussen de LUT s en TLUT s vast staan en enkel de configuratiebits van de TLUT s veranderen kunnen complexe problemen zoals synthese, plaatsing en routering allemaal off-line opgelost worden en bovendien zo dat voor alle mogelijke parameterwaarden een kwaliteitsvolle configuratie gevonden wordt. Als een parameterwaarde verandert moet de CM de Tuningfuncties evalueren en de TLUT s herconfigureren. De configuratiebits in de gewone LUT s blijven gelijk voor alle parameterwaarden. De techniek heeft dus veel voordelen. Al de moeilijke, tijdverslindende problemen, zoals plaatsing en routering, moeten niet tijdens de werking opgelost worden. Het volstaat een set van boolese functies te evalueren om een configuratie te genereren. Bovendien wordt het deel van de hardware dat afhankelijk is van de parameters afgezonderd. Het is enkel dit deel dat geherconfigureerd moet worden. Ten slotte merken we op dat de methode volledig generiek is. De parameters kunnen eender welke traag veranderende signalen zijn. Er is een tool ontwikkeld die vanuit eender welk ontwerp met traag variërende signalen

30 3.2 Het automatisch genereren van parametriseerbare configuraties 20 een parametriseerbare configuratie kan genereren. uitgewerkt. Dit wordt hieronder in meer detail 3.2 Het automatisch genereren van parametriseerbare configuraties Figuur 3.3 geeft de toolflow weer om vanuit een VHDL beschrijving parametriseerbare configuraties te verkrijgen. Het is raadzaam om deze even te vergelijken met de conventionele toolflow weergegeven in figuur 2.7. Parametrizable HDL Design Synthesis TMAP Instantiëren van LUT primitieven Extract Static LUT Circuit Extract Tuning Functions Uniek nummer elke TLUT Place & Route Generate Reconfiguration Procedure Functies voor HWICAP Master Configuration Reconfiguration Procedure Posities van alle TLUT's Figuur 3.3: Toolflow voor run-time herconfiguratie a.h.v. parametriseerbare configuraties. Annotatie van traag veranderende signalen We vertrekken van een VHDL beschrijving van een toepassing waarin traag veranderende signalen aanwezig zijn. Hierin moet de ontwerper met een annotatie aangeven welke sig-

31 3.2 Het automatisch genereren van parametriseerbare configuraties 21 nalen traag veranderen in de tijd. Het ontwerpen van een RTR applicatie wordt dus herleid tot beslissingen die op het niveau van de hardwarebeschrijvingstaal moeten gemaakt worden, namelijk aanduiden welke signalen traag variëren. In dit onderdeel behandelen we als voorbeeld een 4:1 MUX. Figuur 3.4 geeft de 4:1 MUX weer samen met zijn VHDL beschrijving. Afhankelijk van de selectie ingangen laat de MUX een van de 4 ingangen door. De selectie ingangen zijn als parameters geannoteerd. Dit gebeurt door boven en onder de regel die de declaratie van de selectie-ingangen bevat --BEGIN PARAM en --END PARAM te zetten. entity multiplexer is port( --BEGIN PARAM sel : in std_logic_vector(1 downto 0); --END PARAM in : in std_logic_vector(3 downto 0); out : out std_logic ); end muxltiplexer; architecture behavior of multiplexer is begin out <= in(conv_integer(sel)); end behavior; Figuur 3.4: Geannoteerd VHDL ontwerp van een 4:1 MUX. De synthese van de VHDL beschrijving gebeurt net zoals in de conventionele toolflow. Het resultaat hiervan is een gerichte acyclische graaf of Directed Acyclic Graph (DAG). De DAG verkregen na synthese van de VHDL beschrijving van de 4:1 MUX wordt afgebeeld in figuur 3.5. A staat hierbij voor een AND-poort, O voor een OR-poort en N voor een NOT-poort. TMAP: genereren van een TLUT-circuit Om de gedachten te vestigen wordt in figuur 3.6(a) het resultaat van de volgende stap, de mapping, weergegeven voor een conventionele mapper. Deze zoekt een bedekking met zo weinig mogelijk 3-LUT s. In dit geval zijn er 3 3-LUT s nodig om een 4:1 MUX te

32 3.2 Het automatisch genereren van parametriseerbare configuraties 22 Figuur 3.5: Een Directed Acyclic Graph (DAG) van het 4:1 MUX voorbeeld. implementeren. Zoals we op de figuur zien gaat de mapper op zoek naar delen van de DAG met maximaal 3 inputs en 1 output, dit is een stuk logica dat altijd past in een 3-LUT. De mapper heeft als resultaat een netwerk van LUT s en voor elke LUT de boolese functies die de ouput in functie van de inputs beschrijft. Deze boolese functies zijn nodig om de waarheidstabellen op te stellen waaruit later de configuratiebits van de LUT s worden gegenereerd. De waarheidstabel van een LUT wordt opgesteld a.d.h.v evaluatie. We vullen elke mogelijke input in in de boolese functie en noteren het resultaat in de waarheidstabel. Het hart van de toolflow om parametriseerbare configuraties te genereren is een aangepaste mapper, TMAP genaamd (dit staat voor TLUT Mapper). Het resultaat van TMAP voor de 4:1 MUX wordt weergegeven in figuur 3.6(b). Door de annotaties aangebracht in de VHDL beschrijving van het ontwerp is TMAP er zich van bewust welke inputs de traag variërende parameters zijn. Bij het zoeken naar een optimale bedekking wordt hier rekening mee gehouden. TMAP gaat op zoek naar delen van de DAG met maximaal 3 inputs, 1 output en een onbeperkt aantal parameterinputs. Zulk een deel van de DAG past telkens in 1 fysische LUT. De aanwezigheid van parameterinputs vertaalt zich later tot een run-time te herconfigureren TLUT. Het resultaat van TMAP voor de 4:1 MUX wordt weergegeven in figuur 3.7(a). We zien hierop een TLUT circuit, een netwerk van LUT s waarvan sommige afhankelijk zijn van

33 3.2 Het automatisch genereren van parametriseerbare configuraties 23 (a) (b) Figuur 3.6: Vergelijking conventionele mapper en TMAP. parameterinputs. De LUT s die afhankelijk zijn van parameterinputs zijn de TLUT s. Dit TLUT circuit komt overeen met de bedekking gevonden in figuur 3.6(b). In het geval van de 4:1 MUX bestaat het TLUT circuit uit 2 TLUT s en geen gewone LUT s. Extraheren van de Tuningfuncties TMAP houdt, net als een conventionele mapper, voor elke LUT de boolese functie bij die de output uitdrukt in functie van al de inputs. Nu bestaan de inputs zowel uit gewone inputs als parameterinputs. Dit wordt onderaan afgebeeld op figuur 3.7(a). De boolese functies die de gewone LUT s beschrijven zijn net als bij de conventionele mapper nodig om de waarheidstabel op te stellen waaruit later de configuratiebits van de LUT wordt gegenereerd. Deze veranderen niet als de parameterwaarden veranderen. De waarheidstabel van een TLUT bestaat uit Tuningfuncties. Hoe de waarheidstabellen van de 2 TLUT s L 0 en L 1 van het voorbeeld worden bekomen wordt weergegeven in figuur 3.7(b). Er worden voor elke TLUT 8 Tuningfuncties afgebeeld die door partiële evaluatie van de boolese functies worden verkregen. We spreken van partiële evaluatie omdat we enkel elke mogelijke gewone input invullen, het resultaat bevat nog parameterinputs. Deze Tuningfuncties worden run-time geëvalueerd door de CM wanneer de parameters veranderen. In deze fase krijgt elke TLUT een uniek nummer die het mogelijk maakt na de PAR elke TLUT terug te vinden.

34 3.2 Het automatisch genereren van parametriseerbare configuraties 24 (a) (b) Figuur 3.7: Resultaat van TMAP: TLUT-circuit en bijhorende boolese functies. Genereren van de Masterconfiguratie We merken op dat de parameterinputs geen echte inputs zijn, maar uitdrukken dat de waarheidstabel van de TLUT afhankelijk is van de parameters. De volgende stap is dan zeer simpel. We laten de parameterinputs gewoon weg en plaatsen en routeren (PAR) het TLUT-circuit dat zo bekomen wordt. Figuur 3.8 geeft dit weer voor het 4:1 MUX voorbeeld. Het circuit dat zo bekomen wordt kan gebruikt worden om de FPGA bij startup te configureren en wordt de Masterconfiguratie genoemd. In dit geval zijn beide LUT s TLUT s. In de meeste ontwerpen zullen in een TLUT-circuit zowel LUT s als TLUT s voorkomen. Voor het genereren van de Masterconfiguratie wordt gebruik gemaakt van bibliotheekprimitieven van de Xilinx V2Pro reeks. Een TLUT wordt dan geïnstantieerd als een LUT2, LUT3 of LUT4. Dit is een 4-LUT waarvan respectievelijk 2, 3 of 4 inputs gebruikt worden. De geïnstantieerde TLUT s krijgen elk een uniek nummer. Met elk nummer (of TLUT) worden 16 Tuningfuncties geassocieerd.

35 3.2 Het automatisch genereren van parametriseerbare configuraties 25 PAR Figuur 3.8: Extraheren van het statisch circuit en de Masterconfiguratie. Genereren van de Herconfiguratieprocedure De PAR genereert een bestand waarin staat hoe de verschillende LUT s geplaatst zijn. Dit is een bestand in een ncd formaat. Dit wordt naar een menselijk leesbaar document, in het xdl formaat, omgezet. Het unieke nummer van elke TLUT dat bij het extraheren van de Tuningfuncties werd gegeven maakt het mogelijk de slice op te zoeken waarin de TLUT zich bevindt en of het om de F of G LUT van de slice gaat. Na de PAR kennen we de fysische locatie van de TLUT s. Samen met de Tuningfuncties van de TLUT s kunnen we een herconfiguratieprocedure opstellen die als basis dient voor de CM. In ons geval is de CM op de PPC geïmplementeerd en de herconfiguratieprocedure bestaat uit een C-programma dat met elke TLUT een positie en 16 Tuningfuncties associeert (4-LUT). Het bevat bovendien functies die met deze informatie de HWICAP aanspreken. Steeds als de parameterwaarden veranderen worden de Tuningfuncties geëvalueerd. Het genereren van een configuratie gespecialiseerd voor de parameterwaarden wordt dus herleid tot evalueren van een set van boolese functies van deze parameterwaarden. In het voorbeeld van de 4:1 MUX moet de CM de TLUT s herconfigureren volgens de Tuningfuncties telkens de selectie ingangen veranderen. Na het evalueren van de Tuningfuncties wordt aan de hand van de HWICAP module de herconfiguratie uitgevoerd. De werking van de HWICAP is uitgewerkt in sectie

36 3.3 Theoretische resultaten Theoretische resultaten De theoretische resultaten werden behaald in VPR. Dit is een theoretische simulatie omgeving waar het mogelijk is de architectuur van de FPGA te veranderen. Hierbij kunnen bijvoorbeeld het aantal inputs van een LUT en de hoeveelheid beschikbare routering ingesteld worden. Er werd gekozen voor een standaard architectuur met 4-LUT s. Ook is het mogelijk bepaalde delen van de toolflow te herschrijven. In dit geval werd de mapper vervangen door TMAP. De toolflow werd dan toegepast op een 16-tap FIR-filter, met input en coëfficienten van 8 bit. In figuur 3.10 wordt een 32-tap FIR-filter schematisch weergegeven. De techniek van parametriseerbare configuraties werd vergeleken met een statische implementatie en een gewone RTR implementatie waarbij heel de toolflow runtime wordt doorlopen. Tabel 3.1 geeft de bekomen resultaten weer. Tabel 3.1: Theoretische resultaten voor een 16-TAP FIR-filter behaald in VPR. Opp. Max. Klok Generatie (LUTs) Freq.(MHz) tijd (ms) Statisch Param. config gewone RTR Hieruit blijkt dat RTR kan zorgen voor een veel efficiëntere implementatie met een oppervlaktewinst van meer dan 50% en een winst van meer dan 30% in maximale klokfrequentie van het ontwerp. De techniek van parametriseerbare configuraties levert hierbij gelijkaardige winsten op als de gewone RTR waar heel de toolflow wordt doorlopen, maar de tijd nodig om een gespecialiseerde configuratie te genereren is veel kleiner. Dit maakt parametriseerbare configuraties bruikbaar voor toepassingen met een meer dynamisch gedrag en niet enkel voor die met een quasi-statisch gedrag. Om een commerciële toepassing van parametriseerbare configuraties toe te laten werd de TMAP-toolflow geïntegreerd met de gewone toolflow voor FPGA ontwerp voor Xilinx FPGA s. De resultaten hiervan worden hieronder besproken.

37 3.4 Experimentele resultaten Experimentele resultaten Figuur 3.9 geeft de implementatie weer van de TMAP-toolflow. Deze maakt gebruik van een V2Pro FPGA bord van Xilinx. Deze bevat 2 ingebedde PowerPC s (PPC s) en een V2Pro FPGA met LUT s. Zoals eerder vermeld is de CM geïmplementeerd geweest op de PPC. De CM communiceert met de HWICAP om de herconfiguratie uit te voeren. Dit gebeurt via een OPB. Figuur 3.9: Implementatie van de TMAP-toolflow op een V2Pro FPGA bord Proefopstelling De toolflow is toegepast op een 32-tap FIR fiter. Deze staat afgebeeld in figuur De omgekeerde driehoekjes zijn vermenigvuldigers, de rechthoekjes zijn registers die tijdelijke resultaten bijhouden. De input en de coëfficienten c i zijn elk 8 bit breed. We kiezen hierbij de coëfficienten c i als parameters en gaan er dus vanuit dat deze niet vaak veranderen. Dit zou bijvoorbeeld het geval zijn in een wifi toepassing waarbij de coëfficienten moeten aangepast worden telkens de wifi cliënt zich verplaatst. Een statische implementatie van de FIR-filter wordt weergegeven in figuur 3.11(a). De coëfficienten worden hierbij veranderd door vanuit de PPC naar registers te schrijven. In 3.11(b) wordt de implementatie waarbij de TMAP-toolflow is toegepast weergegeven. Zoals eerder reeds vermeld bevindt de CM zich op de PPC en deze zal wanneer de parameters veranderen, in dit geval de coëfficienten van de FIR-filter, de Tuningfuncties evalueren en via de HWICAP de TLUT s herconfigureren. Beide implementaties worden getest door de

38 3.4 Experimentele resultaten 28 Figuur 3.10: Schematische weergave van een FIR-filter. in hardware gegenereerde waarden te vergelijken met een in software gesimuleerde FIRfilter. (a) (b) Figuur 3.11: FIR-filter: statisch en a.h.v. de TMAP-toolflow Resultaten Tabel 3.2 geeft de resultaten weer voor de 32-tap FIR-filter. We zien dat in het geval van de oplossing aan de hand van de techniek van parametriseerbare configuraties de toepassing 40 % minder plaats inneemt. De conventionele implementatie heeft de coëfficienten als inputs en kan zich dus in een aantal klokcycli aanpassen als deze veranderen. De RTR doet er 151 ms over om zich aan te passen. Hierbij duurt het ongeveer 10 ms om de Tuningfuncties te evalueren en ongeveer