Author:
Henri Faber is senior designer bij Adeas in Eindhoven. Hij heeft zestien jaar ervaring in het ontwerp van digitale elektronica, waarvan twaalf met FPGA‘s. Momenteel is hij verantwoordelijk voor de ontwikkeling van snelle transportsystemen voor digitale video op basis van Ethernet-technologie.
Reading time: 7 minutes
In het verleden was het voor de timing van een FPGA-ontwerp voldoende om de set-up– en hold-tijden op te geven, de tijden dat data aanwezig moet zijn voor en na een kloktik. Secundaire invloeden zoals skew, jitter en slew rate waren te verwaarlozen. De snelheden van externe interfaces op een FPGA worden echter steeds hoger, waardoor er een steeds kleinere marge overblijft voor de timing. Het correct specificeren van de interfacetiming wordt daarmee van kritiek belang.
Naast het aantal logische elementen maakt ook de I/O-capaciteit van FPGA‘s een flinke groeispurt door. Aan de ene kant komt dat doordat applicaties direct om snelle communicatie vragen – denk maar aan 40 Gigabit en 100 Gigabit Ethernet, de nieuwe mobiele telefoonstandaard LTE en HD- en 3D-televisie. Aan de andere kant groeien de geheugenvereisten fors met zowel vraag als aanbod. Bovenstaande toepassingen vragen bijvoorbeeld continu nieuwe data en moeten ook vaak grote hoeveelheden gegevens in het geheugen opslaan. Een H.264-video-encoder (ook wel AVC of MPeg-4 part 10) moet bijvoorbeeld meerdere videobeelden opslaan om daarin naar beweging van delen van het beeld te zoeken. Bovendien worden er vaak meerdere bewerkingen ondergebracht in een enkele FPGA, die elk onafhankelijk van elkaar hetzelfde externe geheugen gebruiken.
Regelmatig worden specifieke I/O-functies al in de hardware van de FPGA meegebakken, zoals een Gigabit Ethernet-Mac, een PCI Express-eindpunt of een externe geheugencontroller. De gebruikte interfaces zijn ruwweg te verdelen in twee groepen. De eerste gebruikt seriële verbindingen waarbij de klokinformatie in de data wordt gecodeerd. Voorbeelden hiervan zijn PCI express (pc-insteekkaarten), Ethernet (internet), Sata (harddisks), SDI en Asi (beide digitale video). Deze protocollen vereisen over het algemeen het gebruik van een serieel-naar-parallel-omzetter in de FPGA en een manier om verschillende datakanalen met elkaar te synchroniseren. De timing is hier altijd impliciet correct. Bij de protocollen uit de andere groep is dat niet het geval. Die gebruiken een apart kloksignaal naast de datasignalen. Voorbeelden zijn DDR-, DDR2- en DDR3-SDRam (dynamisch computergeheugen), QDR-SRam, Hypertransport (onder meer AMD-processoren) en Quickpath (de nieuwe Intel-processoren).
Aansluitpunten
Het gebruik van deze interfaces waarbij een synchroniserend kloksignaal meeloopt met de datakanalen stelt de ontwerper voor een aantal uitdagingen. De meeste worden veroorzaakt door de hoge overdrachtssnelheid. Bij DDR-geheugen, Hypertransport en Quickpath is er bijvoorbeeld dataoverdracht op elke flank van de kloktik, dus met de dubbele frequentie van de klok. Bij QDR-SRam worden er zelfs vier keer per klokperiode gegevens overgedragen.
Bovendien kunnen de kloksnelheden zelf ook nog eens zeer hoog zijn. Bij DDR3, de huidige standaard voor pc-geheugens, zijn klokfrequenties mogelijk tot 1066 MHz. Bij de volgende standaard wordt dit waarschijnlijk opgetrokken tot 1,6 GHz. De meest recente Hypertransport-standaard specificeert al een maximumkloksnelheid van 3,2 GHz. Op deze frequentie duurt elke dataoverdracht slechts 156 picoseconde. Om een idee te geven hoe kort deze tijd is: licht verplaatst zich in een vacuüm met een snelheid van bijna driehonderdduizend kilometer per seconde. In 156 picoseconde legt het licht slechts 4,7 centimeter af. Die frequenties zijn nog buiten bereik van de huidige FPGA-generaties. De Altera Stratix IV en Xilinx Virtex-6 kunnen DDR3 tot een klokfrequentie van 533 MHz aan. De in april aangekondigde Altera Stratix V zal tot 800 MHz kunnen gaan.
Bij het plaatsen van de logische elementen en de onderlinge bedrading is het noodzakelijk om voor alle geklokte interfaces op te geven wat de relatie in tijd is tussen klok en data. Wanneer deze timingconstraints niet correct zijn, zal het ontwerp op mysterieuze wijze soms wel en soms niet functioneren.
In de datasheet staan alle benodigde gegevens om het device correct te kunnen gebruiken. De belangrijkste voor het instellen van de FPGA zijn de set-up- en hold-tijden. Set-up slaat op de tijdspanne waarin de data al aanwezig moeten zijn voordat de kloktik arriveert. Hold gaat over de periode waarin de data nog aanwezig moet blijven na de klokflank (zie Figuur 1).
Helaas zijn in de datasheet alleen de gegevens te vinden ten opzichte van de aansluitpunten van de chip. Er zijn echter verschillende factoren die de timinggegevens beïnvloeden. Samen bepalen ze de marge die het datasignaal heeft om tot de juiste waarde te komen. Hoe groter de marge, hoe gemakkelijker het is om de plaatsing en routing van de logica in de FPGA te doen. Een kleine marge zorgt voor lange runtijden van de FPGA-compilatiesoftware.
Omklaptijd
Om te beginnen, is er de tijd die het kost voor de signalen om van de FPGA naar de externe geheugenchip te reizen en weer terug. Elektrische signalen verplaatsen zich met een snelheid van ongeveer 5,8 ps/mm over een printplaat. Als klok en data dezelfde richting op gaan, doet de spoorlengte er niet echt toe. Als ze in tegenovergestelde richtingen lopen, begint de spoorlengte bij een hoge klokfrequentie een flinke hap uit de marge te nemen. De snelste protocollen werken daarom vaak met klokken in beide richtingen.
Omdat er meestal meerdere datasignalen tegelijk worden doorgegeven, is ook het verschil in lengte tussen de sporen direct van invloed op de timing. Het tijdverschil tussen de signalen op het kortste en op het langste spoor wordt skew genoemd. Deze skew gaat ook ten koste van de marge.
Een andere invloed is jitter, de variatie in de periode van de klok. Er zijn verschillende oorzaken van jitter. Ten eerste is er de intrinsieke jitter van de klokbron, meestal een kristaloscillator. Bij snelle protocollen wordt de klokfrequentie meestal verhoogd met een regellus (phase-locked loop, PLL, of delay-locked loop, DLL). Dat geeft op zijn beurt extra jitter, maar kan wel de invloed van de bron-jitter verminderen.
Een minder voor de hand liggende oorzaak van jitter is een storingsfenomeen dat bekendstaat onder de naam ground bounce. Hierbij verandert het niveau van de aarde plaatselijk en tijdelijk op de print, waardoor ook het beslissingsniveau voor ’hoog‘ of ’laag‘ verschuift. Doordat de klokflanken niet oneindig steil zijn, resulteert dat in een verandering in tijd. Dat gaat ook weer ten koste van de marge.
De volgende invloed is de snelheid van de overgangen tussen de logische 0 en 1. Deze wordt bepaald door de steilheid van de signaalflanken, oftewel de slew rate. Die is afhankelijk van de gebruikte I/O-standaard, het aantal milliampère dat de pin kan leveren, de afsluiting van het signaal en de symmetrie van de driver: hoe verhoudt de overgang van 0 naar 1 zich ten opzichte van de overgang van 1 naar 0. Hoe hoger de slew rate, hoe sneller een signaal verandert van 0 naar 1 en omgekeerd.
De omklaptijd tussen 0 en 1 gaat ten koste van de marge, dus het lijkt logisch om te zorgen voor een zo hoog mogelijke slew rate. Maar zoals altijd moet er een compromis worden gesloten. Een te hoge slew rate kan namelijk spanningspieken boven de voedingsspanning en onder het nulniveau veroorzaken. Naast EMC-problemen kan dat ook weer het ground bounce-effect veroorzaken.
Monstermoment
Hoe nu om te gaan met al deze variatie? Een typisch systeem heeft een groot aantal bronnen die op de een of andere manier de marge kunnen beïnvloeden, zoals instellingen van de driver in de FPGA, de lay-out van de sporen op de print, de afsluiting en karakteristieke impedantie van de sporen en het type en aantal van de andere devices. Daardoor is het ondoenlijk om de optimale configuratie te vinden door het systeem te meten.
Bij snelle interfaceprotocollen worden simulaties daarom noodzakelijk om snel variaties uit te proberen. Van vrijwel alle IC‘s die bij deze snelle protocollen worden gebruikt, zijn Ibis-modellen (I/O Buffer Information Specification) beschikbaar om dergelijke simulaties op te zetten. Voor FPGA‘s geldt dat echter niet. Er zijn simpelweg te veel mogelijkheden om een I/O-pin van een FPGA in te stellen. Het model van de fabrikant bevat alleen een beschrijving van alle mogelijke instellingen. Gelukkig kan de software van de FGPA-leverancier helpen om voor het specifieke ontwerp een Ibis-model aan te maken.
Vervolgens is er nog het verschil tussen het uitgangspunt van de datasheet en de werkelijke situatie. De datasheet gaat uit van een specifieke slew rate van data en klok. Wanneer de werkelijke slew rate hiervan afwijkt, moet er een correctie worden toegepast. Dat wordt derating genoemd. Voor DDR-geheugeninterfaces worden er in de datasheets al derating-tabellen opgenomen, maar het kan nodig zijn om de aanpassing zelf uit te rekenen.
Ook kunnen de timingreferentiepunten van de FPGA-leverancier en het externe device verschillen. Voor geheugen wordt bijvoorbeeld uitgegaan van het punt waarop het signaal het referentieniveau kruist, terwijl bij de FPGA wordt uitgegaan van de kruispunten met 20 en 80 procent van de voedingsspanning (zie Figuur 2). Ook hiervoor moet worden gecompenseerd.
Dan zijn er nog de procesvariaties in het fabricageproces. Die kunnen ervoor zorgen dan sommige IC‘s wat sneller of juist langzamer zijn dan gemiddeld. Bij FPGA‘s en geheugens wordt de snelheid in de fabriek getest en afhankelijk daarvan wordt aan de chip een snelheidsgradatie toegekend. Maar een langzame speed grade betekent niet altijd dat de chip ook daadwerkelijk langzaam is. Soms worden er te veel snelle chips gemaakt en te weinig langzame. In zo‘n geval kan een snelle chip toch een langzame gradatie krijgen.
Ook de voedingsspanning en de temperatuur van het IC veroorzaken snelheidsverschillen, die in de tijd variëren. De FPGA-software houdt met deze verschillen rekening door fast en slow timing-modellen te gebruiken en de timing op beide te controleren. Om de invloed van spannings- en temperatuurvariaties te verminderen, kan een PLL worden ingezet. Door continu het monstermoment van de data in de gaten te houden, kan een regelsysteem de marge vergroten door de PLL on-the-fly bij te sturen.
