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