View
0
Download
0
Category
Preview:
Citation preview
Faculteit Toegepaste WetenschappenVakgroep Elektronica en InformatiesystemenVoorzitter: prof. dr. ir. J. Van Campenhout
Hardware/Software Co-design
van de H.264/AVC-codec
door Jan De Cock & Stijn Notebaert
Promotoren: prof. dr. ir. R. Van de Walle & prof. dr. ir. D. StroobandtBegeleiders: lic. P. Lambert & dr. ir. M. Christiaens
Afstudeerwerk ingediend tot het behalen van de graad van Burgerlijk Ingenieur inde Computerwetenschappen
Academiejaar 2003–2004
Toelating tot bruikleen
De auteurs geven de toelating dit afstudeerwerk voor consultatie beschikbaar te stel-len en delen van het afstudeerwerk te kopieren voor persoonlijk gebruik. Elk andergebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met be-trekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen vanresultaten uit dit afstudeerwerk.
1 juni 2004
Jan De Cock Stijn Notebaert
i
Dankwoord
Bij het afronden van dit afstudeerwerk, als de kroon op het werk van deze fraaieafstudeerrichting, willen wij enkele mensen bedanken, die als co-producenten bijge-dragen hebben tot de verwezenlijking van dit afstudeerwerk.
Allereerst willen wij onze promotoren Rik Van de Walle en Dirk Stroobandt bedan-ken voor de uitdaging die zij ons gegeven hebben en de goede begeleiding van ditafstudeerwerk.
Een woord van dank gaat zeker uit naar onze persoonlijke begeleiders, Peter Lamberten Mark Christiaens. We willen hen bedanken voor de raadgevingen bij het afstu-deerwerk. We wensen alle medewerkers van de onderzoeksgroepen Multimedia Laben Paris te bedanken voor hun bijdragen. In het bijzonder een dankwoord aanPhilippe Faes voor de vele praktische tips.
Aangezien wijzelf allen het resultaat zijn van een jarenlange interactie met onzeomgeving, is dit werk niet alleen ons werk, maar vloeit het onrechtstreeks voort uitiedereen in deze omgeving. Volgende mensen hebben er dan ook voor gezorgd datwe vanaf nu twee letters en een puntje voor onze naam mogen zetten.
. . . van Jan
Het spreekt voor zich dat m’n ouders en familie op de eerste plaats komen, aangezienzij er altijd als eerste bij waren, en steeds voor de nodige steun hebben gezorgd. Maarop een niet minder belangrijke tweede plaats gaat mijn dank uit naar Peter, Griet,Dennis, Sofie, Stijn, Evelien, Eline, Joris en natuurlijk m’n allerliefste Anneline.
. . . van Stijn
Aan mijn ouders heb ik natuurlijk veel te danken. Zonder hun steun was dit afstu-deerwerk geen feit geweest. Tijdens deze vele jaren van hard studeren waren zij ersteeds voor mij, net zoals Eveline en Geert, Sofie en Daniel, Nele en Bram.
En daarnaast willen we ook onze medestudenten Wouter, Stijn en Stijn bedankenvoor de toffe momenten die we samen doorbrachten.
ii
Hardware/Software Co-design van de H.264/AVC-codec
doorJan De Cock & Stijn Notebaert
Afstudeerwerk ingediend tot het behalen van de graad van Burgerlijk Ingenieur inde Computerwetenschappen
Academiejaar 2003–2004
Universiteit GentFaculteit Toegepaste WetenschappenVakgroep Elektronica en InformatiesystemenVoorzitter: prof. dr. ir. J. Van Campenhout
Promotoren: prof. dr. ir. R. Van de Walle & prof. dr. ir. D. StroobandtBegeleiders: lic. P. Lambert & dr. ir. M. Christiaens
iii
Samenvatting
Multimediatoepassingen zijn alomtegenwoordig en razend populair. Snelle proces-soren en breedbandverbindingen maken na audio nu ook video voor iedereen toe-gankelijk. Om de bandbreedte van de netwerken en de capaciteit van opslagmediazo optimaal mogelijk te benutten, zal men pogen de videosequenties zo compactmogelijk te beschrijven. Dit verklaart de nood aan efficiente methoden voor video-compressie.
Om compatibiliteit tussen de verschillende producenten en onderzoeksgroepen teverzekeren, werden een aantal standaarden gedefinieerd. Door de International Or-ganization for Standardization (ISO) en International Telecommunication Union(ITU) werd enkele jaren geleden een nieuwe standaard ontwikkeld, die bekend staatals de H.264/AVC-standaard.
De hoge mate van efficientie wordt verkregen door het gebruik van geavanceerdealgoritmes die zeer rekenintensief kunnen zijn. Dit uit zich dan ook in een trage co-dering van videosignalen bij het gebruik van een implementatie van de H.264/AVC-standaard in software. Om dit probleem op te lossen kunnen hardwareversnellersworden ontwikkeld. Deze zullen een deel van de functionaliteit van de videocoderingovernemen van de processor, zodat het volledige coderingsproces versneld wordt.
In deze thesis worden het gebruik van hardwareversnellers en de moeilijkheden bijde ontwikkeling ervan onderzocht, gebruikmakende van een programmeerbare com-ponent (i.c. een FPGA). Het is gebleken dat het niet steeds evident is om eenhardwareversneller te verkrijgen. Het belangrijkste probleem hierbij is de communi-catie tussen software en hardware. Hoe kunnen beide componenten op een efficientemanier communiceren, zodat de snelheidswinst die we verkrijgen uit de hardware-implementatie niet verloren gaat? In deze thesis worden een aantal voorwaarden enmethoden vooropgesteld die het ontwerpen van een hardwareversneller tot een goedeinde kunnen brengen.
Trefwoorden: H.264/AVC, HW/SW co-design, videocodering, FPGA
iv
Inhoudsopgave
1 Inleiding 1
1.1 Doel van dit afstudeerwerk . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Structuur van dit afstudeerwerk . . . . . . . . . . . . . . . . . . . . . 3
2 H.264/AVC-standaard 6
2.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Intra-codering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3 Inter-codering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4 Transformatie en quantisatie . . . . . . . . . . . . . . . . . . . . . . . 14
2.5 Entropiecodering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.6 Profielen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.7 Profilering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3 WildCard-II 19
3.1 Testopstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2 Architectuur van de WildCard-II . . . . . . . . . . . . . . . . . . . . 22
3.3 Xilinx Virtex-II XC2V3000 . . . . . . . . . . . . . . . . . . . . . . . . 28
4 Entropiecodering 31
4.1 Context-Adaptive Binary Arithmetic Coding . . . . . . . . . . . . . . 31
4.2 Context-Adaptive Variable Length Coding . . . . . . . . . . . . . . . 38
4.3 Besluiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
v
5 Transformatie & Quantisatie 45
5.1 Beschrijving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.2 Implementatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.3 Integratie in de referentiesoftware . . . . . . . . . . . . . . . . . . . . 49
5.4 Resultaten: de harde cijfers . . . . . . . . . . . . . . . . . . . . . . . 50
5.5 Besluiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6 Intra-codering 53
6.1 Beschrijving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.2 Implementatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.2.1 Predictie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.2.2 Transformatie en quantisatie . . . . . . . . . . . . . . . . . . . 62
6.3 Integratie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.4 Resultaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.5 Besluiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
7 Besluit 78
A Verklarende woordenlijst 80
B Context Adaptive Binary Arithmetic Coding 82
B.1 CABAC-glossarium . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
B.2 Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
B.3 Bespreking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
B.3.1 Binarisatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
B.3.2 Contextmodellering . . . . . . . . . . . . . . . . . . . . . . . . 88
B.3.3 Binaire aritmetische codering . . . . . . . . . . . . . . . . . . 90
B.4 Toepassing: codering van residuele data . . . . . . . . . . . . . . . . . 96
B.4.1 Theorie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
B.4.2 Praktijkvoorbeeld . . . . . . . . . . . . . . . . . . . . . . . . . 99
vi
C Handleiding voor WildCard-II 107
C.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
C.2 FPGA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
C.3 SelectRAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
C.4 ZBT SRAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
C.4.1 Gebruik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
C.5 Communicatie tussen PC en WildCard-II . . . . . . . . . . . . . . . . 115
C.5.1 LAD Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
C.5.2 Register-operaties . . . . . . . . . . . . . . . . . . . . . . . . . 116
C.5.3 Interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
C.6 DMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
C.7 ZBT via DMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
C.8 Xilinx ISE en ModelSim . . . . . . . . . . . . . . . . . . . . . . . . . 129
C.9 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
D CD-ROM 130
Bibliografie 131
vii
Lijst van figuren
2.1 De encoder van de H.264/AVC-standaard. . . . . . . . . . . . . . . . 6
2.2 Onderbemonsteringsformaten. . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Sequentie van beelden met onderlinge afhankelijkheden. . . . . . . . . 8
2.4 De opbouw van een QCIF-beeld en een macroblok. . . . . . . . . . . 9
2.5 Overzicht van de intra-voorspelling. . . . . . . . . . . . . . . . . . . . 10
2.6 Overzicht van de inter-voorspelling. . . . . . . . . . . . . . . . . . . . 11
2.7 Tree Structured Motion Compensation. . . . . . . . . . . . . . . . . . 12
2.8 Bidirectionele voorspelling. . . . . . . . . . . . . . . . . . . . . . . . . 13
2.9 Multihypothese voorspelling. . . . . . . . . . . . . . . . . . . . . . . . 13
2.10 Transformaties bij het coderen van een macroblok. . . . . . . . . . . . 14
2.11 Aandeel van de functionele blokken bij intra-codering. . . . . . . . . . 18
3.1 De opbouw van een typische chipsetarchitectuur. . . . . . . . . . . . . 20
3.2 De architectuur van de WildCardTM-II. . . . . . . . . . . . . . . . . . 22
3.3 Kost als functie van het aantal verkochte exemplaren. . . . . . . . . . 23
3.4 ZBT-geheugen in Pipeline modus. . . . . . . . . . . . . . . . . . . . . 25
3.5 ZBT-geheugen in Flow Through modus. . . . . . . . . . . . . . . . . 25
3.6 Leesoperatie bij een DDR-geheugen. . . . . . . . . . . . . . . . . . . . 26
3.7 De systeembus met de voornaamste componenten. . . . . . . . . . . . 27
3.8 De architectuur van de Xilinx r© VirtexTM-II XC2V3000. . . . . . . . . 29
4.1 Zigzag-scan en omgekeerde zigzag-scan. . . . . . . . . . . . . . . . . . 32
4.2 Voorbeeld 4×4-blok. . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.3 Schema van de implementatie van het CABAC-algoritme. . . . . . . . 35
4.4 Het pijplijnmodel van het CABAC-algoritme. . . . . . . . . . . . . . 36
4.5 De temporele decompositie van CAVLC. . . . . . . . . . . . . . . . . 41
viii
4.6 De gepijplijnde decompositie van CAVLC. . . . . . . . . . . . . . . . 42
4.7 Illustratie van CAVLC met het pijplijnmodel. . . . . . . . . . . . . . 42
6.1 Schematische weergave van de positie van de predictiepixels. . . . . . 54
6.2 Richtingen van acht voorspellingsmodi. . . . . . . . . . . . . . . . . . 55
6.3 Schematische weergave van 9 voorspellingsmodi. . . . . . . . . . . . . 57
6.4 Overzicht van de componenten voor de predictie. . . . . . . . . . . . 58
6.5 De pijplijnverwerking voor de intra-codering. . . . . . . . . . . . . . . 59
6.6 Schematisch verwerking in de SAD-component. . . . . . . . . . . . . 61
6.7 Overzicht van gegevensstroom bij intra-codering. . . . . . . . . . . . . 63
6.8 Overzicht van het ontwerp voor intra-codering. . . . . . . . . . . . . . 66
6.9 Overzicht van de aanroepen in de referentiesoftware. . . . . . . . . . . 67
6.10 De volgorde van de macroblokken in een beeld. . . . . . . . . . . . . . 69
6.11 De volgorde van de blokken binnen een macroblok. . . . . . . . . . . 69
6.12 Het gebruik van indices voor de selectie. . . . . . . . . . . . . . . . . 70
6.13 DMA-test bij een DellTM InspironTM 8600. . . . . . . . . . . . . . . . 71
6.14 De synchronisatie tussen de verschillende onderdelen. . . . . . . . . . 73
B.1 Voorbeeld van aritmetische codering. . . . . . . . . . . . . . . . . . . 84
B.2 Encodeerproces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
C.1 SelectRAM in dual-port modus . . . . . . . . . . . . . . . . . . . . . 108
C.2 Schrijven naar SelectRAM . . . . . . . . . . . . . . . . . . . . . . . . 110
C.3 Lezen uit SelectRAM . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
C.4 Schrijven naar het ZBT-geheugen met de Basic Interface. . . . . . . . 112
C.5 Lezen uit het ZBT-geheugen met de Basic Interface. . . . . . . . . . 112
C.6 Schrijven naar het ZBT-geheugen met de Standard Interface. . . . . . 114
C.7 Lezen uit het ZBT-geheugen met de Standard Interface. . . . . . . . . 114
C.8 Register-schrijfoperatie. . . . . . . . . . . . . . . . . . . . . . . . . . . 117
C.9 Register-leesoperatie. . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
C.10 Controller voor DMA-initialisatie. . . . . . . . . . . . . . . . . . . . . 126
C.11 Detectie van DMA-data. . . . . . . . . . . . . . . . . . . . . . . . . . 126
C.12 Versturen van data via DMA. . . . . . . . . . . . . . . . . . . . . . . 127
C.13 Controller voor ZBT via DMA . . . . . . . . . . . . . . . . . . . . . . 128
ix
Lijst van tabellen
2.1 Voornaamste slicetypes in de H.264/AVC-codec. . . . . . . . . . . . . 9
3.1 Karakteristieken van PCMCIA en CardBus. . . . . . . . . . . . . . . 21
4.1 Een voorbeeld van een codering met het CAVLC-algoritme. . . . . . . 40
5.1 Quantisatieparameter en bijhorende quantisatiestap. . . . . . . . . . . 47
5.2 Schalingsfactoren. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.3 Multiplicatiefactoren. . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6.1 Uitvoeringstijden voor de verschillende voorspellingsmethoden. . . . . 54
6.2 DC-voorspelling afhankelijk van beschikbare pixelwaarden. . . . . . . 56
6.3 Gebruikte resources op het WildCardTM-II-bordje. . . . . . . . . . . . 75
6.4 Resultaten van de integratie in referentiesoftware. . . . . . . . . . . . 76
B.1 Eigen-informatie. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
B.2 De Exponentiele Golomb codering van de 0e orde. . . . . . . . . . . . 88
B.3 De UEG0-code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
B.4 Syntax elementen en bijhorende context index γ. . . . . . . . . . . . . 90
B.5 Probabiliteiten volgens Formule B.1. . . . . . . . . . . . . . . . . . . 91
B.6 Aanpassing van de probabiliteitsindex σ. . . . . . . . . . . . . . . . . 92
B.7 RLPS-tabel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
B.8 Waarden van γ voor residuele data (deel 1). . . . . . . . . . . . . . . 97
B.9 Waarden van γ voor residuele data (deel 2). . . . . . . . . . . . . . . 98
B.10 De binarisaties van de coefficienten. . . . . . . . . . . . . . . . . . . . 100
B.11 Waarden van γ bij de significance map. . . . . . . . . . . . . . . . . . 101
B.12 De initiele waarden voor de contextmodellen. . . . . . . . . . . . . . . 101
x
C.1 SelectRAM configuraties . . . . . . . . . . . . . . . . . . . . . . . . . 109
xi
Hoofdstuk 1
Inleiding
Hoewel de transfersnelheid van netwerken en de capaciteit van opslagmedia conti-
nu toenemen, blijven veel onderzoekscentra pogen betere compressietechnieken voor
videocodering te ontwikkelen. Men zou zich dan kunnen afvragen waarom videoco-
dering nog nodig is en waarom nog zo’n inspanningen worden verricht om de huidige
videocodering te verbeteren?
Enerzijds tracht men om digitale video in netwerkomgevingen en opslagomgevin-
gen te ondersteunen, waar het gebruik van niet gecomprimeerde video gewoon on-
mogelijk blijkt. Anderzijds probeert men om de infrastructuur van netwerken en
opslagmedia zo efficient mogelijk te benutten.
Een beeldsequentie kan gecomprimeerd worden door het verwijderen van redundante
informatie. Bij verliesloze compressie wordt enkel statistische redundantie verwij-
derd. De ontvanger is in staat het origineel videosignaal exact te reconstrueren.
Maar door het verwijderen van de statistische redundantie alleen wordt onvoldoen-
de compressie bereikt.
Om een betere codering van videosignalen te verkrijgen, zal een verlieshebbende
compressie op het videosignaal worden doorgevoerd. Het gereconstrueerde video-
signaal aan de ontvangerzijde zal nu verschillen van het origineel videosignaal aan
de zenderzijde. Het doel van videocodering is een efficiente compressie te verkrijgen
waarbij de distorsie (het gevolg van de verlieshebbende compressie) wordt gemini-
maliseerd.
Bij videocompressie met verlies wordt temporele, spectrale en/of spatiale redundan-
tie geelimineerd:
1
• Tussen opeenvolgende beelden in een videosequentie is er vaak veel gelijkenis.
Deze temporele redundantie is eenvoudig verwijderbaar door het beschrijven
van het verschil tussen het huidig beeld en het vorig beeld.
• Het menselijk zicht (Human Visual System of HVS) is minder gevoelig voor
hogere frequenties waaruit volgt dat objecten nog steeds herkenbaar zijn na
de eliminatie van de hoogfrequent informatie. Het toepassen van een LP-filter
is dus de oplossing voor het wegwerken van spectrale redundantie.
• Bij beelden waar weinig variatie voorkomt in bepaalde gebieden, kan men de
spatiale redundantie verwijderen. Een beeldpunt geeft veel informatie over de
omringende beeldpunten.
Door het verwijderen van verschillende vormen van redundantie (temporeel, spec-
traal en spatiaal) is het mogelijk om het videosignaal behoorlijk te comprimeren
met een minimum aan distorsie. Verdere compressie kan bekomen worden door het
coderen van de gecomprimeerde data met behulp van entropiecodering, zoals een
Huffman-codering of een aritmetische codering.
Er wordt nog altijd heel wat onderzoek verricht om de compressie van videosignalen
te verbeteren. De codering van het videosignaal wordt beschreven door een stan-
daard, waarin de gecomprimeerde vorm van het signaal alsook een methode voor
de decodering wordt beschreven. Iedere standaard zorgt dat encoders en decoders
conform de standaard kunnen samenwerken, waardoor onderzoeksteams in univer-
siteiten en bedrijven de vrijheid hebben om op onafhankelijke wijze onderzoek te
verrichten en producten te ontwikkelen.
Dit heeft geleid tot enkele standaarden waaronder MPEG-2 en MPEG-4 van de
International Organization for Standardization (ISO) en H.261 tot H.263 van Inter-
national Telecommunication Union (ITU). Samen hebben zij onlangs een standaard
gedefinieerd voor een buitengewoon efficiente video-codec die gedoopt werd onder
de naam MPEG-4 deel 10 of ITU-T Rec. H.264.
Om die hoge efficientie te verkrijgen, worden zeer verfijnde algoritmes gebruikt die
dan ook bijzonder rekenintensief zijn. Een softwareversie, zoals de referentiesoft-
ware, vergt heel wat processorkracht. Om dit euvel te verhelpen, kan men een
hardwareversneller gebruiken.
2
Een mogelijke hardwareversneller kan bekomen worden door het gebruik van een
Field Programmable Gate Array (FPGA). Dit is een digitale component die kan
geprogrammeerd worden om een welbepaalde functionaliteit te vervullen. Een groot
voordeel bij het gebruik van een FPGA is de relatief korte ontwerpcyclus.
Bij een HW/SW co-design is het de bedoeling bepaalde onderdelen van een algoritme
(de rekenintensieve delen van de H.264/AVC-specificatie) op FPGA te implemente-
ren, waarbij de software ten gepaste tijde de hardwarecomponenten aanspreekt.
Om een succesvolle versnelling te verkrijgen moeten rekenintensieve onderdelen in
de software geıdentificeerd worden. Het meest rekenintensieve onderdeel van de
H.264/AVC-specificatie, de inter-codering van temporele redundantie tussen opeen-
volgende beelden, wordt uitgewerkt in een andere scriptie. In dit afstudeerwerk wor-
den de intra-codering (spatiale redundantie in beelden), de transformatie (spectrale
redundantie in beelden) en de entropiecodering (statistische redundantie) behandeld.
1.1 Doel van dit afstudeerwerk
Het hoofddoel van dit afstudeerwerk is het versnellen van de referentiesoftware die
voorvloeit uit de H.264/AVC-specificatie. Om dit doel te realiseren moeten een
aantal belangrijke stappen worden doorlopen.
• Men moet eerst inzicht verwerven in de referentiesoftware en met behulp van
een analyse de tijdskritische functies bepalen.
• Men moet dan een aantal componenten in hardware ontwerpen die de verwer-
king van deze tijdskritische functies vervullen.
• Men kan deze componenten dan integreren in de referentiesoftware. Enerzijds
wordt vanuit de software een correcte aansturing voorzien van de WildCardTM-
II. Anderzijds wordt in hardware een controlesysteem voorzien met een aantal
controleregisters en dataregisters.
1.2 Structuur van dit afstudeerwerk
Globaal gezien kan dit afstudeerwerk worden opgesplitst in twee grote delen.
3
Enerzijds een theoretisch gedeelte waarin de functionele blokken van de H.264/AVC-
standaard kort worden toegelicht en de architectuur van de WildCardTM-II wordt
beschreven.
Anderzijds worden een aantal projecten uitgewerkt waarin delen uit de referentiesoft-
ware worden geımplementeerd in hardware, waarna eventueel ook nog een integratie
volgt.
In Hoofdstuk 2 wordt een overzicht gegeven van de H.264/AVC-codec. Daarbij
worden de functionele eenheden kort toegelicht. Dit hoofdstuk wordt afgesloten met
een profilering van de H.264/AVC-standaard.
In Hoofdstuk 3 wordt een uiteenzetting gegeven van het WildCardTM-II-platform.
De architectuur en de mogelijkheden van de WildCardTM-II en de FPGA daarin
opgenomen wordt beschreven.
In Hoofdstuk 4 wordt beknopt een theoretische beschrijving gegeven van de beide en-
tropiecoderingen die zijn opgenomen in de H.264/AVC-standaard. Daarnaast wordt
telkens een implementatie in hardware beschreven die poogt zo optimaal mogelijk
te zijn.
In Hoofdstuk 5 wordt de theorie van de transformatie en de quantisatie beschreven.
Daarna volgt een mogelijke implementatie in hardware die in de rest van dit verhaal
zal gebruikt worden. Dit hoofdstuk wordt afgesloten met de integratie waaruit een
aantal belangrijke conclusies volgen.
In Hoofdstuk 6 wordt de intra-codering op een theoretische wijze beschouwd, in
het bijzonder voor de luminantiecomponent op het 4×4-niveau. Daarna wordt een
uiteenzetting gegeven van componenten die gebruikt worden bij de implementatie
in hardware, samen met de interactie met de geheugens. Er wordt bij de integratie
veel aandacht besteed aan de communicatie en synchronisatie tussen de FPGA en
de computer.
Dit afstudeerwerk wordt uiteindelijk afgesloten met een besluit.
Verder zijn in deze scriptie een aantal bijlagen opgenomen.
In Bijlage A wordt een verklarende woordenlijst voorzien.
In Bijlage B wordt het CABAC-algoritme besproken. Dit algoritme is conceptueel
een van de meest complexe coderingsmethoden.
4
In Bijlage C wordt een handleiding voor het gebruik van de WildCardTM-II meege-
leverd.
In Bijlage D wordt een CD-ROM opgenomen met alle projecten en de documenten.
5
Hoofdstuk 2
H.264/AVC-standaard
Het Joint Video Team (JVT), bestaande uit leden van de Moving Picture Experts
Group (ISO/IEC) en de Video Coding Experts Group (ITU-T), werkt sedert 2001 aan
de ontwikkeling van de H.264/AVC-specificatie. Daaruit vloeien twee standaarden,
namelijk MPEG-4 deel 10 en ITU-T Rec. H.264. De fundamentele doelstelling van
de nieuwe standaard is de ontwikkeling van een buitengewoon efficiente video-codec.
transformatiequantisatie
inverse quantisatieinverse transformatie
entropie-codering
motioncompensation
+
-
++
motionestimation
antiblokfilter
intra-codering
Figuur 2.1: De encoder van de H.264/AVC-standaard.
6
In Figuur 2.1 wordt de encoder van de H.264/AVC-standaard afgebeeld. In dit
hoofdstuk worden kort de verschillende functionele blokken besproken. Voor meer
uitleg verwijzen we naar [7] en [9].
2.1 Inleiding
Een videosignaal is een sequentie van beelden. De representatie van de beelden zal
plaatsvinden in de YUV-kleurenruimte. Daarbij wordt de luminantie (helderheid)
van de chrominantie (kleur) gescheiden. Voor de luminantie wordt een component
bijgehouden (Y), voor de chrominantie twee componenten (U en V).
Het voordeel van een voorstelling in de YUV-kleurenruimte is dat de chrominantie-
componenten kunnen voorgesteld worden met een lagere resolutie. Dit staat bekend
als de onderbemonstering van de chrominantie. Het menselijk zicht (HVS of Human
Vision System) is immers minder gevoelig voor chrominantie dan voor luminantie.
In Figuur 2.2 wordt een overzicht gegeven van de meest voorkomende onderbemon-
steringsformaten.
4:4:4 4:2:2 4:2:0
Y-component
U-component
V-component
Figuur 2.2: Onderbemonsteringsformaten.
Een videosignaal kan op verschillende manieren gecodeerd worden. Elk beeld wordt
onderverdeeld in een bepaalde klasse van beelden. De belangrijkste types zijn het
I-beeld, het P-beeld en het B-beeld. Het eerste beeld in een videosignaal is steeds
7
een I-beeld, dit kan enkel via intra-voorspelling worden gecodeerd. De beelden die
daarop volgen zijn P-beelden en/of B-beelden, ze worden gecodeerd gebruikmakend
van de informatie van de reeds gecodeerde beelden. Een mogelijke sequentie van
beelden wordt voorgesteld in Figuur 2.3, een pijl duidt op een afhankelijkheid bij
het codeerproces.
I-beeld B-beeld P-beeld B-beeld P-beeld
Figuur 2.3: Sequentie van beelden met onderlinge afhankelijkheden.
In de H.264/AVC-standaard werd speciale aandacht besteed aan het voorkomen van
foutpropagatie: als er een fout optreedt in een I-beeld of een P-beeld, dan wordt die
gepropageerd doorheen de videosequentie. Als bij de codering van een B-beeld een
fout voorkomt, dan heeft dat geen gevolg in andere beelden aangezien geen enkel
ander beeld afhankelijk kan zijn van een B-beeld.
Twee methoden worden gebruikt om foutpropagatie te verhinderen. De eerste me-
thode is opgebouwd rond het gebruik van een Group Of Pictures (GOP). Een GOP
begint steeds met een I-beeld. Door het opsplitsen van de videosequentie in groepen
zal nu geregeld een I-beeld worden gecodeerd, waarop de achterliggende beelden zich
zullen baseren bij de codering. De fout propageert nu niet meer verder.
Daarnaast kan een beeld in meerdere slices worden onderverdeeld, die men dan
onafhankelijk gaat coderen. Ook de decodering van de verschillende slices zal onaf-
hankelijk verlopen zodat een fout in een slice niet tot gevolg heeft dat andere slices
fouten vertonen. Dit is een zekere vorm van foutbestendigheid binnen een beeld.
Een slice bestaat uit de groepering van een aantal macroblokken. In Tabel 2.1
worden de voornaamste slicetypes voorgesteld, en de macroblokken waaruit de slices
kunnen worden opgebouwd.
De opbouw van een QCIF1-beeld (formaat van 176×144 pixels) wordt afgebeeld in
1QCIF staat voor Quarter Common Intermediate Format.
8
slicetype macrobloktypeI-type I-macroblokP-type I-macroblok & P-macroblokB-type I-macroblok & P-macroblok & B-macroblok
Tabel 2.1: Voornaamste slicetypes in de H.264/AVC-codec.
Figuur 2.4. Het beeld bestaat uit een rooster van 99 macroblokken van 16 bij 16
pixels. Elk macroblok bevat drie componenten: een luminantiecomponent (Y) van
16 bij 16 pixels en twee chrominantiecomponenten (U en V) van 8 bij 8 pixels, bij
een onderbemonstering 4 : 2 : 0.
11
9
QCIF-beeld
Y
Macroblok16
16
U
8
8 V
8
8
Figuur 2.4: De opbouw van een QCIF-beeld en een macroblok.
Na deze korte introductie is voldoende terminologie verduidelijkt om de functionele
blokken van de H.264/AVC-standaard kort toe te lichten.
2.2 Intra-codering
De werking van intra-voorspelling wordt afgebeeld in Figuur 2.5. Op basis van
omringende pixels in hetzelfde beeld wordt een reeks voorspellingen uitgewerkt.
Een blok van het origineel beeld wordt aangeboden, waarvan de beste voorspelling
wordt afgetrokken. De residuwaarden worden getransformeerd en gequantiseerd en
9
vervolgens aangeboden voor entropiecodering. Het resultaat van de entropiecodering
wordt uiteindelijk opgeslagen of doorgestuurd naar de decoder.
De getransformeerde en gequantiseerde gegevens worden ook onderworpen aan hun
inverse bewerkingen, waarna het resultaat wordt opgeteld bij de beste voorspelling.
Op deze geınverteerde waarden zal de intra-coder zich baseren voor verdere voor-
spellingen. Dit gebeurt om foutdrift te voorkomen aan de decoderzijde. De decoder
beschikt immers enkel over de getransformeerde coefficienten, niet over de originele
pixelwaarden!
transformatiequantisatie
inverse quantisatieinverse transformatie
entropie-codering
intra-voorspelling
+
-
++
Figuur 2.5: Overzicht van de intra-voorspelling.
De H.264/AVC-standaard beschrijft voor de intra-voorspelling twee modi, namelijk
intra-codering van een 4×4-blok en intra-codering van een 16×16-blok. Beide modi
zijn van toepassing op I-macroblokken, die in alle slicetypes voorkomen.
We beschouwen een I-macroblok. De luminantiecomponent bestaat uit een 16 bij
16 matrix. Daarvoor bestaan twee manieren van intra-codering, enerzijds de intra-
codering van de 16 4×4-blokken (9 voorspellingsmodi) en de intra-codering van een
16×16-blok (4 voorspellingsmodi). Iedere chrominantiecomponent bestaat bij een
onderbemonsteringsformaat 4 : 2 : 0 uit een matrix van 8 bij 8 pixels. Daarvoor
bestaat een intra-voorspelling op een 4×4-blok (4 voorspellingsmodi).
10
2.3 Inter-codering
De werking van inter-voorspelling wordt geıllustreerd in Figuur 2.6. Er wordt een
blok van het origineel beeld aangeboden. Via Motion Estimation/Motion Compen-
sation wordt een voorspelling gedaan door het zoeken van een beste match in de
referentiebeelden. Het verschil tussen de voorspelling en het origineel blok wordt
getransformeerd en gequantiseerd. Op dat resultaat wordt het functionele blok voor
de entropiecodering losgelaten, waaruit een bitstring volgt.
Het getransformeerde en gequantiseerde blok wordt onderworpen aan zijn inver-
se bewerking, waarna het resultaat van die bewerking wordt opgeteld bij de beste
voorspelling. Vervolgens wordt daarop het antiblokfilter losgelaten, dit om artefac-
ten van de blokgebaseerde codering te onderdrukken. Het resultaat van het filter
wordt gebruikt voor toekomstige zoekacties naar optimale voorspellingen.
transformatiequantisatie
inverse quantisatieinverse transformatie
entropie-codering
motioncompensation
+
-
++
motionestimation
antiblokfilter
Figuur 2.6: Overzicht van de inter-voorspelling.
De inter-codering bij de H.264/AVC-standaard is gelijkaardig aan die opgenomen
in eerdere standaarden. Toch zijn enkele wijzigingen doorgevoerd die een betere
compressie mogelijk maken. Een nadeel hiervan is de toegenomen complexiteit,
waardoor het algoritme zeer rekenintensief is geworden.
11
Een van de vernieuwingen maakt het mogelijk om een macroblok op te splitsen
tot partities en subpartities. De partitionering wordt uitgevoerd in twee fases. In
een eerste fase wordt een macroblok onderverdeeld in een partitie van 16×16, twee
partities van 16×8 of 8×16 of vier partities van 8×8. In een tweede fase wordt een
partitie verder opgesplitst tot een subpartitie van 8×8, twee subpartities van 8×4
of 4×8 of vier subpartities van 4×4. Dit staat bekend als Tree Structured Motion
Compensation en wordt voorgesteld in Figuur 2.7.
0
0
1
0 1
0
2
1
3
16x16 16x8 8x16 8x8
Partities
0
0
1
0 1
0
2
1
3
8x8 8x4 4x8 4x4
Subpartities
Figuur 2.7: Tree Structured Motion Compensation.
Voor iedere partitie en iedere subpartitie moet een afzonderlijke bewegingsvector en
een index van het referentiebeeld worden verstuurd. Enkel de luminantiecomponent
wordt gecodeerd; de bewegingsvectoren voor de chrominantiecomponenten kunnen
worden afgeleid uit de bewegingsvector van de luminantiecomponent. Hierbij wordt
de horizontale component en de verticale component van de bewegingsvector van de
luminantie gehalveerd bij een onderbemonstering 4 : 2 : 0.
Daarnaast beschikt men nog over een skipmodus, waarbij geen macroblokdata wordt
verstuurd. Men neemt dan een kopie van het macroblok in het vorig beeld op dezelfde
positie.
Voor een P-macroblok wordt een referentiebeeld gekozen uit een lijst. Men kan echter
12
zoeken in verschillende beelden, wat de kans op een betere match vergroot. Maar
uiteindelijk wordt slechts een bewegingsvector verzonden. Het algoritme ligt niet
vast, men heeft hier alle vrijheid. De meest voorkomende algoritmes zijn sequential
search, logaritmic search en hierarchical search.
Voor een B-macroblok wordt een lineaire combinatie voorzien van twee bewegings-
vectoren uit twee lijsten. Men onderscheidt volgende twee gevallen.
Men kan een lineaire combinatie nemen van een voorwaartse voorspelling en een ach-
terwaartse voorspelling. Dit is een bidirectionele voorspelling en wordt geıllustreerd
in Figuur 2.8.
P-beeld B-beeld P-beeld P-beeldB-beeld
Figuur 2.8: Bidirectionele voorspelling.
Men kan ook een lineaire combinatie nemen van twee voorwaartse of twee achter-
waartse voorspellingen. Dit is een multihypothese voorspelling en wordt afgebeeld
in Figuur 2.9.
P-beeld B-beeld P-beeld P-beeldB-beeld
Figuur 2.9: Multihypothese voorspelling.
13
2.4 Transformatie en quantisatie
De H.264/AVC-standaard beschrijft drie types van transformaties:
• Een Hadamard-transformatie op een 4×4-blok van DC-coefficienten van de
luminantiecomponent.
• Een Hadamard-transformatie op een 2×2-blok van DC-coefficienten van de
chrominantiecomponent.
• Een geheelwaardige Discrete Cosinus Transformatie (DCT) op een 4×4-blok
van residuele waarden.
De transformaties die plaatsgrijpen bij het coderen van een macroblok worden weer-
gegeven in Figuur 2.10.
0 1 4 5 18 19
20 21
-1 16 17
2 3 6 7
8 9 12 13
10 11 14 15
22 23
24 25
Y-component
U-component V-component
Figuur 2.10: Transformaties bij het coderen van een macroblok.
Om te beginnen worden in totaal 24 DCT-transformaties verricht op de 4×4-blokken
van de luminantiecomponent en de chrominantiecomponenten (0-15,18-25). De DC-
coefficienten worden samengevoegd en daarop wordt een Hadamard-transformatie
van 4×4 (-1) of 2×2 (16,17) uitgevoerd. Enkel bij de intra-codering op 16×16-
niveau wordt een Hadamard-transformatie op de 4×4-matrix van DC-coefficienten
14
uitgevoerd, in alle andere gevallen niet. De andere transformaties worden altijd
voltooid.
De gewijzigde DCT-transformatie maakt een verliesloze compressie mogelijk, aan-
gezien enkel geheelwaardige operaties op de coefficienten worden toegepast. Bij de
standaard transformatie is een exacte reconstructie niet steeds mogelijk wegens het
verlies aan informatie door afrondingsfouten.
De H.264/AVC-standaard definieert ook een scalaire quantisatie. Men heeft 52
quantisatieniveaus gedefinieerd die leiden tot een verschillende compressie. Er wordt
eigenlijk een deling uitgevoerd op de coefficienten. Hoe sterker de deling, hoe minder
informatie overblijft voor de codering, hoe lager de uitgestuurde bitsnelheid, maar
hoe slechter de kwaliteit van het videosignaal.
2.5 Entropiecodering
Uit de vorige stap verkrijgen we de getransformeerde en gequantiseerde coefficienten
in 4×4-blokken. We willen nu deze informatie in matrixvorm zo efficient mogelijk
beschrijven, deze statistische codering wordt entropiecodering genoemd.
De H.264/AVC-standaard voorziet in twee methoden voor de entropiecodering, na-
melijk CAVLC (Context-based Adaptive Variable Length Coding) en CABAC (Context-
based Adaptive Binary Arithmetic Coding).
CAVLC
CAVLC is een Huffman-codering, behorende tot de klasse van variable lengte code-
ringen. Aan alle symbolen wordt een variabele lengte code gekoppeld. Veelvuldig
voorkomende symbolen worden geassocieerd met korte codes, sporadisch voorko-
mende symbolen worden gerepresenteerd met langere codes.
De Huffman-codering introduceert twee problemen bij een video-codec. Ten eer-
ste moet de decoder hetzelfde codewoord gebruiken als de encoder. Daarom moet
de probabiliteitstabel die wordt opgemaakt tijdens de codering eveneens worden
doorgestuurd waardoor een grotere overhead ontstaat. Ten tweede kan die proba-
biliteitstabel enkel worden verstuurd nadat het complete videosignaal is gecodeerd.
Dit levert een belangrijke vertraging op, die niet kan getolereerd worden.
15
Daarom worden probabiliteitstabellen gebruikt die werden opgesteld voor een ty-
pisch videosignaal. Bij de codering van een 4×4-matrix worden die tabellen geraad-
pleegd, waardoor de eigenlijke entropiecodering herleid wordt tot enkele opzoekin-
gen.
Met de CAVLC entropiecodering wordt een doorgedreven compressie bekomen door
gebruik te maken van de kenmerken van een getransformeerd en gequantiseerd 4×4-
blok.
Ten eerste zijn de 4×4 blokken typisch schaars. Het grote aantal nullen kan dan zeer
efficient worden gecodeerd in run/level-formaat.
Ten tweede concentreren de meeste coefficienten verschillend van nul zich bij de lage
frequenties. Bij de hogere frequenties komen vooral nullen en enen voor.
Ten derde kunnen de enen bij hogere frequenties heel compact worden gecodeerd.
Men zal enkel het teken bijhouden.
Ten vierde zal het aantal coefficienten in het huidige 4×4-blok sterk gecorreleerd zijn
aan het aantal coefficienten in naburige 4×4-blokken.
Een belangrijk nadeel is het suboptimale karakter van deze codering omdat een
geheel aantal bits wordt gekoppeld aan een symbool. Teneinde een nog betere
efficientie te bereiken kan een aritmetische codering worden gebruikt.
CABAC
CABAC is een aritmetische codering. Typisch wordt met een aritmetische codering
een betere compressie bereikt dan met variabele lengte codes. Het nadeel is de
bijkomende rekenkracht nodig voor de codering.
Aritmetische codering komt tegemoet aan een aantal tekortkomingen van variabele
lengte codes. Ten eerste kan een niet-geheel aantal bits worden toegekend aan een
symbool. Bovendien kan een aritmetische coder zich eenvoudig aanpassen aan de
wijzigende statistiek binnen een beeld, daar waar de tabellen bij variabele lengte
codes constant blijven.
De efficientie van CABAC wordt bereikt door het gebruik van een uitgebreide ver-
zameling contextmodellen, die na het coderen van elk symbool worden aangepast.
In Appendix B wordt het CABAC-algoritme in detail besproken.
16
2.6 Profielen
De H.264/AVC-standaard beschrijft drie profielen die specifiek voor een welbepaalde
klasse van toepassingen ontwikkeld zijn. Ieder profiel selecteert een subset van de
mogelijkheden van de H.264/AVC-standaard om zodoende zo optimaal mogelijk
aan de vereisten van die welbepaalde toepassing te voldoen. In onderstaande tabel
worden de voornaamste kenmerken van de profielen weergegeven.
Baseline Main Extended
I-frame X X X
P-frame X X X
B-frame X X
SI-frame X
SP-frame X
CAVLC X X
CABAC X
Het Baseline-profiel wordt vooral gebruikt bij toepassingen voor de uitwisseling
van informatie op interactieve of bidirectionele wijze zoals videoconferencing. De
complexiteit van de encodering en de decodering moet zo minimaal mogelijk worden
gehouden, daardoor blijft interactiviteit gegarandeerd.
Het Main-profiel wordt gebruikt bij broadcast en entertainment toepassingen. In dit
geval is een efficiente codering uitermate belangrijk om de netwerkbandbreedte en de
opslagcapaciteit zuinig te benutten. De keerzijde van de medaille is de toegenomen
complexiteit zodat meer rekenkracht geen overbodige luxe zal zijn.
Het Extended -profiel wordt gebruikt bij streaming media. De bijkomende functiona-
liteit moet bijdragen tot een efficienter transport over netwerken en de mogelijkheid
tot het overschakelen tussen verschillende videostromen.
2.7 Profilering
Omdat in deze thesis de inter-codering niet wordt beschouwd (deze wordt onderzocht
in andere scripties), zullen we bij de profilering van de referentiesoftware enkel intra-
gecodeerde beelden onderzoeken.
17
Bij het coderen kunnen een groot aantal parameters worden ingesteld, zodat de
coderingstijd sterk kan varieren. De codering is bijvoorbeeld afhankelijk van de
quantisatieparameter (QP). QP kan een waarde tussen 0 en 51 aannemen. Het
spreekt voor zich dat een grotere QP (een ruwere quantisatie) zal aanleiding geven
tot minder resterende informatie, zodat het relatieve belang van de entropiecodering
zal verminderen. Of: hoe minder informatie er moet gecodeerd worden, hoe minder
lang de codering zal duren. We zullen daarom een algemeen beeld schetsen dat
voldoet voor het merendeel van de gecodeerde sequenties.
Voor een sequentie van 100 intra-gecodeerde beelden in QCIF-formaat verkrijgen we
volgende resultaten.
Intra-voorspelling
Transformatie en quantisatie
Entropiecodering
Overige
Figuur 2.11: Aandeel van de functionele blokken bij intra-codering.
De relatieve belangen van de functionele blokken worden hieruit duidelijk. Vooral de
intra-voorspelling (ongeveer 40%) en de entropiecodering (35 %) vallen hierbij op.
De transformatie en quantisatie (inclusief de inverse transformatie en quantisatie)
nemen ongeveer 15 % van de tijd in. De intra-voorspelling zal steeds het grootste
deel van de tijd innemen. De entropiecodering zal daarentegen aan belang inboeten
wanneer een grotere quantisatieparameter wordt gebruikt (in dit geval is QP = 10).
18
Hoofdstuk 3
WildCard-II
In dit hoofdstuk bespreken we beknopt het WildCardTM-II-platform1. Dit platform
werd ontwikkeld door Annapolis Micro Systems Inc. (http://www.annapmicro.com),
een bedrijf dat zich mengt op de markt van de Reconfigurable Computing Engines.
We starten met een korte beschrijving van de testopstelling, waarna twee iets meer
technische delen volgen. In het eerste deel wordt kort de architectuur van het
WildCardTM-II-platform geschetst, vervolgens wordt in een tweede deel de program-
meerbare component besproken, die de krachtbron van de WildCardTM-II vormt.
3.1 Testopstelling
Hardware
De testmachine is een DellTM InspironTM 8600 laptop. Deze heeft als processor een
Intel r© Pentium r©-M 1,5 GHz aan boord, en 512 MB geheugen. Het besturingssys-
teem Microsoft r© Windows r© XP is hierop geınstalleerd.
De WildCardTM-II is een apparaat met een CardBus-interface. Het is dus ideaal
geschikt voor draagbare computers. De positie van de WildCardTM-II binnen de
chipsetarchitectuur wordt afgebeeld in Figuur 3.1 (Meer informatie op [6]).
De verbindingen tussen de North Bridge enerzijds en de processor, het hoofdgeheu-
gen en de grafische kaart anderzijds zijn zeer krachtig. Een van de connecties met
1Met het WildCardTM-II-platform wordt de CardBus-insteekkaart bedoeld.
19
CPU
NorthBridge
SouthBridge
MainMemory
Graphics
PCIto
CardBus
PCI
ISA
WildCardII
chipset
Figuur 3.1: De opbouw van een typische chipsetarchitectuur.
de South Bridge wordt de PCI-interface genoemd. Dit is een bus werkzaam bij een
klokfrequentie van 33 Mhz of 66 MHz en een busbreedte van 32 bits of 64 bits. Dit
levert snelheden op van 132, 264 of 528 MB/s. Daar situeert men de PCI-to-CardBus
adapter.
Van waar komt nu die CardBus?
In 1990 werd een technologie ontwikkeld om draagbare computers te voorzien van
meer geheugen. Men doopte het kind tot Personal Computer Memory Card In-
ternational Association (PCMCIA). Al snel werd ingezien dat die interface ook kan
gebruikt worden voor I/O-apparaten. Later bleek dat de capaciteit van de PCMCIA-
interface ontoereikend was. Men besloot om een nieuwe technologie te ontwikkelen,
de opvolging was voorzien. De CardBus-interface werd ontwikkeld in het jaar 1995
met als hoofddoel een behoorlijke toename van de bandbreedte. De belangrijkste
karakteristieken van beide technologieen kan men vinden in Tabel 3.1.
20
technologie PCMCIA CardBusinterface 68-pins 68-pins
buskloksignaal 10 MHz 33 MHzbusbreedte 16-bits 32-bits
transfersnelheid 20 MB/s 132 MB/s
Tabel 3.1: Karakteristieken van PCMCIA en CardBus.
Software
Tijdens het ontwikkelingsproces werden onderstaande softwarepakketten gebruikt.
• Aldec Active-HDLTM 5.1 en 6.1 : bouwen en simuleren van componenten, dit
totaal onafhankelijk van de technologie waarvoor het ontwerp dient.
• Modelsim r© 5.7 : simuleren van een compleet ontwerp specifiek voor de ge-
bruikte technologie.
• Xilinx r© ISE 6 : synthetiseren van een compleet ontwerp voor een specifieke
technologie, dit is het converteren van het ontwerp naar een bitstroom waarmee
de FPGA kan worden geprogrammeerd.
• Microsoft r© Visual Studio r© 6.0 : ontwikkelen van applicaties voor het pro-
grammeren van de WildCardTM-II, waaronder de testprogramma’s en de refe-
rentiesoftware.
Daarnaast werd ook nog gebruikgemaakt van software voor analyse van projecten.
Om meer inzicht te verkrijgen in de structuur van de referentiesoftware werd het
pakket VTuneTM Performance Analyzers van Intel r© gebruikt. Voor meer informatie
verwijzen we de lezer naar [5].
Dit pakket laat de gebruiker toe een uitgebreide analyse van een softwareproject uit
te voeren om eventuele bottlenecks op te sporen. Daarbij wordt een graaf opgesteld
die een overzicht geeft van de oproepen naar functies. Over de functies worden karak-
teristieke gegevens bijgehouden zoals het aantal oproepen, de uitvoeringstijd,. . .Wij
hebben dit pakket voornamelijk gebruikt voor de analyse van de referentiesoftware.
Hierdoor werd het mogelijk om de tijdskritische functies te identificeren.
21
3.2 Architectuur van de WildCard-II
De WildCardTM-II is een platform met een CardBus-interface dat ontwikkeld is rond
een programmeerbare component. De architectuur van de WildCardTM-II wordt
schematisch weergegeven in Figuur 3.2.
DDRSDRAM64 MB
ZBTSRAM2 MB
FPGAProcessing
Element
Virtex-IIXC2V3000
CardBusController
CardBus
Figuur 3.2: De architectuur van de WildCardTM-II.
Op de WildCardTM-II zijn een aantal geheugens opgenomen voor allerhande doel-
einden, enerzijds een Zero Bus Turnaround (ZBT) geheugen van 2 MB en anderzijds
een Double Data Rate (DDR) geheugen van 64 MB.
De architectuur wordt opgebouwd rond een programmeerbare component, bij de
WildCardTM-II is dit een Field Programmable Gate Array (FPGA). Dit is een chip
met een specifieke structuur, die behoort tot de klasse van de volatile componenten.
Een herprogrammering is noodzakelijk na een stroomonderbreking.
22
Wanneer het ontwerp op punt staat en getest werd in simulatie kan het gesynthe-
tiseerd worden voor de FPGA in kwestie. Het resultaat is een bitstroom waarmee
de FPGA kan geprogrammeerd worden. De programmeerbare component vertoont
dan het gewenste gedrag.
Het gebruik van een FPGA heeft een aantal voordelen ten opzichte van het ontwik-
kelen van een Application-Specific Integrated Circuit (ASIC2):
• De Non-Recurring Engineering (NRE) kost is tamelijk klein in vergelijking met
de ontwikkeling van een ASIC. De NRE-kost is het geheel aan kosten voor de
ontwikkeling van het product, zonder een exemplaar verkocht te hebben. In
Figuur 3.3 wordt een grafiek afgebeeld van de kost als functie van het aantal
verkochte exemplaren.
kost
aantal
FPGA
ASIC
ca. 106
NREASICNREFPGA
Figuur 3.3: Kost als functie van het aantal verkochte exemplaren.
• De ontwerpcyclus is ook een stuk korter in vergelijking met het langdurige
ontwerp van een ASIC. De ontwikkelcyclus duurt enkele weken bij een FPGA-
toepassing tegenover enkele maanden voor een ASIC-ontwerp.
Een nadeel is dat men bij het ontwerp van een ASIC een grotere vrijheid heeft voor
de keuze van geheugen en logica, terwijl men bij een FPGA meer gebonden is aan
de beschikbare logica.
2Een ASIC is een chip die specifiek ontworpen is voor een welbepaalde toepassing (op maatgemaakt).
23
Het is ook zo dat de snelheid op FPGA nooit in de buurt zal komen van de snelheid
van een ASIC. Tegenwoordig zijn er FPGA’s op de markt met kloksnelheden tot
500 MHz, waar ASIC’s een klokfrequentie kunnen hebben tot ongeveer 5 GHz.
ZBT-geheugen
Het ZBT-geheugen is een synchroon statisch geheugen waarbij geen tijd verloren
gaat bij het wisselen tussen het lezen en het schrijven. Dit in tegenstelling tot
andere geheugens waar steeds enkele klokcycli verloren gaan bij de wisseling van
de gegevensoverdracht. Dit geheugen is dan ook zeer interessant voor welbepaalde
toepassingen, denken wij daarbij vooral aan geheugens in netwerkapparatuur (een
switch, een router,. . . ), waar zeer afwisselend geschreven en gelezen wordt.
Bij het schrijven naar het ZBT-geheugen wordt een 32-bit woord aangelegd aan
de datalijnen. De gebruiker heeft de keuze welke bytes effectief naar het geheugen
moeten weggeschreven worden. Dit wordt gerealiseerd door 4 bitlijnen waarbij elke
byte van de databus wordt gecontroleerd door zo’n bitlijn. Daarbij komt dat men
naar eigen keuze ook een pariteitsbit kan gebruiken per byte, waardoor een grotere
foutbestendigheid wordt verkregen.
Het geheugen kan op twee manieren worden aangestuurd, in de Pipeline modus of
de Flow Through modus. In beide modi is het schrijfgedrag gelijkaardig aan het
leesgedrag. Bij het schrijfgedrag legt men de data aan op het ogenblik dat men de
data ziet verschijnen bij het leesgedrag. Enkel het leesgedrag wordt hier beschouwd.
In de Pipeline modus verschijnt de data twee klokcycli na het aanleggen van de
signalen voor het adres en de controle. Bij deze modus is het geheugen werkzaam
bij hogere klokfrequenties, maar moet men toch genoegen nemen met de grotere
wachttijd bij geheugenoperaties. In Figuur 3.4 wordt dit schematisch weergegeven.
In de Flow Through modus zal de data al na een klokcyclus ter beschikking zijn,
maar moet de component geklokt worden aan een lagere frequentie. In Figuur 3.5
wordt dit gedrag afgebeeld.
De geınteresseerde lezer verwijzen we voor meer informatie naar de datasheet [3].
24
Clk
Adres
WE
Data In
Data Out
A4 A5 A6 A7
D3 D5
D2 D4
Figuur 3.4: ZBT-geheugen in Pipeline modus.
Clk
Adres
WE
Data In
Data Out
A4 A5 A6 A7
D3 D5
D4 D6
Figuur 3.5: ZBT-geheugen in Flow Through modus.
DDR-geheugen
Het DDR-geheugen is een dynamisch geheugen, het is typisch zeer groot en relatief
goedkoop. Het gebruik van een dynamisch geheugen verschilt fundamenteel in het
gebruik van een statisch geheugen. Hieronder volgt een korte uiteenzetting over het
algemeen gebruik van een DDR-geheugen.
Een dynamisch geheugen is opgebouwd als een grote matrix van condensatoren waar-
bij iedere condensator wordt aangestuurd door een individuele transistor. De lading
aanwezig op de condensator stelt de opgeslagen informatie voor. Bij het lezen van
de informatie gaat de lading op de condensator verloren, zodat die noodgedwongen
moet worden hersteld.
Het adresseren verloopt in twee stappen zoals aangegeven in Figuur 3.6. Terwijl
men het Row Address Strobe (RAS) signaal laag houdt, wordt het rij-adres aan-
geboden. Even later wordt het kolom-adres aangeboden waarna men het Column
25
Address Strobe (CAS) signaal laag brengt. Daarna verschijnt de gewenste data aan
de uitgang. Dit is het typisch verloop van een leesoperatie bij DDR-geheugen.
Adres
RAS
CAS
Datadata
rij-adres kolom-adres
Figuur 3.6: Leesoperatie bij een DDR-geheugen.
Wanneer gelezen wordt van opeenvolgende adressen, heeft men heel wat voordelen
met DDR-geheugens. Het rij-adres wordt eerst aangelegd zoals hoger. Daarna wordt
het kolom-adres aangeboden. Door enkel het kolom-adres te incrementeren worden
opeenvolgende geheugenlocaties gelezen of geschreven.
Een refresh cycle is ook vereist omdat de lading op de condensator verdwijnt na
verloop van tijd. Daarom wordt intern een circuit voorzien dat een woord leest en
het daarna terugschijft. Zo blijft de informatie in het geheugen bestaan.
Omdat in dit afstudeerwerk geen gebruik wordt gemaakt van het DDR-geheugen,
wordt hier niet dieper op ingegaan. De geınteresseerde lezer verwijzen we voor meer
informatie naar de datasheet [1].
DMA-geheugenoperaties
Voor de overdracht van gegevens heeft de gebruiker de keuze tussen twee mechanis-
men, namelijk geprogrammeerde I/O en Direct Memory Access (DMA). We bespre-
ken kort geprogrammeerde I/O, daarna volgt het DMA-mechanisme.
Bij geprogrammeerde I/O leest de processor een woord uit het geheugen van de
computer en schrijft dat woord daarna weg naar het geheugen op de WildCardTM-
II. Dit neemt twee buscycli in beslag. Erger nog, de processor zal in een actieve lus
blijven vragen aan het apparaat wanneer het volgend woord mag verstuurd worden.
De processor blijft gedurende de gehele operatie bezet.
26
Een DMA-transactie is essentieel om grote blokken gegevens te verzenden naar een
van die geheugens zonder daarbij veel processorcycli te verspillen, zoals het geval is
bij geprogrammeerde I/O.
Een algemene structuur voor de overdracht van een groot geheugenblok van het
hoofdgeheugen van de computer naar een van de geheugens in de WildCardTM-II
wordt hieronder geschetst.
We beschikken over een fysieke adresruimte van 4 GB. In die geheugenruimte wordt
het hoofdgeheugen van de computer ondergebracht in de onderste gelederen, in het
geval van 512 MB geheugen wordt dit afgebeeld op de adressen 0 tot 536 870 911.
Andere apparaten beschikken ook over een adresbereik dat ook moet ondergebracht
worden in die ene adresruimte.
CPU
geheugen FPGA
Figuur 3.7: De systeembus met de voornaamste componenten.
In Figuur 3.7 wordt conceptueel de systeembus afgebeeld. Een heleboel componen-
ten zijn aan die bus aangesloten. Slechts een component kan de bus tegelijk aanstu-
ren (master), de andere componenten zijn een en al oor (slave). Een mechanisme
werd ontwikkeld om de aanvragen voor het aansturen van de bus te behandelen, die
component krijgt meestal de naam “bus arbiter”. Meestal zal de processor als master
een geheugentransactie verrichten. Maar soms zijn andere configuraties mogelijk.
Wat gebeurt er nu bij een DMA-operatie waarbij de WildCardTM-II wordt betrok-
ken?
27
De computer start de DMA-transactie door het doorsturen van het bronadres, het
doeladres en het aantal te kopieren bytes naar de DMA-controller. Hier komt het
systeem van slechts een adresruimte echt van pas. De DMA-controller start de over-
dracht van gegevens van het bronadres naar het doeladres voor een totaal van het
opgegeven aantal bytes. Als de overdracht is afgelopen, wordt een interrupt gege-
nereerd. De interrupt wordt opgevangen door de interruptcontroller die vervolgens
een interrupt genereert voor de processor.
De interrupt wordt in de processor volgens de gekende methode afgehandeld. De
context van het actieve proces wordt opgeslagen. Men zoekt met de interrupt in een
tabel met interruptvectoren en men bekomt uiteindelijk een interruptvector. Door
de verwijzing van de interruptvector wordt een interruptroutine opgeroepen. Die zet
een variabele in kernel space. Vervolgens wordt de context van een proces3 geladen
en kan de verwerking weer aanvatten.
Op het ogenblik dat in de software een API-functie wordt aangeroepen om de status
van de interrupt te controleren, wordt een functie in kernel-space opgeroepen die de
variabele gaat verifieren. Als de variabele niet gezet werd, dan blokkeert die functie.
Is dit niet het geval, dan weet men in het proces dat de DMA-transactie afgelopen
is en kan men overgaan naar de volgende instructie.
3.3 Xilinx Virtex-II XC2V3000
Een FPGA is een elektronische component die de gebruiker naar eigen keuze kan
herprogrammeren. Een algemeen overzicht van de architectuur van een FPGA wordt
afgebeeld in Figuur 3.8.
Interconnecties
Voor de communicatie met de buitenwereld is de FPGA voorzien van een groot
aantal pinnen. Zo’n pin wordt meestal aangeduid als een Input/Output Block (IOB)
en kan dienen voor zowel invoer als uitvoer. De pinnen kunnen geclassificeerd worden
met betrekking tot de aansturing van het DDR-geheugen, het ZBT-geheugen of de
connectie met de hostmachine.
Daarnaast is een uitgebreid interconnectiesysteem aangebracht op de FPGA dat zal
instaan voor de verbindingen tussen de verschillende componenten. Dit geheel aan
3Welk proces wordt geladen hangt af van de scheduler.
28
CLB
IOB
DCM
SelectRAM
Vermenigvuldiger
...
... ...1
2
3
4
5 1
2
3
4 5
Figuur 3.8: De architectuur van de Xilinx r© VirtexTM-II XC2V3000.
mechanismen voor de connectie tussen allerlei componenten op de FPGA wordt de
General Routing Matrix (GRM) genoemd.
Rekenkracht
De rekenkracht van de FPGA komt voornamelijk van de Configurable Logic Blocks
(CLB’s). Ze worden typisch in een regelmatig rooster geplaatst en kunnen gaan
van enkele honderden tot enkele duizenden. Een CLB is opgebouwd uit een aantal
slices, die op hun beurt kunnen opgesplitst worden in een combinatorisch deel en
een sequentieel deel.
Het combinatorisch deel is opgebouwd rond een aantal functiegeneratoren, die als
look-up table (LUT), als shift register of als 16-bit distributed SelectRAM kunnen
fungeren. Het sequentieel deel bevat een aantal geheugenelementen, dit zijn flank-
gestuurde D-type flipflops. Het geheel wordt verbonden met een reeks connecties en
multiplexers. Daarnaast zijn nog een heleboel 18-bits vermenigvuldigers opgenomen
die geoptimaliseerd zijn voor snelheid en vermogenverbruik.
29
Geheugen
Ook op de FPGA zijn een reeks kleine geheugens opgenomen, die worden aangeduid
met de term SelectRAM. Die geheugens hebben een omvang van 512 woorden van
32 bits4, aangevuld met 4 pariteitsbits. De geheugens zijn van het dual-port type
waardoor twee gelijktijdige operaties kunnen uitgevoerd worden. Ze liggen verspreid
over de FPGA en zijn werkzaam bij de klokfrequentie die opgelegd wordt aan de
FPGA.
Klokbeheerder
Een Digital Clock Manager (DCM) is in staat enkele belangrijke operaties op klok-
signalen te verrichten.
• Clock de-skew : het genereren van nieuwe kloksignalen die gealigneerd zijn met
betrekking tot de aangelegde ingangsklok.
• Frequency synthesis : het genereren van nieuwe klokken vertrekkende van de
ingangsklok, door het opgeven van een multiplicator.
• Phase Shifting : het voorzien in grove of fijne verschuiving van de ingangsklok
en dit op dynamische wijze voor de compensatie van schommelingen in de
spanning of de temperatuur.
Voor meer informatie over Xilinx r© VirtexTM-II XC2V3000 verwijzen we de geınteresseerde
lezer naar [2].
Daarnaast verwijzen we naar Bijlage C voor de technische handleiding. Daarin
worden enkele richtlijnen gegeven die een ontwerper helpen bij het ontwikkelen van
Hardware/Software-projecten met behulp van de WildCardTM-II. Die kennis is de
sleutel voor een succesvol ontwerp. Het heeft de auteurs van deze scriptie dan ook
bloed, zweet en tranen gekost om die kennis te verzamelen. Voor gedetailleerde
informatie omtrent WildCardTM-II verwijzen we ook naar [4].
4De SelectRAM-blokjes kunnen ook andere configuraties aannemen [2].
30
Hoofdstuk 4
Entropiecodering
De laatste stap van de H.264/AVC-codering is de entropiecodering. Fundamen-
teel verschillend met eerdere standaarden is de H.264/AVC-standaard, in die zin
dat hier twee totaal verschillende coderingen voorzien zijn. Enerzijds behoudt men
een meer traditionele Huffman-codering, anderzijds wordt een aritmetische codering
opgenomen. De gebruiker heeft dus vrij de keuze tussen het relatief snelle CAVLC-
algoritme, en het iets efficientere (qua compressie), maar tragere CABAC-algoritme.
Hierna volgt een bespreking van beide algoritmes aangevuld met hun respectieve
implementaties in hardware.
Beide algoritmes werden specifiek geımplementeerd met het oog op het coderen van
4×4-blokken met residuwaarden. Het coderen van residuwaarden maakt immers het
grootste deel uit van de entropiecodering (zowel in aantal oproepen als in uitvoe-
ringstijd).
4.1 Context-Adaptive Binary Arithmetic Coding
Inleidende opmerking
In deze beschrijving wordt het CABAC-algoritme besproken in zoverre dit nodig is
voor de hierna volgende implementatie, dit om de tekst niet te overladen met te
technische of theoretische details. Voor een detailstudie van het volledige CABAC-
algoritme wordt de geınteresseerde lezer doorverwezen naar Bijlage B.
31
Beschrijving
Bij het encoderen van een 4×4-blok met residuwaarden worden een aantal fases
doorlopen. In een eerste fase zal een binaire weerspiegeling worden opgesteld van
het 4×4-blok. Voor elke positie in de verkregen bitstring wordt vervolgens het pas-
sende contextmodel geselecteerd. Op basis van dit contextmodel wordt tenslotte de
aritmetische codering doorgevoerd.
Stap 1: Opstellen van de intermediaire bitstring / scannen van de ge-
transformeerde coefficienten
Indien er niet-nulcoefficienten aanwezig zijn in het 4×4-blok, worden in een eerste
stap deze coefficienten in kaart gebracht (het opstellen van de significance map). De
matrix wordt hierbij doorlopen in zigzag-scan (zie Figuur 4.1).
Figuur 4.1: Zigzag-scan en omgekeerde zigzag-scan.
Indien een niet-nulcoefficient voorkomt, wordt dit aangeduid met een ‘1’ in de bit-
string (de significant coeff flag). In dat geval zal ook aangeduid worden of het om de
laatste niet-nulcoefficient gaat (de last significant coeff flag). Dit resulteert in een
bitstring van in het slechtste geval 30 bits. Indien de laatste positie wordt bereikt
in de zigzag-scan, betekent dit immers dat op die positie een coefficient voorkomt.
Bijgevolg is dit ook de laatste coefficient. Op die manier kunnen twee bits worden
uitgespaard. De significance map van de matrix in Figuur 4.2 ziet er als volgt uit:
coefficienten 18 -2 0 0 0 -5 1 -1 0 0 0 0 1 0 0 1
SIG 1 1 0 0 0 1 1 1 0 0 0 0 1 0 0 (1)
LAST 0 0 0 0 0 0 (1)
32
18 -2 -5 1
0 0 -1 1
0 0 0 0
0 0 0 1
Figuur 4.2: Voorbeeld 4×4-blok.
Nadat de positie van de significante coefficienten is vastgelegd, zullen de absolute
waarden van deze coefficienten worden gecodeerd. Dit gebeurt in omgekeerde zigzag-
scan (zie Figuur 4.1). De encodering verloopt volgens het UEG0-codeerschema (zie
Bijlage B voor meer informatie). De lengte van elke code neemt toe met de grootte
van de coefficient. Als laatste wordt aan elke coefficient een tekenbit toegevoegd.
Stap 2: Contextmodellering
Voor elk syntax element wordt het passende contextmodel geselecteerd. Dit con-
textmodel baseert zich op eerder gecodeerde symbolen, en geeft aan welk bit op die
positie in de bitstroom het meest waarschijnlijk is. Het model doet als het ware
een voorspelling van het huidige bit. Het geeft tevens aan met welke waarschijnlijk-
heid (zekerheid) we dit kunnen verwachten. Vervolgens wordt aan de hand van dit
contextmodel de aritmetische codering doorgevoerd.
Voor de encodering van residuele data bestaan 171 contextmodellen (in totaal zijn
er 277).1 Al deze modellen bestaan uit een meest waarschijnlijk symbool (MPS,
1 bit) en een probabiliteitstoestand (tussen 0 en 63, 6 bits). Deze twee worden
afgeleid uit eerder gecodeerde symbolen, en moeten geactualiseerd worden na het
encoderen van elk symbool. Afhankelijk van de oorsprong van de residuwaarden (we
maken een onderscheid tussen luminantie- en chrominantiewaarden, en tussen intra-
en inter-codering) kiezen we de gepaste contextmodellen.
De probabiliteiten worden aangepast aan de hand van tabellen. Deze vervangen
vermenigvuldigingen bij de probabiliteitsberekening. Hieruit blijkt een eerste maal
1Voor gemengde frame/field coding bestaan er zelfs 399 modellen. In deze thesis wordt verderenkel zuivere framecodering toegepast.
33
hoe getracht wordt het algoritme zo snel mogelijk te realiseren.
Bepaalde symbolen zullen gecodeerd worden in de zgn. bypass mode. Deze snellere
codering maakt geen gebruik van een contextmodel, en is bedoeld voor elementen
die over een uniforme probabiliteitsdistributie beschikken. Een voorbeeld hiervan
is het tekenbit (positieve of negatieve coefficienten zijn even waarschijnlijk in de
matrix).
Stap 3: Aritmetische codering
Het interval zoals gebruikt in de aritmetische codering wordt gekarakteriseerd door
2 getallen: het huidige beginpunt van het interval (L, ondergrens), en het bereik (R).
Afhankelijk van de huidige probabiliteitstoestand, zoals aangegeven in het context-
model (1 van de 64 toestanden), zal het interval opgesplitst worden. Deze opsplitsing
gebeurt, in tegenstelling tot de aritmetische codering in eerdere standaarden, niet
via een vermenigvuldiging of deling, maar wel via een opzoeking in een vaste tabel.
Dit ook weer met het oog op een zo snel mogelijk implementatie van het algoritme.
Aangezien we te maken hebben met vaste grenzen, en opsplitsing volgens op voor-
hand vastgelegde tabellen, moet op regelmatige basis een hernormalisatie van de
ondergrens en het bereik gebeuren, zodat beide waarden binnen vooraf vastgelegde
grenzen blijven.
Implementatie
De implementatie zal logischerwijze ook de structuur volgen van het CABAC-algo-
ritme. Ten eerste zal de intermediaire bitstring opgesteld worden. Deze zal in
een buffer geplaatst worden. Van zodra bits aanwezig zijn in de buffer, begint de
aritmetische coder te rekenen, aan de hand van de contextmodellen, die telkens
worden gelezen en aangepast.
Het blijkt dat de laatste stap, de feitelijke aritmetische codering, het meest tijds-
kritische deel van het algoritme vormt. De focus zal er dan ook op liggen om deze
codering zo snel mogelijk uit te voeren. Dit wil zeggen: het aantal klokcycli per
symbool zoveel mogelijk te beperken. Gelukkig is het algoritme zo geconstrueerd
dat er geen vermenigvuldigingen of delingen vereist zijn, wat een relatief snelle im-
plementatie mogelijk maakt.
34
Opstellen vanintermediaire bitstring
Buffer Aritmetische coder
SelectRAM metcontextmodellen (277 x 7 bits)
Figuur 4.3: Schema van de implementatie van het CABAC-algoritme.
De verschillende delen werden geımplementeerd, waarbij we een model verkrijgen
zoals in Figuur 4.3. In een eerste implementatie werden de symbolen sequentieel
gecodeerd. Op die manier zouden we tenminste 11 cycli per symbool nodig hebben.
Dit is echter onaanvaardbaar traag. Bovendien merken we in een afhankelijkheids-
analyse dat bepaalde bewerkingen naast elkaar kunnen uitgevoerd worden. Er werd
dan ook voor gekozen om bepaalde onderdelen parallel te laten werken, op die ma-
nier werd een pijplijnimplementatie verkregen (zie Figuur 4.4). Hierin onderscheiden
we de volgende drie trappen:
• Het opzoeken van het nieuwe symbool.
• Opzoeken van het contextmodel, aanpassen en wegschrijven van de contextin-
formatie.
• De eigenlijke aritmetische codering: aanpassen van de intervalgrenzen en weg-
schrijven van de output.
De nieuwe versie vereist tenminste 4 klokcycli per symbool, wat een aanzienlijke
snelheidswinst betekent. Vaak zal echter een hernormalisatiestap moeten worden
uitgevoerd, zodat 2 klokcycli extra vereist zijn. Een gemiddelde codering per sym-
bool zal ongeveer 5 klokcycli duren.
35
Inlezen uit buffer
Context schrijvennaar geheugen
Context lezen uitgeheugen
Context aanpassen
Inlezen uit buffer
Context schrijvennaar geheugen
Context lezen uitgeheugen
Context aanpassen
Interval aanpassen
Uitgang
Hernormaliseren
Interval aanpassen
Uitgang
Hernormaliseren
Inlezen uit buffer
Context schrijvennaar geheugen
Context lezen uitgeheugen
Context aanpassen
Interval aanpassen
Uitgang
Hernormaliseren
1e symbool 2e symbool 3e symbool
Figuur 4.4: Het pijplijnmodel van het CABAC-algoritme.
Bypass mode
Waar extra rekening mee moet gehouden worden, is de zogenaamde bypass coding
engine. De pijplijn werd zo geımplementeerd dat ze naadloos overschakelt op deze
bypass mode. Deze werd ontworpen om voor bepaalde syntaxelementen een snellere
verwerking mogelijk te maken. Dit is ook het geval in de implementatie, hier zijn
(slechts) 3 cycli nodig per symbool.
36
Resultaten
Na de synthese met behulp van de Xilinx r© ISE-omgeving verkrijgen we een klok-
snelheid van 43 MHz. Aangezien voor elk symbool gemiddeld 5 klokcycli vereist
zijn, betekent dit dat er 116 ns nodig zijn om een symbool te coderen. In bypass
mode is dit iets sneller, nl. 3 klokcycli, ofte 70 ns.
Wat betekenen deze cijfers nu in de praktijk? In een gemiddeld QCIF-beeld moeten
zo’n 100 000 symbolen gecodeerd worden. Dit betekent dat de encoder 86 QCIF-
beelden per seconde aankan, wat ruim voldoende is voor real-time encodering. Ook
bij CIF-beelden kan hij nog om en bij de 20 beelden per seconde coderen. Dit is
echter op het randje voor real-time codering, wanneer we rekenen op 25 beelden per
seconde. Het moge duidelijk zijn dat CABAC heel wat rekenwerk vereist, en dat het
in de toekomst uitermate moeilijk zal zijn om real-time AVC-codering te verkrijgen,
wanneer CABAC gebruikt wordt. Zeker in het geval van grotere beeldformaten zal
de grens snel overschreden worden.
Ook een vergelijking met de referentiesoftware is natuurlijk op z’n plaats. In soft-
ware duurt het encoderen van een symbool op een snelle processor ongeveer 230
nanoseconden. In bypass mode duurt dit ongeveer 175 nanoseconden. Dit betekent
dat de hardware-implementatie (ruwweg) een factor twee beter presteert dan de
softwareversie. Dit is een mooi resultaat, maar het verschil is niet zo denderend.
Zeker wanneer we rekening houden met de almaar sneller wordende processoren
kan men zich de vraag stellen of zo’n hardware-implementatie wel zin heeft. Het
CABAC-algoritme is immers een sequentieel algoritme. Of, eenvoudig gezegd: het
vorige symbool moet volledig verwerkt zijn vooraleer de codering van het volgende
kan starten. En het is natuurlijk zo dat processoren uitblinken in het uitvoeren van
sequentiele code. De enige reden dat de hardware-implementatie (voorlopig) sneller
is dan in software, is dat het maximale potentieel aan parallelliseerbaarheid wordt
uitgebuit in hardware.
Een methode om de hardwareversie nog ietwat te versnellen is de klokfrequentie te
verhogen. De 43 MHz die we nu verkrijgen is immers het resultaat van een uitge-
breid ontwerp, dat niet alleen het CABAC-algoritme omvat, maar ook uitgebreide
bibliotheken voor communicatie en voor de aansturing van de diverse componenten
van het WildCardTM-II platform. Wanneer de aritmetische codering op zichzelf ge-
synthetiseerd wordt, wordt een klokfrequentie bekomen van maar liefst 124 MHz!
37
Het kan in verder onderzoek de moeite lonen om voor de aritmetische codering een
aparte klok in te voeren, los van de rest van het ontwerp. Dit valt echter buiten het
kader van deze thesis.
4.2 Context-Adaptive Variable Length Coding
Beschrijving
De codering met CAVLC is de traditionele codering die ook voorkomt bij eerdere
standaarden. Dit is een Huffman-codering waarbij men poogt symbolen die minder
frequent voorkomen met meer bits te coderen dan veel voorkomende symbolen die
steeds zullen voorgesteld worden met een korte code. Daardoor bekomt men een
efficientere codering van de informatie.
Voor de codering van een 4×4-blok wenst men niet alleen informatie bij te houden
van de coefficienten zelf, ook hun plaats binnen de 4×4-matrix is van belang. Bij
CAVLC codeert men ook die twee gegevens afzonderlijk, maar op zo’n manier dat
men daar bijna geen mindere efficientie door bekomt.
Om de coefficienten steeds op een uniforme manier aan te spreken, wordt een af-
spraak gemaakt omtrent het doorlopen van de 4×4-matrix. Men heeft gekozen voor
de zigzag-scan die in Figuur 4.1 wordt weergegeven.
Alvorens de eigenlijke codering te bespreken, moet het concept van de trailing one
nog toegelicht worden. De verkregen matrix na transformatie heeft een karakteris-
tieke structuur, de grootste coefficienten bevinden zich in de linkerbovenhoek en in
de rechterbenedenhoek komen vooral veel enen en nullen voor. Het algoritme maakt
handig gebruik van die eigenschappen.
Tijdens het doorlopen van de coefficienten in de zigzag-scan komt men eerst de
grote coefficienten tegen. De grootte blijft afnemen naarmate men vordert in de
4×4-matrix. Uiteindelijk komt men slechts enen en nullen tegen, waarbij men de
enen zeer efficient kan beschrijven door enkel het teken bij te houden. Dit zijn
dan de trailing ones. In de standaard werd ervoor gekozen om rekening te houden
met maximaal 3 trailing ones, alle andere coefficienten worden op reguliere wijze
gecodeerd.
38
Algoritme
Als belangrijkste gegeven wenst men bij te houden hoeveel coefficienten in de matrix
aanwezig zijn. Daarnaast wil men ook weten hoeveel daarvan tot de klasse van de
trailing ones behoren. Deze gegevens worden gecodeerd gebruikmakend van een
opzoektabel die in de H.264/AVC-standaard werd vastgelegd.
Daarnaast gaat men de grootte van iedere coefficient coderen. In het geval van een
trailing one is dit enkel het teken, in het andere geval wordt een procedure opgezet
die gaat coderen volgens een aantal klassen. Hoe groter de coefficient, hoe hoger
de coderingsklasse. Het algoritme is erop voorzien dat de hogere coderingsklassen
die coefficienten efficient gaan coderen. De coderingsklasse gaat toenemen naarmate
men de lagere frequenties nadert, er wordt namelijk gecodeerd in omgekeerde zigzag-
scan.
De plaats van de coefficienten wordt ook bijgehouden. Dit volgens het systeem
waarbij men aangeeft hoeveel nullen zich bevinden tussen twee coefficienten. Indien
men dan nog het totaal aantal nullen voor de laatste coefficient opgeeft, is men in
staat de exacte plaatsbepaling uit te voeren zonder bijkomende informatie.
Voorbeeld
0 3 -1 0
0 -1 1 0
1 0 0 0
0 0 0 0
Na het doorlopen van de 4×4-matrix volgens de zigzag-scan wordt volgende sequentie
van coefficienten bekomen: 0, 3, 0, 1, -1, -1, 0, 1, 0, 0, . . .
In Tabel 4.1 volgt dan de uitwerking van de codering.
De codering met de bovenstaande 4×4-matrix met CAVLC levert dan het volgende
resultaat: 000010001110010111101101.
Implementatie
Voor de implementatie kan men kiezen uit drie vormen.
39
TotalCoeffs=5, T1s=3 0000100Sign(5)=+ 0Sign(4)=- 1Sign(3)=- 1Level(1)=1 1Level(0)=3 0010TotalZeros=3 111RunBefore(4)=1, ZerosLeft=3 10RunBefore(3)=0, ZerosLeft=2 1RunBefore(2)=0, ZerosLeft=2 1RunBefore(1)=1, ZerosLeft=2 01RunBefore(0)=1, ZerosLeft=1 geen code
Tabel 4.1: Een voorbeeld van een codering met het CAVLC-algoritme.
Ten eerste kan men kiezen voor een zuiver temporele implementatie. Men start pas
de codering van de volgende coefficient nadat de codering van de vorige coefficient
afgelopen is. De tijd voor de codering van de matrix hangt hier sterk af van het
aantal coefficienten.
Ten tweede kan men opteren voor een pijplijnversie. Hierbij zullen de verschillende
coderingen elkaar overlappen. Dit leidt tot een snelle implementatie die nog steeds
afhankelijk is van het aantal coefficienten in de matrix, maar de logica wordt hier
efficienter gebruikt dan bij de temporele implementatie.
Ten derde kan men een spatiale implementatie uitwerken. Het aantal coefficienten
heeft hier echter geen invloed op de uitvoeringstijd, na een aantal klokcycli is de
codering voltooid. Hier wordt een massa aan logica gebruikt.
De temporele implementatie en de pijplijnversie worden hierna besproken. Ons
inziens is een spatiale implementatie onverantwoord. Meerdere redenen zijn daarvan
de oorzaak.
Ten eerste is de logica zeker een beperkende factor. Een spatiale decompositie kan
leiden tot een enorme inname van chipoppervlakte, waardoor andere functionele
blokken misschien niet meer kunnen geımplementeerd worden. Spaarzaam omsprin-
gen met de beschikbare middelen is dus de boodschap.
Ten tweede is ook in digitaal ontwerp de volgende stelling geldig: “de ketting is
maar zo sterk als de zwakste schakel”. Het heeft hier geen zin een bijzonder snelle
40
schakeling te bouwen zonder in gedachten te houden dat andere functionele blokken
misschien de snelheidsbeperkende factor zullen zijn.
Eerste decompositie: temporele implementatie
De temporele decompositie staat afgebeeld in Figuur 4.5.
NC C1 C2 C3 C4PRE POST
Figuur 4.5: De temporele decompositie van CAVLC.
In de PRE-fase verricht men zeer algemene taken zoals het tellen van het aantal
coefficienten in de 4×4-matrix. In de POST-fase wordt algemene informatie gecodeerd
zoals het aantal coefficienten en het totaal aantal nullen voor de laatste coefficient.
De verwerking tenslotte bestaat uit het doorlopen van de toestanden NC,C1,C2,C3
en C4 voor iedere coefficient. De toestand NC bepaalt de coefficient die als volgende
moet gecodeerd worden. De eigenlijke codering zal dan verlopen in de toestanden C1
tot C4, enerzijds het coderen van de coefficient volgens een van de coderingsklassen
en anderzijds het coderen van de positie van de coefficient via het aantal nullen voor
de huidige coefficient. Per coefficient in de 4×4-matrix heeft men dus 5 klokcycli
rekenwerk te verrichten.
Bij het worst case scenario worden 16 coefficienten gecodeerd, waardoor een 4×4-
matrix maximaal 16 × 5 = 80 klokcycli in beslag zal nemen. Bij een klokfrequentie
van ongeveer 50 MHz duurt de codering van een 4×4-blok ten hoogste 1,6 µs. Bij een
QCIF-formaat duurt de entropiecodering van een beeld dus hooguit 2,55 ms, wat dus
neerkomt op ongeveer 400 beelden per seconde. Dit is meer dan real-time verwerking
bij het QCIF-formaat, expansie naar beeldformaten met een grotere resolutie is dus
zeker mogelijk.
Tweede decompositie: gepijplijnde implementatie
De gepijplijnde decompositie staat afgebeeld in Figuur 4.6.
41
NC C1 C2 C3 C4PRE POSTC5
Figuur 4.6: De gepijplijnde decompositie van CAVLC.
De PRE-fase en de POST-fase vervullen dezelfde taak. De verwerking van de ver-
schillende coefficienten verloopt nu wel gelijktijdig, ze wordt uitgevoerd door een
pijplijn die wordt opgebouwd uit 6 trappen. Dit is mogelijk omdat er geen afhan-
kelijkheden bestaan tussen de verwerking van opeenvolgende coefficienten. Dit wil
zeggen dat de codering van de ene coefficient niet moet voltooid zijn alvorens aan
de codering van de andere coefficient te kunnen beginnen.
De codering van de opeenvolgende coefficienten volgens het pijplijnmodel wordt
geıllustreerd in Figuur 4.7.
NC C1 C2 C3 C4 C5
NC C1 C2 C3 C4 C5
NC C1 C2 C3 C4 C5
NC C1 C2 C3 C4 C5
NC C1 C2 C3 C4 C5
NC C1 C2 C3 C4 C5
Figuur 4.7: Illustratie van CAVLC met het pijplijnmodel.
De verwerkingstijd voor een 4×4-matrix waarin n coefficienten voorkomen, wordt in
Formule 4.1 voorgesteld.
t(n) = l + (n − 1) (4.1)
De eerste term omvat de rekentijd voor de codering van de eerste coefficient, waarbij
l het aantal trappen van de pijplijn voorstelt en waarbij iedere trap slechts een
klokcyclus duurt.
42
De tweede term slaat op de codering van de andere coefficienten, iedere klokcyclus
wordt de codering van de volgende coefficient beeindigd.
In het worst case scenario worden 16 coefficienten gecodeerd, wat dus neerkomt op
6 + (16 − 1) = 21 klokcycli. Bij een klokfrequentie van ongeveer 50 MHz duurt de
codering van CAVLC ongeveer 400 ns. Dit komt neer op een versnelling met factor
4 in vergelijking met het sequentieel model.
De entropiecodering bij een QCIF-formaat neemt dan 650 µs in beslag per beeld,
waaruit volgt dat men 1500 beelden per seconde kan coderen. Dit is opnieuw meer
dan real-time en een uitbreiding naar beeldformaten met een hogere resolutie zal
zeker geen probleem opleveren.
4.3 Besluiten
Uit de implementaties van CABAC en CAVLC is gebleken dat het mogelijk is een
grote snelheidswinst te bekomen t.o.v. de software-versie. Vooral bij CAVLC is dit
het geval, bij CABAC is de winst eerder beperkt omdat we te maken hebben met
een sequentieel algoritme.
Ondanks de snelheidswinst werden de implementaties (nog) niet geıntegreerd in de
referentiesoftware, en wel om volgende redenen.
De entropiecodering is zoals uit de profilering in Paragraaf 2.7 bleek, een van de
belangrijkste blokken bij de intra-codering. Wanneer echter een ruwere quantisatie
doorgevoerd wordt, zal het relatieve belang van de entropiecodering inkrimpen. De
behaalde snelheidswinst zal dan ook sterk afhangen van de gebruikte quantisatiepa-
rameter.
We hebben bovendien te maken met tamelijk kleine functies in software die een vrij
korte rekentijd hebben, maar die zeer vaak worden opgeroepen. Vooral bij CABAC
is dit het geval, het encoderen van een symbool duurt daar slechts 230 ns. Het is
intuıtief duidelijk dat een groot deel van de snelheidswinst zal verloren gaan door
communicatie tussen de FPGA en de software.
Het is ook niet eenvoudig om de aritmetische coder te isoleren van de rest van de
software. Het CABAC-algoritme in de referentiesoftware is een wirwar van een groot
aantal functies, die bovendien gebruik maken van globale structs om de gegevens in
43
op te slaan. Er zou dan ook een grote aanpassing van de referentiesoftware nodig
zijn om al deze functies te vervangen. Bij CAVLC is de situatie identiek.
Andere functies, zoals de transformatie en quantisatie, lenen zich beter voor een
implementatie en een integratie in software. Dit zal dan ook het onderwerp zijn van
de volgende hoofdstukken.
44
Hoofdstuk 5
Transformatie & Quantisatie
5.1 Beschrijving
Zoals uit de profilering blijkt, vormen de transformatie en de quantisatie samen een
een belangrijk onderdeel van de intra-codering. Vooral de transformatie van 4×4-
blokken met residudata van luminantiewaarden komt veelvuldig voor en blijkt een
rekenintensief onderdeel te zijn.
De oorsprong van de residudata is als volgt. We beschouwen een 4×4-blok van
luminantiewaarden uit het huidige beeld. Uit de predictie via intra-codering of
inter-codering verkrijgen we een voorspelling van dit 4×4-blok. Wanneer we het
verschil berekenen tussen deze voorspelling en het originele blok, bekomen we een
blok met residuwaarden. Op dit blok worden achtereenvolgens een transformatie,
een quantisatie en een entropiecodering toegepast.
Transformatie
De transformatie zoals toegepast in de H.264/AVC-codec is in feite een benade-
ring van de 4×4 Discrete Cosinus Transformatie (DCT). Er werd gekozen voor een
geheelwaardige benadering, met het oog op een eenvoudige implementatie in soft-
ware en hardware. Op die manier is er ook geen sprake meer van afrondingen en
afrondingsfouten, wat een verliesloze inverse transformatie mogelijk maakt.
De geheelwaardige transformatie verloopt als volgt:
45
W =
1 1 1 1
2 1 −1 −2
1 −1 −1 1
1 −2 2 −1
X
1 2 1 1
1 1 −1 −2
1 −1 −1 2
1 −2 1 −1
(5.1)
Deze matrix wordt vervolgens geschaald d.m.v. een scalaire vermenigvuldiging:
Y = W ⊗ E (5.2)
waarbij de matrix E er als volgt uitziet:
E =
a2 ab/2 a2 ab/2
ab/2 b2/4 ab/2 b2/4
a2 ab/2 a2 ab/2
ab/2 b2/4 ab/2 b2/4
(5.3)
Hierbij hebben a en b volgende waarden:
a =1
2b =
√2
5(5.4)
Deze waarden vinden hun oorsprong in de omzetting van de oorspronkelijke discrete
cosinus transformatie naar de geheelwaardige transformatie.
Om het aantal vermenigvuldigingen te reduceren wordt deze schaling geıntegreerd
in het quantisatieproces, dat hierna volgt. Op die manier zal er slechts een verme-
nigvuldiging per coefficient nodig zijn.
Quantisatie
De quantisatie gebeurt volgens volgende formule:
Zij = round(Yij
Qstep) (5.5)
Yij is de getransformeerde coefficient, Zij wordt dan de gequantiseerde coefficient.
De quantisatiestap Qstep wordt bepaald uit de quantisatieparameter, in Tabel 5.1
46
wordt dit verduidelijkt. De quantisatieparameter kan ingesteld worden met waarden
tussen 0 en 51, en wordt vastgelegd door de gebruiker.
QP Qstep QP Qstep QP Qstep QP Qstep0 0.625 6 1.25 12 2.5 48 1601 0.6875 7 1.375 13 2.75 49 1762 0.8125 8 1.625 14 3.25 . . . 50 2083 0.875 9 1.75 15 3.5 51 2244 1 10 2 16 45 1.125 11 2.25 17 4.5
Tabel 5.1: Quantisatieparameter en bijhorende quantisatiestap.
Wanneer de quantisatieparameter hier met 6 verhoogt, zal dit aanleiding geven tot
een verdubbeling van de quantisatiestap. Ruwweg betekent dit dat de bitsnelheid
van de uitgezonden stroom zal halveren.
De quantisatie kunnen we ook herschrijven als:
Zij = round(WijSF
Qstep) (5.6)
De schalingsfactoren SF kunnen we terugvinden in matrix E. Ze zijn opgenomen in
Tabel 5.2.
Positie SF(0,0),(2,0),(0,2),(2,2) a2
(1,1),(1,3),(3,1),(3,3) b2/4andere posities ab/2
Tabel 5.2: Schalingsfactoren.
Zoals in Formule 5.6 aangegeven, wordt de quantisatie verricht door een deling uit
te voeren op de getransformeerde coefficienten. Aangezien delingen tijdskritische
operaties zijn, zeker met het oog op een implementatie in hardware, werden deze
vervangen door een vermenigvuldiging gevolgd door een rechtse bitschuifoperatie.
Deze vermenigvuldiging zal zowel de schalingsfactor uit vorige paragraaf, als de
quantisatie incorporeren, zodat in totaal slechts een vermenigvuldiging vereist is per
coefficient:
47
Zij = round(WijMF
2qbits) (5.7)
Hierbij is MF2qbits = SF
Qstep, met qbits = 15 + bQP
6c.
Deze constructie zorgt ervoor dat de multiplicatiefactoren MF op voorhand kunnen
vastgelegd worden. Voor de verschillende posities zien de waarden er als volgt uit,
voor de waarden nul tot vijf van de quantisatieparameter QP. Voor alle andere
waarden van QP wordt dezelfde MF gebruikt, enkel de bitschuifoperatie zal over
een variabel aantal qbits gebeuren.
QP Posities (0,0),(2,0),(2,2),(0,2) Posities (1,1),(1,3),(3,1) andere posities0 13107 5243 80661 11916 4660 74902 10082 4194 65543 9362 3647 58254 8192 3355 52435 7282 2893 4559
Tabel 5.3: Multiplicatiefactoren.
Deze waarden worden gebruikt in de referentiesoftware, en kunnen eenvoudig nage-
rekend worden met de formule
MF = 2qbits SF
Qstep(5.8)
5.2 Implementatie
Transformatie
De transformatie bestaat uit de vermenigvuldiging van de coefficientenmatrix met
de geheelwaardige benadering van de 4×4 DCT-matrix (zie Formule 5.1). Deze
operatie kan worden herleid tot 2 bewerkingen, nl. een rijoperatie, gevolgd door een
identieke operatie op de kolommen (orthogonale transformatie). Deze operatie is
zeer eenvoudig, en kan worden geımplementeerd met enkel optellingen, aftrekkingen
en bitschuifoperaties.
48
Deze basisbewerking werd geımplementeerd in een aparte eenheid (dct eenheid) en
vervolgens vier maal geınstantieerd, zodat de horizontale en verticale transformatie
elk in 1 klokcyclus kunnen worden afgewerkt.
Quantisatie
De quantisatie daarentegen vereist voor elke coefficient een vermenigvuldiging, ge-
volgd door een schuifbewerking. De berekening wordt uitgevoerd op de absolute
waarde van de getransformeerde coefficient. Ze hangt af van de quantisatieparame-
ter, en van het feit of het om een intra- dan wel om een interblok gaat.
Voor de vermenigvuldiging kan de keuze worden gemaakt tussen een sequentiele uit-
voering (de coefficienten worden een na een vermenigvuldigd, gebruikmakende van
1 vermenigvuldiger op de FPGA) of een parallelle realisatie, waarbij verschillende
vermenigvuldigers van de FPGA worden ingezet. Gezien het tijdskritische aspect
van de operatie, valt de keuze op een parallelle interpretatie. Aangezien de FPGA
beschikt over 96 18-bits vermenigvuldigers vormt dit geen probleem. De schuifbe-
werking die hierop volgt is afhankelijk van de quantisatieparameter.
De totale bewerking vereist nu 11 klokcycli.
5.3 Integratie in de referentiesoftware
Op de FPGA werden 8 32-bits registers voorzien als input, en 8 als output. Alle
resultaten (na transformatie en quantisatie) kunnen immers, zelfs in de meest extre-
me gevallen, voorgesteld worden m.b.v. 16 bits. Bovendien werden controleregisters
voorzien voor de quantisatieparameter, en om te bepalen of het om een intra- dan
wel om een interblok gaat.
In de referentiesoftware werd de oproep van de functie dct luma vervangen door een
oproep naar de FPGA. In plaats van deze oproep worden nu de 16 coefficienten
weggeschreven naar de registers van de FPGA. Vervolgens wordt het start-bit weg-
geschreven, en zal de referentiesoftware actief pollen tot de bewerking op de FPGA
voltooid is.
49
5.4 Resultaten: de harde cijfers
De transformatie en de quantisatie werden gesynthetiseerd. We verkrijgen uiteinde-
lijk een kloksnelheid van 40 MHz. Op de FPGA wordt 18% van de slices gebruikt.
Aangezien de berekening op FPGA 11 klokcycli vereist, kost de volledige berekening
275 ns per 4×4-blok. In software kost dezelfde berekening 4,91 µs per oproep. Dit
betekent dat we in theorie een versnelling met een factor 17 zouden realiseren!
In de praktijk blijkt dit echter niet het geval. Dit is te wijten aan de grote over-
head veroorzaakt door communicatie, ook al hebben we te maken met zeer kleine
hoeveelheden data. Elke oproep naar het WildCardTM-II platform veroorzaakt een
grote vertraging.
Voor 100 intra-gecodeerde beelden verkrijgen we de resultaten1
Software HW/SW co-design
Totale encodeertijd 8,251 s 18,637 s
Tijd nodig voor DCT 0,778 s 11,609 s
] beelden 100 100
] oproepen per beeld 1584 1584
Tijd / oproep 4,91 µs 73,289 µs
We bekomen een vertraging van om en bij de 100 ms per beeld. Aangezien de
transformatie in een QCIF-beeld 99×16=1584 keer wordt opgeroepen, betekent dit
dat we per oproep van de DCT op FPGA zo’n 73 µs nodig hebben. Dit omvat het
versturen van de data, het verwerken op FPGA, en het terughalen van de resultaten.
En dit terwijl de verwerking op FPGA zelf minder dan 1 µs inneemt!
De grote boosdoener bij deze vertraging is het teruglezen van de resultaten. Er
bestaat immers geen burst-operatie voor het lezen uit registers, wat er op neerkomt
dat telkens een nieuwe busaanvraag moet gebeuren.
5.5 Besluiten
De eenvoudige, brute force aanpak die in dit hoofdstuk werd gevolgd, heeft gefaald.
Het was reeds vroeg duidelijk dat weinig snelheidswinst mogelijk was, aangezien de
1De totale encodeertijd en de tijd per beeld verkrijgen we als uitvoer bij het encoderen. Dezeresultaten werden gecontroleerd met de Intel r© VTuneTM Perfomance Analyzers.
50
transformatie inwerkt op blokken van 4 bij 4 pixels, en dat een groot deel van de po-
tentiele, theoretische winst teniet zou worden gedaan door communicatie. Het viel
echter buiten de verwachtingen dat deze winst zou worden omgebogen in een (groot)
verlies. Even werd dan ook getwijfeld aan het potentieel van deze hardwareversnel-
lers, waarbij bedoeld wordt, het selectief vervangen van bepaalde rekenintensieve
blokken in software.
Ondanks de teleurstellende resultaten werden een aantal interessante conclusies uit
deze test getrokken.
Om een hardwareversneller te realiseren heeft het geen zin om kleine functies te
implementeren op de FPGA, en deze telkens op te roepen vanuit de C-code. De
overhead, te wijten aan communicatie is veel te groot om veelvuldige oproepen te
rechtvaardigen.
Het potentieel van een hardwareversneller zal vooraf moeten gemeten worden, en
hangt af van een aantal factoren, die een positieve of negatieve invloed zullen hebben
op deze potentiele snelheidswinst.
De rekentijd in software zal voldoende groot moeten zijn. Het is duidelijk dat wan-
neer de rekentijd van een functie kleiner wordt dan de tijd nodig voor het doorsturen
van de argumenten of resultaten, er al geen sprake kan zijn van een versnelling. Een
zeer goed voorbeeld hiervan is de aritmetische codering van een enkel symbool.
Niet alleen de rekentijd van een functie in software speelt een rol. Vaak is het
niet eenvoudig om grote functies te isoleren uit de rest van de software. Slecht
geprogrammeerde software, zoals de H.264/AVC-referentiesoftware, heeft het nadeel
dat een grote verwevenheid kan bestaan tussen de verschillende functies. Resultaten
van functies kunnen bijvoorbeeld worden gewijzigd in andere functies. Hoe kunnen
deze wijzigingen hun weg vinden naar de hardwareversneller? Enkel via bijkomende
communicatie.
Daarnaast is het evident dat functies die zich beroepen op een groot aantal argumen-
ten, of die een groot aantal resultaten leveren, een grote hoeveelheid communicatie
met zich meebrengen. Bij videocodering geldt dit bijvoorbeeld voor functies die in-
werken op een volledig beeld, of zelfs meerdere beelden. Een voorbeeld hiervan is de
inter-codering. Dit argument speelt zeker een rol wanneer register-operaties worden
gebruikt (geprogrammeerde I/O). Wanneer echter andere communicatieprotocollen
worden gebruikt zoals DMA, vervalt dit argument in grote mate.
51
Ook de tijd tussen het aanleveren van de argumenten en het terugvragen van de re-
sultaten moet voldoende groot zijn. Wanneer de argumenten net beschikbaar zijn,
en de resultaten b.v. 1 ms later bekend moeten zijn, zal de volledige implementatie
in hardware inclusief communicatietijd, ook slechts 1 ms mogen innemen. Wanneer
er wel voldoende tijd tussen de twee bestaat, kunnen de software en de hardware-
versneller perfect parallel functioneren, wat natuurlijk een grote snelheidswinst met
zich meebrengt. De rekentijd wordt in dat geval niet alleen verkort tot de tijd nodig
in hardware en communicatie, maar verdwijnt dan eenvoudigweg!
Al deze argumenten beperken het aantal functies dat in aanmerking komt voor hard-
wareversnelling. Ze bewijzen eveneens dat hardware-software co-design niet enkel
het werk is van de hardware-ontwerper, maar ook van de software-programmeur.
52
Hoofdstuk 6
Intra-codering
Uit het vorige hoofdstuk kunnen een aantal interessante conclusies worden getrok-
ken. Hoewel de implementatie van de transformatie en quantisatie op FPGA bedui-
dend sneller is dan de versie in software, bleek de integratie sterk vertragend.
De oorzaak hiervan ligt bij de communicatie. De methoden die op het einde van het
vorige hoofdstuk werden voorgesteld, zullen in dit hoofdstuk worden toegepast. Ten
eerste breiden we het ontwerp uit naar de volledige intra-codering. Hiermee komen
we tegemoet aan een van de elementaire eisen: grotere functionele blokken worden
geıntegreerd zodat het aantal functie-oproepen beperkt blijft. Op die manier zal de
communicatie tussen de computer en de FPGA beperkt blijven.
6.1 Beschrijving
Het doel van de intra-codering is het wegnemen van de spatiale redundantie in
een beeld. De H.264/AVC-specificatie beschrijft daarvoor twee manieren, namelijk
intra-codering op een 16×16-blok en intra-codering op een 4×4-blok.
We beschouwen een macroblok dat bestaat uit een luminantiecomponent (Y) van
16 bij 16 pixels en twee chrominantiecomponenten (U en V) van 8 bij 8 pixels.
De luminantiecomponent van het macroblok kan voorspeld worden op het 4×4-niveau
of het 16×16-niveau. De intra-codering op 4×4-niveau voorziet in 9 modi en de intra-
codering op 16×16-niveau voorziet in 4 modi. De chrominantiecomponenten worden
voorspeld op het 4×4-niveau waarbij 4 modi voorhanden zijn.
53
Uit een analyse van de referentiesoftware met Intel r© VTuneTM blijkt dat de intra-
codering op het 4×4-niveau bij de luminantiecomponent het meest rekenintensief is.
De uitwerking van 9 voorspellingsmodi heeft hier een belangrijk aandeel in. Voor
100 intra-gecodeerde beelden zien de uitvoeringstijden er als volgt uit (de totale
coderingstijd bedraagt 8,311 seconden):
4×4 luminantie 2,775 s16×16 luminantie 0,183 s4×4 chrominantie 0,398 s
Tabel 6.1: Uitvoeringstijden voor de verschillende voorspellingsmethoden.
Daarnaast blijkt dat de waarschijnlijkheid van een codering op 4×4-niveau groter
is dan een codering op 16×16-niveau. De codering op 16×16-niveau is ideaal ge-
schikt voor een macroblok dat zeer egaal is voor de luminantiecomponent, wat in de
praktijk zeer zelden voorkomt.
Eigenlijk wordt ieder macroblok uitgewerkt volgens beide methoden. Maar indien
blijkt dat de kost van de codering op 16×16-niveau slechter is dan de kost van de
codering op 4×4-niveau dan wordt die methode na de predictie direct afgebroken.
We focussen ons op de intra-codering op het 4×4-niveau.
We beschouwen enerzijds de positie van het macroblok in het beeld en anderzijds
de positie van het 4×4-blok in het macroblok. Het weze duidelijk dat niet in alle
gevallen de 13 predictiepixels ter beschikking zullen zijn (b.v. aan de randen van
het beeld). Dan wordt slechts een subset van de voorspellingen uitgewerkt. De
respectieve posities van de predictiepixels worden weergegeven in Figuur 6.1.
A B C D E F G HM
I
J
K
L
a b c d
e f g h
i j k l
m n o p
Figuur 6.1: Schematische weergave van de positie van de predictiepixels.
54
De 13 predictiepixels zijn niet afkomstig van het origineel beeld, ze komen van het
gereconstrueerd beeld. De reconstructie gebeurt dus niet alleen aan de decoderzijde,
maar ook bij het encoderen. Op die manier wordt bij de voorspelling gebruik ge-
maakt van gedecodeerde pixels, net zoals bij de decoder. Aan de decoderzijde zijn
de waarden van het origineel beeld immers niet voorhanden, die uit het gerecon-
strueerd beeld wel. Een voorspelling op basis van verschillende pixelwaarden kan
immers leiden tot verschillende waarden, die op hun beurt gebruikt worden voor een
nieuwe voorspelling,. . . Dit fenomeen wordt foutpropagatie genoemd.
In Figuur 6.2 worden de richtingen van 8 voorspellingsmodi voorgesteld, de DC-
voorspelling kan niet op die manier worden voorgesteld.
0
1
8
6
4
57
3
Figuur 6.2: Richtingen van acht voorspellingsmodi.
De 9 voorspellingsmodi voor de intra-codering van een 4×4-blok worden hieronder
kort toegelicht.
• Modus 0 (verticaal): de samples A,B,C en D worden verticaal geextrapoleerd.
• Modus 1 (horizontaal): de samples I,J,K en L worden horizontaal geextrapoleerd.
• Modus 2 (DC-voorspelling): alle samples in de voorspelling nemen de DC-
voorspelling aan.
• Modus 3 (diagonaal linksonder): een extrapolatie in de ZW-richting
55
• Modus 4 (diagonaal rechtsonder): een extrapolatie in de ZO-richting
• Modus 5 (verticaal rechts): een extrapolatie in de ZZO-richting
• Modus 6 (horizontaal onder): een extrapolatie in de OZO-richting
• Modus 7 (verticaal links): een extrapolatie in de ZZW-richting
• Modus 8 (horizontaal boven): een extrapolatie in de ONO-richting
De DC-voorspelling is afhankelijk van de beschikbare pixelwaarden. Er worden vier
gevallen onderscheiden, zoals te zien is in Tabel 6.2.
Beschikbaar DC-voorspellingA,B,C,D en I,J,K,L (A+B+C+D+I+J+K+L+4)/8
A,B,C,D (A+B+C+D+2)/4I,J,K,L (I+J+K+L+2)/4niets 128
Tabel 6.2: DC-voorspelling afhankelijk van beschikbare pixelwaarden.
Alle voorspellingsmodi worden in Figuur 6.3 grafisch gerepresenteerd.
Uiteindelijk behoudt men de beste voorspelling. Er wordt een kostcriterium gehan-
teerd dat gekend is onder de naam Sum of Absolute Differences. In Formule 6.1
wordt dit weergegeven.
SAD =3∑
x=0
3∑y=0
|f(x, y) − f ′(x, y)| (6.1)
In dit kostcriterium neemt men de som van de absolute waarden van de verschillen
tussen het origineel blok f en de voorspelling f ′.
Op de CD-ROM in Bijlage D wordt ook nog een Excel-bestand toegevoegd waarmee
men de intra-codering, de transformatie en de quantisatie, de inverse quantisatie en
de inverse transformatie kan simuleren. Dit document is terug te vinden onder de
naam “intra-codering.xls”.
56
Modus 0: verticaal Modus 1: horizontaal Modus 2: DC-voorspelling
Modus 3: diagonaal linksonder Modus 4: diagonaal rechtsonder Modus 5: verticaal rechts
Modus 6: horizontaal onder Modus 7: verticaal links Modus 8: horizontaal boven
A B C D E F G HM
I
J
K
L
A B C D E F G HM
I
J
K
L
A B C D E F G HM
I
J
K
L
A B C D E F G HM
I
J
K
L
A B C D E F G HM
I
J
K
L
A B C D E F G HM
I
J
K
L
A B C D E F G HM
I
J
K
L
A B C D E F G HM
I
J
K
L
A B C D E F G HM
I
J
K
L
DC DC DC DC
DC DC DC DC
DC DC DC DC
DC DC DC DC
Figuur 6.3: Schematische weergave van 9 voorspellingsmodi.
6.2 Implementatie
6.2.1 Predictie
Voor de uitwerking van de 9 voorspellingsmodi werd geopteerd voor een gepijplijnd
ontwerp, opgebouwd rond 4 functionele componenten. Die componenten worden
aangestuurd door de PREDICT-component die instaat voor de controle. In Figuur
6.4 wordt de hierarchie van de componenten weergegeven.
De taak van de vier trappen van de pijplijn wordt hieronder toegelicht.
• PRED-component : Eerst wordt de voorspelling volgens een der modi uitge-
voerd. Gewapend met de pixelwaarden van de omringende blokken wordt
gepoogd een zo goed mogelijke benadering van het huidig 4×4-blok te verkrij-
gen.
• DIFF-component : Vervolgens wordt het verschil berekend tussen het origineel
57
PREDICT
PRED DIFF HADA SAD
Figuur 6.4: Overzicht van de componenten voor de predictie.
beeld en de voorspelling. Deze operatie vereist het berekenen van 16 onafhan-
kelijke verschillen.
• HADA-component : Daarna is men vrij1 een Hadamard-transformatie uit te
voeren op het residuele beeld. De transformatie kan voltooid worden met
enkel geheelwaardige optellingen en aftrekkingen, wat bijzonder interessant is
voor een implementatie in hardware.
• SAD-component : Uiteindelijk wordt een kostindicator bepaald door het som-
meren van de absolute waarden van de coefficienten. Dit getal geeft aan hoe
goed de welbepaalde voorspelling is voor het huidig 4×4-blok.
In Formule 6.2 wordt de verwerkingstijd t van n objecten in een pijplijn met l trappen
berekend in de veronderstelling dat de cyclustijd van iedere trap de waarde τ heeft.
t(n) = lτ + (n − 1)τ (6.2)
De verwerkingstijd kan opgesplitst worden in twee delen. Enerzijds de opstarttijd
lτ waarna het eerste resultaat aan de uitgang van de pijplijn verschijnt. Anderzijds
worden de overige n − 1 resultaten verkregen in de daaropvolgende periodes.
Indien alle voorspellingsmodi worden uitgevoerd volgens bovenstaand gepijplijnd
gedrag, dan is de beste voorspelling gekend na 12τ . In Figuur 6.5 wordt dit sche-
matisch weergegeven.
1Dit kan ingesteld worden in het configuratiebestand encoder.cfg van de referentiesoftware.
58
P HD S
P HD S
P HD S
P HD S
P HD S
P HD S
P HD S
P HD S
P:PRED-componentD:DIFF-componentH:HADA-componentS:SAD-component
modus 0
modus 1
modus 2
modus 3
modus 4
modus 5
modus 6
modus 7
P HD Smodus 8
Figuur 6.5: De pijplijnverwerking voor de intra-codering.
Afhankelijk van het beschouwde 4×4-blok kan het aantal uit te voeren voorspellingen
een stuk minder zijn. In het meest extreme geval, als geen pixelwaarden beschikbaar
zijn, wordt slechts een voorspelling uitgevoerd, namelijk een DC-voorspelling. In dat
geval herleid de pijplijn zich tot een zuiver sequentiele berekening.
PREDICT-component
De overkoepelende component heeft een dubbele functie. Enerzijds wordt de pijplijn
aangestuurd en anderzijds wordt de beste voorspelling bijgehouden.
Het aansturen van de pijplijn vertoont een vrij eenvoudig gedrag. Er wordt niet
voortgegaan alvorens alle trappen van de pijplijn klaarstaan om de volgende ver-
werking aan te vatten. Daaruit volgt dat de pijplijn optimaal werkt bij gelijkmatige
belasting van alle trappen, in de zin dat alle trappen voor ongeveer evenveel klok-
cycli werkzaam zijn. Wil men een pijplijn efficient gebruiken, dan moet men ervoor
zorgen dat de pijplijn zoveel mogelijk gevuld blijft. Dit hangt echter af van de
beschikbare predictiepixels waaruit de te behandelen predictiemodi volgen.
Het bijhouden van de beste voorspellingsmodus is noodzakelijk. Men wil achteraf
niet alleen weten welke de beste voorspellingsmodus is, ook de beste predictie en
het beste verschilbeeld moeten bijgehouden worden. Het beste verschilbeeld wordt
verwerkt door de component die voorziet in de DCT-transformatie. Het verkregen
resultaat is klaar voor de entropiecodering. Het resultaat van de DCT-transformatie
59
wordt ook onderworpen aan zijn inverse bewerking. Na het vermeerderen met
de voorspelling worden de verkregen waarden bijgehouden als het gereconstrueerd
beeld.
PRED-component
Het voorspellen van een 4×4-blok doorloopt twee fases. In een eerste fase wordt
een aantal karakteristieke getallen geextraheerd uit de 13 predictiepixels. In een
tweede fase wordt de predictie opgesteld met behulp van die karakteristieke getallen.
Daarom duren de meeste voorspellingsmodi slechts 2 klokcycli, behalve de DC-
voorspelling die afhankelijk van het aantal beschikbare predictiepixels tot 6 klokcycli
kan innemen.
DIFF-component
Na de voorspelling wil men echter weten hoe goed die eigenlijk is. Dit kan door
het beschouwen van het verschil tussen het origineel beeld en de voorspelling. Hier-
voor zijn 16 aftrekkingen vereist die allen onderling onafhankelijk uitgevoerd kunnen
worden. Hier heeft men dus de vrijheid om dit temporeel, spatiaal of in een niet
extreme vorm te implementeren.
Bij een temporele implementatie wordt een verschileenheid gebruikt, alle aftrekkin-
gen worden achter elkaar uitgevoerd en nemen dus in totaal 16 klokcycli in beslag.
Bij een spatiale implementatie worden 16 verschileenheden geınstantieerd waardoor
het verschilbeeld in een klokcyclus kan bepaald worden. Wij kiezen echter voor
een tussenvorm, noch temporeel noch spatiaal. Hierbij wordt het verschil tussen
de pixelwaarden rij per rij bepaald. De belangrijkste reden voor die keuze is de
gelijkmatige belasting in iedere trap van de pijplijn. Deze implementatie neemt 7
klokcycli in.
HADA-component
Eerst detecteert men of het uitvoeren van een Hadamard-transformatie op de residu-
waarden wel gewenst is. Indien de transformatie vereist is, zal men overgaan tot de
effectieve uitvoering. Die vindt plaats in twee stappen. In een eerste stap wordt
60
de horizontale transformatie uitgevoerd, in een tweede stap de verticale transforma-
tie. Het resultaat van de eerste stap is noodzakelijk voor de tweede stap, met die
afhankelijkheden moet wel degelijk rekening worden gehouden bij het ontwerp.
Bij nader onderzoek blijkt dat beide transformaties op dezelfde wijze georganiseerd
zijn. Dit laat toe dat de componenten voor de transformatie opnieuw kunnen ge-
bruikt worden, waardoor de logica van de FPGA beter benut wordt. De trans-
formatie wordt spatiaal geımplementeerd waardoor alle transformaties op kolom-
men evenals alle transformaties op rijen gelijktijdig kunnen uitgevoerd worden. De
Hadamard-transformatie wordt uitgevoerd in 7 klokcycli.
SAD-component
De absolute waarden van de coefficienten afkomstig uit de vorige stap worden be-
rekend zoals Formule 6.1 aangeeft. De sommatie van de 16 positieve coefficienten
wordt uitgevoerd in twee stadia zoals in Figuur 6.6 wordt weergegeven.
+ + +
+
+
/2
Figuur 6.6: Schematisch verwerking in de SAD-component.
In een eerste stadium worden de positieve waarden per 4 opgeteld. In een tweede
stadium worden die 4 resultaten gesommeerd en het eindresultaat wordt gehalveerd.
Wederom gaan wegens een afhankelijkheid tussen het eerste stadium en het tweede
stadium klokcycli verloren. Uiteindelijk wordt nog een additionele kost aangerekend
indien de voorspellingsmodus van het huidig 4×4-blok niet samenvalt met de modus
aangegeven door de “most probable mode”. De kostberekening wordt uitgevoerd in
8 klokcycli.
61
6.2.2 Transformatie en quantisatie
Uit de predictie volgt een beste voorspelling waarbij een beste verschilmatrix hoort.
Die verschilmatrix moet nu zo efficient mogelijk beschreven worden. Dit proces
verloopt in twee sterk verschillende stappen.
In de eerste stap wordt een transformatie en een quantisatie op het verschilbeeld
doorgevoerd. Daardoor wordt de spectrale redundantie binnen het 4×4-blok uitge-
buit.
In de tweede stap wordt een entropiecodering uitgevoerd. De entropiecodering van
een getransformeerde matrix wordt niet opgenomen in dit model. Dit kan volgens
CABAC of CAVLC zijn, afhankelijk van het geselecteerde profiel.
Voor dit onderdeel worden 3 componenten geconstrueerd, namelijk een eenheid voor
de transformatie en de quantisatie (DCT-component), een eenheid voor de run/level-
codering (RUN/LEVEL-component) en een eenheid voor de inverse quantisatie en
de inverse transformatie (IDCT-component).
De DCT-transformatie wordt direct na het bekendmaken van de beste predictie uit-
gevoerd. Het resultaat van deze operatie wordt gebruikt in de IDCT-transformatie
en de run/level-codering. Die twee operaties kunnen dus parallel uitgevoerd worden.
Waarvoor dient de inverse quantisatie en de inverse transformatie? Startend bij het
concept van voorspellen met behulp van pixelwaarden in de omgeving, worden niet
de pixelwaarden van het origineel beeld genomen, maar wel van het gereconstrueerd
beeld zonder het toepassen van een antiblokfilter. Zo bekomt men het beste resul-
taat want zowel aan de decoderzijde als aan de encoderzijde wordt een voorspelling
gemaakt vertrekkend van reeds gecodeerde en gedecodeerde pixelwaarden.
DCT-component
Daarvoor verwijzen we naar het vorige hoofdstuk dat dieper ingaat op de transfor-
matie en de quantisatie, dit zowel theoretisch als praktisch. De component wordt
zonder wijzigingen overgenomen in dit ontwerp.
62
IDCT-component
Men heeft er ook bij de inverse quantisatie en de inverse transformatie voor gezorgd
dat er slechts een vermenigvuldiging moet uitgevoerd worden. Daardoor wordt de
eigenlijke inverse transformatie vrijgemaakt van vermenigvuldigingen en kan die
uitgevoerd worden met enkel sommen, verschillen en schuifoperaties.
Men neemt eerst van alle coefficienten de absolute waarde, maar het teken wordt ook
bijgehouden in een 16-bit geheugenwoord. Men heeft slechts een bit nodig om het
teken bij te houden. Daarna volgt de vemenigvuldiging met een factor, die bepaald
wordt naargelang de positie in het 4×4-blok. Daarna volgt een schuifbewerking,
waarna het teken terug wordt toegevoegd.
4x4-blokorigineel beeld
4X4-blokvoorspelling
- 4x4-blokverschilbeeld
4x4-blokgetransformeerdgequantiseerd
4x4-blokinvers
getransformeerdgequantiseerd
+
4x4-blokvoor
toekomstigevoorspellingen
Figuur 6.7: Overzicht van gegevensstroom bij intra-codering.
63
Vervolgens wordt de inverse transformatie uitgevoerd, eerst de horizontale en daarna
de verticale. Dit neemt in totaal 6 klokcycli in beslag.
Uiteindelijk wordt nog een deling doorgevoerd waarna nog een controle volgt om
de samplewaarden te begrenzen. De pixels in een beeld worden immers voorgesteld
met 8-bit getalwaarden. Men zal de bekomen resultaten afronden tot de extreme
waarden 0 of 255 indien die buiten het bereik vallen. Men gaat de beste predictie
toevoegen aan dit resultaat. Die gegevens worden nog gebruikt voor voorspellingen
in de toekomst, die benaderen het best de samplewaarden die ook ter beschikking
zullen zijn aan de decoderzijde.
Het aantal klokcycli voor de uitvoering van de inverse quantisatie en de inverse
transformatie komt op 12.
RUN/LEVEL-component
Het principe achter run/level-codering is bijzonder eenvoudig en wordt frequent
toegepast in omgevingen waar gewerkt wordt met gegevensstromen waarin vaak een
rij nullen optreedt. De matrix wordt doorlopen in de zigzag-scan zodat men een
sequentie van alle coefficienten bekomt. De codering is opgebouwd rond een rij van
koppels van de vorm (run, level). Het element run geeft het aantal nullen aan voor
de coefficient, het element level stelt de coefficient zelf voor.
De implementatie is opgebouwd rond een doorsijpelstructuur die de sequentie door-
loopt tot de volgende te coderen coefficient. De klokcyclus erna wordt in een 16-bits
woord zowel de run als de level gecodeerd. Voor de run volstaan 4 bits en de overige
12 bits kunnen benut worden voor de level-waarde. Daaruit blijkt dat slechts 2
klokcycli nodig zijn voor de codering van een coefficient en men mag rekenen dat de
meeste matrices schaars zullen zijn als men behoorlijk quantiseert. Het worst case
senario duurt dan 32 klokcycli waarbij men 16 coefficienten codeert.
Waarom wordt deze run/level-codering uitgevoerd? In de referentiesoftware wordt
het resultaat van de transformatie en de quantisatie altijd omgezet in run/level-
vorm. De entropiecodering is zo georganiseerd dat enkel een 4×4-matrix in run/level-
codering wordt aanvaard. Dit is dus niet meer dan een voorstellingswijze die wordt
gehanteerd in de referentiesoftware.
64
6.3 Integratie
We beginnen met een opmerking omtrent het formaat van beelden. De verdere
tekst baseert zich op het QCIF-formaat (176×144 pixels), een uitbreiding van het
ontwerp naar het CIF-formaat (352×288 pixels) is triviaal. We laten dit over aan
de geınteresseerde lezer.
Wat zijn eigenlijk de taken bij de integratie van dit ontwerp in de referentiesoftware?
• De componenten voor de intra-voorspelling, de transformatie, de quantisa-
tie, de inverse quantisatie, de inverse transformatie en de run/level-codering
samenvoegen tot een samenwerkend systeem.
• Voor de interactie met de geheugens worden ook componenten voorzien, waar-
onder lezen en schrijven met het ZBT-geheugen en het SelectRAM.
• Voor de communicatie met de software wordt een interface voorzien, bij iedere
uitwisseling van grote datastructuren tussen de computer en de FPGA wordt
gebruik gemaakt van interrupts en het DMA-mechanisme.
Alvorens dieper op de taken bij de integratie in te gaan, wordt eerst het geheel
geschetst.
In Figuur 6.8 wordt een overzicht gegeven van het ontwerp voor intra-codering.
Er wordt een DMA-transactie gestart die het deel beeld1 van het ZBT-geheugen op-
vult met de luminantiecomponent van een volledig beeld (176×144 pixelwaarden van
8 bits=202 752 bits). Dit is een eenmalige operatie, bij het begin van elk beeld. Dit
voorkomt dat tijdens de verdere berekeningen grote hoeveelheden gegevens moeten
getransfereerd worden. De communicatie is immers de meest tijdrovende factor. Het
beeld wordt rechtstreeks doorgestuurd naar het ZBT-geheugen, zonder tussenkomst
van registers of andere vormen van geheugen.
Daarna kan de intra-codering van start gaan. Eerst moeten enkele gegevens uit het
ZBT-geheugen worden opgehaald. We starten met het ophalen van een 4×4-blok
van het origineel beeld en maximaal 13 predictiepixels die daarbij horen. Vervolgens
kan de eenheid voor de voorspelling de verschillende voorspellingsmodi uitwerken en
de beste voorspelling bepalen. Het verschilbeeld wordt bepaald uitgaande van de
beste voorspelling en het origineel 4×4-blok.
65
PREDICT
PRED DIFF HADA SAD
beeld1 beeld2
ZBT-geheugen
ZBT_LEES ZBT_SCHRIJF
CONTROLLER
DCT IDCTRUN
LEVEL
SelectRAM
Figuur 6.8: Overzicht van het ontwerp voor intra-codering.
Vervolgens wordt het 4×4-blok met residuwaarden getransformeerd en gequantiseerd.
Het resultaat van deze stap wordt bijgehouden in een SelectRAM-blok. Maar dat-
zelfde resultaat zal ook een inverse quantisatie en inverse transformatie ondergaan.
De bekomen 4×4-matrix gelijkt sterk op het verschilbeeld, de afwijkingen zijn de
oorzaak van de quantisatie. Indien daarbij dan nog de beste voorspelling wordt
bijgeteld, is het resultaat sterk gelijkaardig aan het origineel 4×4-blok. Dat wordt
bijgehouden in het deel beeld2 van het ZBT-geheugen. Daarop zal men de toekom-
stige intra-voorspellingen baseren, men zal uit dat beeld de predictiepixels ophalen.
66
Referentiesoftware
In de referentiesoftware wordt zowel de inter-voorspelling als de intra-voorspelling
voor een macroblok uitgevoerd in de functie encode one macroblock.
In de functie encode one macroblock wordt de intra-voorspelling op de 16 4×4-blokken
van het macroblok uitgevoerd door de functie Mode Decision for Intra4×4Macroblock
op te roepen.
In Figuur 6.9 wordt de graaf voorgesteld die de structuur van de onderliggende
oproepen weergeeft.
encode_one_macroblock
Mode_Decision_for_Intra4x4Macroblock
Mode_Decision_for_8x8IntraBlocks
Mode_Decision_for_4x4IntraBlocks
intrapred_luma dct_luma
Figuur 6.9: Overzicht van de aanroepen in de referentiesoftware.
De functie Mode Decision for Intra4×4Macroblock roept voor ieder 8×8-blok de func-
tie Mode Decision for 8×8IntraBlocks op. Daarin wordt voor ieder 4×4-blok de functie
Mode Decision for 4×4IntraBlocks opgeroepen. Na het bepalen van de voorspellin-
gen met de functie intrapred luma wordt het verschilbeeld dat correspondeert met
de beste voorspelling getransformeerd en gequantiseerd met de functie dct luma.
ZBT-geheugen
Er werd voor geopteerd om het volledige beeld op te slaan in het ZBT-geheugen,
ook al is er voldoende SelectRAM voorhanden om het beeld te stockeren. In het
andere geval zouden 202 752 bits/18 432 bits = 11 SelectRAM blokken nodig zijn.
67
De aansturing van het ZBT-geheugen is vrij eenvoudig en behoorlijk flexibel. We
denken daarbij vooral aan de interessante eigenschappen die een ZBT-geheugen be-
zit. Er gaan namelijk geen klokcycli verloren bij het omschakelen tussen leesbewer-
kingen en schrijfbewerkingen, wat de overhead vermindert bij een sterk wisselend
gebruik van het geheugen.
Een andere reden om de keuze van het ZBT-geheugen te verrechtvaardigen is het
feit dat de uitbreiding naar andere beeldformaten met een hogere resolutie triviaal
zijn.
Voor uitleg bij de aansturing van het ZBT-geheugen verwijzen we de geınteresseerde
lezer graag door naar de technische handleiding van het WildCardTM-II-platform.
Op de een of andere manier moet de tweedimensionale structuur van een beeld
vertaald worden in een eendimensionale adresstructuur van het geheugen. De pixels
die boven elkaar liggen in het beeld, liggen nu immers verspreid over het geheugen.
Wanneer een 4×4-blok met pixelwaarden of de 13 predictiepixels moeten opgehaald
worden uit het geheugen, kan dit nu niet gebeuren via een burst-operatie. Een
flexibele automaat voor leesoperaties is dus vereist.
Het QCIF-formaat bouwt een beeld op met 99 macroblokken, die op hun beurt elk
16 blokken van 4 bij 4 pixels bevatten. Op deze manier wordt het 176×144 beeld
opgesplitst.
De beschrijving van een QCIF-beeld valt uiteen in twee niveaus.
Op het eerste niveau wordt het beeld opgedeeld in macroblokken van 16 bij 16 pixels,
zoals wordt weergegeven in Figuur 6.10.
Op het tweede niveau wordt een macroblok opgesplitst in 4×4-blokken zoals wordt
afgebeeld in Figuur 6.11.
De selectie van een 4×4-blok binnen een macroblok kan heel eenvoudig worden
verricht met behulp van twee indices, namelijk een index b8 en een index b4. Laten
we beginnen met de opdeling van een macroblok naar 4 8×8-blokken. Met de index
b8 wordt dan een 8×8-blok geselecteerd. Vervolgens wordt het 8×8-blok opgedeeld
in 4 4×4-blokken. Met de index b4 wordt dan een 4×4-blok aangeduid.
68
0 1 2 3 4 5 6 7 8 9 10
11 12 13 14 15 16 17 18 19 20 21
22 23 24 25 26 27 28 29 30 31 32
33 34 35 36 37 38 39 40 41 42 43
44 45 46 47 48 49 50 51 52 53 54
55 56 57 58 59 60 61 62 63 64 65
66 67 68 69 70 71 72 73 74 75 76
77 78 79 80 81 82 83 84 85 86 87
88 89 90 91 92 93 94 95 96 97 98
Figuur 6.10: De volgorde van de macroblokken in een beeld.
0 1
2 3
16 pixels
16 p
ixel
s
8 9
10 11
4 5
6 7
12 13
14 15
Figuur 6.11: De volgorde van de blokken binnen een macroblok.
DMA or no DMA?
De gebruiker heeft de keuze uit twee verschillende types voor de overdracht van
gegevens, enerzijds de geprogrammeerde I/O en anderzijds het DMA-mechanisme.
Om verschillende redenen werd gekozen voor een gegevensoverdracht met behulp
van het DMA-mechanisme:
• De gegevenstransfer kan plaatsvinden zonder tussenkomst van de processor,
zodat die niet nodeloos wordt belast tijdens de overdracht. Daardoor kan de
69
0 1
2 3
0
2
1
3
index b8 index b4
16 pixels
8 pixels16 p
ixel
s
8 pi
xels
Figuur 6.12: Het gebruik van indices voor de selectie.
processor blijven verderrekenen. Zowel de berekeningen op de FPGA als de
overdracht van informatie tussen de FPGA en het geheugen zal parallel met
de rest van het algoritme in software plaatsgrijpen.
• DMA-operaties verlopen uitermate snel, zeker voor grote gegevenstransfers.
De CardBus-interface biedt potentiele snelheden tot 132 MB/s. De opgemeten
snelheden zijn zichtbaar in Figuur 6.13. Vooral bij leesoperaties kan grote
snelheidswinst worden gehaald, aangezien er geen burst-mode wordt voorzien
wanneer uit registers wordt gelezen.
• Zoals eerder vermeld moet voor de transfer van een QCIF-beeld ongeveer
25 KB verstuurd worden. Voor andere beeldformaten zoals CIF, wordt dit
al gauw 100 KB. Het is dan zeker niet meer te verantwoorden om zulke hoe-
veelheden data over te sturen via geprogrammeerde I/O, daar iedere geheu-
genoperatie individueel de bus zal moeten aanvragen.
Combinatie ZBT-DMA
De combinatie van het ZBT-geheugen en het DMA-mechanisme levert een belangrijk
probleem op. De overdracht van honderden of duizenden bytes tussen het geheugen
van de computer en de FPGA kan niet in een aaneensluitend geheel wordt uitge-
voerd. De transfer kan immers niet het alleenrecht over de alle bussen opeisen.
Via signalen op de LAD Bus moet dus geconstateerd worden wanneer valabele data
op de bus beschikbaar is. Bij het schrijven naar het ZBT-geheugen zit men met
70
0
10
20
30
40
50
60
70
80
90
100
100 1000 10000 100000 1000000
blokgrootte (bytes)
transfer-snelheid(MB/s)
PC-naar-PE
PE-naar-PC
bidirectioneel
Figuur 6.13: DMA-test bij een DellTM InspironTM 8600.
een vertraging van 2 klokcycli alvorens men de datalijnen mag aansturen. Een
intelligente controller is vereist voor de correcte aansturing. De bespreking hiervan
vindt de geınteresseerde lezer terug in Bijlage C.
Verwerking
De verwerking verloopt op twee niveaus, enerzijds het niveau van een macroblok en
anderzijds het niveau van een 4×4-blok. Op het niveau van 4×4-blokken worden
volgende bewerkingen uitgevoerd:
• De pixels van elk 4×4-blok worden opgehaald uit het geheugen, samen met de
pixels voor de voorspelling.
• Voor elk 4×4-blok van coefficienten worden de mogelijke voorspellingsmodi
berekend, waaruit de modus met de kleinste kost geselecteerd wordt.
71
• Het verschil tussen het originele blok en de beste voorspelling wordt berekend.
• Op dit verschil wordt de DCT-transformatie toegepast, hierna worden de
coefficienten gequantiseerd (afhankelijk van QP).
• Dit resultaat wordt voorgesteld in run/level-codering.
• Op de getransformeerde en gequantiseerde coefficienten wordt de inverse quan-
tisatie evenals de inverse transformatie toegepast.
• Daarbij wordt de beste voorspelling opgeteld, waardoor het resultaat een goede
benadering zal zijn van het originele 4×4-blok.
• De voorspelling aan de encoderzijde en de reconstructie aan de decoderzijds
werken met dezelfde waarden.
• Alle resultaten worden weggeschreven in een SelectRAM-blokje, dat via een
DMA-oproep gebonden is aan een adres in het hoofdgeheugen van de PC.
Nadat bovenstaande bewerkingen werden uitgevoerd op alle 4×4-blokken van een
macroblok zijn alle resultaten gestockeerd in een SelectRAM-blok. Wederom kan
men gebruikmaken van het DMA-mechanisme om die resultaten terug te schrijven
naar het hoofdgeheugen van de computer. De gegevens die worden teruggestuurd
zijn als volgt opgebouwd.
• De verkregen run/level-waarden, dit zijn de waarden die effectief zullen worden
geencodeerd in de bitstroom met behulp van entropiecodering.
• De pixelwaarden van het gereconstrueerd beeld, dit zijn de resultaten na de
IDCT-transformatie waarbij de beste voorspelling wordt opgeteld.
• De totale kost van het macroblok, die wordt verder in de software vergeleken
met de voorspellingskost van de bewegingsschatting e.d.
Om de hoeveelheid getransfereerde data te minimaliseren, worden alle data verpakt
binnen de beschikbare 32 bits busbreedte van de LAD Bus. Op die manier moeten
per macroblok maximaal 256 woorden van 32-bits worden teruggestuurd. Deze
waarden worden vervolgens gekopieerd in de desbetreffende datastructuren, zoals ze
voorkomen in de referentiesoftware.
72
Synchronisatie
Om ervoor te zorgen dat software en hardware parallel kunnen draaien, is er een
zeker vorm van synchronisatie vereist tussen beide. Aangezien alle gegevenstransfers
via DMA gebeuren, (en dus achter de rug van de processor heen), moet op een
zeker ogenblik de processor toch op de hoogte gebracht worden dat de resultaten
beschikbaar zijn in het hoofdgeheugen. Dit zal gebeuren via interrupts.
Wanneer alle berekeningen zijn voltooid op de FPGA, en de resultaten zijn terugge-
stuurd via een DMA-transactie, wordt vanuit de FPGA een interrupt gegenereerd.
Dit gebeurt door op de LAD Bus het interrupt-request signaal gedurende tenminste
90 ns hoog te zetten. Op die manier wordt aan het besturingssysteem duidelijk ge-
maakt dat de berekeningen voltooid zijn. De software weet dan dat het de resultaten
kan ophalen uit het geheugen.
De synchronisatie tussen de processor en de FPGA enerzijds en de overdracht van
gegevens tussen het hoofdgeheugen en de FPGA anderzijds worden in Figuur 6.14
geıllustreerd. De arcering van de band die hoort bij de FPGA en de processor wijst
op het actief zijn van de FPGA of de processor.
processor
FPGA
hoofd-geheugen
1
2 3
4 6
7
85 9
Figuur 6.14: De synchronisatie tussen de verschillende onderdelen.
We verklaren de verschillende stappen bij de synchronisatie.
• Stap 1: Starten van de eerste DMA-transactie. De processor verzendt het
bronadres, het doeladres en het aantal over te dragen bytes naar de DMA-
controller, waarna een startsignaal volgt.
• Stap 2: Uitvoeren van de eerste DMA-transactie. Een volledig beeld wordt
gekopieerd van het hoofdgeheugen naar het ZBT-geheugen. Alle gegevens zijn
73
daarna ter beschikking, de FPGA kan de berekeningen aanvatten.
• Stap 3 & 7: Starten van de tweede DMA-transactie. Nadat de bewerkingen
op de FPGA voor een volledig macroblok zijn afgelopen, worden de resultaten
van een macroblok teruggestuurd naar het hoofdgeheugen.
• Stap 4 & 8: Genereren van een interrupt. De FPGA geeft de processor te
kennen dat hij zijn taak voltooid heeft. De resultaten zijn op dat moment
weggeschreven in het hoofdgeheugen.
• Stap 5 & 9: Ophalen van de resultaten. De processor zal de gegevens uit het
hoofdgeheugen lezen en op gepaste wijze wegschrijven in de structuur die door
de referentiesoftware wordt voorzien.
• Stap 6: Bevestigen van de interrupt. Uiteindelijk gaat de processor de FPGA
inlichten dat de resultaten zijn ontvangen en verwerkt. Daaruit concludeert
de FPGA dat de verwerking van het volgend macroblok mag starten.
Hoewel het mogelijk is het volledige beeld in een ruk te verwerken, en dan alle
resultaten terug te schrijven, doen we dit niet. Op die manier bestaat er immers
geen enkele vorm van synchronisatie tussen software en hardware.
Dit betekent ook dat alle resultaten moeten worden opgeslagen op unieke locaties in
het geheugen, wat vraagt om reservatie van grote geheugenblokken. De manier die
we gebruiken vergt nu echter een minimale hoeveelheid geheugen, omdat het gereser-
veerde blok in het hoofdgeheugen van de PC steeds wordt overschreven. Bovendien
zal deze implementatie even snel zijn.
Als laatste stap worden in de software de waarden gekopieerd naar de desbetreffende
datastructuren, waaronder:
• De run/level-waarden, dit zijn de waarden die verderop effectief zullen worden
gecodeerd d.m.v. entropiecodering.
• De totale kost: deze wordt vergeleken met de kost van andere coderingsme-
thoden.
74
6.4 Resultaten
Het volledige project werd gesynthetiseerd, en draait aan een kloksnelheid van
38 MHz. De vereisten van de volledige implementatie op de FPGA zijn te zien
in Tabel 6.3.
Slices 9518 66 %Flipflops 8102 28 %
Vermenigvuldigers 33 34 %SelectRAM-blokjes 1 1%
ZBT-geheugen 50688 bytes 2,15%
Tabel 6.3: Gebruikte resources op het WildCardTM-II-bordje.
Uit deze getallen blijkt duidelijk dat we te maken hebben met een omvangrijk pro-
ject, dat heel wat van de beschikbare bronnen inneemt. Toch is er nog voldoende
plaats om (in een later stadium) b.v. de entropiecoder naast de intra-voorspeller te
laten werken.
Voor de verwerking van een 4×4-blok zijn, afhankelijk van de beschikbare predictie-
pixels, 150 tot 240 klokcycli vereist. De totale berekening voor een typisch 4×4-blok
bedraagt dan 5 µs. Het weze duidelijk dat dit enkel een raming is; de werkelijke
tijd hangt af van de positie van het macroblok binnen het beeld, en van de positie
van het 4×4-blok binnen het macroblok. Het encoderen van een macroblok duurt
gemiddeld zo’n 80 µs.
In de referentiesoftware worden alle voorgaande blokken uitgevoerd door de functie
Mode decision for intra4×4 macroblock. Deze functie neemt per oproep in software
gemiddeld 280 µs in. De implementatie op de WildCardTM-II verloopt dus sneller
met een factor 3,5. Hierbij houden we echter nog geen rekening met de communi-
catie, die gemakkelijk nog 100 µs inneemt. Op die manier is er wel snelheidswinst
mogelijk, maar die is eerder beperkt.
Na meting blijkt dat de tijd om een volledig macroblok te verwerken in software
740 µs bedraagt. Dit omvat niet alleen de intra-voorspelling, die we geımplementeerd
hebben, maar ook (onder andere) de entropiecodering van de resultaten. We weten
ook dat de tijd nodig voor intra-codering zo’n 280 µs bedraagt. Dit betekent dat
tussen twee oproepen van de intra-codering nog zo’n 460 µs gerekend wordt. We
zullen nu deze tijd gebruiken om de verwerking op FPGA (inclusief communicatie)
75
uit te voeren, wat meer dan voldoende is. Op deze manier kunnen we de software en
hardware parallel laten lopen. Alle vervangen functieoproepen betekenen nu pure
snelheidswinst.
De opgemeten tijden zien er uit als in Tabel 6.4.
Software HW/SW co-designTotale encodeertijd 8,311 s 6,64 s
Tijd voor intra-codering 2,775 s 0,53 s] oproepen 9900 9900
Tijd / oproep 280,34 µs 53,528 µs
Tabel 6.4: Resultaten van de integratie in referentiesoftware.
We houden nog 53 µs over per oproep. Dit is de tijd nodig voor het afhandelen van
interrupts, ophalen van resultaten uit het geheugen (de resultaten worden gekopieerd
in de respectieve structuren zoals ze voorkomen in de referentiesoftware),...
Bij de totale encodeertijd gaat bovendien nog wat tijd verloren voor initialisatie van
DMA-structuren (het toewijzen van aaneengesloten geheugenblokken e.d.). Uitein-
delijk zal de totale tijd versneld worden met ongeveer 20% (van 8,3 s tot 6,6 s).
6.5 Besluiten
De techniek die we in dit laatste project hebben toegepast, bleek een goede methode
om een versnelling te realiseren. De belangrijkste punten hierbij zijn:
• Het versturen van grote blokken is altijd voordeliger dan kleine blokken, daar
aan iedere datatransfer een initialisatie voorafgaat onafhankelijk hoeveel bytes
men effectief gaat verzenden.
• Door het implementeren van overkoepelende functies wordt het aantal oproe-
pen beperkt. Daardoor zal het aantal datatransfers afnemen, de hoeveelheid
data per transfer zal toenemen.
• Men kiest steeds voor de transfermethode die de grootste bandbreedte ople-
vert, namelijk het DMA-mechanisme. Leuk meegenomen dat de processor niet
betrokken wordt bij de eigenlijke overdracht van de gegevens.
76
• De FPGA en de processor zijn gelijktijdig actief. Ze voeren parallel een deel
van de codering uit. In een later stadium kan nog grotere winst gerealiseerd
worden door bijkomende blokken te implementeren. Het zou b.v. mogelijk
zijn om de entropiecodering te combineren met de intra-codering, en zoveel
mogelijk werk over te nemen van de processor.
Deze methode is algemeen toepasbaar, maar meer specifiek bij de referentiesoftware
van de H.264/AVC-specificatie is dit niet evident, daar het vaak moeilijk is grote
blokken te isoleren, zonder andere bewerkingen te schaden. Dit wegens de grote
verwevenheid van de software, en het exorbitante (en vaak ongepaste) gebruik van
globale structuren.
77
Hoofdstuk 7
Besluit
Om een compacte voorstelling te verkrijgen van beeldsequenties worden steeds effi-
cientere algoritmes uitgewerkt, die trachten het onderste (bitje) uit de kan te halen.
Een impliciet gevolg hiervan is dat de vereiste rekenkracht steeds toeneemt. Nieuwe,
steeds snellere, processoren volgen elkaar in snel tempo op. Toch hebben ook deze
gigahertz-monsters moeite om de recentste hersenkronkels op vlak van videocodering
te verwerken.
Intelligente componenten zijn vereist die de processoren kunnen verlossen van deze
zware last. In deze thesis werd de rol van intelligente component vertolkt door een
FPGA. Hoewel FPGA’s aan beduidend lagere klokfrequenties werken dan de recente
processoren, is het mogelijk gebleken om een hardwareversneller te realiseren.
De huidige generatie FPGA’s is in staat om uitgebreide en complexe algoritmes uit
te voeren. Hiertoe behoren zeker de huidige videocoderingsalgoritmes. Het is dan
ook gebleken dat de implementatie op FPGA vaak sneller is dan de tegenhanger in
software. De reden hiervoor is het sterk doorgedreven parallellisme: in een klokcyclus
kunnen een groot aantal berekeningen gebeuren.
Toch zijn bepaalde algoritmes niet meteen geschikt voor implementatie op FPGA.
Door de sterk sequentiele aard van bepaalde algoritmes zijn de mogelijkheden be-
perkt; de sterke punten van de FPGA worden dan niet ten volle benut. Het is
dan ook van groot belang dat een duidelijk onderscheid wordt gemaakt tussen de
verschillende software-functies. Zij kunnen ingedeeld worden volgens “hardware-
potentieel”.
78
Hoewel oorspronkelijk weinig belang werd gehecht aan communicatie, is dit de be-
perkende factor gebleken, en dus een van de belangrijkste punten in ons onderzoek.
De verschillende communicatiemogelijkheden werden onderzocht en vergeleken. Al
gauw werd duidelijk dat Direct Memory Access de manier is om optimaal gebruik te
maken van hardwareversnellers. DMA biedt alle nodige voordelen: een hoge trans-
fersnelheid is mogelijk; maar vooral, de DMA-transacties kunnen gebeuren zonder
tussenkomst van de processor. En net daar draait het om: parallellisme.
Net zomin het zin heeft om sequentiele algoritmes over te hevelen naar FPGA, zo
ook is het een slecht idee om de FPGA en de CPU sequentieel te laten rekenen.
Hiermee wordt bedoeld dat de CPU blijft wachten zolang de FPGA aan het rekenen
is. Veel interessanter wordt het wanneer beide parallel kunnen rekenen. Slechts op
bepaalde ogenblikken is een raakpunt vereist: wanneer de berekening op FPGA mag
starten, wanneer resultaten beschikbaar zijn,...
Wanneer alle belangrijke factoren aanwezig zijn, nl. functies met groot hardwarepo-
tentieel, die bovendien parallel kunnen werken met de software, is grote snelheids-
winst mogelijk. De rekentijd die vroeger in software nodig was, verdwijnt nagenoeg
volledig!
Het gebruik van hardwareversnellers biedt heel wat mogelijkheden. Rekenintensieve
toepassingen kunnen overgelaten worden aan de FPGA, zodat de processor onder-
tussen rustig kan verderwerken aan andere, misschien dringender, zaken. Bovendien
is het zeer eenvoudig om een FPGA te herprogrammeren. Afhankelijk van de toepas-
sing kan een nieuwe bitstring worden ingeladen in de FPGA, wat in een vingerknip
gebeurd is.
Het is duidelijk dat het gebruik van hardwareversnellers heel wat voordelen biedt.
Daartegenover staat dat het ontwerp ervan niet steeds evident is. Een groot aan-
tal beperkingen dringen zich op, waarmee de hardware-ontwerper en de software-
programmeur rekening dienen te houden.
79
Bijlage A
Verklarende woordenlijst
• API (Application Programming Interface). Een verzameling van func-
ties die programmeurs kunnen gebruiken om het besturingssysteem bepaalde
taken te laten uitvoeren.
• CIF (Common Intermediate Format). Een beeldformaat dat bestaat uit
352×288 pixels.
• CLB (Configurable Logic Block). CLB’s zijn de functionele elementen
waaruit een FPGA is opgebouwd.
• DCM (Digital Clock Manager). Dit is een component die op de FPGA
het beheer van de klokken voor zijn rekening neemt.
• DMA (Direct Memory Access). Een mechanisme waarbij gegevens kun-
nen overgedragen worden tussen het geheugen en diverse apparaten zonder
tussenkomst van de microprocessor.
• FPGA (Field Programmable Gate Array). Dit is een programmeerbare
component. De Xilinx r© VirtexTM-II XC2V3000-FPGA vormt het hart van
het WildCardTM-II-platform.
• LAD Bus (Local Address Data Bus). De bus tussen de PE en de CardBus-
controller. Alle communicatie tussen PC en PE verloopt via deze bus.
• LUT (Look-Up Table). De rekenkracht van een CLB komt van enkele
functiegeneratoren die men met deze term aanduidt.
80
• PE (Processing Element). Hiermee wordt de FPGA van de WildCardTM-II
bedoeld.
• QCIF (Quarter Common Intermediate Format). Een beeldformaat dat
bestaat uit 176×144 pixels (een vierde van een CIF-beeld).
• ZBT (Zero Bus Turnaround). Een van de geheugens aanwezig op het
WildCardTM-II-platform.
81
Bijlage B
Context Adaptive Binary
Arithmetic Coding
B.1 CABAC-glossarium
• Syntax element: te coderen element, zoals:
– luminantiecoefficienten
– chrominantiecoefficienten
– bewegingsvectoren en bijhorende informatie
– coded block pattern
– predictiemodi
– macroblok- en submacrobloktypes
• Symbool: invoer van de aritmetische coder. Aangezien in CABAC een binaire
aritmetische coder wordt gebruikt, zijn de symbolen in dit geval 0 of 1.
• Residuele data: data die overblijft na transformatie en quantisatie.
82
B.2 Inleiding
CABAC (Context-based Adaptive Binary Arithmetic Coding) is een efficiente vorm
van entropiecodering, die gebruikt wordt in de recent opgestelde H.264/AVC-speci-
ficatie.
CABAC baseert zijn efficientie op het gebruik van adaptieve aritmetische codering
en uitgebreide contextmodellering, wat leidt tot een zeer hoge mate van compressie.
Bovendien werd het algoritme opgesteld om een efficiente realisatie in software en
hardware mogelijk te maken. Opvallend hierbij is dat in het volledige codeerproces
geen enkele vermenigvuldiging vereist is.
De kern van het algoritme is de aritmetische codering. Aritmetische codering tracht
tegemoet te komen aan de minpunten die we terugvinden bij variabele lengte co-
des, zoals Huffman-codes. Een aritmetische coder kan bijvoorbeeld een niet-geheel
aantal bits toekennen aan een symbool. Vooral bij symbolen die een probabiliteit
groter dan 0, 5 hebben, geeft dit een groot voordeel. Een variabele lengte code van
een symbool heeft tenminste lengte 1. Voor verschillende probabiliteiten wordt de
ideale codelengte (de informatie-inhoud) gegeven in Tabel B.1. Wanneer p de pro-
babiliteit voorstelt van een symbool, is de informatie-inhoud van het symbool gelijk
aan −log2(p) (zie ook [9]):
p −log2(p)0,1 3,320,3 1,740,5 10,7 0,510,9 0,15
Tabel B.1: Eigen-informatie.
Een symbool dat zeer waarschijnlijk is (met p = 0, 9 b.v.), zal in een variabele lengte
code met minimaal 1 bit worden voorgesteld, terwijl dit in het ideale geval met 0,15
bits zou kunnen gebeuren!
Men streeft er naar om het gemiddeld aantal bits per symbool te laten naderen
naar de entropie (d.i. de eigeninformatie uitgemiddeld over alle symbolen). Wan-
neer symbolen met een hoge probabiliteit inefficient worden voorgesteld, wordt dit
natuurlijk zeer moeilijk.
83
Hoe kan een aritmetische coder dit oplossen? In plaats van alle symbolen afzon-
derlijk te behandelen, zal de volledige inputstring als een metasymbool beschouwd
worden. Op deze manier kan over de symboolgrenzen heen worden gecodeerd. Aan
dit metasymbool wordt dan een subinterval toegekend van het eenheidsinterval [0,1[.
De lengte van dit subinterval is gelijk aan de probabiliteit van het metasymbool.
De aritmetische coder zal nu de te coderen bitstring vervangen door de binaire
representatie van de ondergrens van het interval. De representatie hiervan is steeds
van de vorm 0.????. De aritmetische encoder slaat nu net voldoende bits op, zodat
de decoder uniek kan bepalen van welk van de mogelijke intervallen dit de ondergrens
is.
In het CABAC-algoritme wordt een binaire aritmetische coder gebruikt, wat bete-
kent dat de symbolen enkel de waarden 0 of 1 kunnen aannemen. Een kort voor-
beeldje illustreert het concept. We coderen de bitstring “011”, waarbij p(0) = 0, 25
en p(1) = 0, 75 (we veronderstellen dat de bron stationair is). Achtereenvolgens
wordt het eenheidsinterval opgesplitst zoals in Figuur B.1.
������
0 1
0 0,25 1
0
����������
10 0,0625 0,25
0
����������1
0,0625 0,109375 0,25
Geselecteerde subinterval
1
1
0
Figuur B.1: Voorbeeld van aritmetische codering.
Het uiteindelijke subinterval heeft als lengte p(0) · p(1) · p(1) = 964
= 0, 140625
en als ondergrens 764
= 0, 109375. Dit laatste getal heeft als binaire voorstelling
0,000111. Uiteindelijk zullen vijf bits (00011) voldoende zijn om deze ondergrens
uniek1 voor te stellen in een codewoord. Dit leiden we af uit volgende tabel, die ook
de codewoorden corresponderend met de andere mogelijke metasymbolen weergeeft:
1Er is geen ander codewoord dat begint met 00011, dus het codewoord is uniek decodeerbaar.
84
metasymbool ondergrens binair codewoord lengte
000 0 0,000000 000000 6
001 1/64 0,000001 000001 6
010 1/16 0,000100 00010 5
011 7/64 0,000111 00011 5
100 1/4 0,010000 01000 5
101 19/64 0,010011 01001 5
110 7/16 0,011100 011 3
111 37/64 0,100101 1 1
Het codewoord uit de voorlaatste kolom vormt de finale uitgang van de aritmeti-
sche coder. Aangezien de decoder ook de probabiliteiten van de symbolen kent,
kan aan de hand van dit codewoord de decoder het oorspronkelijke metasymbool
terugvinden.
Bij elk bijkomend symbool (wanneer de lengte van de metasymbolen toeneemt)
zal het interval moeten opgesplitst worden. Dit kan door de lengte van het vorige
interval te vermenigvuldigen met de probabiliteit van het huidige symbool. Dit
is de werkwijze die in traditionele aritmetische coders wordt gevolgd (en in ons
voorbeeldje). In het CABAC-algoritme zal de opsplitsing echter gebeuren aan de
hand van vooraf vastgelegde tabellen, zodat een kostbare vermenigvuldiging kan
vermeden worden.
Een tweede tekortkoming van variabele lengte codes is dat de codes op voorhand
worden vastgelegd in tabellen. Tijdens het encoderen blijven de tabellen constant,
ze kunnen dus niet mee evolueren met de wijzigende statistiek van het beeld. In te-
genstelling tot het voorbeeldje, is de bron niet stationair. Op verschillende plaatsen
in het beeld zullen de symbolen een verschillende probabiliteit hebben. Aritmetische
codering kan zich op eenvoudige wijze aanpassen aan de veranderende eigenschappen
van het beeld: de opsplitsing wordt afhankelijk gemaakt van de probabiliteitsdis-
tributie van het huidige te coderen symbool. Wanneer deze probabiliteiten exact
zouden berekend worden, zou dit het algoritme te complex maken. Daarom worden
de probabiliteiten geschat aan de hand van tabellen, zodat ook hier geen vermenig-
vuldigingen vereist zijn.
Meteen zijn hiermee de twee belangrijkste aspecten van de CABAC-encoder opge-
somd, namelijk de tabelgestuurde intervalopsplitsing en de tabelgestuurde probabi-
liteitsberekening.
85
Alvorens kan begonnen worden met de binaire aritmetische codering, zijn twee voor-
bereidende stappen nodig: de binarisatie van niet-binaire symbolen en de context-
modellering.
B.3 Bespreking
Samengevat bestaan er drie stappen in het CABAC-algoritme:
• Binarisatie
• Contextmodellering
• Binaire aritmetische codering
We beginnen met de bespreking van de drie stappen in het CABAC-codeerproces.
Vervolgens passen we dit toe op het coderen van residuele data, aan de hand van
een voorbeeld.
B.3.1 Binarisatie
Inleiding
Tijdens de binarisatie zullen alle niet-binaire symbolen omgevormd worden tot een
intermediaire binaire string, zodat de grootte van het gebruikte alfabet gereduceerd
wordt. Voor elementen die reeds binair zijn voorgesteld, wordt deze stap uiteraard
overgeslagen.
De redenen voor deze voorbereidende stap zijn tweeerlei, nl. de complexiteit ver-
kleinen en een eenvoudige schatting van conditionele probabiliteiten toelaten.
1. Complexiteit : Het omzetten van de syntax elementen naar een binaire string
maakt het mogelijk een binaire aritmetische encoder te gebruiken i.p.v. een m-aire
aritmetische coder. Berekeningen bij een m-aire aritmetische coder worden immers
complexer naarmate m toeneemt (het aantal opsplitsingen en vermenigvuldigingen
neemt toe). Bovendien bestaan er snelle varianten van binaire aritmetische code-
ring, die geen vermenigvuldigingen vereisen. Dit is het type aritmetische coder
86
dat gebruikt wordt in het CABAC-algoritme, en dat verder in deze bijlage wordt
besproken.
2. Conditionele probabiliteiten: Een kleiner alfabet maakt het mogelijk op een
aanvaardbare manier gebruik te maken van hogere orde conditionele probabiliteiten.
Dit om een explosie van het aantal te schatten probabiliteiten te vermijden.
CABAC binarisatieschema’s
In CABAC bestaan vier elementaire binarisatieschema’s, en ook combinaties ervan
worden gebruikt.2
De 4 basisschema’s zijn:
• Unaire code
• Getrunceerde unaire code
• EGk code (Exponentiele Golomb code van de ke orde)
• Vaste lengte code
Unaire binarisatie: voor elk positief geheel getal bestaat de unaire code uit x enen,
gevolgd door een afsluitende nul.
Getrunceerde unaire binarisatie: deze wordt enkel gedefinieerd voor getallen x tussen
0 en een grens S. Voor x < S is de code identiek aan de unaire binarisatie, voor
x = S is de codering gelijk aan S enen. Het enige verschil met unaire binarisatie is
dat in dit laatste geval de afsluitende nul verdwijnt.
EGk code (Exponentiele Golomb code van de ke orde): deze bestaat uit de con-
catenatie van een prefix- en suffixdeel. Bij het coderen van het getal x wordt de
prefix gevormd door unaire codering van de waarde l(x) = blog2(x/2k + 1)c. Het
suffixgedeelte is eenvoudigweg de binaire voorstelling van de waarde x+2k(1−2l(x)),
waarbij k + l(x) significante bits worden gebruikt.
De EG0 (Exponentiele Golomb codering van de 0de orde) wordt kort geıllustreerd
in Tabel B.2.
2Voor specifieke syntax elementen, zoals macroblok- en submacrobloktypes worden nog vijfspecifieke binaire bomen gebruikt. Zie [8] voor meer informatie.
87
x l(x) prefix suffix EG00 0 0 - 01 1 10 0 1002 1 10 1 1013 2 110 00 110004 2 110 01 110015 2 110 10 11010
Tabel B.2: De Exponentiele Golomb codering van de 0e orde.
Vaste lengte code: we beschouwen een eindig alfabet behorende bij een syntax ele-
ment. Voor 0 ≤ x < S wordt de code gegeven door de binaire representatie van x
met een vaste lengte l(x) = dlog2(S)e. Deze codering is zeer efficient voor uniforme
distributies.
Concatenatie van binarisatieschema’s
De UEG0-code (Unaire Exponentiele Golomb) is de concatenatie van de getrunceer-
de unaire code en de exponentiele golomb codering van de 0e orde.
Deze UEG0-codering wordt toegepast in 2 gevallen: bij het encoderen van bewe-
gingsvectoren, en bij het coderen van getransformeerde coefficienten. Bij deze laat-
ste wordt de absolute waarde van de coefficient, verminderd met een gecodeerd. Een
nul-coefficient moet immers niet worden doorgestuurd, deze wordt reeds uitgesloten
door de significance map. De UEG0-codering van enkele getallen wordt voorgesteld
in Tabel B.3.
B.3.2 Contextmodellering
In deze stap wordt aan elk symbool in de intermediaire string een contextmodel
geassocieerd. Dit model speelt een grote rol bij de aritmetische codering. Ten eerste
geeft het de probabiliteit weer van het huidige symbool. Deze kennis werd afgeleid uit
eerder gecodeerde symbolen. Aan de hand van deze probabiliteit wordt het interval
opgesplitst. Bovendien geeft het contextmodel aan wat het meest waarschijnlijke
symbool is (0 of 1). Dit bepaalt welk van beide subintervallen wordt geselecteerd
voor verdere codering.
88
x TU-prefix EG0-suffix0 01 102 110
. . .11 11111111111012 111111111111013 1111111111111014 11111111111111 015 11111111111111 10016 11111111111111 10117 11111111111111 11000
Tabel B.3: De UEG0-code.
Bij de contextmodellering wordt een keuze gemaakt tussen twee codeermodi: de
regular mode en de bypass mode.
Regular Mode
In regular mode wordt de keuze gemaakt uit een van de 399 bestaande contextmo-
dellen. De indexering van deze contextmodellen gebeurt aan de hand van context
index γ. Deze bestaat uit de som van de context index offset en de context index
increment :
γ = Γ + χ
De keuze van γ hangt af van de oorsprong van het symbool, d.w.z. van het syntax
element waaruit het symbool door binarisatie is afgeleid. Het verband tussen γ en
de syntax elementen blijkt uit Tabel B.4. De context index offset Γ is telkens de
beginwaarde van het aangegeven bereik. De context index increment χ loopt dan
van 0 tot het verschil van de eindwaarde en de beginwaarde.
Het gros van de contextmodellen wordt gebruikt voor het coderen van de residuele
data (γ tussen 73 en 398).
Bypass Mode
De bypass mode wordt gebruikt om het codeerproces te versnellen. Dit is vooral
zinvol wanneer de syntax elementen met gelijke waarschijnlijkheid voorkomen (bv.
het tekenbit van de coefficienten).
89
Syntax elementSlice type
SI/I P/SP Bmb type 0/3-10 14-20 27-35
mb skip flag 11-13 24-26sub mb type 21-23 36-39
mvd(horizontal) 40-46 40-46mvd(vertical) 47-53 47-53
ref idx 54-59 54-59mb qp delta 60-63 60-63 60-63
intra chroma pred mode 64-67 64-67 64-67prev intra4×4 pred mode flag 68 68 68
rem intra4×4 pred mode 69 69 69mb field decoding flag 70-72 70-72 70-72coded block pattern 73-84 73-84 73-84
coded block flag 85-104 85-104 85-104
significant coeff flag105-165, 105-165, 105-165,277-337 277-337 277-337
last significant coeff flag166-226, 166-226, 166-226,338-398 338-398 338-398
coeff abs level minus 1 227-275 227-275 227-275end of slice flag 276 276 276
Tabel B.4: Syntax elementen en bijhorende context index γ.
B.3.3 Binaire aritmetische codering
Inleiding
Twee meesterlijke ingrepen hebben het mogelijk gemaakt een relatief snelle arit-
metische codering te verkrijgen: enerzijds een tabelgestuurde intervalopsplitsing en
anderzijds een tabelgestuurde probabiliteitsschatting.
Probabiliteitsschatting
In CABAC wordt een probabiliteitsschatting toegepast die vrij is van vermenig-
vuldigingen. In plaats van telkens de probabiliteit van een symbool te berekenen,
bestaat een verzameling van 64 representatieve probabiliteiten3 tussen 0,01875 en
3Dit zijn in feite de probabiliteiten van het minst waarschijnlijke symbool, aangezien ze allekleiner zijn dan 0,5
90
0,5 die worden berekend uit de recursieve relatie in Formule B.1.
pσ = α.pσ−1 met σ = 1, . . . , 63 (B.1)
Hierbij is
p0 = 0, 5 en α =
(0, 01875
0, 5
) 163
≈ 0, 95
De probabiliteiten corresponderend met de waarden van σ worden voorgesteld (tot
3 beduidende cijfers) in Tabel B.5.
σ pσ
0 0,51 0,4752 0,4513 0,4284 0,406
. . . . . .61 0,02162 0,02063 0,019
Tabel B.5: Probabiliteiten volgens Formule B.1.
Hierbij is het belangrijk op te merken dat deze probabiliteiten nooit als dusdanig
worden gebruikt! Enkel de index σ tussen 0 en 63 zal gebruikt worden in het
algoritme. De echte probabiliteiten worden m.a.w. impliciet gelaten.
Alle 399 contextmodellen bestaan zoals gezegd uit 2 delen: enerzijds het meest
waarschijnlijke symbool (1 bit), en anderzijds de probabiliteit van het symbool. Deze
laatste wordt dus vervangen door de index σ. Dit betekent dat alle contextmodellen
bestaan uit 7 bits. Deze 7 bits samen vormen de zogenaamde probabiliteitstoestand
van het contextmodel (128 mogelijkheden).
Nadat elk symbool is gecodeerd, wordt de probabiliteitstoestand aangepast, rekening
houdend met dit laatste symbool. Dit gebeurt volgens formule B.2:
pnieuw =
max(α · poud, p62) wanneer symbool=MPS
α · poud + (1 − α) wanneer symbool=LPS(B.2)
91
In plaats van telkens de vermenigvuldiging in formule B.2 uit te voeren, verspringt
men tussen de verschillende toestanden, volgens vooraf vastgelegde tabellen. Dit
wordt geıllustreerd in Tabel B.6. Deze geeft de huidige toestand weer, aan de hand
van diens index (tussen 0 en 63). Er wordt ook weergegeven wat de volgende toe-
stand wordt indien het huidige symbool gelijk is aan het meest waarschijnlijke sym-
bool (MPS), of aan het minst waarschijnlijke symbool (LPS).
σ σ na MPS σ na LPS σ σ na MPS σ na LPS0 1 0 56 57 361 2 0 57 58 362 3 1 58 59 373 4 2 . . . 59 60 374 5 2 60 61 375 6 4 61 62 386 7 4 62 62 387 8 5 63 63 63
Tabel B.6: Aanpassing van de probabiliteitsindex σ.
Tabel B.6 kan men ook terugvinden wanneer men de bewerking uit Formule B.2
toepast.
Twee grensgevallen treden op: men blijft in toestand 62 zolang men het meest
waarschijnlijke symbool terugvindt in de bitstroom. Wanneer men zich in toestand
0 bevindt (beide symbolen zijn even waarschijnlijk), en in de bitstroom het minst
waarschijnlijke symbool volgt, zullen het MPS en het LPS omwisselen.
Toestand 63 kan niet worden bereikt vanuit andere toestanden, en wordt toegepast
om het codewoord af te sluiten.
Bij de initialisatie van de coding engine is het niet zo dat alle symbolen even waar-
schijnlijk zijn. In plaats daarvan vindt bij het opstarten van het algoritme een initi-
alisatie plaats, die afhankelijk is van de quantisatieparameter. Deze initiele waarden
werden op voorhand vastgelegd, en werden bepaald aan de hand van testsequenties.
Ze geven m.a.w. voorkennis omtrent typische beelden.
92
Intervalopsplitsing
ρ = (R >> 6) & 3
RLPS = TabelRLPS(σ,ρ)
R = R - rLPS
L = L + R
R=RLPS
Nee
MPS = 1 - MPS
Ja
σ = TabelLPS(σ)
Neeσ = min(σ+1,62)
Ja
Hernormalisatie
symbool == MPS
σ == 0
Figuur B.2: Encodeerproces.
De aritmetische coder baseert zich in sterke mate op benaderingen. Ten eerste wordt
het eenheidsinterval benaderd door een interval [0,1024[. Hierbinnen zal het interval
zich bewegen.
Ook bij de intervalopsplitsing worden benaderingen gebruikt. Zoals gezegd bestaat
het huidige interval uit een ondergrens L en een bereik R. Het huidige bereik R
zal (door een hernormalisatie-actie na elke codering, zie verder) steeds een waarde
93
aannemen tussen 256 en 511. Dit gebied wordt opgesplitst in 4 even grote quanti-
satiegebieden: [256,320[, [320,384[, [384,448[, [448,512[, die worden geındexeerd als
0, 1, 2 en 3. Binnen deze gebieden worden alle waarden van R gelijk behandeld; ze
worden benaderd door de waarden Q0, Q1, Q2 en Q3. De indexwaarde ρ tussen 0
en 3 die men op deze manier verkrijgt is de eerste sleutel tot de opsplitsing.
ρ Grenzen Qρ
0 [256,320[ 288
1 [320,384[ 352
2 [384,448[ 416
3 [448,512[ 480
De tweede sleutel die men nodig heeft, is de huidige probabiliteitstoestand σ. Deze
verkrijgt men uit het contextmodel dat correspondeert met het huidige symbool.
Dit is een waarde tussen 0 en 63.
Aan de hand van deze twee sleutels zal een opzoeking gebeuren in de RLPS-tabel.
Deze tabel bevat 4 maal 64 waarden voor RLPS. Het zijn deze waarden die de
opsplitsing zullen bepalen van het interval. Ze kunnen gevonden worden als een
benadering van het product Qρ×pσ. Wanneer men de intervalopsplitsing doorvoert,
is dit de lengte van het subinterval dat correspondeert met het minst waarschijnlijke
symbool.
σ pσρ = 0 ρ = 1 ρ = 2 ρ = 3
RLPS Q0 × pσ RLPS Q1 × pσ RLPS Q2 × pσ RLPS Q3 × pσ
0 0,5 144 128 176 176 208 208 240 2401 0,475 137 128 167 167 197 197 228 2272 0,451 130 128 159 158 187 187 216 2163 0,428 123 123 151 150 178 178 205 2054 0,406 117 116 143 142 169 169 195 195
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tabel B.7: RLPS-tabel
Op deze manier worden twee nieuwe intervallen verkregen: een met lengte RLPS en
een met lengte RMPS = R−RLPS. Afhankelijk van het feit of het te coderen symbool
gelijk is aan het meest waarschijnlijke resp. het minst waarschijnlijke, zal als nieuwe
interval het onderste subinterval resp. het bovenste subinterval geselecteerd worden.
94
Na de laatste stap wordt gecontroleerd of de nieuwe waarde van R nog steeds tussen
256 en 512 ligt. Indien dit niet het geval is, moet een hernormalisatie gebeuren. Dit
gebeurt met volgende pseude-code:
while (R < 256)
{
if (L >= 512)
{
put_one_bit_plus_outstanding(1);
L -= 512;
}
else
if (L < 256)
{
put_one_bit_plus_outstanding(0);
}
else
{
bits_to_follow++;
L -= 256;
}
L <<= 1;
R <<= 1;
}
Er wordt hierbij onderscheid gemaakt tussen drie gevallen. Het interval kan behoren
tot drie gebieden, afhankelijk van de voorwaarden in de if -structuur:
Voorwaarden Gebied
L >= 512 R < 256 [512,1024[
L >= 256 R < 256 [256, 768[
L < 256 R < 256 [0,512[
Na hernormalisatie liggen alle intervallen weer tussen 0 en 1024.
De uitvoer voor de drie mogelijkheden is verschillend:
95
• Wanneer het interval tussen 512 en 1024 ligt, kan zeker een ‘1’ uitgeschreven
worden. De binaire voorstelling van L begint dan immers met een ‘1’.
• Wanneer het interval tussen 0 en 512 ligt, kan met zekerheid een ‘0’ worden
uitgeschreven.
• Wanneer het interval tussen 256 en 768 ligt, bestaat er nog geen zekerheid.
In tegenstelling tot vorige twee mogelijkheden, kan een ondergrens van een
subinterval (na een nieuwe opsplitsing) zowel liggen tussen 256 en 512, als tus-
sen 512 en 768! Een speciale variabele, bits to follow, wordt geıncrementeerd
wanneer een hernormalisatie zonder uitvoer optreedt.
Wanneer een bit wordt uitgeschreven, en bits to follow is verschillend van nul, zal
voor elke bit to follow een bit worden uitgeschreven, tegengesteld aan het eerste bit.
B.4 Toepassing: codering van residuele data
In deze paragraaf passen we het CABAC-algoritme toe op de codering van residuele
data. Eerst worden de verschillende stappen beschreven, daarna zetten we de theorie
om in de praktijk aan de hand van een voorbeeld.
We vertrekken van een 4×4-blok met residuwaarden.
B.4.1 Theorie
Binarisatie
Het 4×4-blok zal eerst omgezet worden in een binaire string. Deze zal bestaan uit
volgende elementen:
• Het eerste bit geeft aan of de matrix niet volledig nul is (zijn er niet-nulcoefficienten4
aanwezig?). Dit is de coded block flag.
• Indien er coefficienten aanwezig zijn, wordt de locatie ervan aangegeven door
de significance map.
4Vanaf nu spreken we eenvoudigweg van coefficienten.
96
• Vervolgens worden de coefficienten zelf gecodeerd.
Significance Map Dit deel van de string is een weerspiegeling van de inhoud van
het 4×4-blok. Het duidt aan waar in de matrix zich de coefficienten bevinden. De
volledige matrix wordt in zigzag-volgorde doorlopen.
Wanneer een coefficient wordt gevonden, duidt men dit aan met een ‘1’ (de signi-
ficant coeff flag). In dat geval zal men ook aanduiden of het de laatste coefficient
is (de last significant coeff flag). Wanneer een nul wordt gevonden, duidt men dit
eenvoudigweg aan met een ‘0’ in de bitstring.
Dit resulteert in een bitstring van maximaal 30 bits. De laatste positie hoeft immers
nooit gecodeerd te worden. Indien de laatste positie wordt bereikt in de significance
map, is het zeker dat daar een coefficient voorkomt. Bijgevolg is dit meteen de
laatste coefficient.
Level-informatie De aangeduide coefficienten uit de significance map hebben allen
waarden groter dan nul. Deze waarden, verminderd met 1, worden nu gecodeerd
volgens het UEG0-schema. Dit gebeurt in omgekeerde zigzag-volgorde.
Contextmodellen
Er bestaan verschillende types blokken met residuele data, die worden ingedeeld in
vijf categorieen. De types binnen die klassen hebben een gelijkaardige statistiek,
en worden op dezelfde manier behandeld. Ze maken dan ook gebruik van dezelfde
contextmodellen.
De contextmodellen die worden gebruikt bij het coderen van residuele data hebben
een index γ tussen 85 en 275. De onderverdeling gebeurt als volgt:
ctx cat categorie] modellen modellen modellen
coeff CBF SIG LAST0 luma intra 16 DC 16 85-88 105-119 166-1801 luma intra 16 AC 15 89-92 120-133 181-1942 luma 4 16 93-96 134-148 195-2093 chroma DC 4 97-100 149-151 210-2134 chroma AC 15 101-104 152-165 214-228
Tabel B.8: Waarden van γ voor residuele data (deel 1).
97
Voor het coderen van de coded block pattern bestaan bij elke categorie 4 modellen.
Voor de significant coeff flag en de last significant coeff flag bestaat in elke categorie
een aantal modellen gelijk aan het aantal coefficienten, verminderd met 1. Dit
is voor elke positie in de matrix, behalve de laatste positie, die nooit gecodeerd
hoeft te worden. Dit betekent dat er 61 contextmodellen bestaan voor zowel de
significant coeff flag als de last significant coeff flag.
Voor het encoderen van de level-informatie bestaan nog 49 modellen. In tegenstelling
tot de vorige modellen, is hier geen verband tussen de positie in de matrix en het
nummer van het contextmodel. Het contextmodel wordt wel bepaald op basis van
de reeds eerder gecodeerde waarden. Dit gebeurt op volgende manier.
In elke categorie kunnen de contextmodellen ingedeeld worden in 2 reeksen. De
eerste reeks heeft toepassing op bit 0 van het getal na binarisatie, de rest op de bits
1-13.
ctx cat bit 0 bits 1-13 overige bits0 227-231 232-236 bypass1 237-241 242-246 bypass2 247-251 252-256 bypass3 257-261 262-265 bypass4 266-270 271-275 bypass
Tabel B.9: Waarden van γ voor residuele data (deel 2).
2 tellers worden telkens bijgehouden bij het encoderen:
• numT1: het aantal trailing ones dat reeds gecodeerd is.
• numLgt1: het aantal reeds gecodeerde coefficienten groter dan 1.
Voor bit 0 wordt de context index increment χ dan als volgt bepaald:
χbit0 =
0 als numLgt1 > 0
1 + min(3, numT1) anders
Voor bits 1 tot 13 gebeurt dit als volgt:
χbits1−13 = min(4, numLgt1)
98
Dit verklaart eveneens waarom er bij DC chrominantiecoefficienten (categorie 3)
slechts 9 modellen zijn i.p.v. 10: op de laatste scanning positie (links boven) kunnen
er in de 2×2 matrix nog maar 3 coefficienten groter dan 1 geweest zijn.
De overige bits van de gebinariseerde coefficienten worden gecodeerd in bypass mo-
dus.
B.4.2 Praktijkvoorbeeld
In dit voorbeeld wordt de codering besproken van een intra 4×4-blok met residuele
data (luminantiedata). Het blok behoort m.a.w. tot categorie 2, dit volgt uit Tabel
B.8.
Onze matrix ziet er als volgt uit:
7 -9 -8 -4
2 -2 1 0
2 -1 -1 1
0 0 0 0
We kiezen uiteraard een niet-triviaal voorbeeld. Dit betekent dat de coded block flag
gelijk zal zijn aan ‘1’, aangezien er coefficienten voorkomen in de matrix.
Binarisatie
In deze stap zal de significance map opgesteld worden:
coefficienten 7 -9 2 2 -2 -8 -4 1 -1 0 0 -1 0 1 0 0
SIG 1 1 1 1 1 1 1 1 1 0 0 1 0 1 (0) (0)
LAST 0 0 0 0 0 0 0 0 0 0 1
De laatste twee nullen zijn overbodig en moeten dus niet doorgestuurd worden. De
bitstring die we verkrijgen voor de significance map bestaat dus uit 25 bits:
1010101010101010100010011
99
De volgende stap is het coderen van de coefficienten, in omgekeerde zigzag-volgorde.
In dit geval 1, -1, -1, 1, -4, -8, -2, 2, 2, -9 en 7 volgens het UEG0-schema (zie
Tabel B.3). Het is voldoende de waarde min een te coderen, aangezien de nullen
reeds uitgesloten werden in de significance map. De binarisaties voor de coefficienten
worden weergegeven in Tabel B.10.
coefficient UEG0-code tekenbit1 0 0-1 0 1-1 0 11 0 0-4 1110 1-8 11111110 1-2 10 12 10 02 10 0-9 111111110 17 1111110 0
Tabel B.10: De binarisaties van de coefficienten.
Uit de laatste twee kolommen kunnen we het tweede deel van de te coderen bitstring
uitlezen. Deze bestaat uit 49 bits:
0001010011101111111101101100100111111110111111100
Contextmodellen
Alvorens over te kunnen gaan naar de aritmetische codering, is het noodzakelijk de
contextmodellen te bepalen.
In dit voorbeeld beschouwen we zoals gezegd een blok dat behoort tot categorie
2. Bij het encoderen van de significant coeff flags zijn de contextmodellen 134 tot
148 voorzien. Voor de last significant coeff flags de modellen 195 tot 209 (zie Tabel
B.8). De context indices γ voor de verschillende posities in de matrix zien er dan
uit als in Tabel B.11:
Voor het encoderen van de coefficienten worden hier de contextmodellen 247 tot 256
voorzien. Zoals vermeld hangt de keuze uit deze modellen niet af van de positie in
de matrix, maar wel van de reeds eerder gecodeerde coefficienten.
100
134 135 139 140 195 196 200 201136 138 141 146 197 199 202 207137 142 145 147 198 203 206 208143 144 148 - 204 205 209 -
significant coeff flag last significant coeff flag
Tabel B.11: Waarden van γ bij de significance map.
γ MPS σ γ MPS σ γ MPS σ134 1 19 195 0 34 247 1 5135 1 7 196 0 39 248 0 37136 1 12 197 0 32 249 0 22137 1 2 198 0 32 250 0 13138 1 7 199 0 31 251 0 6139 1 5 200 0 25 252 0 13140 0 9 201 0 21 253 0 2141 1 3 202 0 25 254 1 2142 1 5 203 0 16 255 1 7143 0 1 204 0 9 256 1 14144 0 5 205 0 13145 1 7 206 0 3146 1 8 207 1 6147 1 0 208 1 8148 1 28 209 1 29
Tabel B.12: De initiele waarden voor de contextmodellen.
Zoals gezegd zijn de contextmodellen adaptief, d.w.z. dat ze voortdurend aangepast
worden aan de inhoud van het beeld. Of: de kennis die men heeft over vorige
symbolen wordt gebruikt om nieuwe symbolen te voorspellen. Om toch een beeld te
geven van de gebruikte probabiliteiten en de werking van de contextmodellen, zullen
we een momentopname gebruiken. Meest geschikt hiervoor zijn de initiele waarden
van de contextmodellen.
De initiele waarden van de contextmodellen in ons voorbeeldje worden weergegeven
in Tabel B.12.
Aritmetische codering Om een idee te geven van de aritmetische codering, zullen
we ook hier een momentopname bekijken. We vertrekken vanuit een situatie waarbij
R=356, L=0 en bits to follow=0. De contextmodellen werden reeds beschreven in
101
vorige paragraaf, en bevatten de initiele waarden.5
We bespreken in detail de eerste regels.
Het oorspronkelijke interval loopt van 0 tot 356. R bevindt zich aldus in het
quantisatie-interval met ρ = 1. We vertrekken uit probabiliteitstoestand σ = 19.
In de RLPS-tabel vinden op positie (ρ, σ) dat RLPS = 65. Deze waarde wordt af-
getrokken van 356, zodat we twee nieuwe intervallen [0,291[ en [291,356[ verkrijgen.
Aangezien het symbool gelijk is aan MPS, houden we het onderste interval over. De
waarde R is nog steeds groter dan 256, er is dus geen hernormalisatiestap vereist.
Het encoderen van het tweede symbool verloopt analoog.
Bij het derde symbool vertrekken we van het interval [0,267[. De probabiliteits-
toestand is 7 en quantisatie-interval ρ = 0. Dit levert RLPS = 100 op. Na opsplitsing
blijft interval [0,167[ over. Het algoritme rekent er echter op dat het bereik R
tussen 256 en 512 blijft. Er is dus hernormalisatie vereist. De waarde van R wordt
verdubbeld, en aan de uitgang verkrijgen we een nul.
5Dit voorbeeld kunnen we terugvinden bij de sequentie foreman qcif.yuv. Het is de eerste maaldat een blokje van categorie 2 wordt gecodeerd, vandaar dat de contextmodellen nog steeds deinitiele waarden bevatten.
102
inγ
voor
RL
PS
her
nna
uit
LR
BT
FM
PS
σL
RB
TF
MP
Sσ
SIG
NIF
ICA
NC
EM
AP
113
40
356
01
1965
N0
291
01
20-
019
50
291
00
3424
N0
267
00
35-
113
50
267
01
710
0J
033
40
18
0
019
60
334
00
3923
N0
311
00
40-
113
60
311
01
1277
J0
468
01
130
019
70
468
00
3245
N0
423
00
33-
113
70
423
01
218
7J
047
20
13
0
019
80
472
00
3245
N0
427
00
33-
113
80
427
01
714
4N
028
30
18
-
019
90
283
00
3129
J0
508
00
320
113
90
508
01
518
5N
032
30
16
-
020
00
323
00
2548
N0
275
00
26-
114
00
275
00
990
J22
836
01
07
0
020
122
836
01
021
59N
228
301
10
22-
114
122
830
11
13
123
J45
635
60
14
01
020
245
635
60
025
48N
456
308
00
26-
114
245
630
80
15
111
J40
039
41
16
-
020
340
039
41
016
90N
400
304
10
17-
103
inγ
voor
RL
PS
her
nna
uit
LR
BT
FM
PS
σL
RB
TF
MP
Sσ
014
340
030
41
01
128
J28
835
22
02
-
014
428
835
22
05
135
J64
434
30
6-
114
564
434
31
714
4N
6429
03
18
-
020
664
290
30
312
3J
128
334
00
401
11
014
612
833
40
18
116
J36
046
40
16
01
114
736
046
40
10
240
J20
844
81
11
-
120
820
844
81
18
158
N20
829
01
19
-
SIG
NIF
ICA
NT
EC
OE
FFIC
IEN
TE
N
024
820
829
01
037
21N
208
269
10
38-
0B
P20
826
91
--
-J
416
269
0-
-01
024
941
626
90
022
46J
320
446
10
23-
1B
P32
044
61
--
-J
6244
60
--
10
025
062
446
00
1310
5N
6234
10
014
-
1B
P62
341
0-
--
J46
534
10
--
0
025
146
534
10
06
128
J41
842
61
07
-
0B
P41
842
61
--
-N
324
426
2-
--
125
132
442
62
07
144
J18
828
80
05
100
125
218
828
80
013
73J
7629
22
011
-
125
276
292
00
1181
J12
432
40
09
0111
104
inγ
voor
RL
PS
her
nna
uit
LR
BT
FM
PS
σL
RB
TF
MP
Sσ
025
212
432
40
09
110
J24
842
80
010
0
1B
P24
842
80
--
-J
412
428
1-
--
124
741
242
81
15
160
N41
226
81
16
-
125
341
226
81
02
128
J80
256
00
110
125
380
256
00
112
8J
416
256
00
00
125
341
625
60
00
128
J64
256
01
01
125
364
256
01
012
8J
128
256
01
10
125
312
825
60
11
128
J25
625
60
12
0
125
325
625
60
12
128
J0
256
11
3-
025
30
256
11
312
3J
2049
21
12
-
1B
P20
492
1-
--
J20
492
2-
--
124
720
492
21
617
5N
2031
72
17
-
025
420
317
21
212
8J
418
256
01
101
1
1B
P41
825
60
--
-J
6825
60
--
1
124
768
256
01
710
0J
136
312
01
80
025
513
631
20
17
100
J36
840
00
18
01
0B
P36
840
00
--
-J
224
400
1-
--
124
722
440
01
18
137
N22
426
31
19
-
025
622
426
31
114
69J
136
276
31
11-
0B
P13
627
63
--
-J
272
276
0-
-01
11
105
inγ
voor
RL
PS
her
nna
uit
LR
BT
FM
PS
σL
RB
TF
MP
Sσ
124
727
227
60
19
90J
3237
21
110
-
125
632
372
11
1199
N32
273
11
12-
125
632
273
11
1277
J64
392
01
1301
125
664
392
01
1310
5N
6428
70
114
-
125
664
287
01
1469
J12
843
60
115
0
125
612
843
60
115
95N
128
341
01
16-
125
612
834
10
116
76N
128
265
01
17-
125
612
826
50
117
59J
256
412
01
180
025
625
641
20
118
81J
300
324
01
1510
1B
P30
032
40
--
-J
412
324
1-
--
124
741
232
41
110
104
J31
244
02
111
-
125
631
244
02
115
95N
312
345
21
16-
125
631
234
52
116
76N
312
269
21
17-
125
631
226
92
117
59J
112
420
31
18-
125
611
242
03
118
81N
112
339
31
19-
125
611
233
93
119
65N
112
274
31
20-
025
611
227
43
120
51J
120
408
11
1601
111
0B
P12
040
81
--
-J
240
408
1-
-01
106
Bijlage C
Handleiding voor WildCard-II
C.1 Inleiding
Deze handleiding is een weerslag van een jaar naarstig onderzoek naar de mogelijk-
heden van het WildCardTM-II platform. Ze bevat, naast algemene karakteristieken,
ook VHDL-code en een aantal voorbeelden van enkele belangrijke functies van het
platform. Enkel de A/D-convertor en het DRAM-geheugen werden niet onderzocht
of gebruikt, en worden dus niet besproken. Op de bijgevoegde CD-ROM staan nog
een aantal projecten die gebruik maken van alle besproken functionaliteit.
C.2 FPGA
Het WildCardTM-II platform beschikt over een FPGA van producent Xilinx r© (type
VirtexTM-II XC2V3000). Deze FPGA heeft grote aantallen flipflops, CLB’s, verme-
nigvuldigers aan boord:
CLB matrix 64x56
] poorten 3 M
] slices 14336
] LUTs 28672
] flipflops 28672
] carry chains 112
] vermenigvuldigers 96
107
Een korte uitleg van de belangrijkste functies van een FPGA werd reeds gegeven
in Paragraaf 3.3. Meer informatie is te vinden in de gedetailleerde datasheet van
Xilinx r© [2].
C.3 SelectRAM
De Xilinx r© VirtexTM-II XC2V3000 beschikt over een ruim arsenaal aan flipflops,
maar grotere datablokken kunnen best opgeslagen worden in andere geheugenvor-
men. De eenvoudigste vorm van geheugen is het zogenaamde SelectRAM (of Block-
RAM). Dit is de verzamelnaam voor 96 over de FPGA verspreide geheugenblokjes
van 18 Kb elk. In totaal kan in SelectRAM dus 1728 Kb worden opgeslagen.
Een SelectRAM-blokje is een tweepoortgeheugen, wat betekent dat twee bewerkin-
gen tegelijkertijd kunnen plaatsvinden op eenzelfde blok van 18 Kb. Beide poorten
hebben een apart kloksignaal, enable en write enable signaal (zie Figuur C.1).
DIA
DOA
DOPA
DIPA
ADDRA
WEA
ENA
SSRA
CLKA
DIB
DIPB
ADDRB
WEB
ENB
SSRB
CLKB
DOB
DOPB
Figuur C.1: SelectRAM in dual-port modus
Verschillende configuraties zijn mogelijk. Zoals blijkt uit Tabel C.1, maken niet alle
configuraties gebruik van de volledige opslagcapaciteit. De configuraties in de linkse
kolom gebruiken slechts 16 Kb per blok.
108
16K×1 bit 2K×9 bits8K×2 bit 1K×18 bits4K×4 bit 512×36 bits
Tabel C.1: SelectRAM configuraties
De configuratie die gebruik maakt van 512 woorden van 36 bits elk ziet er als volgt
uit in VHDL:
component RAMB16_S36_S36
port (DIA : in std_logic_vector (31 downto 0);
DIB : in std_logic_vector (31 downto 0);
DIPA : in std_logic_vector (3 downto 0);
DIPB : in std_logic_vector (3 downto 0);
ENA : in std_logic;
ENB : in std_logic;
WEA : in std_logic;
WEB : in std_logic;
SSRA : in std_logic;
SSRB : in std_logic;
CLKA : in std_logic;
CLKB : in std_logic;
ADDRA : in std_logic_vector (8 downto 0);
ADDRB : in std_logic_vector (8 downto 0);
DOA : out std_logic_vector (31 downto 0);
DOB : out std_logic_vector (31 downto 0);
DOPA : out std_logic_vector (3 downto 0);
DOPB : out std_logic_vector (3 downto 0));
end component;
SelectRAM is uitermate flexibel in gebruik. In een klokcyclus kunnen het adres, de
gegevens en het write enable-signaal aangelegd worden. Dit is gelijkaardig aan het
schrijven naar flipflops op de FPGA (Figuur C.2).
Ook het uitlezen gebeurt zeer snel: de klokcyclus nadat het adres en het read ena-
ble-signaal zijn aangelegd, zijn de gegevens beschikbaar aan de uitgangen van het
SelectRAM (Figuur C.3).
109
ClkA
WEA
AddrA
��A4A0
DIA
���� D3 D4D0
A3A1 A2
D1 D2
Figuur C.2: Schrijven naar SelectRAM
ClkA
WEA
AddrA A4A0
DOA D2 D3
A3A1 A2
D0 D1����������
Figuur C.3: Lezen uit SelectRAM
C.4 ZBT SRAM
ZBT-geheugen is relatief eenvoudig in gebruik, en voldoende groot voor een brede
waaier aan toepassingen (18 Mb). Het is een statische RAM, in tegenstelling tot
SelectRAM is het een eenpoortgeheugen. ZBT (Zero Bus Turnaround) of NBT (No
Bus Turnaround) betekent dat er geen klokcycli verloren gaan wanneer overgescha-
keld wordt van een leesoperatie naar een schrijfoperatie of omgekeerd.
C.4.1 Gebruik
Bij de aansturing in VHDL kan worden gekozen uit twee interfaces. De eerste
(SRAM Basic IO) werd geleverd bij de oorspronkelijke versie van de software. In
110
januari 2004 werd nieuwe software geleverd, die tevens een nieuwe interface biedt
(SRAM Std IF). Deze zorgt voor de abstractie van enkele signalen, en is dus iets
eenvoudiger in gebruik.
SRAM Basic Interface (SRAM Basic IO)
De interface bestaat uit een SRAM Basic IO In Type en een SRAM Basic IO Out Type.
Deze types zien er als volgt uit:
type Sram_Basic_IO_In_Type is record
Data_In : std_logic_vector(35 downto 0);
Feedback_Clk : std_logic;
end record;
type Sram_Basic_IO_Out_Type is record
Addr : std_logic_vector(20 downto 0);
Data_Out : std_logic_vector(35 downto 0);
Data_OE_n : std_logic_vector(35 downto 0);
ByteWrite_n : std_logic_vector( 3 downto 0);
CS_n : std_logic;
WE_n : std_logic;
CKE_n : std_logic;
Sleep : std_logic;
Clk : std_logic;
Feedback_Clk : std_logic;
end record;
Deze signalen komen overeen met de signalen uit de datasheet van het ZBT-geheugen.
De signalen eindigend op “ n” zijn active low signalen. Deze komen overeen met de
signalen op pagina 8 van de datasheet [3].
Enkele signalen uit de datasheet vinden we echter niet terug in de interface. Deze
signalen zijn vastgepind op het bordje. Tot deze signalen hoort ook signaal FT,
zodat het ZBT-geheugen steeds in pipeline-modus werkt.
Het schrijven naar en lezen uit het ZBT-geheugen wordt verduidelijkt in Figuur C.4
en Figuur C.5.
111
Clk
Addr
WE_n
A3 A4A0
Data_out D2
����
A1 A2
D1D0����CS_n��
Data_OE_n
����
����
Figuur C.4: Schrijven naar het ZBT-geheugen met de Basic Interface.
Clk
Addr
WE_n
A3 A4A0
Data_In D1
����
A1 A2
D0
CS_n��
�������
Figuur C.5: Lezen uit het ZBT-geheugen met de Basic Interface.
SRAM Standard Interface (SRAM Std IF)
Bij de laatste release van WildCardTM-II (revisie 2.2) werd een nieuwe SRAM inter-
face geleverd, die een eenvoudigere communicatie toelaat. De definities zijn terug te
vinden in het bestand sram if entarch.vhd. Deze nieuwe interface kan handig zijn
bij gebruik. De grootste verschillen met de Basic Interface zijn:
• Bepaalde signalen worden geabstraheerd van de gebruiker, wat een iets een-
voudigere aansturing mogelijk maakt.
• Een DCM werd geıncludeerd, zodat de interface zelf reeds rekening houdt met
112
de externe vertraging.
De interface ziet er als volgt uit:
component SRAM_Std_IF is
generic
(
CLK_DLL_TYPE : Clk_DLL_Type := LOW_FREQ
);
port
(
Pads : inout SRAM_Pads_Type;
Clk : in Clock_In_Type;
Global_Reset : in std_logic;
User_In : out SRAM_Std_IF_In_Type;
User_Out : in SRAM_Std_IF_Out_Type
);
end component;
De types worden gedefinieerd in bestand “pe package.vhd” en zien er als volgt uit:
type SRAM_Std_IF_In_Type is record
Data_In : std_logic_vector ( 35 downto 0);
Data_Valid : std_logic;
DCM_Locked : std_logic;
end record;
type SRAM_Std_IF_Out_Type is record
Addr : std_logic_vector(20 downto 0);
Data_Out : std_logic_vector(35 downto 0);
Write : std_logic;
Strobe : std_logic;
Sleep : std_logic;
DCM_Reset : std_logic;
end record;
113
type Clk_DLL_Type is ( NONE, LOW_FREQ, HIGH_FREQ );
Met de nieuwe interface verlopen schrijf- en leesoperaties zoals in Figuur C.6 en
Figuur C.7.
Clk
Addr
Write
A3 A4A0
Data_Out D1
����
A1 A2
D0
��
Strobe
��D3 D4D2
Figuur C.6: Schrijven naar het ZBT-geheugen met de Standard Interface.
Clk
Addr
Write
A3 A4A0
Data_In D1
���A1 A2
D0
������
������Data_valid
Strobe
UIT
IN
Figuur C.7: Lezen uit het ZBT-geheugen met de Standard Interface.
114
C.5 Communicatie tussen PC en WildCard-II
C.5.1 LAD Bus
Alle communicatie tussen de PC en de WildCardTM-II gebeurt via de LAD Bus.
Langs de kant van de C-programmeur is een API voorzien, langs de kant van de
hardware-ontwerper bestaat de LAD Bus Standard Interface.
Deze interface ziet er als volgt uit (bestand pe package.vhd):
type LAD_Bus_Std_IF_In_Type is record
Addr : std_logic_vector ( 15 downto 0 );
Data_In : std_logic_vector ( 31 downto 0 );
Reg_Strobe : std_logic;
DMA_Strobe : std_logic;
DMAInProgress : std_logic;
Write : std_logic;
PciRdy : std_logic;
BusGnt : std_logic;
RxClk_In : Clock_In_Type;
end record;
type LAD_Bus_Std_IF_Out_Type is record
Data_Out : std_logic_vector ( 31 downto 0 );
Strobe_Out : std_logic;
DMA_Init : std_logic;
PeRdy : std_logic;
IntReq : std_logic;
BusReq : std_logic;
RxClk_Out : Clock_Out_Type;
end record;
115
C.5.2 Register-operaties
Een zeer eenvoudige manier om met de FPGA te communiceren, is via register-
operaties. Dit kan m.b.v. 2 functies uit de WildCardTM-II API:
• Voor een schrijfoperatie: WC PeRegWrite
• Voor een leesoperatie: WC PeRegRead
De syntax is als volgt:
WCAPI WC_RetCode WC_PeRegWrite( WC_DeviceNum device,
DWORD dDwordOffset,
DWORD numDwords,
DWORD *pSrcVirtAddr );
WCAPI WC_RetCode WC_PeRegRead ( WC_DeviceNum device,
DWORD dDwordOffset,
DWORD numDwords,
DWORD *pDestVirtAddr );
Hierbij is dDwordOffset het doeladres in de register-adresruimte, numDwords geeft
het aantal te transfereren woorden van 32 bits. Het laatste argument geeft de pointer
naar het beginadres van de data.
Deze API-calls moeten uiteraard worden opgevangen langs de kant van de FPGA.
Dit kan op twee manieren.
116
Rechtstreekse detectie
Op de FPGA kan een schrijfbewerking via de LAD Bus-interface eenvoudig gede-
tecteerd worden (zie Figuur C.8). Registeroperaties worden aangegeven door het
signaal Reg Strobe. Wanneer tegelijkertijd het signaal Write hoog staat, duidt dit
op een schrijfoperatie, zoniet op een leesoperatie. Rechtstreekse detectie van de sig-
nalen is zeer eenvoudig, en handig bij het ontvangen van grote hoeveelheden data,
zonder de tussenkomst van flipflops voor tijdelijke opslag.
Clk
Reg_strobe
Addr��
Write
A2 A3A0
��
Data_In
��D2 D3D0
A1
D1
Figuur C.8: Register-schrijfoperatie.
117
In VHDL-code kan een automaat voor het detecteren van schrijfoperaties er als volgt
uitzien:
type Register_Vector is array (natural range<>) of
std_logic_vector(31 downto 0);
signal ControlRegs : Register_Vector(3 downto 0);
constant REG_ADRES : std_logic_vector(19 downto 0) := x"01000";
constant REG_MASKER : std_logic_vector(19 downto 0) := x"FFFFC";
alias LAD_Clk : std_logic is LAD_Bus_In.RXClk_In.Clk;
process(LAD_Clk)
begin
...
if ((LAD_Bus_In.Addr and REG_MASKER(LAD_Bus_In.Addr’range)) =
REG_ADRES(LAD_Bus_In.Addr’range)) then
if (LAD_Bus_In.Reg_Strobe = ‘1’) then
if (LAD_Bus_In.Write = ‘1’) then
ControlRegs(Reg_Index) <= LAD_Bus_In.Data_In;
end if;
end if;
end if
...
end process;
Reg_Index <= CONV_INTEGER(‘0’ & LAD_Bus_In.Addr(1 downto 0));
Het adres dat aangelegd wordt op de LAD Bus wordt vergeleken met het gevraagde
adres. Hiervoor wordt een masker gebruikt dat enkel de laatste twee bits vrijlaat
(1111 1111 1111 1111 1100), zodat de adressen van 0x1000 tot 0x1003 eruit worden
geplukt.
Wanneer een leesoperatie wordt aangevraagd (Reg Strobe=‘1’ en Write=‘0’), moet
binnen 64 klokcycli de gevraagde data verstuurd worden. Dit gebeurt door de data
118
aan te leggen op de bus, en tegelijkertijd het Strobe Out-signaal op ‘1’ te zetten (zie
Figuur C.9).
Clk
Data_Out
Reg_strobe
Addr
��Write
������ ����
D��������Strobe_out
IN
UIT
A
Figuur C.9: Register-leesoperatie.
119
LAD registers
In het VHDL-bestand “LAD tools package.vhd”wordt een alternatieve methode voor-
opgesteld. Zogenaamde LAD registers worden gedefinieerd. Deze vormen eigenlijk
een abstractie van de signalen die in de vorige methode werden gebruikt, en verge-
makkelijken enigszins de interface.
De LAD registers zijn types die als volgt gedefinieerd zijn:
type LAD_register is record
Data_In : std_logic_vector(31 downto 0);
Strobe : std_logic;
Data_Out : std_logic_vector(31 downto 0);
end record;
type LAD_register_vector is array (natural range<>) of LAD_register;
Een vector van LAD registers kan vervolgens worden gekoppeld aan een registerbe-
stand. Aan zo’n registerbestand wordt een hexadecimaal adres toegekend. Wanneer
men vanuit de software naar dit adres schrijft, komen de data terecht in het data in
veld van de respectieve LAD registers. Data die moet teruggestuurd worden naar
software plaatst men in het data out veld.
component LAD_RegFile is
generic
(
BASE : std_logic_vector(15 downto 0) := x"0000";
L2Num : natural
);
port
(
Global_Reset : in std_logic;
LAD : in LAD_Bus_Std_IF_In_Type;
Data_Out : out std_logic_vector(31 downto 0);
Strobe_Out : out std_logic;
Regs : inout LAD_register_vector(0 to 2**L2Num-1)
);
end component;
120
Voorbeeld
Een voorbeeld van 2 LAD registers, die worden geassocieerd aan een registerbestand
op adres 0x1000 (Adressen 0x1000 tot 0x1001 worden hiermee gereserveerd voor de
LAD registers).
signal ControlRegister : LAD_Register_Vector(0 to 1);
u_ControlRegister : LAD_CRegFile
generic map
(
BASE => x"1000",
L2Num => 1
)
port map
(
clk => LAD_Clk,
Global_Reset => Global_Reset,
LAD => LAD_bus_In,
Data_Out => Regs_Data_Out1,
Strobe_Out => Regs_Strobe1,
Regs => ControlRegister
);
ControlRegister(0).Data_Out(31 downto 0) <=
ControlRegister(0).Data_In(31 downto 0);
ControlRegister(1).Data_Out(31 downto 0) <=
ControlRegister(1).Data_In(31 downto 0);
In dit voorbeeld wordt het Data Out-signaal niet gebruikt. Toch is het belangrijk dat
dit signaal gekoppeld is. In dit voorbeeld gebeurde dit door gewoon het Data Out-
signaal te verbinden met het Data In-signaal.1
1Indien zelfs maar 1 bitje van de data out signalen niet gekoppeld is, zal een fout optreden bijhet synthetiseren! De oorzaak van de fout zal trouwens niet gegeven worden...
121
C.5.3 Interrupts
Een evidente manier om met de FPGA te communiceren, is via actieve polling. Dit
gebeurt door een register-leesoperatie op een vooraf vastgelegd adres in de adresruim-
te van de FPGA. Dit betekent echter dat de processor gedurende de hele operatie
zal bezet worden door deze polling-operatie.
Een efficientere manier is het gebruik van interrupts. Deze kunnen zeer eenvoudig
worden gegenereerd vanuit de FPGA. Dit gebeurt door het interrupt-request signaal
IntReq van de LAD Bus Standard Interface gedurende minstens 90 ns hoog te zetten.
Het stuurprogramma vangt deze interrupt op en signaleert aan de API dat een
interrupt is opgetreden.
In deze API vinden we volgende functies terug die kunnen gebruikt worden om de
interrupt te verwerken:
• IntWait
• IntReset
• IntEnable
• IntQueryStatus
Op twee manieren kan een interrupt gedetecteerd worden in het C-programma:
• Met IntQueryStatus kan nagegaan worden of de API op de hoogte is van een
interrupt.
• Met IntWait kan in de software de huidige draad worden gestopt tot een in-
terrupt wordt opgevangen.
Na het opvangen van de interrupt moet de interrupt-lijn van de PE worden gereset
m.b.v. IntReset. Dit bevestigt dat de interrupt goed is ontvangen.
Alvorens een interrupt kan opgevangen worden, moet de functie IntEnable worden
uitgevoerd. Deze laat toe dat interrupts vanuit de Processing Element naar de host
kunnen gezonden worden.
122
In VHDL kan een eenvoudige teller gebruikt worden om een interrupt te genereren,
het signaal gedurende 8 klokcycli hoog zetten is typisch ruim voldoende.
Bijvoorbeeld:
process(clk,reset) begin
if (reset = ‘1’) then
Int_Counter <= (others => ‘0’);
elsif (rising_edge(clk)) then
if (Generate_Interrupt = ‘1’ and Interrupt_done=‘0’) then
Int_Counter <= Int_Counter + 1;
end if;
end if;
end process;
Interrupt <= Int_Counter(2) or Int_Counter(1) or Int_Counter(0);
Interrupt_Done <= Int_Counter(3);
LAD_Bus_Out.IntReq <= Interrupt;
123
C.6 DMA
Inleidende opmerking: in het vervolg behandelen we twee acties:
• Met een PC-naar-PE actie wordt bedoeld dat gegevens worden verstuurd van-
uit het hoofdgeheugen naar de Processing Element van de WildCardTM-II.
• Met een PE-naar-PC actie: er worden gegevens gelezen, vanuit de WildCardTM-
II, die worden geschreven in het hoofdgeheugen van de PC.
Net zoals register-operaties worden DMA-acties aangestuurd via LAD Bus signalen.
De belangrijkste spelers hierbij zijn:
• DMA strobe
• DMAInProgress
• PCIRdy
• BusGnt
• DMA init
• BusReq
Vooraleer DMA kan gebruikt worden, moeten een aantal intialisatiebewerkingen
uitgevoerd worden.
In software moeten volgende stappen ondernomen worden:
• Een blok in het geheugen moet worden gealloceerd voor DMA-gebruik. Dit
moet een aaneengesloten stuk geheugen zijn, dat niet mag worden weggeswapt!
Dit gebeurt met de functie DMAMemAlloc. Deze geeft een handle terug naar
het geheugenblok. Deze handle is nodig in de volgende stap.
• Vervolgens moet dit blok worden gebonden aan een hardware-adres. Dit adres
zal vervolgens worden doorgestuurd naar de FPGA, die dit adres gebruikt om
van te lezen of naar te schrijven. Deze functionaliteit wordt verzorgt door de
API-functie DMABind.
124
• Een aantal gegevens moet worden doorgestuurd naar FPGA:
– In geval van een PC-naar-PE actie: het beginadres van het geheugenblok
in het hoofdgeheugen, en het aantal te kopieren woorden.
– In geval van een PE-naar-PC actie: het beginadres van het gereserveer-
de geheugenblok in het hoofdgeheugen. Het aantal geschreven woorden
wordt bepaald vanuit de PE zelf.
De PE beschikt over twee DMA-kanalen: een lees- en een schrijfkanaal. Deze worden
geidentificeerd door 1 bit: ‘0’ is gereserveerd voor een PC-naar-PE actie; ‘1’ voor
een PE-naar-PC actie.
In VHDL wordt een component geschreven om te communiceren met de DMA-
controller. Van zodra de gevraagde adressen vanuit de software zijn doorgegeven
aan de FPGA, kan men de DMA-initialisatie starten.
De eerste stap bij de DMA-initalisatie is steeds: de bus aanvragen. Dit gebeurt
door het signaal Bus Req hoog te zetten. Van zodra hierop positief gereageerd wordt
door een BusGnt-signaal gelijk aan ’1’, kan de communicatie met de DMA-controller
beginnen.
De gevolgde stappen hierbij zijn relatief eenvoudig.
Voor een PC-naar-PE actie: hierbij moet de DMA-controller duidelijk weten hoe-
veel woorden hij moet ophalen uit het hoofdgeheugen van de PC. Daarom moeten
vanuit de PE twee parameters worden doorgegeven aan de DMA-controller: het
beginadres (hardware-adres) van het te transfereren blok in het geheugen, en het
aantal woorden.
Voor een PE-naar-PC actie: hierbij bepaalt de PE zelf hoeveel woorden hij door-
stuurt via DMA. Uiteraard moet hij hierbij rekening houden met de gereserveerde
hoeveelheid geheugen voor de DMA-operatie!
De controller voor DMA initialisatie ziet er uit als in Figuur C.10.
Wanneer een transfer in beide richtingen moet worden ondernomen, is het aan te
raden om eerst de PE-naar-PC actie te initialiseren. Zoniet zal de DMA-controller
na de eerste initialisatie reeds starten met de PC-naar-PE transfer, zodat de bus
niet meer vrijkomt voor de tweede initialisatie.
De DMA-gegevens kunnen op volgende manier gedetecteerd worden. Hierbij is het
belangrijk te weten dat de data hoogstwaarschijnlijk niet in een aaneensluitend stuk
125
WAIT
BusReq<='1'
startPC-naar-PE
BusReq<='1'
DMA_Init<='1'
Data_out <= HW_Addr & "00"
BusGnt='1'
BusReq<='1'
DMA_Init<='1'
Data_out <= count
BusReq<='1' BusReq<='1'
DMA_Init<='1'
Data_out <= HW_Addr & "01"
BusGnt='1'start
PE-naar-PC
Figuur C.10: Controller voor DMA-initialisatie.
binnenkomt! Wanneer wel geldige data binnenkomt, zal dit aangegeven worden door
het signaal DMA Strobe (zie Figuur C.11). Er wordt overigens geen adres toegekend
aan de data, de logica op FPGA zal zelf moeten bijhouden welk stukje data nu aan
de beurt is.
Clk
Data_In D0 D1��DMA_strobe
���D2��Figuur C.11: Detectie van DMA-data.
126
Om data te versturen moet eerst en vooral de bus beschikbaar zijn (BusGnt=‘1’).
Van zodra dit het geval is, kan de data aangelegd worden op de bus, terwijl het
signaal Strobe Out hoog wordt gezet.
Clk
Data_out D0 D1��Strobe_out
���D2 ��BusGnt
IN
UIT
Figuur C.12: Versturen van data via DMA.
127
C.7 ZBT via DMA
DMA-data van de bus plukken is betrekkelijk evident. Het is eveneens evident om
deze data weg te schrijven naar SelectRAM. Bij SelectRAM kan het adres en de
data in dezelfde cyclus aangelegd worden.
Bij het ZBT-geheugen is dit minder evident. Het adres moet immers 2 klokcycli
voor de data aangelegd worden! De data die op tijdstip t op de bus verschijnt, kan
pas op tijdstip t+2 aangelegd worden aan het ZBT-geheugen.
Er is een controller vereist om dit probleem op te lossen...
0
1
DMA_strobe='1'
WE_n<='0'
2
adres<=adres+1;
DMA_strobe='1'
3
DMA_strobe='0'DMA_strobe='0'
adres<=adres+1;DateOE_n<='0';
Data_out<=temp2;
DMA_strobe='1'
DateOE_n<='0';Data_out<=temp2;
DM
A_strobe=
'0'DM
A_s
trob
e='1
'DMA_strobe='0'
Figuur C.13: Controller voor ZBT via DMA
Hierbij is temp2 de vertraagde versie van het binnenkomende signaal (over 2 klok-
cycli).
128
C.8 Xilinx ISE en ModelSim
Het is handig om te vertrekken van het standaard-projectje. Dit omvat alle bestan-
den voor aansturing van SRAM, DRAM, klokken, I/O,... Dit project kan zowel
gesimuleerd als gesynthetiseerd worden. Een verschil vereist wel aandacht: bij de
simulatie moeten de Pads (de verbindingen met de buitenwereld) geınitialiseerd
worden. Bij de synthese mag dit niet !
De regel
Pads <= Init_PE_Pads;
moet bij synthese dus uitgecommentarieerd staan!
Daarnaast moet men er bij de synthese op letten dat een constraints-bestand gelinkt
is aan de PE-component. In dit bestand moet een selectie gemaakt worden van de te
gebruiken Pads. Indien bepaalde regels uitgecommentarieerd staan, zullen bepaalde
functies van de WildCardTM-II niet beschikbaar zijn!
C.9 Software
Om de WildCardTM-II API-functies te gebruiken is het nodig dat een aantal be-
standen worden geıncludeerd in het software-project. Om de DMA-mogelijkheden
te kunnen gebruiken is de laatste versie van deze API nodig, namelijk versie 2.6.
De benodigde bestanden zijn na installatie van de WildCardTM-II-software terug te
vinden in de directory “annapolis\host”.
129
Bijlage D
CD-ROM
130
Bibliografie
[1] Datasheet van het DDR-geheugen.
http://www.micron.com.
[2] Datasheet van het VirtexTM-II XC2V3000.
http://www.xilinx.com.
[3] Datasheet van het ZBT-geheugen.
http://www.gsitechnology.com.
[4] WildCardTM-II Reference Manual.
[5] Intel r© VTuneTM Performance Analyzers.
http://www.intel.com/software/products/vtune.
[6] Intel r© Pentium r©-M Chipsets.
http://www.intel.com/design/chipsets/mobile.
[7] M. Depaemelaere. Digitale video: een overzicht van de JVT/AVC-standaard.
Master’s thesis, Universiteit Gent, 2003.
[8] D. Marpe, H. Schwarz, and T. Wiegand. Context-based Adaptive Binary Arith-
metic Coding in the H.264/AVC Video Compression Standard. IEEE Transac-
tions on Circuits and Systems for Video Technology, 2003.
[9] I. E. G. Richardson. H.264 and MPEG-4 Video Compression. John Wiley &
Sons Inc., October 2003. 0-470-84837-5.
131
Recommended