Universiteit Gent Faculteit Ingenieurswetenschappen Vakgroep Informatietechnologie Voorzitter: prof. dr. ir. P. Lagasse
Ontwerp van ingebedde ware-tijd software voor de ontvangst van Digital Radio Mondiale (DRM) door Lieven TYTGAT
Promotor: prof. dr. ir. J. Vandewege Scriptiebegeleider: ir. P. Demuytere
Scriptie ingediend tot het behalen van de academische graad van burgerlijk elektrotechnisch ingenieur Academiejaar 2006-2007
Voorwoord Op het einde van mijn carrière als industrieel ingenieur had ik het gevoel dat ik nog net te weinig wist hoe alles in elkaar stak om zelf iets serieus uit te kunnen werken. Tijdens deze studies was ik heel gefascineerd rond alles wat met audiotechnologie te maken had, waardoor imijn keuze van thesisonderwerp vlug gekozen was, namelijk: “Ontwerp van een High-End klasse-D versterker.” Gedurende de loop van deze scriptie werd mij echter duidelijk dat mijn theoretische achtergrond te gering was om zelfstandig een nieuw principe, de sigma-delta modulatie, te doorgronden. Hierdoor heb ik de stap gezet om de studies van burgerlijk ingenieur aan te vangen. Met vallen en opstaan heeft deze studierichting mij heel wat bijgebracht. Een van de grootste leerervaringen die een student meemaakt, is echter nog steeds het creëren van een scriptie. De keuze van het onderwerp is hierdoor uiterst belangrijk. Ik heb voor het uitdagende onderwerp van: “Ontwerp van ingebedde ware-tijd software voor de ontvangst van Digital Radio Mondiale (DRM)”, gekozen. Dit lag voor mij in de verdere lijn van audiotechnologie, alhoewel het niveau waarop dit zou gebeuren, in vergelijking met mijn eerdere scriptie, heel sterk verschillend was. Graag wil ik iedereen bedanken die mij in enige wijze geholpen en ondersteund heeft. Meer specifiek wil ik mijn promotor, prof. dr. ir. J. Vandewege en mijn begeleider, ir. P. Demuytere danken voor hun begeleiding en advies gedurende de loop van deze scriptie. Mijn vriendin, broers en vrienden wil ik bedanken voor hun steun en geduld op de ogenblikken dat het ietwat moeilijker was. Tenslotte wil ik nog mijn ouders bedanken, zonder dewelke ik niet in staat was om deze studies te kunnen volbrengen. De auteur geeft de toelating deze scriptie voor consultatie beschikbaar te stellen en delen van de scriptie te kopiëren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze scriptie. Lieven Tytgat
I
Ontwerp van ingebedde ware-tijd software voor de ontvangst van Digital Radio Mondiale (DRM) door Lieven Tytgat Scriptie ingediend tot het behalen van de academische graad van burgerlijk elektrotechnisch ingenieur Academiejaar 2006-2007 Promotor: Prof. Dr. Ir. J. Vandewege Scriptiebegeleider: Ir. P. Demuytere Faculteit Ingenieurswetenschappen Universiteit Gent Vakgroep Informatie Technologie Voorzitter: Prof. Dr. Ir. P. Lagasse
Samenvatting Digital Radio Mondiale is een systeem dat ontwikkeld werd om de stilaan verouderende
LF-MF-HF
band
nieuw
leven
in
te
roepen.
Aangezien
de
kanaalbreedtes wereldwijd bepaald zijn, is het onmogelijk om deze te wijzigen. Daarom is het ontwerp van DRM er zo op gericht om deze kanalen zo efficiënt mogelijk te benutten. Wegens deze eisen is het systeem vrij complex en rekenintensief geworden. Om deze rekenkracht enigszins te milderen, werd geopteerd om een Linux gebaseerd hardware/software co-ontwerp te creëren. In hoofdstuk 1 wordt deze scriptie geplaatst binnen het geheel. Hoofdstuk 2 gaat dieper in op de DRM-standaard. In het derde hoofdstuk wordt de globale hardware architectuur gekozen, dewelke in het vierde hoofdstuk ontwikkeld wordt. Het Linux besturingssysteem wordt op het gecreëerde platform geplaatst in het vijfde hoofdstuk en tenslotte wordt in het zesde hoofdstuk de Dreamsoftware nader bekeken. trefwoorden: Digital Radio Mondiale, DRM, Dream, microblaze, uClinux, Linux, embedded, real-time, FPGA II
III
IV
INHOUDSTAFEL 1. Inleiding......................................................................................................... .....1 2. DRM-ontvanger..................................................................................................3 2.1. Wat is DRM?................................................................................................3 2.2. DRM-technologie[1].....................................................................................3 2.2.1. Frequentie- en tijdsafregeling...............................................................4 2.2.2. COFDM-Demodulatie............................................................................6 2.2.3. Kanaaldecodering.................................................................................7 1. Decisie.................................................................................................. ..7 2. Celdeinterleaver (enkel voor MSC).........................................................8 3. Bitdeinterleaver.................................................................................. ....8 4. Kanaaldecodering.............................................................................. .....8 5. Datarate............................................................................. ....................9 2.2.4. Brondecodering..................................................................................10 1. Demultiplexen......................................................................................10 2. Bron decodering...................................................................................11 3. Architectuurkeuze............................................................................................12 3.1. Inleiding.................................................................................................. ...12 3.2. Hardware/Software trade-off.....................................................................12 3.2.1. Complexiteit en Snelheid van een DRM-systeem...............................12 3.2.2. Schatting van de ontwerpsduur.........................................................13 3.2.3. Compleet hardware gebaseerd..........................................................15 1. Complexiteit.........................................................................................15 2. Snelheid...............................................................................................16 3. Kostprijs............................................................................................. ...16 3.2.4. Compleet software gebaseerd............................................................16 1. Complexiteit.........................................................................................16 2. Snelheid...............................................................................................16 3. Kostprijs............................................................................................. ...17 3.2.5. Gesplitst hardware en software ontwerp............................................17 1. Complexiteit en Snelheid......................................................................17 2. Kostprijs............................................................................................. ...18
V
3.2.6. Hardware/software codesign..............................................................18 1. Complexiteit.........................................................................................19 2. Snelheid...............................................................................................19 3. Kostprijs............................................................................................. ...19 3.2.7. Conclusie................................................................................ ............19 3.3. Besturingssysteem....................................................................................20 3.3.1. Voor- en nadelen van een besturingssysteem....................................20 3.3.2. Keuze van het besturingssysteem......................................................21 3.4. Hardware overzicht...................................................................................23 4. Opbouw van het hardware platform.................................................................24 4.1. Inleiding.................................................................................................. ...24 4.2. Minimale eisen van het besturingssysteem...............................................24 4.3. Bouwen van de basishardware..................................................................25 4.4. Hardware verbeteringen............................................................................28 4.4.1. Cache geheugen................................................................................28 4.4.2. Klok frequenties.................................................................................29 4.4.3. Snelle download verbinding...............................................................31 4.5. uClinux specifieke instellingen voor het hardware project........................32 5. Microblaze - uClinux.........................................................................................34 5.1. Inleiding.................................................................................................. ...34 5.2. Memory Management Unit (MMU).............................................................34 5.2.1. Wat is een MMU?[3]............................................................................34 5.2.2. Probleempunten bij het ontbreken van een MMU?[4].........................35 1. Reallocatie ter uitvoering van het proces.............................................35 2. Stackgeheugen....................................................................................36 3. Geheugenprotectie...............................................................................36 4. Wisselgeheugen...................................................................................37 5.3. uClinux versus Linux[4].............................................................................37 5.3.1. Geheugenbeheer................................................................................37 5.3.2. Stackgeheugen.................................................................................. .38 5.3.3. Malloc................................................................................. ................38 5.3.4. fork en vfork.......................................................................................38 5.3.5. flat uitvoerbare bestanden.................................................................39 5.3.6. Gedeelde bibliotheken .......................................................................40 5.4. Opzetten van het uClinux platform............................................................40 VI
5.4.1. Software-instellingen..........................................................................40 1. Globale instellingen..............................................................................41 2. Kernelinstellingen.................................................................................42 3. Gebruikersinstellingen..........................................................................47 5.4.2. Debuggen op het microblaze platform...............................................49 5.5. Bord initialisatie..................................................................................... ....49 6. Dream.............................................................................................................. .53 6.1. Overzicht Dream-software.........................................................................53 6.2. Dream-werkingsprincipes..........................................................................54 6.2.1. Frequentie- en tijdssynchronisatie[11]...............................................54 1. Ideale OFDM-demodulatie....................................................................54 2. Afwijking v.d. IF-frequentie...................................................................54 3. Afwijking v./d. bemonsteringsfrequentie..............................................55 4. Benodigde IF- en bemonsteringsfrequentieaccuraatheid.....................56 5. Werkingsprincipe van de afregelkring..................................................57 6. Invloed op de embedded implementatie..............................................57 6.2.2. Frequentieacquisitie...........................................................................58 6.2.3. Tijdsacquisitie............................................................................. ........59 6.2.4. Kanaalschatting[14]...........................................................................61 6.3. Benodigde bibliotheken.............................................................................62 6.4. Porten van de software..............................................................................63 6.5. Toekomstmogelijkheden............................................................................65 7. Conclusie........................................................................................... ...............66 Appendix A: Installatie van de Xilinx tools en Petalinux...................................68 A.1. Controle van de Linux omgeving...............................................................68 A.2. Installatie van de Xilinx tools.....................................................................68 A.3. Installatie van de download cable (USB of parallel vIII op parallel vIV in vIII compatibiliteit).................................................................................................69 A.4. Installatie van Petalinux............................................................................70 A.5. Kermit................................................................................................. .......71 A.6. Installatie van uClinux BSP bestanden voor Windows...............................72 Appendix B: Opzetten van de basishardware.......................................................73 Appendix C:Voorbereiding uClinux hardwareproject.............................................78 C.1. Instelling van het softwareplatform in het hardwareproject......................78 C.2. Instellen van de Bootloader FS-BOOT.......................................................80 VII
C.3. Hardware-software verbinding maken.......................................................81 Appendix D:Makefiles...........................................................................................83 D.1. Zonder gebruik van configure (Journaline Makefile)..................................83 D.2. Met gebruik van configure (Dream Makefile)............................................84 Bibliografie................................................................................ ...........................87
VIII
Gebruikte afkortingen Afkorting
Betekenis
AAC
Advanced Audio Coding
AM
Amplitude Modulatie
ASIC
Application Specific Integrated Circuit
BER
Bit Error Rate
BRAM
Block RAM
CELP
Code Excited Linear Prediction
COFDM
Coded Orthogonal Frequency Division Multiplexing
DAB
Digital Audio Broadcast
DDS
Direct Digital Synthesizer
DFT
Discrete Fourier Transform
DMB
Digital Multimedia Broadcast
DRM
Digital Radio Mondiale
DVB
Digital Video Broadcast
FAAC
Free Advanced Audio Coder
FAAD
Free Advanced Audio Decoder
FAC
Fast Associated Channel
FFT
Fast Fourier Transform
FFTW FM FPGA FSL
Fastest Fourier Transform of the West Frequentie Modulatie Field Programmable Gate Array Fast Simplex Link
GPIO
General Purpose Input Output
HVXC
Harmonic Vector eXcitation Coding
ICI
Inter Carrier Interference
IDE
Integrated Drive Electronics
IF
Intermediate Frequency
ISI
Inter Symbol Interference
KSLOC
Kilo Source Lines Of Code
LAN
Local Area Network
LCD
Liquid Crystal Display
LF-MF-HF MLC MPEG MSC
Laag Frequent – Midden Frequent – Hoog Frequent Multi Level Coding Moving Pictures Expert Group Main Service Channel IX
OFDM
Orthogonal Frequency Division Multiplexing
PIC
Position Independant Code
PS
Parametric Stereo
QAM
Quadrature Amplitude Modulation
RAM
Random Access Memory
SBR
Side Band Replication
SDC
Service Description Channel
SLOC
Source Lines Of Code
SRV VLAN XIP
Signaal tot Ruis Verhouding Virtual LAN eXecute In Place
X
1. Inleiding Deze scriptie is één van in totaal drie scripties die handelen rond het ontwerpen van een DRM-ontvanger (Zie figuur 1.1). De eerste scriptie, uitgevoerd door Guy Torfs, handelt over het ontwerpen van een kortegolfantenne en front-end. De tweede scriptie, uitgevoerd door Guus Colman en Jasmien Put, handelt over het ontwerpen van een AGC controller, gevolgd door een digitalisatie en een digitale mixer. Het derde deel, en tevens het onderwerp van deze scriptie, handelt over het ontwerp van de DRM-demodulatie en decodering, om uiteindelijk tot een volledig zelfstandig werkende DRM-ontvanger te komen.
Scriptie 1
Scriptie 2
Scriptie 3
Antenne
AGC
DRM demodulatie
versterker
A/D conversie
DRM decodering
Analoge mixer naar een IF van 5Mhz
Digitale mixer naar een IF van 12kHz
Afspelen muziek + Gebruikersinterface
Figuur 1.1: Overzicht van de verscheidene scripties rond het ontwerpen van een DRMontvanger.
Een dergelijke DRM-ontvanger legt een aantal eisen op aan het ontwerp van deze scriptie: 1. De ontvanger moet zelfstandig kunnen werken, zonder dat er een PC een deel van de taken voor zich neemt. 2. De DRM-ontvanger heeft een analoge en/of een digitale interface naar buiten toe. 3. De DRM-ontvanger moet een mogelijkheid bieden om de besturing lokaal te laten gebeuren (met drukknoppen, infrarood of gelijkaardig). 4. Tussen scriptie twee en scriptie drie bevindt zich een digitale verbinding. 5. Optioneel: Mogelijkheid om via netwerk te besturen en te beluisteren. Het blokschema van een dergelijk systeem is te vinden in figuur 1.2.
1
Netwerk besturing
LCD-display met pushbuttons
Interactie met gebruiker
Digitale ingang IF = 12kHz, fs=48 kHz
DRM demodulatie en decodering
Netwerk stream Digitale uitgang Analoge uitgang
Figuur 1.2: Overzicht van de vooropgestelde mogelijkheden die het product zou kunnen verschaffen
Het ontwerpen van een DRM-ontvanger begint natuurlijk met het nader bekijken van de DRM-standaard, zoals in hoofdstuk twee besproken wordt. Zonder deze stap is het onmogelijk om een enigszins gefundeerde beslissing te nemen rond de mogelijke ontwerpkeuzes. In hoofdstuk drie worden de verschillende mogelijke hardwarearchitecturen bekeken. Na deze studie wordt de vraag gesteld of een besturingssysteem hier een extra toegevoegde waarde zou kunnen bieden. Het vierde hoofdstuk draait rond het ontwerpen van het hardwareplatform vooropgesteld
in
hoofdstuk
drie.
Vooral
de
hardware-eisen
van
het
besturingssysteem worden specifiek van naderbij bekeken. Eenmaal het hardwareplatform vastgelegd werd, was het moment aangebroken om de keuze te maken over het wel of niet gebruiken en de keuze van een besturingssysteem. Hoofdstuk zes gaat dieper in op de werking van de Dream-software, gevolgd door de grootste stappen die nodig zijn voor het porten naar het platform. Tenslotte wordt in het laatste hoofdstuk de totale afrekening gemaakt. Wat zijn de sterke en zwakke punten van het product, waar ging het goed en waar was het minder.
2
2. DRMontvanger 2.1. Wat is DRM? DRM staat voor Digital Radio Mondiale, wat vrij vertaald wordt in digitale wereldomroep. Het gaat dus over digitale audio uitzendingen in de LF-MF-HF (30kHz tot 30Mhz) band. Aangezien het zendgebied van dergelijke zenders wereldomvattend kan zijn, is het praktisch onmogelijk om de beschikbare kanalen aan te passen aan de nieuwe technologie. Dit zou namelijk betekenen dat de wereldwijde regulerende instanties de beschikbare kanalen zouden moeten aanpassen, wat een onmogelijke opdracht is. Vandaar dat er bij DRM voor gekozen werd om de beschikbare kanalen zo goed mogelijk te benutten. Dit staat in heel groot contrast met de standaarden DAB, DVB en DMB. Hierbij werden kanalen beschikbaar gemaakt specifiek voor deze standaarden. Helaas zijn deze niet wereldwijd bepaald. De zendbereiken zijn echter ook beperkt, waardoor dit geen echt probleem oplevert. De standaard bandbreedte van een AM kanaal is slechts 9 of 10kHz. De ontvangstkwaliteit van een standaard DRM-kanaal is gelijkaardig aan huidige stereo FM ontvangst. DRM heeft dus slechts 10kHz bandbreedte nodig om met dezelfde kwaliteit als FM te kunnen ontvangen, waar stereo FM 53kHz bandbreedte nodig heeft. Hieruit volgt dat de complexiteit van de codering vrij hoog moet liggen om een dergelijke ontvangstkwaliteit te kunnen garanderen. DRM kan ook extra informatie meesturen met de audiostream. De audiostream wordt verpakt in een MPEG-4 container, waardoor deze extra informatie interleaft kan worden met de audiostream.
2.2. DRMtechnologie[1] De DRM-technologie is volledig gebouwd rond het optimaal benutten van het kanaal. Een heel aantal nieuwe technologieën wordt gebruikt om het mogelijk te maken kwalitatief geluid over te brengen naar wereldwijde ontvangers. Dit hoofdstuk zal dan ook de ontvangstkant van een DRM-systeem bekijken, waarvan een blokschema is weergegeven in figuur 2.1. Het ontvangen signaal bevindt zich al in 'pseudo'-basisband.
3
Audio bron dec.
Ontvangen signaal Tijd en freq. afregeling
COFDM Demod + decisie
Deinterleaver MSC Kanaal dec
Data bron dec.
FAC kanaal dec
Bron Decodering
SDC Kanaal dec
Bron Decodering
Figuur 2.1: Globaal blokschema van een DRM-demodulator en decoder.
Het
eerste
deel
is
de
tijds-
en
frequentieafregeling,
gevolgd
door
de
COFDM-demodulatie en decisie. Hierna wordt de gegevensstroom opgesplitst in een MSC-kanaal (Main Service Channel), een FAC-kanaal (Fast Access Channel) en een SDC-kanaal (Service Description Channel). Het MSC-kanaal bevat de audio en data services die gebonden zijn aan een zender. Het FAC-kanaal maakt het mogelijk om de zendmodus van de zender snel te weten te komen. Door het FACkanaal kan ook snel gescand worden. Tenslotte is het SDC-kanaal het kanaal dat informatie draagt over de decodering van de MSC, en over het vinden van alternatieve zenders.
2.2.1. Frequentie en tijdsafregeling Een DRM-signaal beschikt niet over een carrier waarop kan gesynchroniseerd worden. Hierdoor wordt het heel wat moeilijker om op het signaal te kunnen locken. Vandaar dat er gekozen werd om een framestructuur te gebruiken, zoals in figuur 2.2 weergegeven. Deze structuur is zodanig opgebouwd dat het mogelijk is een degelijke synchronisatie te maken zonder veel verlies van bandbreedte of SRV. Het grootste frame is het superframe. Dit superframe bestaat uit drie transmissieframes,
waarvan
het
allereerste
blok
een
SDC-blok
is.
Een
transmissieframe duurt 400ms, en bevat een aantal COFDM-symbolen. Het eerste symbool van een transmissieframe is een tijdsreferentie symbool. Het aantal COFDM-symbolen binnen een transmissieframe is afhankelijk van de modus waarin de zender werkt (Modus A + B: 15, modus C: 20, modus D: 24). Ieder COFDM-symbool beschikt over een guard interval aan het begin van het symbool, hetwelk bestaat uit een cyclische uitbreiding van het symbool. De lengte van dit interval is net als de totale symboollengte afhankelijk van de modus waarin DRM werkt. 4
Superframe
3 Transmissie frames SDC cellen 400 ms Ns COFDM symbolen Tijds referentie cellen Figuur 2.2: Overzicht van het superframe van een DRM-systeem
De verzonden data wordt gemoduleerd d.m.v. een COFDM-modulatie. COFDM splitst de beschikbare bandbreedte op in een heel aantal kleine subkanaaltjes die orthogonaal gemoduleerd zijn, om zodoende overspraak van het ene kanaal op het andere te voorkomen. Ieder subkanaal wordt een cel genoemd. Deze cellen hebben drie verschillende mogelijke constellaties: 4-QAM, 16-QAM of 64QAM en bezitten geen carrier. Bij COFDM moet echter coherente ontvangst plaatsvinden, die enkel kan voltooid worden door het detecteren van de frequentiereferenties. Deze liggen op vaste frequenties: 750Hz, 2250Hz en 3000Hz, en hebben een vermogen versterking van 2. In de verschillende zendermodi zijn dit verschillende cellen omdat deze kanalen een bandbreedte hebben die afhankelijk is van de modus.
Robuust-
750Hz cel
2250Hz cel
3000Hz cel
heids
cel
fase
cel
fase
cel
fase
modus
nummer
index
nummer
index
nummer
index
A
18
205
54
836
72
215
B
16
331
48
651
64
555
C
11
214
33
392
44
242
D
7
788
21
1014
28
332
Tabel 2.1: Frequentiereferentiecellen en hun respectievelijke faseindex bij de verschillende robuustheidsmodi.
fase index=
fase ×1024 360
5
Deze frequentiereferenties lopen continu verder waardoor over alle symbolen een continu signaal met vaste frequentie ontstaat. Het eerste symbool van ieder transmissie frame bevat een groot aantal tijdsreferentiecellen. In een tijdsreferentiecel liggen de fases en amplitudes vast, gelijkaardig aan de frequentiereferentiecellen. Door de grote hoeveelheid vaste referentiecellen in dit symbool is het echter mogelijk om deze op tijds- en frequentiegebied heel exact te bepalen. Eenmaal de tijdsreferentiesymbolen gevonden zijn is het begin van een frame gevonden. Om de subkanalen exact te kunnen modelleren worden er zogenaamde pilootcellen meegestuurd. Deze pilootcellen wijzigen telkens van subkanaal (=cel) bij ieder nieuw COFDM-symbool, waardoor elk subkanaal apart kan gesynchroniseerd worden. M.a.w., de kanaalvervorming kan hierdoor heel goed geschat worden voor ieder subkanaal, zonder dat elk subkanaal een vaste carrier nodig heeft. De locaties van de pilootsymbolen herhalen zich in ieder transmissieframe.
Het
aantal pilootcellen
is
afhankelijk
van
de
gekozen
robuustheidsmodus en de kanaal bandbreedte.
2.2.2. COFDMDemodulatie Eenmaal de tijds- en frequentieafregeling voltooid is, volgt de COFDMdemodulatie. Deze demodulatie en de tijds- en frequentieafregeling zijn echter afhankelijk van elkaar. De tijds- en frequentieafregeling kan namelijk enkel plaatsvinden
indien
het
ontvangen
signaal
gedemoduleerd
werd
(frequentiedomein naar tijdsdomein terugkoppeling). COFDM wordt gedemoduleerd door middel van het uitvoeren van een DFT op het binnenkomende signaal. Hierdoor worden alle subkanalen die gemultiplexed worden via COFDM terug parallel beschikbaar. Ieder subkanaal kan nu apart gedeciseerd worden. De lengte van de DFT is gelijk aan het aantal elementaire tijdseenheden dat in het bruikbare deel van een symbool aanwezig is (Tu in tabel 2.2). Hieruit volgt dat het onmogelijk is om via het FFT algoritme te werken, aangezien een FFT altijd een macht van twee lang is. Een volledig symbool bezit naast het bruikbare deel nog een guard interval met lengte Tg. Tesamen hebben deze dan een volledige symbooltijd, Ts. Tabel 2.2 toont de verschillende symbooltijden en het aantal gebruikte kanalen i.f.v. de robuustheidmodus en de totale kanaalbandbreedte.
6
Robuustheid
Tu
Tg
Ts
Modus
Tabel
Gebruikte kanalen i.f.v. bandbreedte
(Tu+Tg)
4,5
5
9
10
18
20
A
288
32
320
101
113
202
226
410
458
B
256
64
320
91
103
182
206
366
410
C
176
64
240
-
-
-
138
-
280
D
112
88
200
-
-
-
88
-
178
tijden
worden
2.2:
Samenvatting
van
de
COFDM-symboolparameters.
weergegeven in veelvouden van de elementaire periode T =
De
831/ 3 s .
2.2.3. Kanaaldecodering De kanaalcodering is een zogenaamde multilevel-codering. Het basisprincipe van multilevel-codering houdt in dat de kanaalcodering en de modulatie aangepast zijn aan elkaar om zodoende de optimale Bit Error Rate (BER) te bekomen. Dit betekent in realiteit hoofdzakelijk dat de bit posities die sneller foutief ontvangen zullen
worden,
een
hogere
beschermingsgraad
kunnen
krijgen
door
de
kanaalcodering. De kanaaldecodering wordt voor elk kanaal (MSC, FAC en SDC) apart uitgevoerd. Ze bestaat uit vier delen voor het MSC kanaal, en drie delen voor de FAC en SDC kanalen. Decisie
Cell Deinterleaver
Bit Deinterleaver
Kanaal Decoder
MSC data
Decisie
Bit Deinterleaver
Kanaal Decoder
FAC data
Decisie
Bit Deinterleaver
Kanaal Decoder
SDC data
Figuur 2.3: Overzicht van de kanaaldecodering
1. Decisie De eerste stap na de demodulatie is de decisie. De decisie is een standaard decisie die op ieder subkanaal (cel) uitgevoerd wordt. Er zijn drie verschillende constellaties mogelijk: 4-QAM, 16-QAM en 64-QAM.
7
2. Celdeinterleaver (enkel voor MSC) In de decodering van het MSC-kanaal is de volgende stap de celdeinterleaver. Een
celinterleaver
zorgt
ervoor
dat
de
data
die
door
middel
van
de
kanaalcodering tegen fouten beveiligd is, gespreid wordt over verschillende cellen binnen één kanaal. Hierdoor betekent het verlies van een aantal opeenvolgende cellen niet dat alle gegevens binnen deze cellen verloren zijn. De gegevens van deze cellen kunnen meestal gecorrigeerd worden door de kanaaldecodering. Zonder een celinterleaver is de kans dat een aantal opeenvolgende verloren cel niet kunnen gecorrigeerd worden heel wat groter. De
celdeinterleaver
is
een
convolutionele
deinterleaver
en
heeft
twee
verschillende werkingsmodi: een korte of een lange deinterleaver. Afhankelijk van de te verwachten ontvangstcondities wordt een van deze modi gekozen door de zender. De korte interleaver introduceert een vertraging van 2 superframes (=800ms), terwijl de lange interleaver een vertraging van 6 superframes introducueert (=2,4s). De lange interleaver is beter geschikt voor kanalen met heel grote tijdsdomein-fading.
3. Bitdeinterleaver Deze interleavers zorgen er voor dat binnen de bitstream burstfouten mogen optreden. Deze zijn namelijk heel snel mogelijk indien vb. één cel verloren gaat. Deze cel introduceert een aantal bitfouten na elkaar (2, 4 of 6 afhankelijk van de constellatie), waardoor een interleaving op bitniveau deze fouten kan corrigeren. De bitdeinterleavers zijn, net zoals de celinterleavers bij MSC, convolutionele deinterleavers. De blokgrootte is afhankelijk van het kanaal. Bij de FAC en SDC kanalen is er maar één modus beschikbaar, terwijl er bij het MSC-kanaal verschillende modi beschikbaar zijn.
4. Kanaaldecodering De
kanaaldecodering
wordt
in
de
Dream-software
uitgevoerd
als
een
viterbi-decodering. De codering is een zogenaamde 'punctured' convolutionele codering. Uit de uitvoer van één convolutionele encoder met vier uitgangen, zoals in figuur 2.4 weergegeven, worden de verschillende codesnelheden gecreëerd aan de hand van een zogenaamd puncturing patroon.
8
Figuur 2.4: De vier-uitgangs convolutionele encoder
Het zogenaamde puncturing patroon maakt een nieuw codewoord als een combinatie van deze uitgangsbits. Als voorbeeld van de werking wordt het codesnelheid 3/10 puncturingpatroon genomen, zoals in onderstaande tabel weergegeven. Uitgang
Bitx,0
Bitx,1
Bitx,2
B0,x
1
1
1
B1,x
1
1
1
B2,x
1
1
1
B3,x
1
0
0
Repeterend patroon per 3 ingangsbits b0,0b1,0b2,0b3,0b1,1b2,1b3,1b2,0b2,1b2,2
De FAC- en SDC-kanalen worden altijd met één vaste codesnelheid geëncodeerd, terwijl het MSC-kanaal gebruik kan maken van twee verschillende codesnelheden.
Hierdoor
kunnen
de
gegevens
in
het
MSC-kanaal
op
twee
verschillende beveiligingsniveaus beveiligd worden.
5. Datarate De totale datarate aan informatiebits mogelijk doorheen het gecodeerde kanaal varieert heel sterk afhankelijk van de robuustheidsmodus, de bandbreedte van het kanaal, de constellatie en de gebruikte kanaalcodering. De maximale en minimale datarates afhankelijk van de robuustheidsmodus worden hieronder weergegeven.
9
Robuustheidsmodus
Max. datarate (kbps)
Min. datarate (kbps)
A
72
6,3
B
56,1
4,8
C
45,5
9,2
D
30,6
6,1
Tabel 2.3: Max. en min. datarate beschikbaar voor de bronencoder.[2]
2.2.4. Brondecodering De brondecodering wordt enkel besproken voor het MSC-kanaal, daar deze veruit de hoogste complexiteit bezit. Tevens is er rond de data-brondecodering heel weinig informatie te vinden. Er is wel de zogenaamde journaline-decoder, die tevens bij Digital Audio Broadcast (DAB) en Digital Multimedia Broadcast (DMB) gebruikt wordt. Hier zal echter niet dieper op ingegaan worden. Hoge bescherming Vanaf MSC kanaaldec.
Lage bescherming Demultiplexer
Audio bron decoder
Hoge bescherming Lage bescherming
Data bron decoder
Naar gebruiker
Naar gebruiker
Figuur 2.5: Overzicht van de brondecodering
1. Demultiplexen De gegevens die vanaf de MSC-kanaaldecodering binnenkomen bevatten één tot vier streams. Elke stream bestaat uit logische frames van 400ms en bevat ofwel audio ofwel data. Een audiostream kan nog één data-substream bezitten (om bv. de huidige artiest mee te sturen). Een datastream kan uit vier of minder substreams bestaan, dewelke elk één service bevatten. Ieder logisch frame kan een opsplitsing hebben in twee verschillende beveiligingsniveaus. Binnen één stream is het dus mogelijk dat er twee verschillende beveiligingsniveaus zijn.
10
2. Bron decodering Er zijn een aantal verschillende bron decoders aanwezig om aan de verscheidene eisen van de gebruikte geluidsstromen (muziek of stem) te kunnen voorzien. Deze zijn allemaal beschreven in de MPEG-4 standaarden. Advanced Audio Coding (AAC) is bedoeld als hogekwaliteits muziek-codec. Code Excited Linear Prediction (CELP) is een spraak-codec die toelaat om spraak op een vrij lage bitrate (vb. 8 kpbs) uit te kunnen zenden. Harmonic Vector eXcitation Coding (HVXC) is ook een spraak-codec, maar die bij extreem lage bitrates (tot 2 kpbs!) toch nog een redelijke kwaliteit heeft. AAC decoder Super frame Demultiplexer
CELP decoder
SBR decoder
Audio Uitgang
HVXC decoder Figuur 2.6: Overzicht van de audio bron decodering
Tenslotte kan bij iedere codec tevens de Side Band Replication (SBR) geactiveerd worden. Dit is een codec die hoogfrequent geluid, dat door één van voorgaande codecs niet kon worden gecodeerd wegens de te kleine bandbreedte, toch door kan sturen. Hiervoor wordt slechts een klein deel van de beschikbare bandbreedte
gebruikt.
Een
gelijkaardig
systeem
laat
ook
toe
om
een
Parametrische Stereo (PS) signaal te genereren. Hierbij wordt een mono signaal gedownmixt, om dit dan samen met het verschil tussen het mono en de twee stereo kanalen uit te zenden. Tenslotte moet er nog vermeld worden dat er slechts een aantal van de bij MPEG-4 mogelijke instellingen ondersteund word. De belangrijkste beperkingen zijn: ●
Beperkte bitrate
●
Beperkte samplefrequentie
●
Foutrobuustheid: Een aantal instellingen die het systeem heel bitfout gevoelig maken zijn niet toegelaten. Hierdoor blijft de foutrobuustheid zo hoog mogelijk te houden.
●
De
(super)framelengte
van
de
bron
encoder
moet
exact
in
een
transmissieframe van 400ms passen.
11
3. Architectuurkeuze 3.1. Inleiding De architectuurkeuze van een embedded systeem bepalend voor de uiteindelijke mogelijkheden van het systeem. Vooreerst wordt de hardware/software trade-off bekeken. Hierin wordt getracht om op een gefundeerde manier een globale architectuur te kiezen. Daarna wordt het nut van een besturingssysteem op een dergelijk hardwareplatform bekeken. Tenslotte wordt de effectieve hardwarearchitectuur overlopen.
3.2. Hardware/Software tradeoff In eerste instantie wordt de definitie van de hardware architectuur herleid tot een hardware/software trade-off. De keuze wordt herleid tot vier mogelijke soorten systemen. 1. Compleet hardware gebaseerd 2. Compleet software gebaseerd 3. Gesplitst hardware en software ontwerp 4. Hardware/software codesign In de volgende delen zullen deze vier mogelijkheden verder uitgediept worden. Om een gefundeerde keuze te maken zullen de verschillende aanpakken op drie punten vergeleken worden. Als eerste luik worden de verschillende aanpakken beoordeeld op gebied van mogelijke ontwerpcomplexiteit. Ten tweede wordt de mogelijke verwerkingssnelheid geschat en tenslotte zal de totale kostprijs van het systeem geschat worden.
3.2.1. Complexiteit en Snelheid van een DRMsysteem De complexiteit van een volledige DRM-systeem is, zoals in hoofdstuk 2 beschreven, zeker niet te onderschatten. Uit figuur 3.1 kan men vier essentiële delen halen. Gesampeld signaal Acquisitie
OFDM demodulatie
Kanaal decodering
Bron decodering
Muziek
Figuur 3.1: Beknopt blokschema van een DRM-systeem
12
Ieder van deze vier delen bezit een verschillende nood aan verwerkingssnelheid en complexiteit. Het eerste deel handelt hoofdzakelijk over frequentie- en sampleratedetectie en afregeling. Dit deel is het meest 'eenvoudige', en tijdskritische deel van een DRM-ontvanger. Het tweede deel, de OFDMdemodulatie is al een stuk complexer, omdat er nu al gelockt moet worden op de ontvangen OFDM-symbolen. Onderstaande tabel geeft een overzicht van de benodigde bewerkingen in de acquisitie en OFDM-demodulatie stappen. Modus A Bewerking
B
C
D
*
+
*
+
*
+
*
+
72k
24k
72k
24k
72k
24k
72k
24k
Tijds sync.
144k
168k
144k
168k
144k
168k
144k
168k
Freq. sync.
108k
43k
96k
38k
88k
35k
67k
27k
FFT
396k
396k
346k
346k
298k
298k
210k
210k
Channel eq.
43k
22k
38k
19k
35k
18k
27k
13k
Channel est.
17k
34k
16k
31k
14k
28k
11k
21k
<10k
<10k
<10k
<10k
<10k
<10k
<10k
<10k
Mixer
Overige
Tabel 3.1: Overzicht van het aantal optellingen of vermenigvuldigingen benodigd per seconde voor de verschillende onderdelen van de acquisitie en OFDM-demodulatie.[2]
Vanaf dit punt stijgt de complexiteit heel sterk. De kanaaldecodering is nog ingewikkelder,
aangezien
hier
de
deinterleaving
en
de
viterbidecodering
plaatsvinden. Hierbij is er ook een vrij grote verwerkingssnelheid benodigd. Tenslotte is de brondecodering het meest complexe en rekenintensieve deel van de volledige ontvanger.
3.2.2. Schatting van de ontwerpsduur Om een schatting te bekomen van de omvang van een dergelijk systeem wordt het aantal broncodelijnen, de zogenaamde Source Lines Of Code (SLOC) van de Dream-software naderbij bekeken. In onderstaande tabel wordt een overzicht gegeven van het aantal codelijnen die benodigd zijn. De Dream-software is voorzien van een grafische gebruikersinterface gebaseerd op QT. Aangezien de uiteindelijke oplossing deze gebruikersinterface niet benodigd heeft, zal deze nergens meegerekend worden. Er moet nog opgemerkt worden dat de functionaliteiten die de fftw2 bibliotheek biedt veel groter zijn dan de benodigde functionaliteiten. Om geen vals beeld te 13
geven wordt een gewichtsfactor t.o.v. het werkelijk aantal codelijnen van 10% meegerekend worden. De FAAD2 audiodecodering daarentegen zal vrij compleet gebruikt worden, waardoor een gewichtsfactor van 75% gekozen wordt. Tenslotte zal van de datacompressiebibliotheek, zlib, enkel de decodering gebruikt worden, waardoor een gewichtsfactor van 50% gekozen wordt. Dream is in hoofdzaak in C++ geschreven. De bibliotheken zijn allemaal in C geschreven. Om de schatting eenvoudig te houden wordt er geen verschil gemaakt tussen C en C++ code. Onderdeel
SLOC
Benodigde SLOC
Input-Output
1676
1676
Kanaal schatting
2878
2878
Resample
3070
3070
Synchronisatie
3358
3358
Totaal acquisitie:
10982
10982
fftw2 (10% gewichtsfactor)
76713
7671,3
406
406
1259
1259
78378
9336,3
5220
5220
FAC-decodering
646
646
SDC-decodering
1986
1986
Totaal Kanaaldecodering
7852
7852
Audio decodering (FAAD2) (75% gewichtsfactor)
88055
66041,25
Data decompressie (ZLIB) (50% gewichtsfactor)
22198
11099
Data decodering
10552
10552
Totaal Brondecodering
120805
87692,25
Totaal voor de gehele oplossing
218017
115862,55
interleaver OFDM mapper Totaal COFDM-Demodulatie Multi Level Decodering
Tabel 3.2: Overzicht van de SLOC benodigd bij de verschillende onderdelen van Dream.
Eenmaal deze gegevens gekend zijn is het mogelijk om deze om te zetten in een geschatte ontwerpsduur aan de hand van het basis COCOMO model[16]. Dit model maakt een schatting van de benodigde persoonsontwerpsmaanden afhankelijk van het aantal Kilo-SLOC (KSLOC).
14
Onderdeel
KSLOC
E (pm)
D (m)
P (p)
10,982
63,84
9,45
6,75
Demodulatie
9,336
52,54
8,88
5,92
Kanaaldecodering
7,852
42,69
8,31
5,14
Brondecodering
87,692
772,42
20,99
36,8
Totaal
115,86
1079,03
23,36
46,19
Acquisitie
Tabel 3.3: Overzicht van de benodigde Effort (E) in persoonsmaanden, de optimale tijdsduur (D) en de benodigde bezetting (P) van het project.
In de bovenstaande tabel valt op dat de minimale verwachte tijdsduren voor de verschillende delen minimum 52 maand is. Het totale systeem wordt geschat op een totaal van om en bij de 1100 maand. Deze schatting lijkt extreem hoog. Het grootste deel van de tijd is echter vervat in de brondecodering. Deze werd al gedurende verschillende jaren door een heel aantal mensen uitgebreid en aangepast, waardoor deze waarden toch mogelijk lijken. Uit bovenstaande table volgt vrijwel onmiddellijk dat het ontwerpen van het volledige systeem onmogelijk haalbaar is binnen de context van één scriptie.
3.2.3. Compleet hardware gebaseerd Het compleet hardware gebaseerd ontwerp houdt in dat de volledige DRMontvanger geschreven wordt in een hardware beschrijvende taal zoals VHDL of VERILOG. Het vertalen van een software project in een hardware project is echter geen sinecure omwille van de volledig verschillende aard van hardware en software.
1. Complexiteit Het volledige systeem in hardware bouwen is onmogelijk gedurende de looptijd van één scriptie. Zelfs indien hardwareontwerp even snel zou zijn als softwareontwerp is het geheel heropbouwen niet haalbaar (zie tabel 3.3). Het ontwikkelen van een dergelijk complex software systeem duurde bij de makers van de Dream-software trouwens al meerdere jaren (vanaf begin 2001 tot eind 2003 vooraleer een eerste volledige versie klaar was), en zij hadden nog nood aan een open source community die hun de brondecoder (libfaad) ter beschikking stelde. Het bouwen van de acquisitie (zie figuur 3.2) is echter misschien haalbaar binnen de looptijd van deze scriptie.
15
2. Snelheid Bij het ontwerpen van een hardware gebaseerde DRM-ontvanger komt de snelheidsvraag bijna niet voor. De benodigde verwerkingssnelheden bij DRM zijn relatief laag. Het totale systeem heeft wel een vrij grote verwerkingscapaciteit nodig, maar de vereiste snelheid per onderdeel blijft toch laag.
3. Kostprijs De kostprijs van dit systeem zal vrij hoog worden omdat er een heel groot en complex hardware project zal moeten geschreven worden. DRM is namelijk ontworpen om de beschikbare kanalen zo efficiënt mogelijk te benutten. Om dit te kunnen verwezenlijken is er een heel sterk adaptief systeem nodig, wat heel moeilijk te beschrijven valt in hardware. Kortom, de ontwerpskost zal heel hoog zijn. Ten tweede zal het benodigd aantal logische poorten in het hardware ontwerp heel groot worden, waardoor men niet op kleine ASIC's of FPGA's kan overstappen. Tevens moeten de benodigde functies naar hardwarenormen niet heel snel zijn, waardoor een heel groot deel van de hardware slechts heel weinig benut wordt. Hierdoor dreigt dit een erg kostelijke oplossing te worden.
3.2.4. Compleet software gebaseerd Het software gebaseerd ontwerp komt er op neer dat de beschikbare software geport wordt naar een bepaalde processor/DSP. Het gaat hier dus over een relatief eenvoudige oplossing.
1. Complexiteit Een software gebaseerde oplossing kan heel goed overweg met heel complexe ontwerpen. Er bestaan trouwens al twee software gebaseerde oplossingen, Dream en Diorama, waardoor er zeker geen problemen op gebied van software verwacht worden.
2. Snelheid Op de website van de Dream-software DRM-radio wordt er vermeld dat de software op de achtergrond kan werken op een 700Mhz pentium 3 PC. Dit geeft onmiddellijk de indruk dat het om een vrij rekenintensief stukje software gaat. Vandaar dat een zuiver software oplossing
een heel krachtige processor zal
nodig hebben. Omdat het echter de bedoeling is om uiteindelijk een 'draagbaar' 16
toestel te bekomen is het bijna onmogelijk om een dergelijke processor te gebruiken. Zo'n processor verbruikt namelijk een vrij groot vermogen. Het gebruik van een snelle DSP zou hier wel enigszins soelaas kunnen bieden.
3. Kostprijs Wegens de nood aan de krachtige processor zal dit een vrij dure oplossing worden. Het gebruik van een dergelijke processor is mogelijk indien voor een DSP implementatie wordt gekozen. De ontwikkeltools voor de SHARC en BLACKFIN DSP's zijn beschikbaar in het labo, waardoor deze oplossing zeker tot de mogelijkheden behoort.
3.2.5. Gesplitst hardware en software ontwerp. De twee voorgaande ontwerpen waren zuivere hardware of software oplossingen. De twee laatste trachten een evenwicht tussen hard- en software te vinden. Bij het gesplitst hardware en software ontwerp wordt een eerste stap in vb. hardware uitgevoerd, gevolgd door een tweede stap die dan vb. in software uitgevoerd wordt. Onderstaande figuur geeft een voorbeeld van en mogelijk architectuur. Feedback Inkomende Gegevens
Eerste Tweede verwerking verwerking (vb. Hardware) Gegevens (vb. Software)
Uitgaande Gegevens
Figuur 3.2: Gesplitst hardware en software ontwerp
Een dergelijke aanpak heeft als voordeel dat beide delen slechts heel beperkt moeten interageren, waardoor dit een gescheiden ontwerp mogelijk maakt. Het grootste nadeel is dat de mogelijkheden qua opslitsing eerder beperkt zijn.
1. Complexiteit en Snelheid Aangezien het hardware en software ontwerp opgeplitst wordt in twee verschillende delen, moet het nu ook als twee verschillende projecten bekeken worden. Idealiter wordt het opgesplitst zodoende dat het hardware ontwerp de meest rekenintesieve, maar (hopelijk) minder complexe, functies voor zich neemt. Het software ontwerp bevat nu de complexere zaken, die echter (hopelijk) minder rekenintensief zijn. Beide delen zouden haalbaar moeten zijn indien er 17
zich een wezenlijk complexiteitsverschil voordoet in delen van het systeem. Het zou vb. mogelijk zijn om de acquisitie in hardware uit te voeren daar deze echt realtime moet gebeuren, en zeer rekenintensief is. De volgende delen zouden dan in software kunnen uitgevoerd worden, daar deze zeker complexer zijn. Het is nu echter de vraag of het hardware ontwerp niet extreem complex wordt, terwijl de microprocessor toch nog heel snel moet zijn om de volledige demodulatie en decodering voor zich te kunnen nemen.
2. Kostprijs De ontwerpskost van een dergelijk systeem is vrij groot, omdat er twee volledig gescheiden functionele blokken ontworpen moeten worden. Ieder deel op zich moet getest kunnen worden qua functionaliteiten. Een groot voordeel van deze aanpak is dat hij vrij snel kan geïmplementeerd worden door twee verschillende personen wegens de mooie scheiding tussen de delen. De kostprijs van het uiteindelijke product is vrij moeilijk te bepalen, maar deze zal gelijkaardig zijn aan deze van een volledig software ontwerp. De microprocessor zal een stuk minder snel moeten zijn, waardoor deze een stuk goedkoper zal worden. Er komt echter een stuk hardware bij, waardoor de prijs niet gevoelig lager zal uitvallen.
3.2.6. Hardware/software codesign Een tweede mogelijke hardware/software architectuur wordt gevormd wanneer men gezamenlijk de hard- en software ontwerpt. Het is mogelijk om een microprocessor uit te breiden met de nodige functionaliteiten, zoals in figuur 3.3 voorgesteld, om zodoende de benodigde verwerkingssnelheid te bekomen. Inkomende Gegevensstroom
Hardware functie 1 Software
Uitgaande Gegevensstroom
verwerking
Hardware functie 2 Hardware functie 3 Hardware functie 4
Figuur 3.3: Hardware/software codesign
Deze aanpak heeft als groot voordeel dat geen complete functionele blokken in
18
hardware of software moeten uitgevoerd worden. Nu worden de meest processor intensieve functies versneld, waardoor de verwerkingssnelheid heel sterk kan stijgen. Het grootste nadeel van deze aanpak is dat men zo goed als verplicht wordt om een volledig FPGA of ASIC gebaseerd ontwerp te maken. Het is namelijk heel moeilijk om een standaard microprocessor te voorzien van heel snelle extra hardware functies, waardoor in deze situatie eigenlijk terug gevallen wordt naar het hardware/software gescheiden ontwerp.
1. Complexiteit De complexiteit van het systeem moet nu niet meer bekeken worden vanuit het standpunt van de complexiteit van de te implementeren taken. Het vertrekpunt is nu namelijk de beschikbare software, waarbij de delen die de meeste klokcycli vergen, in hardware opgevangen worden. Wat de complexiteit nu bepaalt, is de complexiteit van het ontwerpen van een dergelijk platform. Door middel van de beschikbare platformen voor FPGA ontwerp is deze piste zeker haalbaar.
2. Snelheid Op gebied van snelheid zou de hardware/software oplossing zeker haalbaar moeten zijn. Het is nu namelijk mogelijk om de meest rekenintensieve delen te vervangen door hardware, in tegenstelling tot het gescheiden hardware/software ontwerp, waar functionele gehelen volledig in hard- of software moeten gecreëerd worden.
3. Kostprijs Op gebied van kostprijs kan dit zeker een vrij kostefficiënte oplossing worden. De ontwerpskost wordt vrij laag gehouden door het hergebruik van de software, terwijl er geen snelle processor nodig is, zoals bij een zuivere softwareoplossing wel het geval is. Toch mag de complexiteit van een dergelijk ontwerp niet onderschat worden daar het samenspel tussen hard-
en software altijd
onverwachte problemen kan opleveren.
3.2.7. Conclusie Uit het voorgaande kan zeker al besloten worden dat een zuiver hardware oplossing zeker niet haalbaar is. Een zuivere software oplossing is een mogelijkheid, maar dan wordt het probleem eigenlijk herleid tot het herschrijven
19
van de beschikbare software naar een ander platform. Op een zware DSP zou het mogelijk moeten zijn om het volledige systeem draaiende te krijgen. Omdat er echter al een FPGA gebaseerde oplossing gekozen werd voor het ontvanger gedeelte van DRM-project, zou toch tenminste een gedeeltelijke hardware oplossing de voorkeur krijgen. Voor de eenvoud van implementatie werd in eerste instantie het gesplitste ontwerp gekozen. Dit is namelijk ideaal om met twee mensen te ontwerpen. Iedere persoon heeft zijn eigen deel, en de interactie tussen beide delen blijft relatief eenvoudig. Na het verdwijnen van mijn thesisgenoot halverwege november was dit voordeel plots volledig verdwenen, waarna ik overgeschakeld ben op de meest belovende route van hardware/software codesign.
3.3. Besturingssysteem Het nut van een besturingssysteem in een dergelijke applicatie moet zeker in vraag gesteld worden. Een besturingssysteem heeft een groot aantal voor- en nadelen, waardoor een enigszins gefundeerde beslissing rond het wel of niet gebruiken er van zeker geen overbodige luxe is. Na het overlopen van de voor- en nadelen is de logische vraag natuurlijk welk besturingssysteem best geschikt is voor deze toepassing.
3.3.1. Voor en nadelen van een besturingssysteem Een besturingssysteem heeft een heel aantal voordelen voor zowel de ontwerper van een embedded systeem, als voor de eindgebruiker. Door het gebruik van een besturingssysteem kan de interactie met de gebruiker heel wat eenvoudiger geimplementeerd worden, waardoor meer tijd overblijft voor het ontwerp van een degelijke gebruikersinterface. Natuurlijk neemt het implementeren van een besturingssysteem in een embedded systeem ook heel wat tijd in beslag. Een heel belangrijk punt dat hierbij komt kijken is natuurlijk het uiteindelijk beoogde product. Hoe meer 'features' het uiteindelijke product heeft, hoe groter het voordeel
van
het
gebruik
van
een
besturingssysteem
wordt.
In de oorspronkelijke context dat vier verschillende thesissen op dit onderwerp plaatsnamen, was het vooropgestelde product een netwerkgeconnecteerde ontvanger die in staat was om via USB of IDE bepaalde uitzendingen op te nemen en terug af te spelen. Deze ontvanger moest volledig via het netwerk bediend kunnen worden. In een dergelijke context is het heel moeilijk om zonder een 20
besturingssysteem
te
werken,
aangezien
heel
wat
routinetaken
zelf
geïmplementeerd zouden moeten worden. Enkele voorbeelden hiervan zijn het gebruik van een harde schijf of een USB stick, netwerkfuncties, implementering van een webserver, multitasking, ... . Een aantal besturingssystemen heeft al een hele rij aan beschikbare programma's, waardoor de functies die door deze programma's uitgevoerd worden eenvoudig beschikbaar zijn. Het toevoegen van extra functionaliteit in een later stadium wordt nu ook heel wat eenvoudiger omdat het DRM-ontvangstprogramma zelf niet meer aangepast moet worden eenmaal het draaiende is. Kortom, het systeem wordt heel wat flexibeler. Een besturingssysteem heeft natuurlijk ook zijn nadelen. Vooreerst moet het werken op de beschikbare hardware. Dit betekend dat de hardware tenminste twee hoofdbestanddelen nodig heeft: 1. Een werkgeheugen 2. Een processor waar het betreffende besturingssysteem op werkt Indien de hardware geschikt is voor het besturingssysteem, dan is de tweede vraag meestal hoe groot de impact is van het besturingssysteem op de vereiste hardware, of m.a.w. hoeveel wijzigt de benodigde hardware om het product te kunnen laten werken met een bepaald besturingssysteem t.o.v. zonder een besturingssysteem. Tenslotte moet men zich ook afvragen op welke manier met alle apparaten kan gecommuniceerd worden. Indien er telkenmale een nieuwe driver voor ieder apparaat geschreven moet worden, dan kan deze taak misschien evengoed gedaan worden zonder besturingssysteem.
3.3.2. Keuze van het besturingssysteem Er zijn een aantal verschillende besturingssystemen beschikbaar voor het platform (Microblaze processor met 64MB DDR-RAM). ●
uClinux
●
Mentor Graphics Nucleus®
●
Express Logic ThreadX®
●
eSOL ulTRON4.0
●
RealFast AB Sierra RTOS
Van
deze
verschillende
besturingssystemen
valt
er
onmiddellijk
één
besturingssysteem op, namelijk uClinux. uClinux moet eigenlijk gezien worden als een volwaardige Linux distributie voor embedded systemen. Dit houdt in dat dit een enorm gamma programma's bevat die in embedded systemen bruikbaar 21
kunnen zijn. Het grootste verschil zit hem in de kernel. Deze is namelijk gepatcht om op processoren te werken die geen MMU1 (Memory Management Unit) bezitten. De Dream-software werkt in Linux, waardoor verwacht wordt dat het porten van de Dream-software naar uClinux veruit het gemakkelijkst zal verlopen in vergelijking met de andere besturingssystemen. Tijdens een verdere studie van uClinux kwamen de onderstaande voordelen aan het licht: ●
Beschikbare drivers voor alle Xilinx IP cores: GPIO, FSL, Xilinx ethernet, Xilinx ethernetlite, Xilinx uartlite
●
Groot aantal drivers voor een heel breed gamma aan extra hardware: flash, memory technology devices, usb apparaten, bedraad en draadloos netwerk, IDE-controllers, ...
●
Enorm groot aantal applicaties zoals: shells, webservers, streaming servers, bestandsbeheer, debugger, ...
●
Mogelijkheid tot het gebruik van netwerkmappen. Dit vereenvoudigt de opslag van gegevens sterk.
●
Vrij klein hoofdgeheugen benodigd. uClinux met een webserver op een microblaze werkt met een hoofdgeheugen van 1MB groot.
●
Dual stage bootloader beschikbaar voor de microblaze processor
●
uClinux wordt in een héél groot aantal hardware apparaten gebruikt zoals netwerk geconecteerde camera's, AP's, NAS, ...
●
Het heeft een GPL licentie, net zoals de Dream-software
Alle benodigde functies voor het vooropgestelde product zijn aanwezig in uClinux. Deze functies, samen met het 'open source' karakter van uClinux, hebben er voor gezorgd dat de keuze voor uClinux snel gemaakt was. De implementatie van uClinux op een microblaze processor heeft enkele specifiek kenmerken wegens het extreem aanpasbaar zijn van deze processor. Hierdoor werd er een speciale versie, genaamd Petalinux, van uClinux ontworpen. Deze versie heeft als doel om het gebruik van uClinux zo eenvoudig mogelijk te maken. Petalinux is eigenlijk niets meer dan uClinux, vergezeld van een aantal scripts en een heel wat verbeterde compiler dan deze meegeleverd bij Xilinx EDK. Deze verbeterde versie is nodig omdat de compiler die in Xilinx EDK aanwezig is een aantal gebreken vertoont. Ten eerste is de C++ ondersteuning van deze compiler heel beperkt. Hij slaagt er in een standaard 'hello world' 1 Meer informatie hierover in hoofdstuk 5
22
programma te compileren, maar daar blijft het ook bij. Er is zeker al geen ondersteuning
voor
namespaces,
andere
gebreken
werden
niet
verder
onderzocht. Als tweede gebrek is het niet mogelijk om via deze compiler PIC code te genereren (Zie hoofdstuk 5.3.5). De versie in Petalinux heeft deze gebreken niet meer.
3.4. Hardware overzicht De gekozen architectuur kan nu in een concrete vorm gegoten worden, zoals hieronder weergegeven. Hardware functie 1 Hardware functie 2 Hardware functie 3
FSL FSL
Microblaze Processor
FSL
XCL-cache FSL
Digitaal DRM signaal
GPIO
MCH-RAM
Ethernet
UART OPB
Druk knoppen LCD Display
GPIO SPI D/A
Audio uitgang
Figuur 3.4: Het volledige hardware overzicht
Het digitale DRM signaal wordt binnengenomen via een GPIO interface met DMA controller, waardoor de gegevens niet doorheen de processor moeten verplaatst worden naar het geheugen. De gegevens worden daarna via de XCL-cache uit het hoofdgeheugen gelezen, waardoor de OPB-bus niet extra belast wordt. Nadat de verwerking voltooid is, kan de audio via een tweede gpio interface naar een D/A convertor gestuurd worden. Het grootste nadeel van deze architectuur is dat er geen DMA-controllers bestaan voor FSL-links. Hierdoor moeten alle gegevens die naar de hardware functies gestuurd moeten worden doorheen de processor. 23
4. Opbouw van het hardware platform 4.1. Inleiding De hardware voor deze scriptie kan eigenlijk op twee verschillende manieren bekeken worden. Een eerste manier is de echte hardware, die bestaat uit het spartan 3E starter bord en hoofdzakelijk de volgende componenten bezit: ●
Xilinx Spartan XC3S-500E
●
Xilinx platform flash
●
64MB ram
●
16MB parallel flash
●
LAN PHY (SMSC LAN83C165)
●
LCD display
●
Enkele drukknoppen, schakelaars en leds
●
Connectoren: RJ-45, twee Seriële poorten, PS/2, VGA
Hierin is het FPGA de kern van het geheel, waar alles rond gebouwd wordt. Een tweede en in deze scriptie meest belangrijke manier, is te kijken naar de hardware die gebouwd wordt in het FPGA. Het
basisprincipe
voor
het
ontwerpen
van
hardware
waarop
een
besturingssysteem moet draaien, is dat het besturingssyteem de minimaal vereiste hardware bepaalt. Eenmaal aan deze eisen voldaan, is de ontwerper vrij om de extra benodigde functionaliteiten te voorzien die het product zijn uiteindelijke vorm zullen geven. Wegens de flexibiliteit van het FPGA-ontwerp betekent dit hoofdzakelijk dat er constant hardware en software moet afgewogen worden tegenover elkaar. Bij een heel grote complexiteit verdient software de voorkeur, aangezien deze heel eenvoudig met grote complexiteiten om kan gaan. Bij een heel grote snelheidsvereiste verdient hardware meestal de voorkeur, daar deze sterk geparallelliseerd kan werken.
4.2. Minimale eisen van het besturingssysteem Het uClinux besturingssysteem heeft nood aan een aantal fundamentele hardware elementen. Deze zijn: ●
Een processor
●
Een hoofdgeheugen (Best groter dan 1 MB) 24
●
Timer met IRQ
●
Een vorm van gebruikersinterface
Deze eisen lijken heel eenvoudige eisen. Een standaard besturingssysteem stelt echter heel wat hogere eisen aan de basis hardware. Een klein voorbeeld: een standaard Linux kernel heeft nood aan een processor die minimaal een volledige Memory Management Unit (MMU)2 bezit. Een MMU is echter niet beschikbaar in de Xilinx microblaze processor. Indien er dus gewenst zou zijn dat een standaard Linux kernel moet werken op het systeem, dan is een processor met een MMU (powerpc op virtex, openrisc, ...) een noodzaak. Het hoofdgeheugen dat groter moet zijn dan 1MB is ook relatief klein. Zeker aangezien het bord al 64MB geheugen bezit, en de Dream-software er zeker enkele megabyte nodig heeft. Een timer met een IRQ (Interrupt Request) kan men heel snel vergeten. Dit lijkt niet echt noodzakelijk op een basis systeem, maar dat is het wel. uClinux kan werken zonder enige gebruikersinterface, maar dan is het nut van het besturingssysteem natuurlijk heel gering. Op dit bord kan serieel of via netwerk een gebruikersinterface aangeboden worden.
4.3. Bouwen van de basishardware De minimale hardware eisen van het besturingssysteem zoals hoger vermeld zijn heel
beperkend
naar
een
praktisch
ontwerp
toe.
Om
een
degelijk
ontwerpplatform te bouwen zijn nog een aantal extra onderdelen nodig, die het mogelijk maken om een dergelijk systeem eenvoudig te kunnen aanpassen en beheren. Een eerste benodigd blok is tenminste één Universal Asynchronous Receiver Transmitter (UART). Deze kan door het besturingssysteem als standaard input en output poort gebruikt worden. Een tweede blok is een Microblaze Debug Module (MDM). Deze maakt het mogelijk om een aantal debug taken uit te voeren zoals: ●
De processor te stoppen
●
De processor te doen starten vanaf een bepaald geheugen adres
●
Geheugen operaties uitvoeren
●
Breakpoints instellen
De hardwareblokken zijn echter niet zomaar bruikbaar. Intern in de FPGA moeten de verschillende blokken op een correcte manier met elkaar verbonden worden. Externe blokken (zoals RAM, seriële poort, LAN phy, flash geheugen, ...) moeten 2 Hier wordt in hoofdstuk 5.2 dieper op ingegaan
25
echter ook correct verbonden worden met de interne delen. Er moet dus een pin mapping gebeuren tussen externe FPGA pinnen en interne signalen. Dit is een vrij eenvoudige klus, waarbij echter heel snel fouten gemaakt kunnen worden. Om dergelijke problemen te vermijden werd de Base System Builder (BSB) ontworpen. De BSB heeft een groot gamma aan standaard bord layouts. Deze weet dus hoe de externe pinnen gemapt moeten worden naar de interne signalen. Tevens kan de BSB de verschillende interne blokken automatisch koppelen aan de OPB-bus (On-Chip Peripheral Bus). Deze taak is opnieuw vrij eenvoudig. Toch zou heel snel een fout gemaakt zou kunnen worden. Tenslotte kan de BSB ook een aantal instellingen maken voor de verschillende delen van het systeem, zoals het inschakelen van een IRQ bij een timer, of de baudrate van een seriële poort, ... Het opbouwen van het basissysteem wordt in appendix B uitgebreid besproken. De belangrijkste instellingen die moet gemaakt worden zijn de volgende: ●
HW-debug module gebruiken
●
Tenminste één uart instellen op UARTLITE, en de interrrupt inschakelen
●
Bij IO-devices de Flash16Mx8 inschakelen
●
Bij ethernet_mac de opb_ethernetlite gebruiken. Opnieuw de interrupt inschakelen.
●
Een timer toevoegen met een counter width van 32 bit, slechts één timer beschikbaar en interupt ingeschakeld.
Na het maken van deze instellingen wordt de basishardware, zoals in figuur 4.1 wordt weergegeven, bekomen. Dit ontwerp heeft een aantal problemen zoals: ●
Het ontbreken van cache geheugen
●
Alle geheugenbewerkingen moeten via de OPB-bus
●
De debug link is traag
Zonder deze aanpassingen is het onmogelijk om de Dream-software snel genoeg te laten werken. Hiervoor moeten nog een aantal aanpassingen gedaan worden, zoals in hoofdstuk 4.4 beschreven.
26
Figuur 4.1: Overzicht van de basis hardware voor het uClinux besturingssysteem
27
4.4. Hardware verbeteringen De voorgaande architectuur is rechtstreeks te verkrijgen door de BSB wizard. Deze architectuur is echter niet optimaal om een besturingssysteem op te laten werken. Er kunnen nog heel wat verbeteringen aangebracht worden.
4.4.1. Cache geheugen
OPB bus Processor OPB cache
RAM
Flash
GPIO
Figuur 4.2: OPB cache architectuur
Tijdens de BSB-wizard wordt de optie tot het gebruik van cache aangeboden. Er zijn twee soorten cache-geheugen beschikbaar. Een eerste is de OPB-cache, zoals in figuur B.6 weergegeven. Deze cached alle gegevens die tussen de processor en apparaten op de OPB-bus uitgewisseld worden. Indien gegevens van een heel traag apparaat zoals flash in de cache aanwezig zijn, dan kan dit een heel grote snelheidswinst opleveren bij het lezen van die gegevens. Het soort applicatie bepaalt echter heel sterk in hoeverre de gegevens in cache aanwezig zullen zijn. Het grote nadeel van deze cache architectuur is dat de cache enkel beschikbaar is via de OPB-bus. Dit is een relatief trage bus, en wordt tevens door alle apparaten gebruikt. Indien een traag apparaat, aanwezig op de bus, gegevens verzent,
dan
is
de
cache
niet
beschikbaar.
De tweede soort is de Xilinx Cache Link (XCL), die gebruik maakt van een Fast Simplex Link (FSL). Een FSL-link is een rechtstreekse Master-Slave verbinding tussen twee devices. De FSL link bevindt zich, zoals in figuur 4.3 weergegeven, tussen de XCL-cache en OPB bus Processor XCL cache
FSL
RAM
Flash
GPIO
Figuur 4.3: XCL cache architectuur
28
het RAM-geheugen, waardoor het enkel mogelijk is om het RAM-geheugen te cachen. Deze aanpak maakt het nu echter mogelijk om het hoofdgeheugen te lezen (en te schrijven) zonder dat deze gegevens over de OPB bus moeten. Hierdoor wordt de OPB bus ontlast, en wordt de data een heel stuk sneller geleverd aan de processor. Het grootste nadeel is dat het RAM geheugen nu een Multi Channel Host (MCH) interface nodig heeft. De Dream-software bepaalt voor een heel groot deel welke cache-architectuur het meest geschikt is. De Dream-software moet een heel groot aantal repeterende bewerkingen doen op relatief traag binnenkomende samples (40 Ksps). Hierdoor zal het nut van een heel snelle cache tussen het geheugen en de
processor
veruit
het
meeste
voordeel
bieden.
M.a.w.
de
XCL-cache
architectuur is beter geschikt voor de deze toepassing.
4.4.2. Klok frequenties Het FPGA heeft vier zogenaamde Digital Clock Manager (DCM) hardware blokken. Door middel van deze blokken is het mogelijk om een externe oscillatorfrequentie te vermenigvuldigen en delen. Ze laten het toe om de processor en geheugenklok aan te passen en ze te optimaliseren voor de benodigde toepassing. Tijdens het uitvoeren van de BSB-wizard worden drie DCM-blokken gebruikt zoals in figuur B.8 weergegeven, om het volledige systeem van hun benodigde klokken te voorzien. De standaardklok, op het bord aanwezig, heeft een frequentie van 50Mhz. Dit is de ext_clk in figuur B.8. Deze klok wordt door DCM_0 verdeeld. de clkfx uitgang heeft een frequentie die instelbaar is (Bij een keuze van 75Mhz wordt deze door de BSB-wizard ingesteld op 3/2 maal de ingangsfrequentie). De clkfx-uitgang wordt gekoppeld aan de klok van de OPB-bus. Dit houdt in dat zo goed als het volledige
systeem
deze
klok
als
hoofdklok
zal
gebruiken.
De
grootste
uitzondering hierop is het MCH_OPB_DDR-blok. Deze heeft twee klokcircuits nodig. Het ene klokcircuit is het volledige deel naar de processor toe (OPB- en FSL-verbindingen). Het tweede klokcircuit bestaat uit de volledige aansturing van het DDR SDRAM geheugen. De RAM draait immers op een andere frequentie dan de interne componenten. Standaard wordt er in de BSB-wizard voor gekozen om de RAM te laten draaien op twee maal de frequentie van de externe klok. Deze bedraagd dus 100 Mhz. Het geheugen IC bestaat echter uit DDR333-geheugen. D.w.z. dat dit geheugen op 166 Mhz optimaal werkt. Standaard wordt dit niet 29
gedaan omdat er dan nood is aan een extra DCM. DCM_0 gnd ext_clk 50Mhz
rst Locked clk_in 75Mhz clkfx 100Mhz clk2x clk90 FB clk0
UART
DCM_2
rst Locked clk_in clkfx clk2x clk90 FB clk0
rst Locked clk_in clkfx clk2x clk90 FB clk0
MCH_OPB_DDR
OPB BUS
uBlaze
DCM_1
ddr_clk_90 dev_clk_90 dev_clk
DDR_RAM clk_fb
GPIO ddr_clk_90_n dev_clk_90_n dev_clk_n
Figuur 4.4: De standaard klok distributie architectuur
De externe klok van het uiteindelijke systeem zou echter op 80Mhz werken. Om een controle van het systeem toe te laten zou het mogelijk zijn om nog een extra DCM tussen de externe klok en DCM_0 te plaatsen. Hiermee kan de externe klok van 50Mhz intern gewijzigd worden naar 80Mhz om zodoende een identieke situatie te bekomen. In deze situatie draait het geheugen dan op 160Mhz, wat al heel wat sneller is. Wegens routingproblemen blijkt het echter niet te lukken om een vierde DCM te gebruiken. Een alternatieve oplossing is natuurlijk om een externe klok van 80Mhz te gebruiken op het bord. Indien de externe klok een andere frequentie dan 50 Mhz bezit, moet er op gelet worden dat de timinginstellingen van de volgende apparaten aangepast worden, om de correcte werking ervan te kunnen garanderen. ●
MCH_OPB_DDR De CAS vertragingstijd moet correct ingesteld worden op drie, en de OPB bus periode moet gewijzigd worden in de correcte waarde (Bij 80Mhz wordt dit 12500ps). De andere timing instellingen mogen constant blijven, aangezien deze in pico seconden ingesteld worden. (Bij CAS = 3 wil dit zeggen dat er drie klok cycli gewacht wordt, waardoor de tijdsvertraging 30
varieert bij wijzigende klokfrequentie). ●
UART Bij de UART moet de OPB-bus frequentie correct ingesteld worden. Een verkeerde instelling leidt tot een aantal niet leesbare tekentjes die zichtbaar worden op de console tijdens het opstarten van het platform.
4.4.3. Snelle download verbinding Het ontwerp van een dergelijk systeem vergt heel wat debug-werk. Hierdoor is een snelle verbinding om het systeem te kunnen debuggen zeker geen overbodige luxe. Een snelle debug-verbinding bestaat uit een FSL-link tussen de debug module en een uBlaze FSL-poort. 1. De eerste stap is het toevoegen van een FSL-verbinding. Na het toevoegen ervan wijzigt men best de naam van deze verbinding naar een meer logische naam zoals download_link.
Figuur 4.5: Toevoegen van een FSL IP core
2. De volgende stap is het inschakelen van de uBlaze FSL-link. Deze wordt ingesteld in het tabblad 'bus interfaces' van de uBlaze-processor. Hier moet één FSL link ingesteld worden met een FSL data breedte van 32 bit. 3. In de debug_module moet de 'Enable Fast Download Write Port' op 1 geplaatst worden. 4. De MFSL0 poort van de debug_module en de SFSL0 poort van de microblaze processor moeten nu gekoppeld worden aan de download_link
31
Figuur B.10 toont hoe de debug module aan de uBlaze-processor wordt gekoppeld d.m.v. de download_link FSL-verbinding.
Figuur 4.6: De afgewerkte FSL verbinding tussen de debug module en de uBlaze-processor
4.5. uClinux specifieke instellingen voor het hardware project Nu de belangrijkste elementen van het hardware project vastgelegd werden, moet de koppeling tussen het hardware project en het latere software project voorzien worden. Deze koppeling is nodig om het mogelijk te maken om automatisch de benodigde instellingen door te geven aan het besturingssysteem. Hierdoor kan het besturingssysteem automatisch alle juiste instellingen ter compilatie en uitvoering meekrijgen. Tot nog toe was het besturingssysteem waarop Xilinx EDK en ISE stonden niet belangrijk. De procedures waren identiek voor zowel Windows als Linux. Vanaf dit punt wordt het ten sterkste aangeraden om op een Linux platform te werken. Deze
stap is ook mogelijk op een Windows platform, maar maakt dat de
complexiteit heel sterk stijgt. Allereerst moet er voor gezorgd worden dat de Petalinux-omgeving correct geïnstalleerd wordt3. Nadat deze correct geïnstalleerd werd, volstaan de stappen, 3 Zie appendix A
32
nader uitgelegd in appendix C, om het hardwareproject correct voor te bereiden. Door het uitvoeren van deze stappen worden twee belangrijke dingen verkregen: 1. De koppeling tussen het hardware en software project wordt mogelijk. 2. De FS-boot bootloader wordt in de processor geplaatst. De koppeling tussen het hardware en het software platform wordt gemaakt door middel van het zogenaamde auto-config.in bestand. Dit bestand bezit een heel aantal instellingen van het harware platform, waarvan de belangrijkste zijn: ●
De locatie en de grootte van het hoofdgeheugen. Zonder deze instellingen kan de uClinux kernel niet opstarten, aangezien de uClinux geen idee heeft waar dit geheugen zich bevindt en hoe groot het is.
●
De locatie en de grootte van het flash geheugen uClinux kan opstarten zonder deze informatie. De firststage bootloader, FSboot heeft echter wel nood aan deze informatie. FS-boot moet namelijk de secondstage bootloader vanuit flash laden in het geheugen. Zonder deze gegevens kan dit onmogelijk voltooid worden.
●
De instellingen van de microblaze processor De belangrijkste instelling zijn geactiveerd coprocessor elementen, zoals de Floating Point Unit, de hardware integer multiplier/divider, barrel shifter, ... . Deze instellingen zijn heel belangrijk naar de compiler toe. Deze moet deze instellingen weten, om zodoende alles te compileren naar de juiste hardware.
●
Een aantal instellingen voor randapparatuur zijn benodigd voor de respectievelijke drivers. Zo heeft de UARTLITE, en de Ethernetlite driver nood aan een aantal van deze instellingen.
Vanaf nu is het mogelijk om op het hardwareplatform een uClinux te laten werken. Praktisch gezien is het platform echter nog niet echt bruikbaar wegens het ontbreken van een bootloader. Zonder deze bootloader moet men telkenmale men het systeem inschakelt eerst manueel de uClinux image doorsturen naar het geheugen via de debug-interface en daarna opstarten vanaf geheugen. De uBlaze processor start namelijk altijd op vanaf geheugen adres 0x00000000. Dit bevind zich standaard in het BRAM geheugen in het FPGA. Omdat dit BRAM geheugen slechts heel beperkt is in grootte (Slechts 8kB data en 8kB instructies!) is een bootloader absoluut noodzakelijk.
33
5. Microblaze uClinux 5.1. Inleiding In hoofdstuk drie werd als besturingssysteem uClinux gekozen. De grootste reden waarom er een standaard Linux op de beschikbare hardware niet werkt is het ontbreken van een Memory Management Unit in de microblaze processor. In deel twee van dit hoofstuk zal verder ingegaan worden op de gevolgen van het ontbreken van een MMU op een besturingssysteem. De oplossingen voor deze problemen die aangeboden worden door uClinux worden er ook nader in behandeld. Deel drie van dit hoofdstuk handelt over de compilatie van uClinux voor een microblaze processor. Hierna wordt meer informatie verschaft, waardoor een volledig zelfstandig werkend bord mogelijk wordt.
5.2. M emory M anagement Unit (MMU) Het grootste verschil tussen Linux en uClinux zit hem in het ontbreken van een MMU. Vandaar dat het naderbij bekijken van de functionaliteiten die geboden worden door een MMU zeker geen overbodige luxe is.
5.2.1. Wat is een MMU?[3] Een MMU is het deel van een processor waarvan de taak er hoofdzakelijke in bestaat een vertaling te maken tussen logische adressen en fysieke adressen. In een standaard 32-bit PC is het namelijk zo dat ieder programma op zich een virtuele adresruimte van 32-bit (= 4GB) beschikbaar heeft. In werkelijkheid is het echter niet zo dat het fysieke geheugen een dergelijke omvang heeft, laat staan dat dit voor ieder programma zou moeten verwezenlijkt worden.
34
Er zijn een aantal redenen waarom dit in bijna alle PC's gedaan wordt: 1. Huidige PC's hebben een hoofdgeheugen dat meestal kleiner is dan wat de mogelijke adresseringsruimte beschikbaar maakt. Indien een proces echter meer virtueel geheugen nodig heeft dan hetgeen vrij is in het fysiek beschikbare geheugen, kan de MMU hier een oplossing voor bieden. Deze maakt het zogenaamde swappen mogelijk. Tijdens het swappen worden niet benodigde gegevens naar schijf weggeschreven, terwijl de op dit ogenblik benodigde gegevens vanaf schijf gelezen worden en in het geheugen geplaatst worden. Het swappen is volledig onzichtbaar voor de applicatie, tenzij op het gebied van uitvoeringssnelheid. 2. Indien er een proces uitgevoerd wordt, dan heeft dit een bepaalde hoeveelheid geheugen nodig. Bij een systeem met een MMU heeft een proces altijd een volledig virtueel geheugen beschikbaar voor zichzelf. Dit betekent dat dit proces alles kan doen met deze geheugenruimte zonder dat andere processen hierdoor rechtstreeks beïnvloed worden. Het proces hoeft dus geen rekening te houden met wat andere processen uitvoeren. 3. Indien een proces in uitvoering extra geheugen nodig heeft, dan kan dit ergens in het virtueel geheugen gealloceerd worden. Aangezien er slechts één proces in dit virtueel geheugen aanwezig is, is de kans dat er geen geheugenblok van de gewenste grootte beschikbaar is zo goed als onbestaande. De programmeur van de betreffende softwareapplicatie heeft dit trouwens volledig in de hand en kan dit voorkomen mocht dit toch gebeuren. In het fysiek geheugen kan de MMU een heel aantal verschillende geheugenblokken (zelfs swap geheugen) samennemen om het benodigde virtueel geheugen beschikbaar te maken. Het proces hoeft niet bewust te zijn van de samenhang van het fysieke geheugen.
5.2.2. Probleempunten bij het ontbreken van een MMU?[4] Het ontbreken van een MMU betekent dat alle processen
rechtstreeks in het
fysieke geheugen lopen. De grootste problemen die hieruit voortvloeien worden hieronder beschreven.
1. Reallocatie ter uitvoering van het proces Zonder een MMU lopen alle processen in dezelfde geheugenruimte. Dit wil zeggen dat ieder proces vanaf een ander geheugenadres moet starten. Bij het 35
uitvoeren van een willekeurig process wil dit zeggen dat het eerst moet gerealloceerd worden naar een bepaalde aaneensluitende geheugenruimte, van waaruit de uitvoering gestart kan worden. Deze taak is echter niet rechtstreeks merkbaar voor de programmeur, maar hij moet wel in het achterhoofd houden. vb. Een programma staat op een RAM-bestandsysteem. Dit bestandsysteem heeft dit programma gesplitst in twee delen. Bij een systeem met een MMU kan dit rechtstreeks uitgevoerd worden. Bij een systeem zonder MMU moet dit programma eerst gerealloceerd worden vooraleer het kan uitgevoerd worden. Hierdoor zal het geheugengebruik verdubbeld worden t.o.v. een systeem met een MMU. Een alternatief van reallocatie is echter wel mogelijk indien de compiler Position Independant Code (PIC) kan genereren (zie lager).
2. Stackgeheugen Aangezien verschillende processen na elkaar in de geheugenruimte kunnen geplaatst worden, volgt daar uit dat een proces niet zomaar zijn geheugenruimte kan uitbreiden. Hieruit volgt dat de programmeur op voorhand de grootte van zijn proces moet kunnen bepalen. Dit is vb. een heel groot nadeel voor de stack, die dynamisch kan groeien gedurende de levensduur van het proces. Indien de stack te groot wordt, dan wordt dit normaal opgevangen door de MMU, die een nieuw blok stackgeheugen toekent. Indien de stack nu te groot wordt, dan bestaat de kans dat gegevens overschreven worden.
3. Geheugenprotectie Het gebruik van één globale geheugenruimte betekent ook dat indien een proces buiten zijn geheugenruimte gaat, dit rechtstreeks een ander proces kan beïnvloeden, met de volgende drie mogelijke gevolgen: ●
Het extra geheugen wordt niet gebruikt door een ander proces of de kernel. Dit leidt tot het correct functioneren van het volledige systeem. Er is echter geen garantie dat deze situatie zich altijd zal blijven voordoen.
●
Het extra geheugen wordt gebruikt door een andere programma of door de kernel en het systeem crasht.
●
Het extra geheugen wordt gebruikt door een ander proces. Hierdoor zal dit andere proces misschien blijven lopen, maar verkeerd functioneren. Dergelijke fouten zijn extreem moeilijk te vinden, aangezien deze slechts onder bepaalde voorwaarden zullen ontstaan, en daardoor heel moeilijk 36
traceerbaar zijn.
4. Wisselgeheugen Het gebruik van wisselgeheugen wordt onmogelijk door het ontbreken van een MMU. Bij embedded systemen levert dit echter meestal niet al te veel problemen, daar er slechts een beperkt aantal processen moeten draaien. Hierdoor is het benodigde geheugen meestal vrij constant.
5.3. uClinux versus Linux[4] uClinux heeft een aantal technieken die het mogelijk maken om op een systeem zonder MMU te werken. Hierdoor zijn er een aantal verschillen waar een programmeur rekening mee moet houden bij het programmeren of porten van een programma voor uClinux.
5.3.1. Geheugenbeheer In een standaard Linux kernel wordt het geheugen toegekend via een macht van twee allocator. Dit houdt in dat het aangevraagde geheugen altijd omhoog afgerond wordt naar een waarde die een macht van twee is. Hierdoor kan er bij grote geheugenaanvragen heel veel geheugen onnodig gealloceerd worden (vb. 1,1MB vragen => 2MB krijgen). Bij embedded systemen is het beschikbare geheugen echter heel beperkt, waardoor een dergelijke allocatie problemen kan opleveren.
Een
tweede
probleem
dat
ontstaat,
is
dat
het
geheugen
gefragmenteerd kan raken. Hierdoor kan het mogelijk zijn dat het beschikbare geheugen vb. 5MB bedraagt, en dat een geheugenaanvraag van 3MB een out-ofmemory fout teruggeeft. Om het geheugengebruik efficiënter te laten verlopen is er een alternative geheugenallocator ontwikkeld voor uClinux. Deze kent het geheugen toe in machten
van
twee
zolang
de
geheugenaanvraag
kleiner
is
dan
één
geheugenpagina (4KB). Bij een waarde groter dan één pagina alloceert hij het geheugen per pagina. Het fragmentatieprobleem wordt gedeeltelijk opgelost door het toekennen van grote geheugenaanvragen aan de bovenzijde van het geheugen, terwijl het toekennen van kleine geheugenaanvragen aan de onderzijde van het geheugen gebeurt. Het gebruik van deze geheugenallocator heeft echter wel een iets tragere toekenning tot gevolg. 37
5.3.2. Stackgeheugen Zoals hoger beschreven kan een stack groeien en krimpen gedurende de uitvoer van een programma. Aangezien de stack binnen het proces opgeslagen wordt, kan deze maar tot aan een bepaalde maximale waarde groeien. Op standaard Linux wordt dit opgevangen door de MMU die de stack virtueel uitbreidt. Bij uClinux is dit echter niet mogelijk. Om deze tekortkoming te vermijden, moet er tijdens de compilatie een plaats vrijgemaakt worden die groter is dan de maximale grootte van de stack.
5.3.3. Malloc Malloc in zijn gewone vorm is niet bruikbaar, aangezien deze steunt op het feit dat het systeem met virtueel geheugen werkt. Malloc moet nu echter geheugen toekennen dat in het fysieke geheugen beschikbaar is. In uClinux wordt dit opgevangen door al het vrije kernelgeheugen beschikbaar te maken. De uClinux malloc implementatie moet nu aan de kernelgeheugenallocator het benodigde geheugen vragen. Het grote voordeel is dat er geen geheugen verspild wordt, in tegenstelling tot een vaste maximale grootte, zoals vb. bij de stack gebruikt wordt. Het grote nadeel is dat een programma nu wel alle geheugen van het volledige systeem kan innemen, wat meestal tot een systeemcrash zal leiden.
5.3.4. fork en vfork De fork() systeemaanroep [5] maakt een exacte kopie van het huidige proces, op de proces ID na. Het huidige proces wordt dan het 'parent' proces en het nieuwe proces het 'child' proces. Na het uitvoeren van een fork() opdracht werkt het 'child' proces volledig zelfstandig verder in zijn eigen geheugenruimte. Deze geheugenruimte is initieel een exacte kopie van de geheugenruimte van de 'parent'. Het 'parent' en het 'child' proces kunnen nu volledig parallell werken. De vfork()
systeemaanroep
[6]
heeft
twee
grote
verschillen
met
de
fork()
systeemaanroep. Het 'child' proces dat gecreëerd wordt draait op dezelfde geheugenruimte van de 'parent'. Dit betekend dat de geheugenruimte niet gekopieerd
hoeft
te
worden.
Omdat
het
'child'
proces
op
dezelfde
geheugenruimte werkt, wordt het 'parent' proces wel geblokkeerd gedurende de uitvoering van het 'child' proces. In uClinux is fork() niet beschikbaar [4] omdat het onmogelijk is om een exacte
38
kopie
van
het
proces
te
maken
aangezien
deze
in
dezelfde
fysieke
geheugenruimte lopen. vfork() is wel beschikbaar omdat vfork() het parent proces doet pauzeren. Zodoende kan het child proces verderwerken op dezelfde fysieke locatie. Let wel op dat vfork effectief de data en het geheugen van de 'parent' gebruikt!
5.3.5. flat uitvoerbare bestanden In standaard Linux is het bestandsformaat voor uitvoerbare bestanden ELF. Dit is niet bruikbaar in uClinux, omdat het ELF formaat gebruik maakt van het virtueel geheugen. uClinux gebruikt het FLT bestandsformaat, dat in twee verschillende versies beschikbaar is. Het volledig realloceerbaar formaat, en het PIC formaat. In het volledige realloceerbaar formaat moet het uitvoerbare bestand eerst gekopieerd worden in het RAM geheugen vooraleer het kan uitgevoerd worden. Het PIC formaat laat toe om de instructies onmiddellijk uit te voeren en enkel de data naar het geheugen te kopiëren. Dit is het zogenaamde eXecute In Place (XIP), waardoor er slechts een heel beperkte hoeveelheid RAM geheugen nodig is. Een nadeel hiervan is echter wel dat indien het bestand in vb. flash staat, het slechts vrij traag zal uitgevoerd kunnen worden. Een tweede nadeel is dat het onderliggende bestandssysteem het programma niet mag fragmenteren. Indien dit wel gedaan wordt, dan is XIP ook niet meer mogelijk. Het enige bestandsformaat dat momenteel bruikbaar is dat bestanden niet fragmenteert is ROMFS. In het flat formaat wordt de stackgrootte ingesteld. Deze kan vrij eenvoudig gewijzigd worden op één van volgende manieren: 1. 'FLTFLAGS = -s <stackgrootte>' en 'export FLTFLAGS' toevoegen aan de makefile 2. microblaze-uClinux-flthdr -s <stackgrootte> programmanaam uitvoeren na het compileren Het flat formaat ondersteunt ook een compressie modus, dewelke opnieuw in twee versies komt. Een eerste versie is het volledig gecomprimeerde formaat, en wordt als volgt bekomen: microblaze-uClinux-flthdr -z bestandsnaam In de tweede versie wordt enkel de data gecomprimeerd, waardoor XIP nog steeds mogelijk is. Een dergelijk bestandsformaat wordt als volgt bekomen: microblaze-uClinux-flthdr -d bestandsnaam 39
5.3.6. Gedeelde b ibliotheken Echte gedeelde bibliotheken zijn in een systeem zonder MMU enkel mogelijk indien XIP ondersteund wordt. Indien dit niet het geval is, is het wel nog steeds mogelijk om gedeelde bibliotheken aan te maken. Tijdens het gebruik van een dergelijke bibliotheek wordt er telkenmale deze benodigd is een kopie van gemaakt. Hieruit volgt dat het gebruik van een statische bibliotheek voordeliger is aangezien deze niet gekopieerd moet worden tijdens de uitvoering.
5.4. Opzetten van het uClinux platform Het compileren van uClinux is op zich vrij eenvoudig geworden door het ontstaan van de Petalinux distributie. Het is echter noodzakelijk om de omgeving correct in te stellen, zoals in appendix A uitgelegd wordt. Het compilatieproces bestaat hoofdzakelijk uit drie delen. Het eerste deel is het afwerken van het hardware platform, gevolgd door de link maken tussen het hardware en software platform. Dit wordt uitgebreidt uitgelegd in appendix C. Het laatste deel is de instelling en compilatie van de software. Na het voltooien van deze stappen wordt het systeem op het testbord geplaatst.
5.4.1. Softwareinstellingen Nadat het hardwareplatform gekoppeld werd aan het softwareplatform kan het softwareplatform ingesteld worden. De in te stellen parameters worden in alle figuren correct weergegeven om een werkend systeem te bekomen. De extra uitleg verklaart de belangrijkste keuzes die gemaakt kunnen worden. De instellingen worden ingedeeld in drie grote delen. Het eerste deel behandelt de globale instelling, en werd door Petalogix toegevoegd om de globale configuratie van uClinux eenvoudiger te maken. Het tweede deel zijn de kernel instellingen. Deze bepalen alle beschikbare kernel functies, en zijn uiterst belangrijk om het systeem draaiende te krijgen. Het derde deel zijn de user instellingen. Deze bepalen welke programma's het uiteindelijke systeem zal bevatten. De zelf gemaakte programma's zijn hier standaard echter niet bij. Petalogix heeft deze namelijk in een volledig aparte structuur gegoten. Het is echter wel mogelijk om een zelfgemaakt programma in deze configuratie te plaatsen, waarvoor verwezen wordt naar de $PETALINUX/software/petalinux-dist/Documentation map.
40
1. Globale instellingen De softwareplatformconfiguratie wordt geopend als volgt: cd $PETALINUX/software/petalinux-dist make menuconfig Hiermee
wordt
het
scherm zoals
in figuur
5.1
geopend.
Bij het item
'kernel/library/defaults' kan men nu de basis configuratie van het systeem instellen.
Figuur 5.1: Het kernel/library/default menu
In deze stap moet gekozen worden tussen uClibc en uC-libc als Libc versie. uClibc is een bibliotheek die tracht gelijkaardig te zijn aan de standaard glibc bibliotheek. Ze heeft gelijkaardige functionaliteit, die het toelaat om de meeste programma's vrij eenvoudig te kunnen overzetten van glibc naar uClibc. Hierdoor is deze bibliotheek iets gewichtiger dan de uC-libc. uC-libc is een bibliotheek die rechtstreeks gericht wordt op het embedded systeem. De functionaliteiten wijken hierdoor wel vrij sterk af van de functionaliteit geleverd door glibc, waardoor porten van applicaties moeilijker is indien uC-libc gebruikt wordt. Aangezien de Dream-software werkt op Linux, ligt de keuze voor uClibc hier voor de hand. De items Customize kernel settings en Customize Vendor/user setting maken dat er na het afsluiten van het huidige configuratievenster, respectievelijk een kernel instellingen venster, en daarna een user instellingen venster geopend worden. Hierin kunnen alle mogelijke instellingen van uClinux gemaakt worden. Na het afsluiten van dit venster worden alle standaardinstellingen van de volgende vensters overlopen. Indien er vragen gesteld worden, dan mag de
41
standaard keuze altijd geaccepteerd worden, daar alle instellingen later beschikbaar worden.
2. Kernelinstellingen In dit deel worden de belangrijkste instellingen, benodigd om een werkend systeem te bekomen, overlopen en waar nodig enige uitleg verschaft. De eerste instellingen bevinden zich onder 'processor type and features', hieronder afgebeeld
Figuur 5.2: De te maken instellingen voor 'processor type and features'.
De optie 'console on UARTLITE' mag enkel geactiveerd worden indien de console effectief op een Xilinx UARTLITE IP core geplaatst werd (Indien een standaard UART16550 IP core gekozen werd kan deze gevonden worden onder 'Character devices'). De GPIO driver voorziet extra device nodes die het mogelijk maken om rechtstreeks GPIO gekoppelde apparaten te kunnen gebruiken.
Figuur 5.3: De te maken instellingen voor 'General setup'.
42
Bij general setup, afgebeeld in figuur 5.3, zijn er drie belangrijke zaken. Vooraleerst moet 'kernel support for flat binaries' zeker ingeschakeld zijn. 'Zflat support' is niet noodzakelijk, maar betekent dat geen gecomprimeerde flat bestanden kunnen gebruikt worden (zie hoofdstuk 5.3.5). De 'non-power-of-2 kernel allocator' is de alternative kernel allocator, zoals in hoofdstuk 5.3.1 besproken. 'Allow allocating large blocks of memory' mag best ingeschakeld worden, zeker aangezien Dream geport werd vanaf standaard Linux. Tenslotte moet networking support ingeschakeld worden indien er enig programma op loopt dat iets met een tcp/ip netwerk zal doen, al is het maar gebruik maken van het loopback device. De Dream-software zelf gebruikt deze niet rechtstreeks, maar om de bediening via netwerk mogelijk te maken werd deze toch geactiveerd.
Figuur 5.4: De te maken instellingen voor 'MTD=>RAM/ROM/Flash chip drivers'
In het 'memory technology devices' menu staan alle instelling standaard correct. In
het
submenu
RAM/ROM/FLASH
chip
drivers
moet
de
intel/flash
chip
ondersteuning echter ingeschakeld worden. Zonder deze instelling zou de kernel wel opstarten, maar is het onmogelijk om gegevens weg te schrijven naar flash.
43
Figuur 5.5: De te maken instellingen voor 'MTD=>Mapping drivers for chip access'
Bij 'MTD => mapping drivers for chip access' moeten alle 'CFI Flash device ...' uitgeschakeld
worden
met
uitzondering
van
'CFI
Flash
device
Petalinux
Autoconfig'. Indien dit niet gedaan wordt, kan de kernel de flash partities, die later bij de user settings ingesteld worden, niet gebruiken waardoor hij crashed. Het 'generic uClinux RAM/ROM filesystem' support is ook cruciaal. Zonder dit bestandssysteem kan het root filesystem niet gemount worden, wat leidt tot een kernel panic. Bij block devices is het cruciaal dat 'RAM disk support' ingeschakeld wordt. Zonder deze mogelijkheid heeft het besturingssysteem geen enkele schrijfbare map. Het is echter noodzakelijk om een schrijfbare map te gebruiken, zoniet kan vb. de webserver niet opstarten, welke de Dream netwerkbesturing voor zich zou nemen. Bij 'networking options' moet standaard niets gewijzigd worden. Indien echter geavanceerde netwerkfunctie nodig zijn zoals VLAN, multicasting, Ipv6, bridging, ..., dan bevinden zich hier een heel aantal nuttige instellingen.
44
Figuur 5.6: De te maken instellingen voor 'Network Device Support => Ethernet (10 or 100Mbit)'
Indien de Xilinx ethernet lite IP core gebruikt werd, zoals in deze applicatie het geval is, dan moet deze zoals hierboven ingeschakeld worden. Indien de Xilinx ethernet IP core gebruikt werd, dan bevindt de driver zich onder 'Ethernet (1000 Mbit)'.
Figuur 5.7: De te maken instellingen voor 'Misc devices'
De Dream DRM-software zal gebruik maken van de microblaze FSL links, de driver voor deze apparaten gevonden worden onder 'Misc devices'
45
Figuur 5.8: De te maken instellingen voor 'File systems'
Bij file system moet het 'Compressed ROM' filesystem zeker ingeschakeld worden. Het Journalling Flash File System v2 is een heel handig gecomprimeerd bestandssysteem, geoptimaliseerd om het flash geheugen gelijkmatig te gebruiken. Later kan dit gebruikt worden om instellingen op te slaan. Merk op dat tijdens het inschakelen van jffs2, het item 'library routines => zlib compression support' automatisch ingeschakeld wordt, waardoor dit niet meer zichtbaar is. Aangezien jffs2 een gecomprimeerd bestandssysteem is, heeft het geen nut om XIP gecompileerde bestanden op een dergelijk bestandsformaat te plaatsen.
46
3. Gebruikersinstellingen De meeste gebruikers instellingen zijn minder kritisch dan de net gemaakte kernel instellingen. Vandaar dat hier slechts de allerbelangrijkste instellingen zullen overlopen worden. Eenmaal deze instellingen correct gemaakt zijn, is het vrij om te experimenteren.
Figuur 5.9: Het uClinux gebruikers instellingen hoofdmenu
Figuur 5.10: De te maken instellingen in 'System Settings'
In het 'System Settings' menu worden basiseigenschappen van het systeem ingesteld.In het submenu 'Network Addresses' is het mogelijk om het MAC-adres, het standaard IP-adres en het server adres te wijzigen. Deze instellingen zijn 47
vooral van toepassing bij u-boot bootloader. Deze stelt het MAC-adres in van de netwerkadapter. Het server ip adress bepaald vanaf welke tftp server de firmware geladen wordt. Het root bestandssysteem wordt best op CRAMFS gelaten. JFFS2 is ook één van de mogelijkheden, maar is momenteel nog niet ondersteund. Het 'Build u-boot' item moet zeker ingeschakeld worden. Zoniet wordt de tweede bootloader, uboot, niet gecompileerd. Hierdoor is het enkel mogelijk om via FS-boot op te starten. U-boot heeft echter, in tegenstelling tot FS-boot, de mogelijkheid om via netwerk (nfs of tftp) de firmware te laden, waardoor deze ten sterkste aangeraden wordt. U-boot geeft ook de boot parameters mee aan de kernel, zoals het netwerkadres. Indien het root bestandssysteem via nfs gebruikt wordt, worden de nfs parameters ook als boot parameters meegegeven aan de kernel. De flash partities kunnen ingesteld worden in het submenu 'Flash partition table'. Standaard zijn er 5 ingestelde partities. De boot en boot-env partities zijn nodig om respectievelijk de u-boot image en de u-boot configuratie in op te slaan. De derde partitie bevat de boot parameters die meegegeven worden aan de kernel tijdens het opstarten. Partitie vier bevat de effectieve systeem image, en is 4MB groot. Tenslotte is er nog een reserve partitie ingesteld die de rest van het flash geheugen omvat. Om de Dream-software later te kunnen debuggen is er een aangepaste versie van gdb aanwezig. Deze is te vinden onder 'Miscellaneous Applications => gdb server'. Meer informatie is te vinden in hoofdstuk 5.4.2. Dit zijn de enige echt essentiële instellingen die benodigd zijn. Alle andere programma's kunnen relatief vrij gekozen worden. Het belangrijkste waar op moet gelet worden is dat bepaalde programma's in verschillende versies aanwezig zijn. vb.: mount is beschikbaar onder 'Core applications' en onder 'BusyBox'. Indien deze twee maal geselecteerd wordt, dan zal tijdens de compilatie een fout optreden. De selectie van de juiste versie moet gedaan worden door een vergelijking van de functionaliteiten. Op internet is vrij veel informatie te vinden, het is wel telkenmale zoeken .... In de petalinux-dist/user map staan alle broncodes van de programma's die gekozen kunnen worden in het gebruikers menu. Bij vele programma's staat heel wat documentatie.
48
5.4.2. Debuggen op het microblaze platform Om te kunnen debuggen op het microblaze platform, met de gdb debug server geïnstalleerd worden op het microblaze platform zoals hoger beschreven. Bij de Petalinux distributie is er een client gdb, microblaze-uClinux-gdb meegeleverd. Tijdens de compilatie wordt er standaard een debug bestand (applicatie.gdb) gecreëerd van de applicatie. Als eerste stap moet de applicatie via de debug server op het microblaze platform opgestart worden: gdbserver localhost:1234 /bin/applicatie arg1 arg2 Hierin zijn 'arg' de argumenten die meegegeven worden aan de applicatie. Nu is het mogelijk om d.m.v. de gdb-client vanaf pc de debug verbinding te maken met de server. cd $PETALINUX/software/user-apps/applicatie microblaze-uClinux-gdb applicatie.gdb
5.5. Bord initialisatie Na het afwerken van het hardware- en softwareplatform is het ogenblik aangebroken om het systeem te testen op het SPARTAN-3E bord. Als eerste test kan de hardware getest worden door kermit op te starten (zie appendix A), en daarna de FPGA te configureren. FS-boot zou moeten zichtbaar worden:
Figuur 5.11: Het opstarten van FS-boot
Om een globaal overzicht te hebben over hetgeen moet gebeuren is het noodzakelijk om de vooropgestelde bootsequentie van iets dichter te bekijken. Hierdoor zullen de benodigde stappen om het systeem te installeren vrij logisch worden. 49
FPGA geprogrammeerd Opstarten FS-boot (vanaf 0x00000000)
J
U-boot image gevonden?
N
Laad U-boot (vanaf 0x21000000)
Wacht op u-boot.srec (cat u-boot.srec > /dev/ttyS0)
Laad U-boot config (vanaf 0x21020000)
Verzend U-boot config (serieel, NFS, TFTP)
J
linux image gevonden?
Laad kernel image in RAM (vanaf 0x21080000)
N Laad kernel image (serial, NFS, TFTP)
Start linux kernel Figuur 5.12: De microblaze-uClinux boot sequentie
Na het programmeren van de FPGA (ofwel manueel, ofwel via de platform flash) wordt de first stage bootloader, FS-BOOT, automatisch gestart vanuit BRAM. Deze controleert het begin van het flash geheugen indien er zich een u-boot image bevind. Zo ja, dan laadt hij deze in het hoofdgeheugen en voert hem uit. Zo nee, dan wacht FS-boot totdat er via seriële poort een bestand doorgestuurd wordt in srec formaat. Het u-boot.srec ofwel het image.srec bestand kan doorgestuurd worden via het volgende commando: cd /tftpboot cat u-boot.srec > /dev/ttyS0 U-boot.srec is de second stage bootloader, gemaakt om rechtstreeks in RAM uitgevoerd te worden. Het u-boot-s.srec bestand is het bestand gemaakt om in flash geplaatst te worden. Image.srec is het volledige besturingssysteem. Het 50
wordt echter niet aangeraden om dit door te sturen, aangezien dit meer dan een uur kan duren. Na het voltooien van de transmissie, wordt het doorgestuurde bestand automatisch uitgevoerd. De u-boot bootloader wordt gestart, en controleert als er een configuratie te vinden is in het flashgeheugen. U-boot heeft nu echter nog geen configuratie ingesteld. Deze wordt ingesteld door het uitvoeren van een klein script, ub.config.img . Het doorsturen van een bestand in u-boot is anders dan het doorsturen van een bestand in fs-boot. Bij u-boot moet het bestand via kermit doorgestuurd worden. Eerst moet u-boot een binair bestand verwachten: u-boot> loadb $0x24000000 ## Ready for binary (kermit) download to 0x24000000 at 115200 bps... Hierdoor wordt in u-boot het volgende doorgestuurde bestand via kermit naar het geheugenadres 0x24000000 gekopieerd, het begin van het hoofdgeheugen. Nu moet het bestand doorgestuurd worden. Er kan terug gekeerd worden naar de pc door de toetsencombinatie CTRL+\ gevolgd door C
in te tikken. Daarna het
volgende uitvoeren: C-Kermit>cd /tftpboot C-Kermit>send ub.config.img Na het voltooien van de overdracht kan via 'connect' terug op het bord gewerkt worden. Het script moet nu uitgevoerd worden als volgt: u-boot> autoscr 0x24000000 ## Executing script at 10000000 Petalogix MicroBlaze-Auto Board Configuration --------------------------------------------Network Configuration: MTD Configuration: Clobber DRAM Configuration: Bootloader Configuration: Kernel Configuration: Boot Configuration: Saving Configurations... Saving Environment to Flash... Un-Protected 1 sectors Erasing Flash... . done Erased 1 sectors Writing to Flash... done Configuration Completed Nu is het flashgeheugen zo ingesteld dat het enkel nog een kwestie is van de juiste images te kopiëren en naar de juiste plaats op het flashgeheugen te plaatsen. Er moet echter wel rekening mee gehouden worden dat het flash 51
geheugen 'unprotected' en leeg moet zijn. Flash geheugen kan namelijk enkel per blok gewist worden, waarna de betreffende bits ingesteld moeten worden. Het kopiëren van het bestand naar het platform kan op exact dezelfde manier gebeuren als hierboven. Aangezien het echter grotere bestanden zijn, kan dit vrij lang duren. Vandaar dat de oplossing via nfs hier een stuk sneller is. Het kopiëren van de u-boot flash image via nfs gaat als volgt: nfs 0x24000000 192.168.0.1:/tftpboot/u-boot-s.bin protect off $(bootstart) +$(bootsize) erase $(bootstart) +$(bootsize) cp.b 0x24000000 $(bootstart) $(filesize) Tenslotte moet nog de systeem image gekopieerd worden: nfs 0x24000000 192.168.0.1:/tftpboot/image.bin protect off $(kernstart) +$(kernsize) erase $(kernstart) +$(kernsize) cp.b 0x24000000 $(kernstart) $(filesize) Na het voltooien van deze stap is het bord volledig geïnitialiseerd. Natuurlijk is het nodig om de FPGA zichzelf te laten configureren vanaf platform flash. Dit is heel eenvoudig te verwezenlijken door eerst een prom bestand te maken van het volgende bestand: $PETALINUX/hardware/user-platforms/PLATFORM/implementation/download.bit Dit wordt heel eenvoudig gedaan via een wizard in 'impact', te vinden zoals hieronder afgebeeld:
Figuur 5.13: De locatie van de prom creatie wizard
Om tenslotte de FPGA automatisch vanaf platformflash te laten opstarten, moeten de drie jumpers op J30 allemaal aanwezig zijn. Met deze laatste stap is de configuratie en initialisatie van een volledig autonoom werkend microblaze-uClinux platform volledig voltooid! Op dit platform kan nu de Dream-software geport worden.
52
6. Dream 6.1. Overzicht Dreamsoftware De Dream-software is ontworpen om via een geluidskaart van een PC het DRM signaal te bekomen en te verwerken volgens de stappen zoals in figuur 6.1 weergegeven.
Figuur 6.1: Overzicht van de Dream gegevensstroom. Bron: [10]
53
6.2. Dreamwerkingsprincipes 6.2.1. Frequentie en tijdssynchronisatie[11] Dream werd ontworpen om te werken op een PC. Via de geluidskaart wordt het binnenkomend signaal gesampled op een frequentie van 48 kHz. Bij PC systemen is deze samplefrequentie echter niet 100% correct. Tevens wordt de IF frequentie van de externe demodulator niet 100% vastgelegd. Om deze speling toe te laten is in Dream een samplerate correctie en een frequentie correctie aanwezig. De gevolgen van een verkeerde samplerate en een verkeerde IF zijn gelijkaardig. Beide hebben als invloed dat de ontvangen subkanalen niet meer perfect orthogonaal zijn, waardoor er Inter Carrier Interferentie (ICI) ontstaat. Toch zijn de oorzaken van deze ICI subtiel verschillend.
1. Ideale OFDMdemodulatie Indien een DFT genomen wordt van een discreet signaal, dan wordt een discreet spectrum bekomen. Op exact bepaalde frequenties wordt de amplitude en de fase van het signaal bepaald. Bij DRM worden een heel aantal orthogonale kanalen verzonden als één OFDM symbool. Wegens deze orthogonaliteitseis zijn de frequenties van deze kanalen exact bepaald. Indien de IF en de samplerate correct zijn, dan wordt de situatie zoals in figuur 6.2 bekomen. OFDMsubkanalen DFTFrequenties Figuur 6.2: De ideale situatie: DFT frequenties en OFDM-subkanaalfrequenties zijn identiek
De bekomen DFT-frequenties en de OFDM-subkanaalfrequenties zijn exact gelijk. Omdat op deze OFDM-frequenties geen ICI optreedt, wordt de OFDM-demodulatie ideaal uitgevoerd.
2. Afwijking v.d. IFfrequentie Indien de IF-frequentie enigszins afwijkt van de ideale situatie, dan komen de DFT en de OFDM-subkanaalfrequenties niet exact meer overeen zoals in figuur 6.3.
54
Hieruit
volgt
dat de
bekomen
DFT-frequenties
ICI
zullen
bevatten.
Een
bovengrens aan de invloed van deze ICI kan bepaald worden door het berekenen van de SNR. OFDMsubkanalen DFTFrequenties Figuur 6.3: IF niet exact: DFT frequenties en OFDM subkanaal frequentie zijn nergens identiek
Speth en Meyr [12] hebben een maximale waarde van de SNR-verzwakking bepaald aan de hand van de relatieve frequentieoffset t.o.v. de carrierspacing.
f Tu
3
1 1 1− max
Hierin is ƴ de SRV van het ontvangen signaal, en
Δƴmax de maximale SRV
verzwakking als gevolg van ICI. Aan de hand van deze formule wordt onderstaande figuur bekomen.
Figuur 6.4: SRV Degradatie door ICI bij frequentieoffset. bron: [11]
3. Afwijking v./d. bemonsteringsfrequentie Samplerate fouten hebben een iets andere invloed dan frequentieoffset fouten, zoals in onderstaande figuur wordt weergegeven. Indien de samplerate afregeling ervoor zorgt dat de eerste sample op exact het juiste moment genomen wordt, dan zal de frequentie van dit subkanaal exact overeenkomen met de resulterende 55
DFT-frequentie. Bij verdere samples zal dit tijdstip echter enigszins verlopen t.o.v. het ideale tijdstip, waardoor de resulterende DFT frequentie niet exact gelijk meer zal zijn aan de subkanaal frequentie. Hierdoor ontstaat er dus een ICI waarvan de grootte wijzigt van subkanaal tot subkanaal. OFDMsubkanalen DFTFrequenties Figuur 6.5: Samplerate niet exact: DFT frequenties verschuiven t.o.v. de OFDM subkanaal frequenties
4. Benodigde IF en bemonsteringsfrequentieaccuraatheid Volgens de DRM-standaard ([1], annex A+B) ligt de benodigde SRV voor een BER van 10-4 onder de slechtste omstandigheden op 20,4 dB. Bij de werkelijke implementatie in Dream is volgens [13] in het slechtste geval echter een SNR van 26 dB benodigd. In [11] werd een signaal SRV van 25 dB, en een verlies van 0,5 dB vooropgesteld, waardoor er een relatieve frequentie offset van 1% (=4,8 Hz) toegelaten was. Aangezien praktisch echter 26 dB SRV nodig is, moet er vanuit gegaan worden dat het ontvangen signaal een SRV bezit die hoger is dan 26 dB. Volgens figuur 6.4 wordt een SRV-daling van minder dan anderhalf dB bekomen voor een signaal SRV van minder dan 30 dB indien de relatieve frequentieafwijking minder dan 1% bedraagt. Indien nu opnieuw slechts dezelfde 0,5 dB verzwakking vooropgesteld wordt, dan moet de frequentieoffset dalen tot slechts 0,5% (= 2,4Hz) Om de maximale samplerateafwijking te bekomen, kan het hierboven bekomen resultaat
heel
eenvoudig
gebruikt
worden.
De
maximale
relatieve
frequentieafwijking mag 1% (0,5% indien een ideale ontvanger vooropgesteld wordt) bedragen. Deze frequentieafwijking mag niet bereikt worden over het maximum aantal kanalen. De afregeling van deze kanalen wordt echter uitgevoerd door de frequentiereferenties, waardoor deze ongeveer in het midden van het symbool afgeregeld worden. M.a.w. het maximum aantal kanalen tussen de correct afgeregelde frequentie en de meest afwijkende frequentie bedraagt slechts de helft van het maximaal aantal kanalen. Hieruit volgt dat om een SRV van meer dan 25dB te bekomen een maximale afwijking van 1% gedeeld door 56
200 kanalen, of 0,005% toegelaten is.
5. Werkingsprincipe van de afregelkring In figuur 6.6 wordt de frequentie- en samplerate afregeling die gebruikt wordt in de DRM software nader bekeken.
Figuur
6.6:
Blokschema
van
de
frequentie
en
samplerate afregeling. Bron: [11]
De afregeling van de samplerate en de frequentie wordt aangestuurd door de Frequentie tracker. Deze wordt geplaatst na de OFDM-demodulatie. Hierdoor wordt een frequentie- naar tijdsdomein terugkoppeling voorzien. Vooreerst zal de frequentie tracker de frequentie correctie afregelen aan de hand van de huidige gemeten frequentie en de bekomen offset na de OFDM-demodulatie. Eenmaal deze afregeling voltooid is, kan de sampleratecorrectie voltooid worden aan de hand van het afwijken van de piloot- of referentiecellen t.o.v. de ideale posities.
6. Invloed op de embedded implementatie In het embedded systeem wordt de samplerate afgeleid van een 80Mhz klok die een accuraatheid groter dan 0,5*10-4 heeft waardoor een samplerateaanpassing dus niet nodig zal zijn. Dit is een relatief rekenintensief deel dat volledig kan verwijderd worden uit de Dream-software (Dit werd trouwens ook gedaan in het ontwerp gemaakt in [2]). De frequentiecorrectie is echter niet zo voordelig om te verwijderen. De frequentiecorrectie wordt voltooid aan de hand van de mixer. Deze is toch steeds nodig om te kunnen mixen vanaf de IF van 12kHz naar basisband. Het maken van een tuner die tot op 2,4Hz nauwkeurig kan afstemmen is zeker geen eenvoudig opgave. Dit gebeurt digitaal, waardoor de DDS-precisie heel groot moet worden. Tevens is de frequentietracking hoe dan ook nodig indien een terugkoppeling naar de RF demodulator (= DDS) voorzien wordt. 57
6.2.2. Frequentieacquisitie Zoals in figuur 6.1 weergegeven wordt, wordt de frequentieacquisitie voltooid als eerste stap na het uitvoeren van de sampleratecorrectie. De reden hiervoor is dat het uitvoeren van de frequentieacquisitie heel eenvoudig kan voltooid worden aan de hand van de frequentiereferentiecellen. Deze cellen worden namelijk met een vermogenversterking van twee (=10dB) uitgezonden. Omdat de andere cellen tevens een volledig willekeurige fase en amplitude bezitten, zal het gemiddelde vermogenverschil tussen de frequentiecellen en de standaard cellen groter worden dan de vermogenversterking van 10 dB. Indien een FFT met een lengte groter dan één symbool genomen wordt, dan worden alle cellen in deze symbolen uitgemiddeld. Hieruit volgt dat het spectrum van niet-referentiecellen vrijwel vlak zal worden, terwijl het spectrum van de frequentiereferentiecellen hier heel sterk bovenuit zal steken, zoals in onderstaande figuur weergegeven wordt.
Figuur 6.7: Het spectrum bij het uitvoeren van een FFT over meerdere symbolen. De frequentiereferenties van resp. 750, 2250 en 3000Hz zijn heel goed zichtbaar. Bron: [14]
Om de frequentieacquisitie exacter te maken, kan men de FFT nemen over een langere periode. Deze kan echter niet oneindig lang gemaakt worden, daar de gevolgen van de kanaalfading de resultaten zouden beïnvloeden.
58
6.2.3. Tijdsacquisitie De tijdsacquisitie is relatief simpel qua implementatie, maar zit echter subtiel in elkaar. Bij een OFDM-modulatie bestaat ieder symbool (met lengte Ts) uit een guard interval (TG) en een usable interval (TU). De subkanaalafstand bij een OFDM-symbool is gelijk aan 1 , waaruit volgt dat iedere sinus in een subkanaal
Tu
een geheel aantal keer in de bruikbare symbooltijd past, zoals in onderstaande figuur weergegeven.
Afbeelding 6.8: Iedere sinus van een subkanaal past een geheel aantal keer in de bruikbare symboollengte. Bron: [15]
Het guard interval wordt voor het symbool geplaatst, of m.a.w. dit is een prefix. Het specifieke aan deze prefix is dat dit een cyclische uitbreiding is van het OFDM-symbool. Dit houdt in dat ieder subkanaal een prefix krijgt zoals in figuur 6.9 weergegeven. Hieruit volgt dat de prefix identiek is aan het laatste deel van het symbool. M.a.w., indien een autocorrelatie over een interval met lengte T g en met een tijdsverschuiving Tu genomen wordt, dan zal deze maximaal zijn indien dit interval overeenkomt met de prefix. Op deze manier wordt het vrij eenvoudig om het exacte begin van een symbool te bepalen. Tevens kan men nu aan de hand van dit principe heel eenvoudig de robuustheidsmodus bepalen. De bruikbare symboollengte is namelijk verschillend voor de verschillende modi, waardoor een simpele wijziging van de tijdsverschuiving van de autocorrelatie slechts een maximum zal geven bij de correcte robuustheidsmodus.
59
Tu
Prefix
Bruikbaar symbool
Figuur 6.9: Eén subkanaal van één symbool nader bekeken.
Om de detectie echter betrouwbaarder te maken bij het ontvangen van stoorsignalen, wordt de energie van het gekozen interval nog in rekening gebracht als volgt ([14], p. 14):
¿ i Ng −1
i=
∑ [∣r n r ∗nN∣−∣r n2∣∣r nN2∣ ] n=i
Hierin is:
N = aantal samples in Tu Ng = aantal samples in Tg
Bij het praktisch uitvoeren worden de onderstaande correlaties bekomen.
Afbeelding 6.10: links: Enkel correlatie, rechts: Met guard energie aanpassing
60
6.2.4. Kanaalschatting[14] De kanaalschatting in DRM wordt mogelijk gemaakt door de pilootsymbolen. Deze pilootsymbolen wijzigen telkenmale van kanaal bij ieder ontvangen symbool, zoals in onderstaande figuur weergegeven.
OFDM kanaal index
Tijd Figuur 6.11: Lokatie van de pilootsymbolen. Bron:[14]
De optimale kanaalschatting kan voltooid worden door middel van een tweedimensionaal wienerfilter, zoals in onderstaande figuur weergegeven. Een
tweedimensionaal
wienerfilter
is
echter
te
complex
volgens
OFDM kanaal index
Tijd Figuur 6.12: De optimale implementatie aan de hand van een 2D-wienerfilter. Bron:[14]
61
Kurpiers en Fischer [14]. Een ietwat minder accurate schatting van de kanalen kan bekomen worden door twee ééndimensionale wienerfilters, zoals in figuur 6.13, toe te passen na elkaar. Hierdoor daalt de complexiteit heel sterk, terwijl slechts een kleine schattingsfout geïntroduceerd wordt.
OFDM kanaal index
Tijd Figuur 6.13: De niet optimale implementatie aan de hand van twee 1D-wienerfilters. Bron:[14]
Voor de kanaalschatting wordt als kanaalmodel een typisch kortegolfkanaalmodel met doppler effect gebruikt, als volgt beschreven: 2
∣Hf ∣=
1
2∗∗
2 d
e
−
f 2 2d
Waarin 2 het ruisvermogen is. d Bij deze implementatie wordt bekomen dat de schattingsfout bij een kanaal type 3([1], annex B), 20dB SNR, 10kHz bandbreedte en robuustheidsmodus B, niet hoger dan -24dB is t.o.v. de 2D optimale kanaalschatting([14], p.11).
6.3. Benodigde bibliotheken De Dream-software gebruikt een aantal bibliotheken, zoals in onderstaande figuur weergegeven.
62
Dream DRM-Software
FFTW
FAAD2
Journaline
QWT
Hamlib
Figuur 6.14: Overzicht van de benodigde bibliotheken. (rood = noodzakelijk, oranje = gewenst, groen = optioneel)
De FFTW-bibliotheek is absoluut noodzakelijk. Zonder deze bibliotheek is het onmogelijk om Dream te laten werken aangezien deze nodig is om de OFDM-demodulatie te kunnen voltooien. Om een volledig zelfstandige DRM-ontvanger te kunnen maken, zijn ook de FAAD2 en de Journaline bibliotheek nodig. Zonder deze bibliotheken kan de audio-
respectievelijk
datastream
niet
gedecodeerd
worden.
De
DRM-
gegevensstream kan echter nog steeds gedecodeerd worden. De QWT-bibliotheek zorgt voor een grafische gebruikersinterface. De Hamlibbibliotheek zorgt er voor dat standaard LF-MF-HF-ontvangers kunnen bestuurd worden. Het ontwerpen van een back-end voor de aansturing van de RFdemodulatie is een mogelijkheid.
6.4. Porten van de software Het porten van software naar het microblaze-uClinux gebeurt in twee stappen. De eerste stap is het aanpassen van de Makefile zodoende dat de software gecompileerd wordt voor dit platform. Er zijn twee belangrijke soorten van aanpassingen die gemaakt moeten worden aan de Makefile. Indien het programma gebruik maakt van het configure-systeem, dan kan er heel eenvoudig een Makefile gemaakt worden die dit configure-systeem gebruikt om de aanpassing die benodigd zijn te volbrengen. Indien het configure-systeem echter niet gebruikt werd om de Makefile te genereren, dan is het nodig om manueel ofwel een nieuwe Makefile te schrijven, ofwel de bestaande Makefile te
63
doorgronden en aan te passen. Een voorbeeld van het ontwerp van de Makefiles met of zonder gebruik van het configure-systeem is te vinden in appendix D. De tweede stap is het aanpassen van de software volgens de wijzigingen uitgelegd in hoofdstuk 5.3. De eerste bibliotheek die geport werd is de journaline bibliotheek. Deze bibliotheek bestaat zowel uit C code in de bibliotheek zelf als een deel C++ code in het testprogramma. Hierdoor werd het duidelijk hoe een dergelijke bibliotheek geport moet worden. De volgende output wordt bekomen bij het uitvoeren van het testprogramma: # journalinedemo nml* 00 00 32 01 44 57 20 4f 6e 6c 69 6e 65 02 00 01 44 65 75 74 73 63 68 65 20 4e 61 63 68 72 69 63 68 74 65 6e 02 00 02 45 6e 67 6c 69 73 68 20 6e 65 77 73
..2.DW O nline... Deutsche Nachric hten...E nglish n ews
De tweede bibliotheek die geport werd, is de fftw bibliotheek. Deze is heel belangrijk daar de Dream-software intensief gebruik maakt van deze bibliotheek. De FFTW-bibliotheek werd getest aan de hand van het fftw_test programma met de volgende resultaten: Hardware instellingen: 75Mhz processor, 100Mhz RAM, zonder FPU # fftw_test -s 32 Please wait (exorcising evil spirits). SPEED TEST: n = 32, FFTW_FORWARD, out of place, generic time for one fft: 3.600544 ms (112.516998 us/point) "mflops" = 5 (n log2 n) / (t in microseconds) = 0.222189 De belangrijkste conclusie die hieruit gemaakt kan worden, is dat de processor maar in staat is om 0,22 Mflops te halen zonder FPU. De configuratie van de U-BOOT bootloader, een deel van de extra functionaliteit die bij Petalinux hoort, laat echter het gebruik van een FPU nog niet toe. De maximale theoretische FPU berekensnelheid op een 75Mhz processor bedraagt namelijk 18,75MFlops, waardoor het zeker mogelijk is om de benodigde rekensnelheden voor de DRMdemodulatie4 te behalen.
4 Zie tabel 3.1 op pag. 13
64
6.5. Toekomstmogelijkheden Het aantal mogelijkheden beschikbaar op dit platform is extreem groot. Het kan een volledige DRM-ontvanger, die aan het netwerk gekoppeld is, creëren met een minimum aan IC's. Een flash geheugen, een RAM geheugen, een ethernet PHY, en een FPGA zijn de enige onderdelen die nodig zijn om een netwerkgekoppelde DRM-ontvanger te doen werken. De digitale verwerking die gebeurt in DRM Thesis 2 kan eenvoudig samen in één FPGA geplaatst worden. Een tweede grote mogelijkheid is het rechtstreeks implementeren in de FPGA van de aansturing van een klasse-S eindtrap. Vooral de implementatie van een hogere orde Sigma-Delta modulator[7], zou een heel kwalitatieve klasse-D versterker kunnen leveren.
65
7. Conclusie De hardwarearchitectuur bepaald voor een groot deel de mogelijkheden van het uiteindelijke product. Om een gefundeerde beslissing te kunnen maken omtrent deze architectuur is vooreerst een vrij grondige studie van de DRM-standaard voltooid. Hierdoor werd het vrij snel duidelijk dat een DRM-ontvanger creëeren geen eenvoudige opgave is, waardoor besloten werd om bestaande software, namelijk Dream, te gebruiken als implementatie van tenminste een deel van de ontvanger. Na het maken van deze beslissing werd Dream naderbij bekeken, vooral op gebied van complexiteit en benodigde verwerkingssnelheid, waaruit bleek dat het onmogelijk is om een volledige DRM-ontvanger zelf te creëeren gedurende de looptijd van deze scriptie. In het beste geval was het mogelijk om slechts een klein deel ervan te implementeren. Eenmaal tot deze conclusie gekomen, was het ogenblik aangebroken om een hardwarearchitectuur
te
definiëren.
De
hardwarearchitectuur
had
enkele
mogelijke vormen, maar wegens de complexiteitsstudie en het feit dat de voorgaande scriptie al in FPGA uitgevoerd werd, kwam de beslissing vrij snel om de
hardware/software
co-design
route
te
volgen.
Deze
had
de
beste
verwachtingen en was het meest flexibel, maar was niet de eenvoudigste. De keuze voor het al of niet gebruiken van een besturingssysteem op deze hardware is gesteld. Hierbij is gebleken dat het besturingssysteem voordeliger was. De keuze
van het besturingssysteem viel op uClinux. De belangrijkste
redenen hiervoor waren dat de gebruikersinterface hierdoor heel eenvoudig te implementeren is, evenals het streamen van de audio en data naar het netwerk, terwijl de extra overhead van het besturingssysteem beperkt blijft. Het draaiende krijgen van het besturingssysteem op het platform ging oorspronkelijk vrij snel. Al na enkele weken was er een uClinux draaiende op het platform. Na het ontdekken dat de door Xilinx meegeleverde C++ compiler voor microblaze niet de volledige C++ standaard ondersteunde, was het noodzakelijk geworden om een alternatief te zoeken. Dit alternatief werd gevonden in de Petalinux uClinux distributie. Hierin is een verbeterde versie van de C++ compiler aanwezig. Tevens bezit de Petalinux distributie over een dual-stage bootloader, die noodzakelijk is om een dergelijk platform op te starten.
66
Jammergenoeg bevatte deze distributie heel wat kinderfoutjes, waardoor de initialisatie van het platform heel wat langer duurde dan voorzien. Door deze vertraging was het al halverwege april vooraleer een volledig correct draaiend platform verkregen werd, waarna er slechts een heel beperkte tijd overbleef om de effectieve DRM-software werkende te krijgen op het platform. Helaas werd deze doelstelling niet gehaald. In het begin van deze scriptie werden een aantal eisen aan het ontwerp van de DRM-ontvanger opgelegd. Deze eisen leidden oorspronkelijk tot een gescheiden hardware/software
ontwerp.
Gedurende
de
maand
november
koos
mijn
toenmalige thesispartner echter het hazenpad, waarna ik er alleen voorstond. Hierdoor werd het roer volledig omgegooid, aangezien de oorspronkelijk gekozen route onmogelijk was om alleen te voltooien. De gekozen route bleek echter ook niet zo eenvoudig, maar opende wel een heel aantal
nieuwe
mogelijkheden
naar
toekomstige
applicaties
toe.
Het
implementeren van een werkende DRM-ontvanger is zeker haalbaar op het gekozen platform. De gekozen architectuur laat het toe om een goed evenwicht te zoeken tussen benodigde hard- en software, waardoor de mogelijkheden van een dergelijk platform, zelfs buiten het gebied van een DRM-ontvanger, enorm zijn.
67
Appendix A: Installatie van de Xilinx tools en Petalinux In de loop van deze scriptie werd het duidelijk dat de installatie van de Xilinx ISE en EDK in een algemene (lees recente) Linux versie niet altijd van een leien dakje verloopt. Vooral de installatie van de download cable drivers bleek een bijna onoverkomelijk probleem. Er bestaat sindskort echter een volledige open source oplossing die op iedere recente Linux kernel met udev ondersteuning (bij zo goed als alle distibuties standaard geworden) werkt.
A.1. Controle van de Linux omgeving ●
Op ubuntu Linux en afgeleiden (kubuntu, xubuntu, edubuntu) verwijst de /bin/sh symbolische link meestal naar /bin/dash. Hierdoor ontstaan er een heel aantal fouten tijdens de installatie, aangezien het merendeel van de scripts /bin/sh i.p.v. /bin/bash als interpreter gebruiken. De /bin/sh link moet dus best gewijzigd worden: sudo rm /bin/sh; sudo ln -s /bin/bash /bin/sh
● ●
Ter uitvoering van 'make menuconfig' is de libncurses versie 4 bibliotheek benodigd.
A.2. Installatie van de Xilinx tools Xilinx ISE en EDK zijn vrij eenvoudig te installeren. Een goed locatie om ISE respectievelijk EDK te installeren is: /opt/Xilinx/VERSIE/ise /opt/Xilinx/VERSIE/EDK Hierin word VERSIE uiteraard vervangen door de te installeren versie. Indien nu een nieuwe versie geïnstalleerd moet worden, kunnen deze heel eenvoudig langs elkaar geïnstalleerd worden. Door middel van het maken van een extra symbolische link is het nu ook mogelijk om heel eenvoudig te kunnen overschakelen van de ene versie naar de andere zonder dat er iets moet wijzigen aan de rest van de omgeving: cd /opt/Xilinx ln -s /opt/Xilinx/VERSIE tools Om
het
gebruikersgemak
te
verbeteren,
kunnen
best
een
aantal
omgevingsvariabelen automatisch ingesteld worden. Wegens het maken van 68
bovenstaande symbolische link kan de locatie van de Xilinx tools nu constant blijven, ongeacht de te gebruiken versie. Door het wijzigen van de symbolische link kan nu namelijk de te gebruiken versie gekozen worden. Het automatisch instellen van de Xilinx omgeving kan heel eenvoudig gedaan worden door het toevoegen van de volgende code aan het einde van ~/.bashrc #Xilinx ISE environment settings if [ -e "/opt/Xilinx/tools/ise/settings.sh" ]; then source /opt/Xilinx/tools/ise/settings.sh echo "Xilinx ISE environment set to '/opt/Xilinx/tools/ise'" fi #Xilinx EDK environment settings if [ -e "/opt/Xilinx/tools/EDK/settings.sh" ]; then source /opt/Xilinx/tools/EDK/settings.sh echo "Xilinx EDK environment set to '/opt/Xilinx/tools/EDK'" fi Door het uitvoeren van 'xps' of 'ise' in een console zullen deze nu correct uitgevoerd worden. Indien adobe acrobat reader niet geinstalleerd is op het systeem, dan kan een alternatieve pdf reader ook gebruikt worden. Het enigste dat hiervoor gedaan moet worden is een symbolische link maken met naam acroread naar de te gebruiken pdf weergave programma. vb.: cd /usr/bin sudo ln -s kpdf acroread
A.3. Installatie van de download cable (USB of parallel vIII op parallel vIV in vIII compatibiliteit) De standaard driver die bij ISE en EDK aanwezig is, maakt gebruik van de jungo Windrvr binaire kernel module. Aangezien het een binaire kernel module is, kan deze nogal vaak bij het ontstaan van een nieuwe kernel onbruikbaar worden. Xilinx slaagt er niet in om tijdig nieuwe versies uit te brengen, waardoor enkel oude kernels (lees: 2.4 en 2.6<2.6.18) momenteel ondersteund zijn. Vandaar dat Michael Gernoth een alternatief ontwikkelde om zonder deze proprietary kernel module de impact software te kunnen laten werken. De installatie is echter niet zo eenvoudig, en wordt hier wat toegelicht. 1. Download
de
broncode
vanaf
onderstaande
website
http://cvs.zerfleddert.de/cgi-bin/viewcvs.cgi/usb-driver.tar.gz?view=tar 2. pak het bestand uit (best onder /opt/Xilinx) 69
3. controleer als libusb en fxload geïnstalleerd is (vb. in ubuntu): sudo apt-get install libusb-dev fxload 4. voer 'make' uit in de usb-driver map 5. kopieer libusb-driver.so naar /usr/local/lib 6. Voeg de volgende lijnen toe aan ~/.bashrc #Xilinx download cable settings if [ -e "/usr/local/lib/libusb-driver.so" ]; then export LD_PRELOAD=/usr/local/lib/libusb-driver.so echo "Xilinx download cable module preloaded from '/usr/local/lib/usb-driver.so'" fi sluit nu de huidige console af, en open een nieuwe. 7. maak een nieuw bestand: /etc/udev/rules.d/50-Xilinx-usb-cable.rules en plaats de volgende lijn in dit bestand: ACTION=="add", BUS=="usb", SYSFS{idVendor}=="03fd", MODE="666" 8. restart udev met het volgende commando: sudo /etc/init.d/udev restart 9. sluit het bordje aan en schakel het in 10.controleer het usb bus en nummer met: lsusb | grep Xilinx 11.Als de usb id niet gelijk is aan 03fd:0008 download de nieuwste firmware van: ftp://ftp.Xilinx.com/pub/utilities/fpga/xusbdfwu-1025.zip kopieer hem naar /opt/Xilinx en pak het bestand uit. cp xusbdfwu.hex /opt/Xilinx/tools/ise/bin/lin sudo /sbin/fxload -v -t fx2 -I /opt/Xilinx/tools/ise/bin/lin/xusbdfwu.hex -D /proc/bus/usb/002/004 waarbij 002 en 004 vervangen moeten worden door de bus ID's die lsusb teruggaf. 12.Start impact, normaal moet alles werken. Impact zal waarschijnlijk wel vragen om een firmware update uit te voeren. Daarna kan het systeem gewoon gebruikt worden. 13.Indien impact nog steeds geen connectie kan maken: cd /opt/Xilinx/tools/ise/bin/lin sudo su (Als root inloggen) source ./setup_pcusb
A.4. Installatie van Petalinux
70
De installatie van Petalinux is op zich heel eenvoudig. Het enigste wat moet gedaan worden is Petalinux downloaden vanaf de website: http://developer.Petalogix.com en deze uit te pakken in de home map van de gebruiker. Dit kan best gebeuren door het Petalinux-***.tar.gz bestand naar ~ te verplaatsen en dan via tar xvzf Petalinux-***.tar.gz uit te voeren. Het bestand bevat namelijk een héél groot aantal bestanden, waardoor een grafisch uitpak programma er soms héél lang kan over doen om de inhoud weer te geven. Maak nu nog een symbolische link: vanaf ~/Petalinux naar de Petalinux installatie map. Er is bij de rc1 versie echter een probleem, waardoor het noodzakelijk is om een symbolische link te maken van /home/devel naar de home map van de gebruiker. Hetzelfde is nodig voor /home/jwilliam. Indien er nog geen nieuwere versie dan rc1 verkrijgbaar is, dan zal er best gewerkt worden met de bijgeleverde versie op CD. In deze versie zijn namelijk al een heel aantal kleine foutjes gehaald, die het gebruik ervan heel wat minder zenuwslopend maken. Tenslotte wordt het volgende best nog toegevoegd op het einde van ~/.bashrc #Petalinux environment settings if [ -e "/home/`whoami`/Petalinux/settings.sh" ]; then OLDPWD=`pwd` cd /home/`whoami`/Petalinux source ./settings.sh cd $OLDPWD fi
A.5. Kermit Kermit is een krachtig serieel communicatie programma. Na het installeren ervan (via sudo apt-get install kermit) is het echter aangeraden om een ~/.kermrc bestand aan te maken met de volgende inhoud: set line /dev/ttyS0 set speed 115200 set carrier-watch off set handshake none set flow-control none robust set file type bin set file name lit set rec pack 1000 set send pack 1000 set key \127 \8 71
set key \8 \127 set window 5 Let er echter op de ttyS0 de eerste seriële poort voorstelt. ttyS1 is de tweede, ... Nadat dit bestand gecreëerd werd, kan kermit gebruikt worden als volgt: kermit -c Om tijdens het uitvoeren van kermit terug naar de host pc terug te keren, om vb. een bestand door te sturen, moet CTRL+\ ingedrukt worden. Op azerty toetsenborden kan dit een probleem opleveren aangezien nu CTRL+ALT.GR+< ingedrukt moet worden, en dit op veel toestenborden niet werkt met de linker CTRL toets. Bij het gebruiken van de rechter CTRL werkt dit echter wel.
A.6. Installatie van uClinux BSP bestanden voor Windows Zonder de uClinux BSP bestanden is het onmogelijk om een auto-config.in bestand te maken. Dit bestand is echter nodig om alle instellingen kenbaar te maken aan de uClinux kernel. Deze BSP bestanden waren te vinden op de www.Petalogix.com, maar zijn daar nu verdwenen. Er zit echter altijd een versie van deze bestanden in de Petalogix distributie. De BSP bestanden staan in: $Petalogix/hardware/EDK_user_repository Door het kopiëren van deze map naar de map boven de EDK installatiemap op de windows pc is het mogelijk om de hardware instellingen en compilatie ook op een windows pc te voltooien.
72
Appendix B: Opzetten van de basishardware
Figuur
B.1
(links):
Keuze
van
het
ontwikkelbord
-
Spartan-3E
rev.
D.
Figuur B.2 (rechts): Keuze van de processor – enkel microblaze processor is beschikbaar op een SPARTAN-3E FPGA
73
Figuur B.3 (links): Ingestelde parameters: 50Mhz reference clock, 75Mhz processor clock,
Hardware
debug
module,
8kB
BRAM,
no
cache,
no
FPU
Figuur B.4 (rechts): Ingestelde parameters: RS232_DTE, uartlite, baudrate 115200, use interrupt. De keuze tussen DTE en DCE hangt af van de beschikbare kabel.
Figuur B.5 (links): Ingestelde parameters: flash zeker inschakelen. LED's, DIP switches en Buttons
naar
believen.
Figuur B.6 (rechts): Ingestelde parameters: DDR_SDRAM inschakelen, Ethernet_MAC wijzigen naar OPB_ethernetlite met interrupt
74
Figuur B.7 (links): Toevoegen van extra randapparaten: Timer toevoegen met de volgende
instellingen:
bit
width:
32,
one
timer
present,
use
interrrupt
Figuur B.8 (rechts): STDIN en STDOUT instellen. Deze instellingen zijn enkel geldig voor de testprogramma's die automatisch zullen geïmporteerd worden in het project, en niet voor de uClinux kernel. (instelling vor uClinux: zie hoofdstuk )
Figuur B.9 + B.10: Geheugenlocaties van de verschillende testprogramma's. Indien er voor gekozen wordt om de randapparatuur testen in het DDR geheugen te plaatsen, dan moet men deze manueel inladen in het geheugen.
75
Na het klikken van generate wordt het volledige systeem gegenereerd. De laatste stap geeft een overzicht weer van het te creëren systeem.
Figuur B.11: Overzicht van het bekomen systeem
Merk op dat het DDR geheugenbereik slechts van 0x24000000 tot 0x25ffffff loopt, wat slechts 32MB groot is (i.p.v. de werkelijke 64MB). Dit is een fout die in de BSB-borddefinitie aanwezig is. Deze kan echter heel eenvoudig na het genereren
van
het
systeem
aangepast
worden
via
dubbelklikken
op
DDR_SDRAM_32Mx16 daarna het tabblad system, dan Address => High Address of Bank 0 instellen op 0x27ffffff.
76
Figuur B.12: 64MB ram instellen na de BSB wizard
77
Appendix C:Voorbereiding uClinux hardwareproject C.1. Instelling van het softwareplatform in het hardwareproject 1. Kopieer het volledige hardwareproject naar de $PETALINUX/hardware/userplatforms map (Geen spaties in de mapnamen, anders krijg je een XST 426-error tijdens het genereren van de netlist) 2. Open een shell en voer de volgende stappen uit: cd $PETALINUX/hardware/PROJECTMAP ln -s ../../EDK_user_repository EDK_user_repository
3. open het bestand system.xmp van het hardware project en voeg er de volgende lijn aan toe: ModuleSearchPath: EDK_user_repository/
Deze lijn komt net voor de volgende: MHS File: system.mhs
4. Open het hardwareproject en maak de volgende instellingen in het menu software->software platform settings Software platform CORE_CLOCK_FREQ
75MHz
xmdstub_peripheral
debug_module OS and Libraries
flash_memory_bank
0
flash_memory
FLASH_16Mx8
main_memory_bank
0
main_memory
DDR_SDRAM_16Mx16
stdin
RS232_DTE
stdout RS232_DTE De xmdstub_peripheral maakt duidelijk dat de debug module moet gebruikt
worden
door
de
Xilinx
Microblaze
Debugger
(XMD).
Stdin en stdout worden gekozen als de standaard console voor uClinux. Tijdens het bootprocess wordt alle informatie naar deze console gestuurd. De volgende figuren maken duidelijk waar deze instellingen zich bevinden.
78
Figuur C.1+C.2: De software platform respectievelijk OS and Libraries instelling die gemaakt moeten worden.
79
C.2. Instellen van de Bootloader FSBOOT De volgende stappen vervolledigen het hardware platform tot een volledig systeem dat volledig autonoom kan opstarten: a. Verwijder alle aanwezige softwareprojecten. De microblaze_0_bootloop en microblaze_0_xmdstub projecten kunnen niet verwijderd worden. Deze mogen echter zeker niet geïnitialiseerd worden in BRAM! (Rechtermuistoets op de projecten) b. Voeg een nieuw project toe met naam fs-boot c. Voeg
de
volgende
bron-
en
headerbestanden
toe
(best
via
dubbelklikken op sources respectievelijk headers.) Sources: ../../fs-boot/fs-boot.c ../../fs-boot/srec.c ../../fs-boot/time.c Headers: ../../fs-boot/fs-boot.h ../../fs-boot/srec.h ../../fs-boot/time.h d. Stel de compiler opties in als volgt (Dubbelklikken op Compiler Options) Environment: Application mode: executable Stack size: 1K Debug and Optimization: Optimization level: Size optimized Paths and Options: Other Compiler options to append: -Wall e. Stel het project in als standaardproject, en activeer 'Mark to initialize BRAM's'. Na het voltooien van deze instellingen is het basis hardwareproject volledig afgewerkt. No moet de compilatie van het volledige systeem echter nog gebeuren. De compilatie kan op zich in de EDK-omgeving gebeuren. Persoonlijk geef ik er echter de voorkeur aan dit in tekst modus als volgt te doen: 1. Het aanmaken van de makefile vanuit xps. De -nw optie betekent dat er
80
geen grafische omgeving opgestart wordt. xps -nw system.xmp save make exit 2. De bitstream maken voor het FPGA: make -f system.make bits 3. De bibliotheken genereren: make -f system.make libs 4. De programma's compileren (Hier enkel fs-boot) make -f system.make program 5. De gecompileerde code in de BRAM blokken in de FPGA-bitstream plaatsen make -f system.make init_bram Indien de download cable drivers geïnstalleerd zijn (Zie appendix A), kan nu heel eenvoudig de FPGA geprogrammeerd worden als volgt: make -f system.make download Tijdens de compilatie wordt heel wat uitvoer gecreëerd in de console. Om dit te vermijden, en toch error's te zien kan het volgende een grote hulp zijn make -f system.make bits libs program init_bram download 1>make.log Hierdoor worden de standaard logs (warnings, informatie, ...) opgeslagen in make.log, en worden de grote fouten (errors) weergegeven op de console.
C.3. Hardwaresoftware verbinding maken De eerste stap is het creëren van het nieuwe software platform, en wordt gedaan als volgt: Petalinux-new-platform -v VERKOPER -p PLATFORMNAAM Dit platform wordt nog niet als standaard platform ingesteld, wat vereist is voor de volgende stap. Het standaardplatform wordt als volgt ingesteld: cd $PETALINUX/software/petalinux-dist make menuconfig Nu moet de vendor en het product gekozen worden zoals in onderstaande figuur weergegeven wordt:
81
Figuur C.3: Selectie van de vendor en het product
Na het selecteren van de juiste vendor en product kan via tweemaal exit de configuratie opgeslagen worden. Hierna wordt een heel aantal taken uitgevoerd. Indien er enkele vragen gesteld worden, mogen de standaardantwoorden gebruikt worden door gewoon op de enter toets te drukken. Tenslotte moet nu nog het hardwareplatform aan het gekozen softwareplatform gekoppeld worden: cd $PETALINUX/hardware/user-platforms/PLATFORM Petalinux-copy-autoconfig Hierdoor wordt de auto-config.in file uit het hardware project gekopieerd naar de betreffende locatie in het software project. De auto-config.in file bevat een heel aantal hardware instelling die benodigd zijn tijdens de compilatie van uClinux. Indien het hardware platform op een Windows systeem zou gecompileerd worden, dan is het mogelijk om dit bestand te kopiëren naar uClinux. Er moet echter rekening mee gehouden worden dat het bestand in de Windows indeling opgeslagen is. Dit kan aangepast worden als volgt: dos2unix auto-config.in kopieer het bestand naar onderstaande lokatie en selecteer dan het microblazeauto platform. $PETALINUX/software/petalinux-dist/vendors/Petalogix/microblazeauto Meer informatie over de Windows gebaseerde hardware compilatie is te vinden in appendix A.5. 82
Appendix D:Makefiles Een voorbeeld van het ontwerp van een nieuwe Makefile zonder gebruik van configure is hieronder te vinden, gevolgd door een ontwerp met het gebruik van configure.
D.1. Zonder gebruik van configure (Journaline Makefile) # Point to default PetaLinux root directory ifndef ROOTDIR ROOTDIR=../../petalinux-dist endif UCLINUX_BUILD_USER = 1 -include $(ROOTDIR)/.config -include $(ROOTDIR)/$(CONFIG_LINUXDIR)/.config LIBCDIR = $(CONFIG_LIBCDIR) -include $(ROOTDIR)/config.arch ROMFSDIR=$(ROOTDIR)/romfs ROMFSINST=$(ROOTDIR)/tools/romfs-inst.sh PATH
+= $(ROOTDIR)/tools
APP = demo APP_OBJS_C = dabdgdec_impl.o crc_8_16.o log.o APP_OBJS_CXX = newssvcdec_impl.o NML.o Splitter.o newsobject.o demo.o # Add any other object files to this list below APP_OBJS = $(APP_OBJS_C) $(APP_OBJS_CXX) DEFINES = -DLINUX -DFHG_USEFLATDIRSTRUCT -I $(ROOTDIR)/lib/zlib all: $(APP) $(APP): $(APP_OBJS) #
$(CC) $(DEFINES) $(LDFLAGS) -o $@ $(APP_OBJS) $(LDLIBS)
$(CXX) $(CXX_LDFLAGS) -o $@ $(APP_OBJS) $(CXX_LDLIBS) $(ROOTDIR)/lib/zlib/libz.a
83
ar rcs libfhgjournaline.a NML.o Splitter.o newssvcdec_impl.o newsobject.o log.o dabdgdec_impl.o crc_8_16.o ln -s $(ROOTDIR)/user-apps/journaline/libfhgjournaline.a $(ROOTDIR)/petalinux-dist/lib # ln -s $(ROOTDIR)/user-apps/journaline/libfhgjournaline.a $(ROOTDIR)/petalinux-dist/lib clean: -rm -f $(APP) *.elf *.gdb *.o *.a romfs: $(ROMFSINST) $(APP) /bin/journaline_test $(ROMFSINST) -v -d ./data /data/journaline
%.o:
%.c $(CC) $(DEFINES) -c $(CFLAGS) -o $@ $<
%.o:
%.cpp $(CXX) $(DEFINES) -c $(CXX_FLAGS) -o $@ $<
# Targets for the required .config files - if they don't exist, the tree isn't # configured.
Tell the user this, how to fix it, and exit.
${ROOTDIR}/config.arch ${ROOTDIR}/.config: @echo "Error: You must configure the PetaLinux tree before compiling your application" @echo "" @echo "Change directory to ../../petalinux-dist and 'make menuconfig' or 'make xconfig'" @echo "" @echo "Once the tree is configured, return to this directory, and re-run make." @echo "" @exit -1
D.2. Met gebruik van configure (Dream Makefile) # Point to default PetaLinux root directory ifndef ROOTDIR ROOTDIR=../../petalinux-dist
84
endif UCLINUX_BUILD_USER = 1 -include $(ROOTDIR)/.config -include $(ROOTDIR)/$(CONFIG_LINUXDIR)/.config LIBCDIR = $(CONFIG_LIBCDIR) -include $(ROOTDIR)/config.arch ROMFSDIR=$(ROOTDIR)/romfs ROMFSINST=$(ROOTDIR)/tools/romfs-inst.sh PATH
+= $(ROOTDIR)/tools
BIBLIOTHEKEN="-L /home/lieven/petalinux/software/petalinux-dist/lib" #APP = dream # Add any other object files to this list below #APP_OBJS = dream.o LDLIBS+=-L/home/lieven/petalinux/software/petalinux-dist/lib Configure_options+= --without-qtgui Configure_options+= --disable-alsa Configure_options+= --enable-sound Configure_options+= --with-faad2 Configure_options+= --with-journaline Configure_options+= --without-hamlib Configure_options+= --without-freeimage #Configure_options+= --enable-simulation all: build $(MAKE) -C build build: Makefile rm -rf build mkdir build (cd build; CC="$(CC) $(CFLAGS) -I /home/lieven/petalinux/software/petalinux-dist/include" CXX="$(CXX) $(CXXFLAGS) -I/home/lieven/petalinux/software/petalinux-dist/include" LDFLAGS="$(LDFLAGS) -I/home/lieven/petalinux/software/petalinuxdist/include" CXX_LDFLAGS="$(CXX_LDFLAGS) -I /home/lieven/petalinux/software/petalinux-dist/include" LIBS="$(LDLIBS)" ../configure --host=$(CROSS_COMPILE:-=)
85
$(Configure_options) )
romfs: #
$(ROMFSINST) build/src/grep /bin/grep
#
$(ROMFSINST) -s /bin/grep /bin/egrep
#
$(ROMFSINST) -s /bin/grep /bin/fgrep
clean: rm -rf build
86
Bibliografie [1] European Telecommunication Standardisation Institute, ETSI ES 201 980 v2.1.1: Digital Radio Mondiale (DRM): System Specification, ETSI, (2004) [2] P. T. Wolkotte, G. J.M. Smit, L.T. Smit, Partitioning of a DRM Receiver, 9th International OFDM-Workshop, (2004), p2-5 http://doc.utwente.nl/49344/1/wolkotte_ofdm04.pdf [3] A. S. Tanenbaum, Gestructureerde computerarchitectuur tweede editie, Academic Service, (2001), p436-462 [4] D. McCullough, uClinux for Linux Programmers, Linux Journal, (2004-07), http://www.linuxjournal.com/article/7221 [5] The IEEE and The Open Group, The Open Group Base Specifications Issue 6: IEEE Std 1003.1, (2004) http://www.opengroup.org/onlinepubs/000095399/functions/fork.html
[6] The Open Group, The Single UNIX specification version 2, (1997), http://www.opengroup.org/onlinepubs/007908799/xsh/vfork.html [7] L. Tytgat, Ontwerp van een High-End klasse-D versterker, Hogeschool-West Vlaanderen dep. PIH-Kortrijk, (2004) [8]
Xilinx,
Microblaze
Core
Floating
Point
Unit
specification,
http://www.xilinx.com/ipcenter/processor_central/microblaze/microblaze_fpu.htm [9] L. Hanzo, M. Münster, B.J. Chol, T. Keller, OFDM and MC-CDMA for broadband Multi-User Communications, WLANs en Broadcasting, [10] Dream community, Pdf of the block diagram of the Dream software, http://drm.sourceforge.net/download/dreamsoftblock.pdf
87
[11] V. Fischer, A. Kurpiers, Frequency Synchronisation Strategy for a PC-based DRM
Receiver,
Darmstadt
University
of
Technology,
http://drm.sourceforge.net/papers/Frequency_Synchronization_Strategy_for_a_PCbased_DRM_Receiver.pdf [12] M. Speth and H. Meyr: Optimum Receiver Design for Wireless Broad-Band Systems Using OFDM – Part I. IEEE Trans. Commun. Vol. COM-47(11), p.16681677,(1999) [13] Dream community, Bit-Error-Rate (BER) simulations on all DRM channels, Algemene bronnen: Bron van DRM informatie met links naar alle relevante ETSI documenten: http://en.wikipedia.org/wiki/Digital_Radio_Mondiale [14] A.Kurpiers, V. Fischer, Open-Source implementation of a Digital Radio Mondial
(DRM)
Receiver,
Darmstadt
University
of
Technology,
(2003),
http://drm.sourceforge.net/papers/Talk_HFRadio2003.pdf [15]
International
Engineering
Consortium,
OFDM
for
Mobile
Data
Communications, http://www.iec.org/online/tutorials/ofdm/topic04.html [16] Prof. G. Poels, ICT project management hoofdstuk 3: project estimation, MIMKULEUVEN, (2004)
88
