Kwaliteitsbewaking Van Optische Netwerken Via Ingebedde Digitale Signaalverwerking in Ware Tijd

Faculteit Toegepaste Wetenschappen Vakgroep Informatietechnologie Voorzitter: Prof. Dr. Ir. P. LAGASSE

Kwaliteitsbewaking van optische netwerken via ingebedde digitale signaalverwerking in ware tijd

door

Pieter-Jan BUSSCHAERT Tom DEGRYSE

Promotor: Prof. Dr. Ir. J. VANDEWEGE Copromotor: Ir. B. DE MULDER Scriptiebegeleider: Ir. W. CHEN

Scriptie ingediend tot het behalen van de academische graad van burgerlijk ingenieur in de computerwetenschappen

Academiejaar 2005–2006 Voorwoord

Voor U ligt het resultaat van een jaar hard werken in het laboratorium Intec Design en van vijf jaar studie aan de Universiteit Gent. Tijdens dit jaar kregen we de kans om veel nieuwe kennis op te doen in verschillende domeinen binnen onze interessesfeer. We kunnen dan ook met plezier terugkijken naar de vele aangename momenten, die hebben geleid tot een resultaat waar we zelf tevreden over zijn. We willen hier ook van de gelegenheid gebruik maken om een aantal mensen te bedanken. Eerst en vooral bedanken we Prof. Dr. Ir. P. Lagasse en Prof. Dr. Ir. J. Vandewege voor het beschikbaar stellen van hun infrastructuur zodat deze thesis mogelijk werd. In het bijzonder wensen we onze promotor, Prof. Dr. Ir. J. Vandewege, te bedanken om ons de kans te geven dit onderwerp te bestuderen en uit te werken, alsook voor zijn steun en interesse gedurende het verloop van de thesis. Verder gaat er ook een speciaal woordje van dank uit naar onze copromotor, Ir. B. De Mulder, voor de vele uitleg in verband met de optische netwerken en de analoge elektronica, alsook voor het lezen en het verbeteren van de thesistekst. Daarnaast wensen we ook onze thesisbegeleider, Ir. W. Chen, van harte te bedanken voor de hulp bij het testplatform en bij de digitale elektronica. Verder bedanken we ook alle personen van Intec Design voor de hulp en de vele aangename momenten. Ook onze medestudenten, Frederick Bossuyt, Phillippe Poelaert en Stijn Vancoillie, mogen we zeker niet vergeten. Zij zorgden gedurende het volledige jaar voor een aangename sfeer in ons “thesiskot”. En tenslotte wensen we onze familie en vriendin nog te bedanken voor de jarenlange steun.

Pieter-Jan Busschaert & Tom Degryse, juni 2006 Toelating tot bruikleen

“De auteur geeft de toelating deze scriptie voor consultatie beschikbaar te stellen en delen van de scriptie te kopi¨eren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrek- king tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze scriptie.”

Pieter-Jan Busschaert & Tom Degryse, juni 2006 Kwaliteitsbewaking van optische netwerken via ingebedde digitale signaalverwerking in ware tijd door

Pieter-Jan BUSSCHAERT Tom DEGRYSE

Scriptie ingediend tot het behalen van de academische graad van burgerlijk ingenieur in de computerwetenschappen

Academiejaar 2005–2006

Promotor: Prof. Dr. Ir. J. VANDEWEGE Copromotor: Ir. B. DE MULDER Scriptiebegeleider : Ir. W. CHEN

Faculteit Toegepaste Wetenschappen Universiteit Gent

Vakgroep Informatietechnologie Voorzitter: Prof. Dr. Ir. P. LAGASSE

Samenvatting

Deze thesis is een onderdeel van een overkoepelend project waarin een systeem ontwikkeld wordt om de kwaliteit van een glasvezelverbinding te bewaken. Deze kwaliteitscontrole wordt ge¨ıntegreerd in de eindpunten van het glasvezelnetwerk aan de kant van de gebruiker. Dit betekent dat de kosten zo laag mogelijk moeten gehouden worden. Daarnaast moet de kwaliteitsbewaking gebeuren zonder dat de gebruiker hiervan iets merkt.

Deze thesis bestaat uit twee delen. In het eerste deel worden enkele nieuwe technologie¨en onderzocht die het systeem in de toekomst zouden kunnen verbeteren. In Hoofdstuk 3 wordt het gebruik van een microprocessor op de FPGA’s onderzocht. Hoofdstuk 4 bespreekt enkele alternatieven voor analoog-naar-digitaalconversie. Het tweede deel beschrijft de concrete verbeteringen aan het bestaande systeem. In Hoofdstuk 5 wordt de digitale hardware besproken. Als laatste komt in Hoofdstuk 6 de implementatie van de graﬁsche user interface aan bod.

Trefwoorden optische netwerken, OTDR, digitale signaalverwerking, user interface Optical network monitoring by real time embedded digital signal processing Pieter-Jan Busschaert & Tom Degryse Supervisor(s): Prof. Dr. Ir. J. Vandewege, Ir. B. De Mulder, Ir. W. Chen

Abstract— This article describes the digital signal processing designed In the access network, time-domain multiplexing (TDM) is to monitor the quality of an optical fiber. The first section explains the often used. In TDM networks, time slots are preserved for any technique used to monitor the fiber. The test setup is also described in the next section. In the third section some research topics are described. The transmitter, which sends information in bursts instead of con- next two sections give on overview of the improvements made to the original tinuously. These bursts are long enough to be used to measure system. Firstly, the changes to the digital hardware are discussed. Secondly, the negative step response. This results in a completely non- the implementation of a graphical user interface is presented. This article intrusive OTDR measurement, which assembles measurements ends with some concluding remarks. very quick because every transmitted data burst improves the Keywords—optical network, OTDR, digital signal processing, user interface knowledge of the channel link status. There is no need for a dedicated OTDR laser, which results in a low-cost system.

I.INTRODUCTION II.TESTSETUP HEN a pulse is transmitted through an optical fiber, an To implement the signal processing improvements, a test W echo is returned. This echo is caused by two differ- setup [2] at INTEC Design is used. The analogue front-end con- ent types of reflection. There are reflections caused by sudden tains, amongst others, a laser diode and a photo diode. The laser changes in the fiber, like fiber joins or breaks. The second part diode is used to transmit the excitation signal and both diodes of the echo is a weak backscattering signal caused by the inter- can receive the optical reflection. Both receivers are connected action of the light with particles that are much smaller than the to their own FPGA. The FPGAs process the signals in real time. wavelength of the light. This backscattering decays exponen- The result is transfered to the computer over an USB2.0 inter- tially over the length of the fiber. The echo can be used to locate face. The software on the pc stores this data in text files. Since the damaged parts in a fiber. This technique is called optical there is no graphical user interface (GUI), further processing and time-domain reflectometry (OTDR). displaying is done with Matlab. In a traditional OTDR system, the fiber is excited with a narrow light pulse. There is a trade-off when choosing the pulse width. A narrow pulse results in a measurement with a better spatial accuracy, but the reflected signal is weak and contains more noise. If the signal is too weak, the backscattering from the last part of the fiber might not be visible. When using a longer pulse, the signal is stronger, so the whole fiber can be Fig. 1. Test setup monitored. The disadvantage is the lower spatial resolution. If two events are close to each other, the second one will be ob- scured by the feedback of the first event. The test system has the ability to perform an interleaved mea- In [1] a new method to excite the fiber is described. Instead surement. If the OTDR instrument works in interleaved mode, a of using a narrow pulse, the fiber is excited for a very long time, measurement is made with and without the excitation pulse. The until the fiber is completely filled up with light. When the laser data samples resulting from the measurement without the light is switched off, the backscattered reflection is measured. This pulse are then subtracted from measured data samples after the results in the negative step response of the optical fiber, instead fiber is excited with a light pulse. This is used to suppress the of the pulse response. The pulse response can be derived from transient noise caused by the analogue electronics in the front- the negative step response for an arbitrary pulse width. end. This paper presents a way to embed this monitoring in the last-drop of the fiber access network. This puts several con- III.RESEARCH straints on the fiber monitoring system. Because the equipment In this section some new technologies are investigated that is not shared by a large number of customers, the system needs can improve the OTDR system in the future. Firstly, the use to be very cheap. The customer should not notice the presence of a microprocessor on the FPGA chips is considered. A pro- of this monitoring system at all. The measurement should run totype with the MicroBlaze processor integrated with the other in the background without user interaction. Monitoring the fiber VHDL code has been implemented. Although this prototype may not interfere with the data on the optical fiber. This is nec- has shown that the MicroBlaze is too slow to be used in the real essary to prevent the decrease of the network communication time measurement, it can be used for post-processing. The soft- speed. ware environment on the MicroBlaze allows faster development of the signal processing algorithms, because the C-language can one wants to extend the word length even further, the data words be used instead of VHDL. need to be split up in 8 parts. Secondly, some alternatives are examined for the expensive analog-to-digital converters (ADC). Most research has been V. GRAPHICAL USER INTERFACE done on the topic of multibit sigma-delta modulation. A sigma- The original software platform has two major parts. The first delta ADC uses an ADC with a lower resolution. By using over- part is a FX2 driver for Linux. This driver has to be loaded into sampling techniques, the resolution can be increased by digital the Linux kernel and can be used by other programs to commu- filtering. Due to the large bandwidth of OTDR signals, the max- nicate with the hardware platform over USB. The second part imum oversampling rate is limited and a relatively high resolu- is a collection of command line programs. These are used by tion ADC has to be used. As a result, this setup is not much the user to program the FPGA, to receive data, to configure the cheaper than a regular ADC. FPGA, etc. The measurement results are processed by hand in Matlab. The primary goal of the new user interface is to inte- IV. DIGITAL ELECTRONICS grate all this functionality in one graphical application. The starting point for this task is an existing implementation The GUI is written in Java, because Java is well suited for of the digital hardware. With this implementation it is possible this task. The communication with the hardware platform has to perform an OTDR measurement on both the laser diode and to be done through the FX2 driver, which can most easily be ac- the photo diode simultaneously. Only limited configuration is cessed from within C-code. Those C-programs are called from possible through the I2C-interface. The parameters of the dig- within the Java code and store their results in a text file. The user ital electronics in the FPGAs (e.g. pulse width) are fixed. Ev- interface reads these text files and further processes the data. ery time the user wants to change the settings, the VHDL code Due to this new user interface, there is less user interaction needs to be modified and re-synthesized. This section explains necessary. Clicking one button starts a chain of events that pro- the changes needed to make the digital hardware dynamically grams the FPGA, sends all the parameters for the measurement configurable. and then continuously starts measurements. After every mea- Firstly, an interface to send the parameters from the back-end surement, the results are read and the graphs on the display are computer to the FPGAs is needed. There is a serial link between updated. The results are displayed in two graphs for each chan- the computer and FPGA 1 which can be used to transfer the nel. One of these shows the latest results returned by the hard- parameters (see Fig. 1). On FPGA 1 a shift register is needed to ware, while the other graph displays an average of the last x re- transform this serial input into a parallel data word. To be able sults. This extra average is calculated by using a moving average to identify the different parameters, each parameter is preceded filter to reduce the necessary memory and to prevent overflow. by an additional control byte. As described in the introduction, the results are obtained by The parameters are now available on FPGA 1, but a mech- measuring the negative step response. The user can switch the anism is still needed to transfer them to FPGA 2. There is a view to the impulse response with a chosen pulse width. Ex- direct data path of 16 bits wide between the two FPGAs. Two perimenting with different pulse widths is very easy this way of these wires are used to transfer control signals from FPGA 1 because measurements don’t have to be repeated to test differ- to FPGA 2, while the other 14 bits are used to transfer the data ent widths. samples in the other direction. Because the parameters and the OTDR measurements typically result in exponentially de- data samples need to be transfered in the opposite direction, the creasing graphs. It is easier to detect irregularities on a linear data connection between the two FPGAs is used as a bidirec- graph than it is on an exponential graph. The user can choose to tional bus. The data direction is indicated by the state of the two switch the Y-scale of the graphs from a linear scale to a logarith- control bits, which are set by FPGA 1 only. mic scale. With a logarithmic scale, the exponentially decreas- ing signal will be displayed as a linear graph.

VI.CONCLUSIONS Three key improvements have been applied to the original monitoring system. Firstly, due to the dynamic conﬁguration of the two FPGAs, the properties of the measurement can be Fig. 2. Data bus between the FPGAs changed at run time. Secondly, a higher resolution can be obtained for the measurements. The third key improvement is the The last requested feature is the extension of the word length graphical user interface. The user interface integrates the func- in the memory of the FPGA from 28 to 32 bits. If enough tionality of the command line programs and displays the results averages are made, this results in a higher resolution measure- on a graph. ment. In the original implementation, a data sample is send from FPGA 2 to FPGA 1 in 2 clock cycles. To transfer 32 data bits, REFERENCES a data word is split up in 4 times 8 bits. The speed of the data [1] B. De Mulder, Non-Intrusive Performance Monitoring of TDM Optical Networks, submitted to Journal Of Lightwave Technology, April 2006. transfer is halved, because 4 clock cycles are now needed to send [2] W. Chen, An experimental set-up for the feasibility study of embedded op- out one data sample. Because only 8 of the 14 bits from the data tical ﬁber monitoring, published in the Proceedings of the 10th Annual bus are used, there are still 6 bits available. These additional bits Symposium of the IEEE/LEOS Benelux Chapter 2005, ISBN 2-9600226- 4-5, 1-2 December 2005, Mons , Belgium , pp. 173-176. can be used to further extend the word length up to 56 bits. If INHOUDSOPGAVE i

Inhoudsopgave

1 Inleiding 1 1.1 Situering ...... 1 1.2 Onderwerp van deze thesis ...... 2 1.3 Planning ...... 3

2 Optical time-domain reﬂectometry 4 2.1 Backscattering ...... 4 2.2 OTDR ...... 5 2.3 Non-intrusive OTDR ...... 8

I Onderzoek 9

3 MicroBlaze 10 3.1 Inleiding ...... 10 3.2 Implementatie en simulatie ...... 15 3.2.1 Implementatie ...... 15 3.2.2 Simulatie ...... 18 3.3 Communicatie ...... 19 3.3.1 General Purpose IO ...... 20 3.3.2 Gedeeld geheugen ...... 21 3.4 Besluit ...... 22

4 Sigma-Delta ADC 23 4.1 Omzetting van analoge signalen naar digitale signalen ...... 23 4.2 Binair zoeken ...... 24 INHOUDSOPGAVE ii

4.2.1 Pulse Code Modulation ...... 25 4.2.2 Externe DAC ...... 25 4.3 Sigma-Delta theorie ...... 26 4.3.1 Delta modulatie ...... 26 4.3.2 Sigma-Delta modulatie ...... 27 4.3.3 Multibit sigma-delta modulatie ...... 33 4.3.4 Decimatie ...... 35 4.4 Sigma-Delta simulatie ...... 38 4.4.1 Constante ingang ...... 38 4.4.2 Sinusgolf ...... 39 4.4.3 OTDR ...... 39 4.5 Andere ADC ...... 44

II Implementatie 45

5 Digitale hardware 46 5.1 Hardwareplatform ...... 47 5.1.1 Hardware ...... 47 5.1.2 Analoge front-end ...... 49 5.1.3 Originele FPGA-code ...... 50 5.2 Digitaal laagdoorlaatﬁlter ...... 53 5.3 Dynamische conﬁguratie van de FPGA’s ...... 58 5.4 Selectie van het meetkanaal ...... 63 5.5 Verlengen van de woordbreedte ...... 66

6 User interface 69 6.1 Software platform ...... 69 6.2 Gebruikte technologie ...... 70 6.2.1 Programmeertaal ...... 70 6.2.2 Externe bibliotheek : JChart2D ...... 71 6.3 Functionaliteit ...... 73 6.4 Implementatie ...... 80 6.4.1 Moving average ﬁlter ...... 80 INHOUDSOPGAVE iii

6.4.2 XML ...... 81 6.4.3 JOtdrPanel ...... 84 6.4.4 OtdrAction ...... 85

7 Besluit 89 INLEIDING 1

Hoofdstuk 1

Inleiding

1.1 Situering

Deze thesis kadert in een reeks projecten aan de vakgroep waarbij men glasvezelnetwerken dichter bij de gebruiker thuis wil brengen. Omdat er steeds meer en meer bandbreedte nodig is, gaat men op zoek naar snellere netwerktechnologie¨en. Glasvezelnetwerken worden nu al gebruikt in de backbone-netwerken van de operatoren, maar kunnen ook gebruikt worden dichterbij de eindgebruiker. Om dit te kunnen realiseren maakt men gebruik van passieve optische netwerken of PON’s. Bij PON’s worden er geen actieve componenten gebruikt, waardoor de kostprijs laag blijft. Wil men glasvezelnetwerken dichter bij de eindgebruiker brengen, dan mag de kostprijs ervan niet te hoog oplopen. Dit is vooral belangrijk aan de kant van de eindgebruiker, waar de kosten niet over een groot aantal klanten kunnen gespreid worden. Bij dergelijke PON’s maakt men gebruik van time division multiplexing, waarbij elke gebruiker een tijdsslot heeft waarin hij data mag versturen.

In het project waar deze thesis onder valt, gaat men op zoek naar een manier om een kwaliteitscontrole van de glasvezelverbinding zelf aan het netwerk toe te voegen. Door het toevoegen van foutdetecterende of foutcorrigerende codes kan men de verbinding op de verschillende lagen van de protocolstack gaan controleren. Het bewaken van de kwaliteit van de verbinding op de fysische laag wordt veel minder toegepast, omdat dit vaak veel moeilijker te implementeren is, zoals bij het gebruik van koperverbindingen. 1.2 Onderwerp van deze thesis 2

Het feit dat de meetopstelling dicht bij de gebruiker geplaatst wordt heeft enkele belangrijke gevolgen. De kosten van de apparatuur worden slechts over een klein aantal eindgebruikers gedeeld. Dit vormt meteen een belangrijke randvoorwaarde voor het kwaliteitsbewakingssysteem: de kostprijs moet zo laag mogelijk blijven. Er bestaan al commerci¨ele toestellen die de kwaliteit van een glasvezelverbinding gaan opmeten, maar deze toestellen zijn duur, waardoor ze ongeschikt zijn om gebruikt te worden dicht bij de eindgebruiker. Verder is het wenselijk dat het systeem de kwaliteitsbewaking kan uitvoeren zonder tussenkomst van de gebruikers zelf en zonder dat het dataverkeer over de verbinding verstoord wordt.

Deze thesis bouwt verder op het werk dat reeds aan de vakgroep verricht werd. De opdracht van deze thesis bestaat erin het bestaande hardwareplatform verder uit te breiden. Hiervoor is er een nauwe samenwerking met de thesisbegeleiders ir. B. De Mulder en ir. W. Chen nodig, omdat zij eveneens bezig zijn met het verder ontwikkelen van de hardware.

1.2 Onderwerp van deze thesis

In Hoofdstuk 2 wordt de techniek besproken die gebruikt wordt om de kwaliteit van de glasvezel te observeren. Wanneer je een lichtpuls doorheen een glasvezel stuurt, komen er een gedurende een eindige periode reflecties terug. Deze worden niet alleen veroorzaakt door plotse overgangen, zoals een las of een barst, maar zijn ook het gevolg van de Rayleigh backscattering. De meeste systemen maken gebruik van de optical time-domain reflectometry, waarbij dit gereflecteerde signaal wordt opgemeten om de verzwakking doorheen de volledige glasvezel op te meten. In dit hoofdstuk komt er ook een nieuwe techniek aan bod die toelaat om metingen uit te voeren die niet interfereren met data die over de glasvezel wordt verstuurd.

De opdracht van deze thesis bestaat uit twee grote delen. In het eerste deel worden enkele nieuwe technologie¨en onderzocht die het kwaliteitsbewakingssysteem in de toekomst zouden kunnen verbeteren. In Hoofdstuk 3 wordt de haalbaarheid van een microprocessor op de FPGA onderzocht. In dit hoofdstuk wordt de MicroBlaze meer in detail besproken. De microprocessor kan gebruikt worden om complexe controlestructuren uit te voeren in software, terwijl de hardware veelvoorkomende functies snel kan uitvoeren. Daarnaast kan de microprocessor gebruikt worden om meer complexe signaalverwerking op de chips te implementeren. 1.3 Planning 3

Enkele alternatieven voor de dure analoog-naar-digitaalconvertors (ADC) worden onderzocht in Hoofdstuk 4. Voor deze toepassing is een nauwkeurige ADC nodig, maar ADC’s met een hoge resolutie kosten veel geld. Bij de Sigma-Delta ADC wordt er een afweging gemaakt tussen de resolutie en de bandbreedte. Door een deel van de bandbreedte op te oﬀeren kan men een hogere resolutie verkrijgen.

Het tweede deel gaat over de eigenlijke implementatie van het systeem. In Hoofdstuk 5 wordt de implementatie van de digitale hardware uitgewerkt. Voor deze opdracht moest de bestaande VHDL-code uitgebreid worden. Zo moeten de FPGA’s dynamisch kunnen geconﬁgureerd worden vanuit de software op de computer, zonder het herprogrammeren van de chips. Daarnaast moet het ook mogelijk zijn om op twee kanalen tegelijk te meten.

Naast de digitale elektronica moet er ook een grafische gebruikersomgeving ontwikkeld worden. Via deze gebruikersinterface kan de gebruiker het volledige systeem aansturen en configureren. Dit dient als vervanging van een aantal programma’s die via de command line opgeroepen worden. Daarnaast zorgt de grafische gebruikersinterface ervoor dat de data wordt visueel voorgesteld in een grafiek. Hoofdstuk 6 gaat dieper in op de implementatie van deze grafische gebruikersomgeving.

1.3 Planning

Tijdens het eerste semester werd er vooral tijd besteed aan het bestuderen van het reeds bestaande systeem en aan het onderzoek naar de MicroBlaze en de sigma-delta analoog-naar- digitaalconvertor. De vooruitgang van het onderzoek werd meegedeeld door het schrijven van rapporten, die dan door de thesisbegeleiders besproken werden om het onderzoek eventueel bij te sturen.

De implementatie van de digitale elektronica en de graﬁsche gebruikersinterface vond plaats tijdens het tweede semester. De ontwikkeling ervan gebeurde in nauwe samenwerking met thesisbegeleider ir. Wei Chen. Hier was het belangrijk om voortdurend met elkaar in contact te staan om ontwerpsbeslissingen of eventuele problemen zo vlug mogelijk mee te delen. Om de co¨ordinatie vlot te laten verlopen en om de deadline van tien mei te halen, werd er vooraf een planning opgesteld voor de implementatie en de integratie van de verschillende onderdelen. OPTICAL TIME-DOMAIN REFLECTOMETRY 4

Hoofdstuk 2

Optical time-domain reﬂectometry

Wanneer er licht door een glasvezel wordt verstuurd, treedt er verlies op in de glasvezel. Het optisch vermogen van het uitgezonden signaal verzwakt over de volledige lengte van de vezel. Deze verzwakking is afhankelijk van de propagatieafstand binnen de glasvezel. Een van de oorzaken van dit vermogenverlies is de backscattering in de glasvezel. Sectie 2.1 geeft een overzicht van het ontstaan en de eigenschappen van de backscattering. Vervolgens gaat Sectie 2.2 verder met een bespreking van een veelgebruikte techniek om de verliezen in een glasvezel op te meten. Deze techniek, optical time-domain reﬂectometry of kortweg OTDR, maakt gebruik van het principe van de backscattering om de kwaliteitscontrole van de glasvezelverbinding uit te voeren. In Sectie 2.3 wordt een alternatieve manier besproken om een OTDR-meting uit te voeren. Deze nieuwe techniek laat het toe om metingen uit te voeren die niet interfereren met het dataverkeer over de glasvezel.

2.1 Backscattering

Het grootste deel (ongeveer 96%) van het verlies in een glasvezel wordt veroorzaakt door Rayleigh scattering. Dit effect treedt op als de lichtgolf interageert met imperfecties die veel kleiner zijn dan de golflengte van het uitgestuurde licht. Door de elastische botsing met deze imperfecties binnen de glasvezel wordt het licht verzwakt in de propagatierichting van de golf en wordt er licht in de andere richtingen uitgestuurd. De mate waarin er backscatteringverlies optreedt is afhankelijk van de grootte van de imperfecties in de glasvezel en van de golflengte van het 2.2 OTDR 5 uitgestuurde licht. De intensiteit van het licht dat door scattering uitgestuurd wordt is evenredig met 1/λ4. Het verlies in de glasvezel is het kleinst bij een golflengte van ongeveer 1550 nm, omdat de verliezen bij grotere golflengtes gedomineerd worden door de absorptie. Deze absorptie wordt veroorzaakt door de moleculen van het materiaal waaruit de glasvezel is gemaakt. Figuur 2.1 [1] schetst het verloop van het optisch vermogenverlies in een glasvezel in functie van de golflengte.

Figuur 2.1: Scatteringsverlies in de glasvezel

2.2 OTDR

Bij optical time-domain reflectometry (OTDR) maakt men gebruik van dit gereflecteerde licht om de glasvezel op te meten. Dit heeft als voordelen dat men de glasvezelkabel niet moet beschadigen en dat éénuiteinde van de glasvezel voldoende is om een meting uit te voeren.

Figuur 2.2: Standaard OTDR-opstelling

In een klassiek OTDR-systeem, zoals voorgesteld in Figuur 2.2 [2], zendt men een lichtpuls door de glasvezel. De ontvanger is optisch ge¨ısoleerd van de zender, waardoor de ontvanger niet in 2.2 OTDR 6 saturatie kan gaan wanneer de laserdiode een lichtpuls uitstuurt. Als de diode in saturatie is, duurt het te lang vooraleer de diode terug normaal werkt. Hierdoor zouden een deel van de gegevens verloren gaan. In een ideale glasvezel, zonder verlies, is de Rayleigh backscattering constant over de volledige lengte van de verbinding. De opgemeten reﬂectie is dus constant over de tijd wanneer de puls doorheen de glasvezel voortbeweegt. Bij het gebruik van glasvezels waarbij het verlies constant is over de volledige lengte van de glasvezel, daalt de opgemeten backscattering exponentieel. In een logaritmische schaal komt dit overeen met een dalende rechte.

Bij het opmeten van een glasvezelnetwerk ziet men naast de dalende rechte ook nog verschillende gebeurtenissen op de graﬁek. Figuur 2.3 [3] toont een voorbeeld van een dergelijke meting. Op de graﬁek zijn er twee grote pieken te zien in het ontvangen signaal. Deze pieken komen overeen met het begin en het einde van de glasvezelverbinding. Na de piek die overeenkomt met het einde van de glasvezel zakt de curve naar het ruisniveau.

Figuur 2.3: Standaard OTDR-opstelling

Tussen het begin en het einde van het glasvezelnetwerk treden er nog verschillende gebeurtenissen op. Deze gebeurtenissen kunnen opgedeeld worden in twee categorieën: de reflectieve en de niet- reflectieve gebeurtenissen. Bij de niet-reflectieve gebeurtenissen treedt er een plotse verandering op in het backscatteringssignaal, maar is er verder geen bijkomende reflectie. In Figuur 2.3 zijn er twee niet-reflectieve gebeurtenissen te zien, namelijk het tweede en het vierde event. Dergelijke gebeurtenissen kunnen veroorzaakt worden door een bocht in de glasvezel of door het samensmelten van twee verbindingen met verschillende eigenschappen. Het verlies wordt vooral bepaald door de veranderde eigenschappen van de glasvezel en heeft geen echte fysische oorzaak. In de voorbeelden van Figuur 2.3 gaat het telkens om een verzwakking van het signaal. Het is ook 2.2 OTDR 7 mogelijk dat er een verhoging van de OTDR-curve optreedt als de tweede glasvezel een hogere scatterconstante heeft. Bij de derde gebeurtenis in Figuur 2.3 is wel reflectie aanwezig. Een deel van het uitgezonden licht wordt rechtstreeks gereflecteerd op de plaats waar er bijvoorbeeld een barst of een mechanische connector aanwezig is. Als twee glasvezels met een mechanische connector worden verbonden is er mogelijk een smalle luchtspleet aanwezig waar de reflecties optreden. De hoogte van de reflecteerde piek hangt af van de zuiverheid van het contact en van de afstand tussen de uiteinden van de twee vezels. Bij een volledige breuk van de glasvezel treedt er geen reflectie op aan het einde. De curve valt gewoon terug tot het ruisniveau, zodat een glasvezelbreuk in tegenstelling tot een barst, een niet-reflectieve gebeurtenis is.

De spatiale nauwkeurigheid van deze methode hangt af van de breedte van de puls. Hoe smaller de uitgezonden puls, hoe nauwkeuriger men de positie van eventuele fouten in de glasvezel kan bepalen. Een smalle puls heeft echter als nadeel dat het uitgezonden vermogen lager ligt dan bij een bredere puls. Indien de lichtpuls te smal is, is het gereflecteerde signaal te zwak om door de ontvanger gedetecteerd te worden. Als de uitgezonden puls te lang is, kunnen dichtbijgelegen fouten in de glasvezel niet gedetecteerd worden. Dit effect wordt grafisch voorgesteld in Figuur 2.4.

(a) Korte puls (b) Lange puls

Figuur 2.4: Eﬀect van de pulsbreedte 2.3 Non-intrusive OTDR 8

2.3 Non-intrusive OTDR

De huidige OTDR-instrumenten zenden een puls uit en meten het gereﬂecteerde licht op. De OTDR-instrumenten worden gebruikt voor het controleren van de grote glasvezelverbinding. In een typische architectuur wordt het dure OTDR-toestel gedeeld tussen verschillende verbindingen via optische schakelaars. De klassieke manier van meten heeft als nadeel dat men de meting moet uitvoeren wanneer er geen data verstuurd wordt. Omdat er gedurende de meting geen verkeer toegelaten is, verlaagt de controle van de glasvezel de maximale communicatiesnelheid van het netwerk. Omdat dit niet gewenst is, gaat men op zoek naar andere technieken die niet interfereren met het dataverkeer over de glasvezel.

Een mogelijke oplossing is het gebruik van wavelength division multiplexing (WDM), waarbij men een lichtpuls met een andere frequentie doorheen de glasvezel stuurt. Bij deze methode moeten de zender, de ontvanger en het optisch systeem aangepast worden zodat ze de signalen met een verschillende frequentie kunnen scheiden. Dit zorgt er echter voor dat de ingebedde OTDR-module veel duurder wordt, wat onaanvaardbaar is voor het gebruik binnen een optical networking unit (ONU) [4]. Een ONU zorgt voor de overgang tussen een glasvezelnetwerk en het toegangsnetwerk van de gebruiker (bijvoorbeeld VDSL over een koperverbinding). Door het feit dat men een andere golﬂengte gebruikt, is een WDM-systeem niet zo nauwkeurig.

In een netwerk met multiplexering in het tijdsdomein (TDM) krijgt iedere zender een aantal tijdsslots waarin er data mag verzonden worden. Iedere zender zendt dus uit in bursts in plaats van een continu signaal te versturen. Net als bij het uitsturen van een puls treden er reflecties op. Deze reflecties kunnen na het beëindigen van een burst opgemeten worden. Omdat er geen afzonderlijke laser nodig is voor de OTDR-meting en de kosten dus laag zijn, is deze techniek uitermate geschikt voor een ingebedde OTDR-applicatie.

Een probleem bij het gebruik van deze methode is het feit dat de lengte van de bursts niet kan ingesteld worden. Om elke burstreﬂectie op een zelfde manier te kunnen verwerken worden de opgemeten reﬂecties omgezet naar het negatief stapantwoord [2]. Uit het negatieve stapantwoord kan het pulsantwoord bepaald worden door een vertraagde versie r(t-W) van het negatief stapantwoord r(t) af te trekken. Op die manier kan men uit het negatief stapantwoord het antwoord op een puls met willekeurige lengte W bepalen. 9

Deel I

Onderzoek MICROBLAZE 10

Hoofdstuk 3

MicroBlaze

In dit hoofdstuk wordt het gebruik van een microprocessor op een FPGA-chip besproken. Het is de bedoeling om een deel van de post-processing van de meetresultaten op de FPGA te doen met behulp van deze microprocessor. Met behulp van de microprocessor kunnen meer geavan- ceerde signaalverwerkingsalgoritmes sneller in software ge¨ımplementeerd worden. De inleiding in Sectie 3.1 geeft eerst een algemeen overzicht van het gebruik van een microprocessor op een FPGA, waarna er dieper wordt ingegaan op de toepassing van MicroBlaze microprocessor in het volledige systeem. Sectie 3.2 gaat vervolgens verder met een bespreking van de procedures om de MicroBlaze te implementeren op de chip en het volledige systeem te simuleren met behulp van Modelsim. Daarna gaat Sectie 3.3 verder met het bespreken van verschillende mogelijkheden om te communiceren tussen de MicroBlaze en de rest van de FPGA. Dit hoofdstuk wordt afgesloten met enkele conclusies over het gebruik van een microprocessor binnen het volledige OTDR-systeem.

3.1 Inleiding

Een algoritme in software wordt sequentieel in de tijd uitgevoerd: alle berekeningen worden na elkaar op dezelfde rekeneenheid uitgevoerd. Deze rekeneenheid is dezelfde voor alle berekeningen: de instructie bepaalt de functie van de rekeneenheid. Hierdoor is een softwareoplossing enorm flexibel. Bij een hardwareoplossing gaat men de berekening versnellen door parallellisme in te voeren. Op elk ogenblik zijn er verschillende rekeneenheden aan het werk. Deze eenhe- 3.1 Inleiding 11 den kunnen enkel één bepaalde functie uitvoeren, maar zijn wel sterk geoptimaliseerd voor het berekenen van deze functie. Het gebruik van een microprocessor op een FPGA laat toe om de voordelen van zowel (configureerbare) hardware als software te combineren binnen hetzelfde systeem. De software op de microprocessor zorgt ervoor dat het systeem flexibel is, terwijl de configureerbare hardware op de FPGA kan gebruikt worden om veel uitgevoerde functies in hardware te versnellen.

Er bestaan twee types processoren die op een FPGA kunnen ge¨ımplementeerd worden: de hard core en de soft core microprocessors. Bij een hard core microprocessor, zoals de PowerPC, is de processorhardware vast op de chip aanwezig. Omdat de PowerPC processorkern op de chip moet aanwezig zijn, kan deze processor niet op elke FPGA gebruikt worden. Bij de FPGA’s van Xilinx is de PowerPC enkel beschikbaar bij de Virtex II Pro en de Virtex IV FX reeksen. Op de Virtex II FPGA’s die op het hardwareplatform aanwezig zijn, kan er dus geen gebruik gemaakt worden van de PowerPC. In tegenstelling tot bij de hard core microprocessors is er bij een soft core processor geen extra hardware nodig. De processor bestaat uit gewone VHDL-code, die ge¨ımplementeerd wordt door het programmeren van de configureerbare logica op de FPGA. Het voordeel van een soft core microprocessor ten opzichte van de hard core variant is het feit dat een soft core microprocessor volledig configureerbaar is. De hardware kan aangepast worden aan de noden van de gebruiker. Als er bijvoorbeeld geen floating point bewerkingen nodig zijn, is het ook niet nodig om de floating point unit te integreren in de processor. Omdat hard core processors specifieke hardware hebben, zijn ze doorgaans sneller dan de soft core varianten. De MicroBlaze en de PicoBlaze zijn twee soft core microprocessors die door Xilinx aangeboden worden. De PicoBlaze is een eenvoudige acht bit microcontroller, die dus niet echt krachtig genoeg is voor deze toepassing. De PicoBlaze heeft wel als voordeel dat hij gratis ter beschiking gesteld wordt door Xilinx. Om de MicroBlaze te kunnen gebruiken, moet men de Embedded Development Kit (EDK) van Xilinx aankopen. Omdat de PowerPC kern niet aanwezig is bij de Virtex II en omdat de PicoBlaze niet krachtig genoeg is, wordt er verderop in dit hoofdstuk enkel aandacht besteed aan de MicroBlaze.

De MicroBlaze is een 32-bit RISC-processor met een Harvard-architectuur [5]. Een Reduced Instruction Set Computer, kortweg RISC, maakt gebruik van een kleine instructieset bestaande uit eenvoudige instructies. Dit is in tegenstelling tot de Complex Instruction Set Computer of CISC-architectuur, waar de instructieset wordt uitgebreid met een groot aantal complexe in- 3.1 Inleiding 12 structies. Een RISC-processor kan sterk geoptimaliseerd worden voor het gebruik van deze kleine instructieset, waardoor de gebruikte oppervlakte daalt. De RISC-architectuur is dus uitermate geschikt voor de implementatie van een ingebedde processor. Omdat er geen complexe instructies zijn, is het controlegedeeltde en het datapad van de microprocessor eenvoudiger dan bij een CISC-processor. Hierdoor kan de klokfrequentie opgedreven worden. Om een complexe instructie uit een CISC-instructieset uit te voeren, zijn er verschillende RISC-intructies nodig. Omdat de eenvoudige RISC-instructies sneller uitgevoerd worden dan de complexe CISC-instructie, leidt dit niet noodzakelijk tot een langere uitvoeringstijd. Bij een processor met een Harvard- architectuur wordt het geheugen voor de data en de instructies gescheiden van elkaar. Beide geheugens maken dus gebruik van een afzonderlijk deel van de adresruimte. Bij de configuratie van de microprocessor in de EDK kan men de grootte van het instructie- en het datageheugen instellen. Figuur 3.1 toont een schematische voorstelling van de processorarchitectuur [6]. De pijplijn van de Microblaze bevat drie trappen: Fetch, Decode en Execute. Bij de meeste instructies duurt elke trap éénklokcyclus. Per instructie zijn er dus drie klokcycli nodig, maar omdat er per klokcyclus een nieuwe instructie ingelezen wordt, kan er toch iedere klokcyclus een instructie uitgevoerd worden. De uitvoeringstrap van bepaalde instructies zoals een deling kan echter meerdere klokcycli in beslag nemen. De maximale klokfrequentie van de MicroBlaze microprocessor hangt af van de gebruikte FPGA’s en van de configuratie van de MicroBlaze zelf. Indien de MicroBlaze verschillende uitvoeringseenheden bevat, daalt de maximale kloksnelheid. Op een Virtex II FPGA is de maximale klokfrequentie groter dan 100 MHz.

Om de kunnen communiceren met de rest van de FPGA en het geheugen zijn er verschillende bussen aanwezig bij de MicroBlaze. De Local Memory Bus (LMB) dient als verbinding tussen de processor en het intern geheugen van de MicroBlaze. Met behulp van de On-Chip Peripheral Bus (OPB) kan de MicroBlaze communiceren met extra componenten op de FPGA-chip. Een voorbeeld van zo’n dergelijke component is een geheugen dat gedeeld wordt tussen de MicroBlaze en de rest van de FPGA. De Xilix CacheLink (XCL) bus dient als verbinding met de eventuele caches. Omdat het systeem dat we willen bouwen in real time moet kunnen werken en omdat caches leiden tot een niet-deterministisch gedrag van het programma, is het gebruik van caches niet toegestaan. De laatste bus is de Fast Simplex Link (FSL). Via deze verbinding worden de hardwareversnellers verbonden met de uitvoeringseenheid van de MicroBlaze microprocessor. Figuur 3.2 toont een voorbeeld van het versnellen van een functie fx via de FSL-bus. Naast alle verschillende bussen heeft de MicroBlaze ook nog voorzieningen om te communiceren met 3.1 Inleiding 13

Figuur 3.1: MicroBlaze architectuur

de buitenwereld. De General Purpose IO-pinnen (GPIO), die rechtstreeks een pin van de chip kunnen aanspreken, zijn hier een voorbeeld van.

Figuur 3.2: Hardwareversnelling met Fast Simplex Link

Normaal gezien wordt de MicroBlaze ge¨ımplementeerd als de top-level module in de hardwa- rehiërarchie. In een dergelijke architectuur stuurt de MicroBlaze de io-pinnen aan en dient de VHDL-code om de uitvoeringstijd te verkorten door de implementatie van hardwareversnellers. Deze architectuur is echter minder geschikt om toe te passen in het systeem voor de kwaliteitsbewaking van optische netwerken. Hiervoor zijn er verschillende redenen. Ten eerste is de aard 3.1 Inleiding 14 van de toepassing meer geschikt voor een hardware-implementatie, omdat de kwaliteitsbewaking een datagedreven toepassing is. Het controleverloop van de toepassing is eenvoudig en is voor alle uitvoeringen gelijk. Zowel de aansturing van de front-end als het inlezen van de data gebeurt volgens een vast patroon, zonder dat er bijkomende controlesignalen nodig zijn. Om- dat de signalen voor het aansturen van de front-end tot op een klokcyclus nauwkeurig moeten gecontroleerd worden, moet dit sowieso via de hardware aangestuurd worden. Ten tweede is de communicatie met de buitenwereld nogal complex. Zoals in Hoofdstuk 5 wordt uitgelegd, is er communicatie met de computer via een USB-verbinding en een seriële verbinding en is er communicatiekanaal met een eigen protocol tussen de twee FPGA’s. Deze communicatie kan ook niet in de software gebeuren, omdat de software te traag is om de data in real time in te lezen en te verwerken, zoals gebeurt in de VHDL-code. De oplossing hiervoor is het gebruik van zelf-gedefinieerde IO-blokken, die dan instaan voor de communicatie met de rest van de FPGA en de buitenwereld. Deze IO-interfaces kunnen dan gebruik maken van de snelle FSL-bus. Om- dat de toepassing datagedreven is, en ze dus minder interessant is voor een implementatie in software, loont het niet de moeite om deze blokken te implementeren. Naast deze twee grootste bezwaren is er nog een kleiner praktisch probleem. Op het bordje wordt er gebruik gemaakt van een differentiële klok, terwijl de MicroBlaze werkt met normale enkelvoudige ingangssignalen. Om dit op te lossen voeg ik een buffer toe die een differentieel signaal omvormt naar een single-ended signaal [7]. Door een bug in de EDK die gebruikt wordt (versie 7.1i), lukt dit wel voor gewone ingangssignalen, maar niet voor het kloksignaal. In de nieuwe versie van de EDK (versie 8.1i) zou dit probleem moeten opgelost zijn.

De MicroBlaze wordt dus gebruikt als een gewone VHDL-component, die aangestuurd wordt vanuit de hoofdmodule in VHDL. In een eerste fase leest de hardware de data in real time in. Het inlezen van de data moet in real time gebeuren, want anders zouden er monsterwaarden verloren gaan. Hiervoor is er dus een implementatie in hardware vereist. De meetgegevens worden tijde- lijk opgeslaan in een geheugen op de FPGA. Nadat de metingen voltooid zijn en de hardware de data heeft ingelezen in het geheugen, kan de MicroBlaze dan beginnen met het uitvoeren van de post-processing van de meetgegevens. Op dat moment is het niet langer nodig dat de data in real time verwerkt worden, zodat de tragere verwerkingstijd van de microprocessor geen enkel probleem vormt. Om de post-processing te versnellen kunnen er wel hardwareversnellers toegevoegd worden. In Sectie 3.3 wordt er dieper ingegaan op enkele mogelijke communicatievormen tussen de MicroBlaze en de rest van de VHDL-code. 3.2 Implementatie en simulatie 15

3.2 Implementatie en simulatie

Dit deel gaat dieper in op de implementatie en simulatie van de MicroBlaze microprocessor. Hiervoor wordt er grotendeels de procedure die besproken wordt in [8] gevolgd. Dit document bespreekt de implementatie- en simulatieprocedure voor de MicroBlaze op een Spartan 3 FPGA, maar dezelfde procedure kan gevolgd worden bij een Virtex II FPGA.

3.2.1 Implementatie

De implementatie van de MicroBlaze bestaat uit twee delen: het ontwerp van de hardware en de software. In het eerste deel wordt de hardware van de MicroBlaze ontworpen en wordt de MicroBlaze vervolgens ge¨ıntegreerd in het volledige systeem. Het ontwerpen van de MicroBlaze gebeurt in de Xilinx Platform Studio (XPS). Omdat de MicroBlaze een soft processor is, kunnen er nog verschillende onderdelen van de processor geconﬁgureerd worden. Na het ontwerpen van de MicroBlaze genereert XPS de VHDL-code voor de implementatie van de MicroBlaze. Deze VHDL-code wordt dan verderop gebruikt in de normale ontwikkelomgeving van Xilinx, namelijk de Xilinx Integrated Software Environment (ISE), waar de MicroBlaze in het volledige systeem wordt ingepast. Het tweede deel bestaat uit het ontwikkelen van de software in de programmeertaal C die op de MicroBlaze moet draaien. Hiervoor kan opnieuw gebruik gemaakt worden van de XPS ontwikkelomgeving.

De procedure voor het ontwikkelen van de hardware start met het uitvoeren van de Base System Builder (BSB) design flow in de XPS. In de eerste stappen worden de FPGA en de microprocessor ingesteld. Omdat er op ons bordje twee Virtex II FPGA’s staan, kan er enkel gekozen worden voor de MicroBlaze. Omdat caches kunnen leiden tot een variërende uitvoeringstijd, mogen er geen caches gebruikt indien de MicroBlaze gebruikt wordt in een real time-toepassing. In deze toepassing wordt de MicroBlaze gebruikt voor de post-processing, waardoor caches wel toegelaten zijn. In een volgende stap kunnen de externe input/output-apparaten, zoals een extern geheugen, gekozen worden. De meest eenvoudige IO-verbinding is de General Purpose IO (gpio) connectie. Via een gpio-verbinding kan de MicroBlaze een aantal pinnen rechtstreeks aanspreken. In een normale opstelling, met de MicroBlaze als topmodule in de hiërarchie, worden deze apparaten rechtstreeks verbonden met de pinnen van de chip. Dit laatste gebeurt door het opgeven van een ucf-bestand, waarin de VHDL-signalen toegekend worden aan de 3.2 Implementatie en simulatie 16 pinnen van de chip. Door dit ucf-bestand leeg te laten, kunnen de verbindingen die in de BSB worden opgegeven in de rest van het systeem gebruikt worden als gewone VHDL-signalen. De eenvoudige bidirectionele gpio-verbinding volstaat hier, want er moeten geen ingewikkelde apparaten aangestuurd worden.

In de volgende stap van de design flow worden de randapparaten opgegeven die zich op de FPGA zelf bevinden. In tegenstelling tot de input/output apparaten worden deze nooit met de externe pinnen verbonden. In deze stap kan men bijvoorbeeld een extra geheugen opgeven. Dit bijkomende geheugen zal later gebruikt worden als gedeeld geheugen tussen de MicroBlaze en de rest van de FPGA. Dit geheugen wordt via de On-Chip Peripheral Bus met de MicroBlaze verbonden. In de laatste stap van de BSB procedure moet de lokatie van de instructies, de data, de stack en de heap opgegeven worden. Hier is het belangrijk om al deze gegevens op te slaan in het geheugen verbonden met de Local Memory Bus en niet met het gedeeld geheugen. Als dit niet zo is, kan de VHDL-code de programmainstructies en -variabelen overschrijven. Nu de BSB design flow volledig is uitgevoerd, moet het gedeeld geheugen nog toegankelijk gemaakt worden voor de andere VHDL-modules. Hiervoor moet het Microprocessor Hardware Specification (MHS) bestand aangepast worden. Dit bestand bevat een definitie van de processor samen met de verschillende bussen waarmee de microprocessor verbonden is, de externe verbindingen en hun bijhorende adresruimte en de on-chip randapparaten met de gegenereerde adressen. Concreet moet er een uitgangs- of ingangspoort gedefinieerd worden voor de signalen van het geheugen aan de B-kant, zoals de data en het geheugenadres en moet het geheugenblok zelf aangepast, zodanig dat de nieuwe poorten verbonden worden met de juiste signalen van het geheugen. Na het uitvoeren van de BSB procedure kan de MicroBlaze verder geconfigureerd worden in de XPS. De gebruiker kan bijvoorbeeld eigen hardwareblokken in de microprocessor integreren. Deze nieuwe hardwarecomponenten kunnen gebruikt worden als hardwareversnellers of kunnen dienen als een interface naar de buitenwereld toe.

Bij het testen van de MicroBlaze met het gedeelde geheugen blijkt dat er een opstarttijd van ongeveer veertig seconden nodig is. Deze opstarttijd is niet aanwezig bij de opstelling zonder gedeeld geheugen. Om te onderzoeken of deze opstarttijd afhankelijk is van de grootte van het geheugen worden er een aantal systemen met een verschillende geheugencapaciteit gemaakt en opgemeten. Door de eerste instructie van de software een led aan te sturen kan deze setuptijd opgemeten worden. Uit de metingen blijkt dat de opstarttijd onafhankelijk is van de grootte van 3.2 Implementatie en simulatie 17 het geheugen en deze dus niet zomaar kan vermeden worden. De grote opstarttijd wordt waarschijnlijk veroorzaakt door een opstartlus die ervoor zorgt dat het geheugen correct ge¨ınitialiseerd wordt. Het is echter onmogelijk om deze code te gaan wijzigen. Deze opstarttijd vormt geen onoverkomelijk probleem voor de toepassing van de MicroBlaze in het volledige systeem. Eens het systeem is opgestart kan men blijven metingen uitvoeren zonder dat de FPGA moet gereset worden.

De laatste stap in de hardwaregeneratie is het invoegen van de MicroBlaze in een nieuw ISE project. De ISE genereert uitgaande van de specificatie van de MicroBlaze een stub-module voor de MicroBlaze. Deze stub-module verbergt het inwendige van de microprocessor, zodat enkel de externe poorten van de MicroBlaze zichtbaar zijn. In deze toepassing gaat dit om enkel gpio-poorten en om de interface naar het gedeelde geheugen. Als men de processor in de FPGA wil gebruiken, volstaat het de stub-module te instantiëren. Het volledige systeem, inclusief de MicroBlaze, kan dan net als een gewoon VHDL-project zonder microprocessor gesynthetiseerd worden in de Xilinx ISE tot een binair bestand waarmee logica van de FPGA geconfigureerd wordt.

Het tweede deel in de implementatie van de MicroBlaze op een FPGA bestaat uit het programmeren van de software voor de microprocessor. Deze software wordt in de programmeertaal C geschreven. Bij het uitvoeren van de BSB procedure in de XPS kan de gebruiker kiezen om een eenvoudig softwareproject aan te maken waarin het geheugen getest wordt. De instructies die nodig zijn om data te lezen van of te schrijven naar de gpio-bus of om toegang te verkrijgen tot het gedeeld geheugen zijn bijna identiek aan de instructies in het testproject. Met behulp van de tools in de XPS wordt de C-code gecompileerd naar een uitvoerbaar elf-bestand. Als laatste moet er nog voor gezorgd worden dat de uitvoerbare code in het geheugen van de MicroBlaze wordt gekopieerd. Dit kan door het commando data2mem uit te voeren. Het resultaat is een binair bestand waarmee de logica van FPGA geconﬁgureerd wordt. Als de FPGA wordt opgestart, begint de MicroBlaze na het verstrijken van de opstarttijd met het uitvoeren van de instructies uit het instructiegeheugen.

Figuur 3.3 geeft een voorstelling van de design ﬂow voor de implementatie van de MicroBlaze als sub-level module in het systeem. 3.2 Implementatie en simulatie 18

Figuur 3.3: MicroBlaze Design Flow

3.2.2 Simulatie

In ModelSim is een co-simulatie van de hardware-implementatie en de software mogelijk. De procedure die hiervoor wordt gevolgd, staat net als de procedure voor de implementatie van de MicroBlaze beschreven in [8]. De XPS staat in voor de generatie van de simulatiebestanden voor de MicroBlaze. Telkens de software wordt gewijzigd, moeten deze simulatiebestanden wel opnieuw gegenereerd worden. In de ISE zijn er slechts enkele kleinere wijzigingen nodig aan de testbank die normaalgezien gebruikt wordt om het systeem zonder microprocessor te simuleren.

Er zijn wel enkele praktische nadelen verbonden aan deze co-simulatie. Zo is het bijvoorbeeld niet rechtstreeks mogelijk om een bidirectionele gpio-verbinding te simuleren in ModelSim. Dit 3.3 Communicatie 19 probleem is eenvoudig te omzeilen door enkel unidirectionele verbindingen te gebruiken. Daar- naast zijn er ook nog problemen met het simuleren van zelf-gedeﬁnieerde VHDL-componenten. Tijdens het compileren van de VHDL-code geeft ModelSim een foutmelding dat hij deze componenten niet kan vinden in de bibliotheek. Dit probleem kan opgelost worden door de nodige bestanden te kopi¨eren uit een ander project en deze vervolgens aan de bibliotheek van ModelSim toe te voegen. Deze stappen moeten opnieuw worden uitgevoerd telkens ModelSim opnieuw wordt gestart, waardoor het simuleren van het systeem nogal omslachtig wordt. Erger is het gesteld met de opstarttijd van het gedeelde geheugen. Om de werking van het systeem te kunnen controleren zou men eerst veertig seconden moeten simuleren. Dit duurt echter enorm lang, waardoor de oplossing met het gedeelde geheugen in de praktijk niet kan gesimuleerd worden in een aanvaardbare tijd.

3.3 Communicatie

Het is de bedoeling van het onderzoek naar de MicroBlaze om na te gaan of het gebruik van een microprocessor binnen het glasvezelmonitorsysteem haalbaar is. Nu we uit de vorige secties weten dat de MicroBlaze eﬀectief kan ingebed worden in het volledige systeem, moet de communicatie tussen de MicroBlaze en de rest van de FPGA nog bestudeerd worden. In de volgende twee delen zal ik twee alternatieven nader toelichten: in de eerste implementatie bestaat de dataoverdracht uit het doorgeven van de gegevens over een gpio-verbinding, terwijl de communicatie in het tweede alternatief gebeurt door middel van een gedeeld geheugen.

Om beide alternatieven te kunnen vergelijken wordt er een toepassing ge¨ımplementeerd waarbij de MicroBlaze de data van de analoog-naar-digitaalconvertor verwerkt. Daarna wordt de data door de VHDL-module die instaat voor de USB-communicatie weggeschreven naar de computer over de USB2.0-verbinding. Om de communicatieoverhead te kunnen bepalen is het nodig om het aantal klokcycli te tellen in de VHDL code en dit aantal naar de computer te sturen in plaats van de verwerkte meetresultaten. 3.3 Communicatie 20

3.3.1 General Purpose IO

In deze implementatie zijn er twee FIFO’s aanwezig die instaan voor de tijdelijke opslag van de gegevens. Deze FIFO’s hebben een breedte van veertien bits, wat overeenkomt met de woordbreedte aan de uitgang van de ADC’s. De eerste FIFO wordt gebruikt om de data afkomstig van de ADC op te slaan. Deze FIFO is nodig om geen data te verliezen. De MicroBlaze is namelijk veel te traag om de data aan een snelheid van 64 MHz te kunnen inlezen. Van zodra er éénmonsterwaarde aanwezig is, kan de MicroBlaze beginnen met het verwerken van de meetgegevens. Nadat de verwerking van een element klaar is, wordt het resultaat van de verwerking weggeschreven in de tweede FIFO en kan er gestart worden met de verwerking van het volgende element. Nadat alle gegevens zijn verwerkt, wordt de data uit de tweede FIFO doorgestuurd naar de computer. Deze twee FIFO’s kunnen wel vervangen worden door ééngeheugen, waarin zowel de originele als de verwerkte data bewaard wordt.

Om ervoor te zorgen dat de data aan de ingang van de MicroBlaze en de ingang van de tweede FIFO altijd geldig is, is er een handshaking protocol ge¨ımplementeerd tussen de MicroBlaze en de rest van de logica op de FPGA. De MicroBlaze wacht met het verwerken van de data tot de FPGA een gpio-pin omhoog brengt. Omgekeerd wacht de FPGA op het hoog komen van een controlesignaal dat aangeeft dat de verwerking klaar is om verder te gaan met het opslaan van de data in de tweede FIFO en het aanleggen van de volgende waarde uit de eerste FIFO. Met dit protocol is er een communicatieoverhead van 41 klokcycli van 64 MHz. Deze overhead bestaat uit tien cycli om het controlesignaal van de FPGA in te lezen, tien cycli om de data zelf in te lezen, zeven cycli om de data weg te schrijven en twee maal zeven klokcycli om het controlesignaal dat aangeeft dat de data klaar is naar omhoog te brengen en vervolgens terug laag te zetten. De overhead kan met tien klokcycli gereduceerd worden als we aannemen dat de data afkomstig van de FPGA altijd stabiel is. In de praktijk vormt dit geen enkel probleem omdat de FPGA aanzienlijk sneller is dan de MicroBlaze en men er dus zeker kan van zijn dat de data altijd stabiel is. In dat geval is er enkel een signaal nodig dat aangeeft dat er een volledige rij van gegevens kan verwerkt worden. De handshaking in de andere richting kan niet zomaar weggelaten worden, want de uitvoeringstijd van de software is niet altijd gekend. We kunnen dus besluiten dat er een minimale overhead van 31 klokcycli optreedt bij de communicatie over een gpio-connectie. 3.3 Communicatie 21

3.3.2 Gedeeld geheugen

Om het geheugenverbruik enigszins te beperken, worden er geen twee bijkomende FIFO’s gebruikt zoals in de implementatie met de gpio-pinnen. Als men de MicroBlaze wil gebruiken als ingebedde component, mag het geheugengebruik niet te snel oplopen, omdat het geheugen van een FPGA-chip beperkt is. De VHDL wordt aangepast zodat het gedeelde geheugen kan gebruikt worden als een FIFO-buﬀer. Het geheugen in de MicroBlaze kan enkel een breedte hebben van 32 of van 64 bits. Aangezien de data minder dan 16 bits lang is, zou het een grote verspilling van het geheugen zijn om voor iedere element een geheugenlocatie te voorzien. Daarom worden de meetresultaten per twee woorden op dezelfde geheugenlocatie bewaard. In de C-code zijn er nu wel een paar bijkomende instructies nodig om de data correct in te lezen en terug weg te schrijven. De totale overhead van het communicatieprotocol met het gedeeld geheugen is dertien klokcycli. Dit omvat het lezen en het schrijven uit het geheugen, samen met de extra instructies om de data te splitsten en terug samen te voegen. Deze oplossing presteert duidelijk beter dan het vorige alternatief. De grote opstarttijd van veertig seconden is wel een groot nadeel van deze conﬁguratie ten opzichte van de oplossing met de gpio-verbinding.

Naast deze twee oplossingen zijn er nog verschillende tussenvormen mogelijk. Men kan bijvoorbeeld slechts een klein deel van het geheugen delen tussen de FPGA en de MicroBlaze. Bij een klein aantal geheugenelementen is het niet zo erg dat de helft van de woordbreedte niet gebruikt wordt, want er gaan hoogstens enkele bytes geheugenruimte verloren. De overhead veroorzaakt door de instructies die een geheugenwoord opslitsen en terug samenvoegen is nu niet langer nodig. De FPGA moet er nu wel voor zorgen dat dit gedeeld geheugen een correcte ingangswaarde voor de MicroBlaze bevat en dat de resultaten van de MicroBlaze op tijd weggeschreven worden naar een FIFO, zodanig dat er niets verloren gaat. Om dit te kunnen doen is er een gelijkaardig handshaking protocol nodig als bij de implementatie met de gpio-verbinding. Deze oplossing is aanzienlijk sneller dan het eerste alternatief omdat het lezen en schrijven van een geheugenlocatie veel sneller is dan het lezen of het schrijven van een gpio-pin. 3.4 Besluit 22

3.4 Besluit

Beide implementaties hebben een grote communicatieoverhead, waardoor ze niet geschikt zijn om bewerkingen in real time uit te voeren. De MicroBlaze kan wel gebruikt worden om bepaalde signaalverwerkingsalgoritmes toe te passen als de data al is opgeslaan in het geheugen. De MicroBlaze wordt pas interessant als de complexiteit van de algorimtes in de post-processing stap voldoende hoog is. Bij meer complexe signaalverwerkingsalgoritmes komt men sneller tot een implementatie in software dan in hardware. Eenvoudige bewerkingen op de signalen kunnen beter in hardware ge¨ımplementeerd worden. In het huidige systeem is de signaalverwerking beperkt tot het uitmiddelen van de data. Voor deze toepassing is de MicroBlaze dus minder geschikt, maar hij zou later wel kunnen overwogen worden als een deel van de signaalverwerking van de computer naar de FPGA wordt overgeheveld.

Een ander nadeel van de MicroBlaze is het geheugenverbruik. De MicroBlaze alleen heeft minimum een geheugen van acht kilobyte nodig, wat overeenkomt met vier geheugenblokken op de FPGA. In het systeem om de glasvezel te controleren worden er al 45 van de 48 geheugenblokken op de eerste FPGA in beslag genomen. Om de MicroBlaze te kunnen gebruiken binnen het huidige systeem, zouden de FPGA’s moeten vervangen worden door grotere Virtex II FPGA’s. SIGMA-DELTA ADC 23

Hoofdstuk 4

Sigma-Delta ADC

4.1 Omzetting van analoge signalen naar digitale signalen

Het licht dat in de optische vezel teruggekaatst wordt, veroorzaakt een analoog elektrisch signaal aan de uitgang van de fotodiode. Dit signaal wordt analoog versterkt, maar moet uiteindelijk omgevormd worden tot een digitaal signaal zodat de FPGA er bewerkingen kan op uitvoeren. Deze omvorming gebeurt door een ADC (Analoog-Digitaal Convertor). De omgekeerde bewerking, digitale signalen omzetten in analoge signalen gebeurt door een DAC (Digitaal-Analoog Convertor). Een ADC heeft een aantal speciﬁcaties, maar de belangrijkste zijn deze twee:

• Maximale bemonsteringsfrequentie : Dit getal limiteert het aantal analoog-digitaal om- vormingen dat kan uitgevoerd worden per seconde. Dit is belangrijk om rekening mee te houden, want dit limiteert de bandbreedte van het digitale uitgangssignaal. Volgens het Nyquist-criterium geldt dat de bandbreedte van het uitgangssignaal maximaal de helft van de bemonsteringsfrequentie kan zijn.

• Aantal bits in de digitale uitgang : De uitgang van een ADC is een binaire voorstelling van een getal. Het aantal verschillende getallen dat kan voorgesteld worden, wordt beperkt door het aantal bits dat beschikbaar is aan de uitgang.

Deze twee karakteristieken kunnen ook op een andere manier bekeken worden. Een analoog signaal is zowel continu over de tijd als over de signaalwaarde. Een digitaal signaal is discreet over 4.2 Binair zoeken 24 beide grootheden. De bemonsteringsfrequentie bepaalt de nauwkeurigheid bij het kwantiseren van de tijd, het aantal bits bepaalt de nauwkeurigheid bij het kwantiseren van de signaalwaarde.

De ADC die nu op de hardware gebruikt wordt heeft een maximale bemonsteringsfrequentie van 65 MHz en een resolutie van 14 bits. Dit betekent dat het uitgangssignaal een bandbreedte van 32 MHz heeft en dat er 214 (=16 384) verschillende uitgangen zijn. Het ingangssignaal van deze ADC is afkomstig van een laserdiode of een fotodiode. Beiden hebben een bandbreedte van ongeveer 5MHz. Een ADC die werkt met een conversiesnelheid van 10 MHz is in dit geval eigenlijk reeds voldoende. De uitgangsresolutie is groot, maar dit is nodig. Doordat het OTDR- signaal exponentieel afneemt, zijn de signaalwaarden die corresponderen met het eind van de optische vezel heel klein.

De ADC die nu gebruikt wordt is overgedimensioneerd voor deze toepassing. We onderzoeken nu een aantal goedkopere alternatieven die dezelfde (of gelijkaardige) kwaliteit geven. Het is de bedoeling zo weinig mogelijk analoge componenten te gebruiken. De alternatieven die we onderzoeken kunnen opgedeeld worden in drie categori¨en: de binaire-zoek algoritmes (4.2), de sigma-delta ADC (4.3 en 4.4) en een commerci¨ele niet overgedimensioneerde ADC (4.5). Het grootste deel van dit hoofdstuk bevat informatie over de sigma-delta oplossing, we bespreken eerst de theorie in 4.3 en daarna een aantal simulaties in 4.4.

4.2 Binair zoeken

Het idee achter deze algoritmes is dat er enkel een analoge comparator en een DAC nodig zijn. De digitale elektronica gebruikt een binair zoek algoritme om de digitale uitgang iteratief nauwkeuriger te maken. Eerst geeft de digitale elektronica een 50% waarde door aan de DAC, die dit omvormt naar een analoog signaal dat aangelegd wordt aan de analoge comparator. Indien het ingangssignaal hoger is dan 50%, dan komt er een “1” op het eerste bit van de digitale uitgang. Indien het ingangssignaal lager is, dan komt er een 0 als eerste bit. Hierna zal de waarde 25% of 75% aangelegd worden aan de DAC, waarna de vergelijking met het ingangssignaal het tweede bit van de digitale uitgang bepaalt. Dit process wordt herhaald tot alle bits van de uitgang bepaald zijn.

De twee verschillende versies die we bespreken hebben te maken met de manier die gebruikt 4.2 Binair zoeken 25 wordt om de digitale waarde om te zetten naar een analoog signaal.

4.2.1 Pulse Code Modulation

Dit is de oplossing met een uiterst minimum aan analoge componenten. De digitale waarde wordt uitgestuurd over één pin. Deze pin wordt afwisselend laag en hoog gebracht, zodanig dat de gemiddelde waarde gelijk is aan de analoge waarde die men wil bekomen. Om bijvoorbeeld 75% te verkrijgen, wordt de code 1110 telkens herhaald. Dit analoog uitmiddelen kan op goedkope wijze gebeuren door een gepast laagdoorlaat filter.

Hoewel deze oplossing zeker de goedkoopste is, is ze totaal ongeschikt voor wat wij nodig hebben. Wanneer we ons reeds tevreden stellen met een 8-bits resolutie, dan nog bekomen we een onaanvaardbaar lage bemonsteringsfrequentie:

• PCM omvorming van 8-bits getal naar 1 pin: Deze omzetting vereist een periode van 28 klokcycli.

• Om het laagdoorlaat ﬁlter redelijk stabiel te krijgen, moeten we deze code een aantal keer aanleggen. Veronderstel dat we ze 4 keer na elkaar doorzenden.

• Voor het binair zoek algoritme zelf, moeten we dit alles nog eens 8 maal herhalen om alle bits te bepalen.

Door al deze factoren bekomen we een minimale bemonsteringsperiode van 8192 klokcycli, voor een omvorming naar 8 bits. Dit is compleet onaanvaardbaar.

4.2.2 Externe DAC

De grootste vertraging in de PCM methode bevindt zich in het omvormen van de digitale waarde naar een analoog signaal. Die omzetting op zich heeft 1024 klokcycli nodig. Dit kunnen we eenvoudig oplossen door een externe DAC te gebruiken. Een DAC is steeds veel goedkoper dan een ADC met dezelfde resolutie en snelheid. We kunnen hier een DAC gebruiken die in ´e´en klockcyclus het correcte analoge signaal doorstuurt naar de comparator. Het aantal klokcycli dat we nodig hebben per conversie is in deze opstelling gelijk aan het aantal bits resolutie dat 4.3 Sigma-Delta theorie 26 we willen. Hier hebben we dus te maken met een directe afweging tussen resolutie in signaal amplitude en resolutie in het tijdsgedrag.

Voor een resolutie van 8 bits hebben we 8 klokcycli nodig per conversie. Dit betekent (bij een klokfrequentie van 64 MHz) dat we aan 8 MHz kunnen werken en dus een bandbreedte van 4 MHz hebben voor ons signaal. Dit ligt redelijk dicht bij de 5 MHz bandbreedte die het signaal bevat. Er is echter nog een component nodig naast de analoge comparator en de DAC. Om de ingang stabiel te houden over de 8 klokcycli die het binaire zoek algoritme nodig heeft, zal er een nauwkeurig sample-and-hold ﬁlter nodig zijn.

Hoewel deze oplossing reeds eventueel aanvaardbaar zou zijn, is een resolutie van 8 bits eigenlijk toch nog te weinig. Een hogere resolutie nemen en de bandbreedte nog verlagen is echter ook geen goede oplossing.

4.3 Sigma-Delta theorie

Hier geven we meer uitleg over hoe een sigma-delta modulator precies werkt. Deze beknopte uitleg is een samenvatting van de informatie die te vinden is in [9], [10], [11].

4.3.1 Delta modulatie

Het is nuttig om het principe van delta modulatie uit te leggen vooraleer we sigma-delta modulatie bespreken. Het principe van delta modulatie en demodulatie is voorgesteld in Figuur 4.1. Delta modulatie kwantiseert de verandering in signaal amplitude in plaats van de signaal amplitude zelf. Dit komt uiteindelijk neer op het kwantiseren van de afgeleide van het signaal. Op deze manier is een integrator in de demodulator voldoende om het originele signaal ongeveer te reconstrueren. Een dergelijk systeem is gevoelig voor het opstapelen van opeenvolgende kwantisatie fouten. In plaats van een vertraagde versie van de input te gebruiken om de verandering in signaal amplitude te bepalen, wordt daarom een feedback lus ingevoerd. Deze lus doet in feite hetzelfde als wat in de demodulator gebeurt. Het gereconstrueerde signaal x wordt afgetrokken van het bronsignaal x. Deze bewerking vergelijkt dus de huidige echte waarde met de gereconstrueerde waarde. Wanneer de echte waarde hoger is dan de gereconstrueerde, dan wordt +1 doorgegeven, indien ze lager is, dan wordt -1 doorgegeven. Doordat de vergelijking 4.3 Sigma-Delta theorie 27

Figuur 4.1: Delta modulatie

gemaakt wordt ten opzicht van het gereconstrueerde signaal, kunnen fouten zich niet opstapelen. De bandbreedte van een delta modulator wordt beperkt door de maximale helling die kan behaald worden.

4.3.2 Sigma-Delta modulatie

Een delta modulatie systeem bevat twee integrators, één in de feedback lus en één in de ontvanger. Dit systeem kan vereenvoudigd worden door beide integrators samen te voegen. Ten eerste kunnen we de integrator van de ontvanger vóórhet modulator blok van de zender plaatsen. Daarna kunnen we de twee integrators aan de ingangen van de opteller vervangen door één integrator aan de uitgang van de opteller. Deze twee stappen zijn ge¨ıllustreerd in Figuur 4.2. Er lijkt een alternatieve, misschien logischere manier, om de twee integrators samen te voegen. De integrator kan aan het eind van de modulator geplaatst worden, zodat het kanaal en de feedback-lus beide de uitgang van deze integrator gebruiken. Op deze manier bekomen we echter de transmissie van een analoog signaal, en hebben we geen analoog-digitaal convertor.

In een praktische realisatie van deze schakeling komen nog twee extra elementen voor. Een 4.3 Sigma-Delta theorie 28

Figuur 4.2: Van delta modulatie naar sigma-delta modulatie

comparator heeft in de praktijk een uitgang gelijk aan 0 of 1, die continu wijzigt. We moeten hier dus een latch toevoegen die deze uitgang aan een bepaalde klokfrequentie bemonstert om de uitgang volledig digitaal te maken. In de feedback lus moet er dan nog een simpele digitaal- analoog convertor toegevoegd worden die de 1 en de 0 laat corresponderen met respectievelijk

+Vmax en −Vmax. De volledige conﬁguratie wordt voorgesteld in Figuur 4.3.

Figuur 4.3: Praktische realisatie van een eerste orde, 1-bit sigma-delta ADC

Door de integrator v´o´orde comparator te plaatsen, is de datastroom die verstuurd wordt natuurlijk ook veranderd. In plaats van de afgeleide, wordt nu opnieuw het signaal zelf verstuurd. 4.3 Sigma-Delta theorie 29

Deze nieuwe signalen en hun betekenis worden voorgesteld in Figuur 4.4

Figuur 4.4: Tijdsverloop van alle signalen in een sigma-delta ADC

De schakeling beschreven in de vorige secties is een eerste orde sigma-delta modulator. Deze schakeling kan aangepast worden om een betere signaal-ruis verhouding te krijgen, maar dan is de werking niet meer eenvoudig intu¨ıtief te verklaren. De meest courante alternatieven worden hier kort voorgesteld.

Figuur 4.5: tweede orde sigma-delta ADC

In Figuur 4.5 staat een tweede-orde sigma delta modulator. Er wordt een extra integrator-stap v´o´oreen eerste orde sigma-delta modulator geplaatst. Deze opstelling is gevoeliger voor niet- lineariteit dan de eerste orde sigma delta modulator. Afwijkingen van 30% in de kringwinst 4.3 Sigma-Delta theorie 30 of feedback-vertraging, kunnen onstabiliteit veroorzaken. Op dezelfde manier kunnen nog extra integrator-stappen bijgeplaatst worden om hogere orde modulators te bekomen. Dergelijke systemen zijn echter zeer gevoelig voor instabiliteit. Afwijkingen van het ideaal gedrag moeten beperkt worden tot maximaal 15%. De buitenste feedback lus bevat dan 3 integrators en een delay. De output van alle integrators moet beperkt worden om niet-uitstervende oscillaties te voorkomen.

Figuur 4.6: Cascade van twee eerste orde sigma-delta ADC’s

Een andere mogelijkheid om de signaal-ruis verhouding op te drijven wordt voorgesteld in Figuur 4.6. Dit is een cascade van twee eerste orde sigma-delta modulators. De eerste trap wordt als normale sigma-delta modulator gebruikt. De tweede trap gebruikt echter het signaal aan de ingang van de comparator als bron. Dit signaal zal door de comparator omgevormd worden in een 0 of een 1. De waarde van dit signaal is dus de kwantisatiefout die zal gemaakt worden. Deze kwantisatiefout wordt gedigitaliseerd in de tweede stage. Door de bitstromen van de twee trappen op een gepaste manier samen te brengen, kan een hogere nauwkeurigheid behaald worden. Deze layout heeft dezelfde signaal-ruis karakteristieken als een tweede orde sigma-delta modulator, maar is even stabiel als een sigma-delta modulator van eerste orde.

Voor een tweede orde sigma-delta modulator kunnen we een gelijkaardige cascade vormen. In Figuur 4.7 wordt de kwantisatiefout van een tweede orde sigma-delta modulator gedigitaliseerd in een tweede trap. Analoog als bij de cascade van twee eerste orde systemen, is ook hier de signaal- ruis karakteristiek beter, zonder de stabiliteit te verminderen. We hebben dus een signaal-ruis karakteristiek die overeenkomt met die van een derde-orde systeem, maar de stabiliteit van een 4.3 Sigma-Delta theorie 31

Figuur 4.7: Cascade van een tweede orde en een eerste orde sigma-delta ADC

tweede orde systeem.

Bij elke analoog-digitaal conversie treedt er kwantisatie ruis op. Deze wordt veroorzaakt doordat digitale signalen niet met oneindige nauwkeurigheid voorgesteld worden. Voor een bepaald analoog-digitaal conversie systeem is de totale hoeveelheid kwantisatie ruis altijd gelijk. De spreiding van deze ruis over het frequentie spectrum is echter niet steeds gelijk. Bij een gewone ADC is deze spreiding van de ruis uniform over de volledige bandbreedte. Aangezien de bandbreedte afhankelijk is van de frequentie waaraan de ADC werkt en de totale hoeveelheid ruis vast is, daalt de ruis-amplitude bij stijgende bemonsteringsfrequentie.

Sigma-Delta modulators hebben echter geen vlak ruisspectrum. De kwantisatie ruis wordt heel sterk geconcentreerd in de hogere frequenties. Dit is ge¨ıllustreerd op Figuur 4.8, samen met een sumiere wiskundige verklaring. Hoe hoger de orde van de sigma-delta modulator, hoe meer de ruis verschoven wordt van de lage frequenties naar de hoge frequenties. Deze hoge frequenties zullen later weggeﬁlterd worden door een laagdoorlaat ﬁlter. In de literatuur ([10]) vinden we formules die de worst-case signaal-ruis verhouding bepalen in de passband van deze circuits. Deze formules zijn afhankelijk van de oversampling rate (OSR). De OSR is de verhouding van de gebruikte bemonsteringsfrequentie tot de bemonsteringsfrequentie die volgens het Nyquist criterium zou gebruikt moeten worden. Vergelijkingen 4.1 tot 4.3 geven de waarde van de signaal-ruis verhouding (SNR) voor eerste orde tot derde orde systemen. 4.3 Sigma-Delta theorie 32

Figuur 4.8: Quantizatieruis bij een eerste orde sigma-delta ADC

π SNReersteorde = q (4.1) 36 · (OSR)3 π2 SNRtweedeorde = q (4.2) 60 · (OSR)5 π3 SNRderdeorde = q (4.3) 84 · (OSR)7

Net als in de vorige delen beschouwen we hier een ingangssignaal met bandbreedte 5 MHz en een klokfrequentie van 64 MHz. Dit betekent een oversampling verhouding van ongeveer 6.4. Dit levert signaal-ruis verhoudingen op voor de verschillende ordes van sigma-delta modulators van respectievelijk 29.8 dB, 38.2 dB en 45.8 dB. In dezelfde bron [10] wordt een formule gegeven voor de signaal-ruis verhouding van een gewone ADC. Deze formule is afhankelijk van het aantal bits van deze ADC (=N) en wordt gegeven in 4.4:

SNRADC = 6.02 · N + 1.76dB (4.4)

Door vergelijking 4.4 te inverteren, kunnen we bepalen met welke bit-resolutie een signaal-ruis niveau overeenkomt. We bekomen een resolutie van 4.7 bits voor een eerste orde systeem, 6.1 bits voor een tweede orde systeem en 7.3 bits voor een derde orde systeem. 4.3 Sigma-Delta theorie 33

In onze toepassing liggen de kloksnelheid (64 MHz) en de bandbreedte van het signaal (5 MHz) relatief dicht bij elkaar. Dit zorgt ervoor dat 1-bits sigma-delta ADC’s geen voldoend nauwkeurige resolutie kunnen verkrijgen door de lage oversampling verhouding.

4.3.3 Multibit sigma-delta modulatie

In het vorige onderdeel werd duidelijk dat we met een eerste orde sigma-delta modulator niet aan de eisen zullen kunnen voldoen. Naast de hogere orde en cascade systemen die daar voorgesteld werden, kunnen we nog op een andere manier verbeteringen aanbrengen. We kunnen de comparator en de 1-bit DAC vervangen door een meer-bits ADC en DAC. Indien we een 3-bits ADC en DAC gebruiken, dan krijgen we aan de uitgang een stroom van getallen tussen 0 en 7 in plaats van een reeks met enkel 0 of 1. Voor elke extra bit die we hier gebruiken, zal de uitgang ook 1 bit nauwkeuriger worden.

Een 3-bits ADC deelt de analoge ingang op in 8 gelijke intervallen, die overeenkomen met de getallen 0 tot en met 7. In de feedback-loop zal een 3-bits DAC deze getallen terug omzetten in een analoge waarde. De 3-bits DAC zal 8 verschillende analoge niveau’s kunnen teruggeven. Hiervoor zijn er echter twee mogelijkheden.

• Ofwel zullen de uitgang niveau’s van de DAC gelijk verspreid zijn over het volledige analoge ingangsbereik van de ADC

• Ofwel zullen de uitgang niveau’s van de DAC overeenkomen met de gemiddelde waarde van de 8 intervallen van de ADC.

Beide mogelijkheden zijn ge¨ıllustreerd in Figuur 4.9.

De eerste optie geeft echter problemen. Het verschil tussen twee opeenvolgende analoge niveau’s van de DAC is groter dan de kwantisatie intervallen van de ADC. Dit betekent dat er kans is dat de uitgang oscilleert over twee niet-naburige waarden. Bijvoorbeeld een constante ingangswaarde van -0.1375 zorgt voor een uitgangssignaal dat gedurende korte periodes een aantal keer alterneert tussen 2 en 4. De reden voor dit probleem is ge¨ıllustreerd in Figuur 4.10. Deze graﬁek toont de uitgang van de integrator, vooraleer deze gekwantiseerd wordt door de 3-bits ADC. Zoals beschreven in 4.3.2, is dit de kwantisatiefout. We zien dat deze fout blijft toenemen, zolang 4.3 Sigma-Delta theorie 34

Figuur 4.9: Illustratie van de twee opties voor de uitgangsniveau’s van een 3-bits DAC

Figuur 4.10: Oscillaties over niet-naburige uitgangsniveau’s

de uitgangswaarde gelijk is aan 3. Wanneer de kwantisatiefout de waarde 0 bereikt, zal de ADC een 4 geven als uitgang. Hierdoor zal de kwantisatiefout sterk afnemen. Het resultaat is echter kleiner dan -0.25, dus de ADC geeft een 2 als uitgang. Dit zorgt ervoor dat de kwantisatiefout terug stijgt en positief wordt. Deze oscillatie tussen de waarden 2 en 4 duurt een aantal klokcycli, waarna de uitgang terug 3 wordt voor een langere periode.

Omwille van deze reden gebruiken we de tweede mogelijkheid als uitgangsniveau’s voor de DAC. Elk getal wordt omgevormd naar de analoge waarde die overeenkomt met het gemiddelde van het interval. Dit zorgt ervoor dat de stapgrootte van de ADC en de DAC identiek zijn en we bovenstaand probleem niet zullen tegenkomen. Het nadeel hiervan is een verkleind ingangsbereik. Indien het bereik van de ADC gelijk is aan -1 tot +1, dan wordt het werkingsbereik van B−1 B−1 b−1 onze sigma-delta modulator beperkt tussen − B en + B , met B = 2 . Indien het aantal bits voldoende groot is, wordt het bereik bij benadering gelijk aan -1 tot +1. 4.3 Sigma-Delta theorie 35

4.3.4 Decimatie

Na de modulatie hebben we een groot aantal datapunten met een kleine bit-resolutie. We moeten de bemonsteringsfrequentie verlagen en de bit-resolutie verhogen. Deze twee bewerkingen worden tegelijkertijd uitgevoerd in een Cascaded Integrator-Comb ﬁlter. Een CIC ﬁlter bestaat uit 3 grote delen:

• K integrator blokken die werken aan de hoge bemonsteringsfrequentie

• Een decimator, die slechts 1 op N resultaten doorlaat (N = decimatiefactor)

• K diﬀerentiator blokken die werken aan de lage bemonsteringsfrequentie (= decimatiefrequentie)

Deze blokken kunnen allemaal ge¨ımplementeerd worden met optellers en aftrekkers. Een CIC- ﬁlter kan dus gerealiseerd worden zonder complexe componenten, wat natuurlijk zeer interessant is.

Figuur 4.11: Spectrum van 1ste tot 4de orde CIC-ﬁlters met decimatiefrequentie 400 kHz

Het spectrum van een aantal CIC-filters wordt getoond in Figuur 4.11. In deze voorbeelden wordt de lage bemonsteringsfrequentie telkens 400 kHz, maar het aantal integrator en differen- tiator blokken is verschillend. Normaal moeten we een laag-doorlaat filter gebruiken om het 4.3 Sigma-Delta theorie 36 originele signaal terug te bekomen. Het is duidelijk dat een CIC-filter een laag-doorlaat filter is, maar geen goed laag-doorlaat filter. De passband is zeker niet vlak en er treedt relatief veel aliasing op bij hogere frequenties. Dit kan opgelost worden door een compenserende filter die de passband vlak maakt en beperkt tot een vierde van de decimatiefrequentie. In Matlab kan een FIR filter gegenereerd worden die een bepaalde CIC-filter compenseert [12]. Deze FIR-filter is symmetrisch. In Figuur 4.12 staat het spectrum van een CIC-filter, de gepaste compenserende filter en hun combinatie. In dit voorbeeld wordt een CIC-filter gebruikt van derde orde (3 integrators, 3 differentiators), met decimatiefactor 4. De compenserende filter is een FIR-filter met 16 coëfficiënten, een maximale variatie van 0.01 dB in de doorlaatband en een maximaal ruisniveau van -40 dB in de stopband. De doorlaatband bevat alle frequenties lager dan 1/4 van de decimatiefrequentie van de CIC-filter.

Zoals te zien in Figuur 4.12 is de fasevertraging van de CIC-filter een licht dalende rechte. Ook de compenserende filter heeft een lineair dalende fase karakteristiek, doordat de coëfficiënten symmetrisch gekozen zijn. De combinatie van deze twee filters heeft opnieuw een lineaire fase. Hieruit leiden we af dat de vertraging voor alle frequenties dezelfde is en er dus geen fase vervorming van het signaal plaatsvindt.

In plaats van een specifiek ontworpen compenserende filter kan ook een eenvoudig accumulate- and-dump circuit gebruikt worden. De kwaliteit bij hoge frequenties zal dan minder goed zijn, maar het filter is eenvoudiger en sneller. 4.3 Sigma-Delta theorie 37

(a) Overzicht

(b) Detail

Figuur 4.12: Spectrum van een CIC-ﬁlter, compenserende ﬁlter en hun combinatie. 4.4 Sigma-Delta simulatie 38

4.4 Sigma-Delta simulatie

Om al deze theorie in verband met sigma-delta ADC’s te testen wordt een simulatiemodel gebouwd in Simulink. Dit model bevat vier grote delen:

• De analoge bronnen : De opstelling wordt getest met een constante ingang, een sinusgolf en een bron die zo goed mogelijk een realistisch OTDR-signaal benadert.

• Modulatie : In de opstelling kan gekozen worden tussen een eerste orde 1-bit modulator en een eerste orde b-bit modulator.

• Decimatie : Er wordt een CIC-ﬁlter gebruikt met 3 integrator blokken en 3 diﬀerentiator blokken. De decimatie factor kan ingesteld worden.

• Filtering : Dit laatste deel zorgt voor een keuze tussen de CIC-compenserende filter, een accumulate-and-dump filter en geen extra filter.

De resultaten van deze opstelling zullen besproken worden op basis van de verschillende ingangssignalen.

4.4.1 Constante ingang

x−1 We gebruiken een constante waarde als bron die overeenkomt met x . We verhogen de x zolang de uitgang ook constant blijft. Vanaf een bepaalde waarde zal de uitgang niet meer volledig constant zijn. Aan de hand hiervan kunnen we het aantal relevante bits bepalen. Bijvoorbeeld: een ingangswaarde van 7/8 levert een constante uitgang op van 7/8, maar een ingangswaarde van 15/16 levert een uitgangssignaal op dat continu wisselt tussen 14/16 en 16/16. In dit geval hebben we 3 relevante bits aan de uitgang.

Na een aantal tests komen we tot deze, relatief eenvoudige, conclusie: het aantal relevante bits is rechtstreeks afhankelijk van de decimatie factor en het aantal bits in de ADC. Indien de decimatiefactor N bedraagt en er een b-bits ADC gebruikt wordt, zullen er log2(N) + b − 1 bits relevant zijn. Indien er nog een accumulate-and-dump filter na de CIC-filter gevoegd wordt, zal de bitresolutie aan de uitgang nogmaals verhoogd worden. Deze extra filter heeft dezelfde invloed als de decimatiefactor in de CIC-filter. 4.4 Sigma-Delta simulatie 39

4.4.2 Sinusgolf

Met een sinusgolf als bron controleren we de bandbreedte van het systeem. Indien we de CIC- compenserende filter niet gebruiken, zakt de amplitude van de sinus reeds bij relatief lage frequenties. Indien we de CIC-compenserende filter wel gebruiken, wordt de theoretische afsnijfrequentie bevestigd. Een sinusgolf met frequentie 1/4 van de decimatiefrequentie behoudt de volledige amplitude na deze compenserende filter. Indien we het eenvoudigere accumulate-and-dump filter gebruiken bij deze frequentie, dan is het signaal volledig verdwenen (amplitude = 0). In Figuur 4.13 staat het analoge ingangssignaal en het resultaat na sigma-delta modulatie, CIC-filter en CIC-compenserend filter. Doordat dit laatste een FIR-filter is met 16 coëfficiënten, duurt het 16 samples vooraleer het uitgangssignaal correct is. Deze verschuiving kan ook verklaard worden door het fase antwoord van de filters (Figuur 4.12).

(a) Analoge ingang

(b) Uitgang na ﬁlteren

Figuur 4.13: Illustratie van de werking van het CIC-compenserend ﬁlter

4.4.3 OTDR

De vorige twee bronnen (constante waarde, sinusgolf) zijn nuttig om theoretische eigenschappen van het systeem te testen. Het is ook nuttig om dit sigma-delta systeem te testen met een meer 4.4 Sigma-Delta simulatie 40 realistisch OTDR signaal. We baseren ons op de informatie in [2] om een OTDR model op te stellen. De basis formule die gebruikt wordt in dit model staat in 4.5. Hierin staan n en B voor eigenschappen van de optische vezel, v is de snelheid van het licht en t is de tijd.

n · exp (−B · v · t) (4.5)

We simuleren een niet-reﬂecterende koppeling tussen twee optische vezels. De tweede optische vezel heeft een gelijkaardig model als de eerste, maar de parameters n en B zullen verschillend zijn. De feedback van de tweede vezel zal ook volledig herschaald worden met een factor fatt1 en vertraagd worden met t1. fatt1 is de totale intensiteit die verloren gaat in de eerste optische vezel, t1 is de vertraging die optreedt in de eerste vezel. De formules voor beide staan in 4.6 en 4.7, waarbij L de lengte van de eerste vezel voorstelt.

fatt1 = exp (−2 · B · L) (4.6) 2 · L t = (4.7) 1 v Na deze 2 optische vezels simuleren we een sterke reflectie aan het eind van de vezel. De combinatie van deze drie delen wordt dan door een 5 MHz laagdoorlaat filter gestuurd om de optische ontvanger te simuleren. Het resultaat hiervan staat in Figuur 4.14. Simulink gebruikt in totaal 7 parameters om deze bron te genereren : n, B en L voor de twee vezels en R voor de reflectie aan het einde.

Figuur 4.14: Gesimuleerde OTDR bron

Hier testen we dit systeem met een 10-bits eerste orde sigma-delta ADC, met decimatiefactor 8. Figuur 4.15 toont de volgende signalen: 4.4 Sigma-Delta simulatie 41

• paars : de analoge OTDR bron

• geel : de uitgang van de 10-bit sigma-delta modulator

• blauw : de uitgang van de CIC ﬁlter

• rood : de uitgang van de CIC ﬁlter nadat enkel de relevante bits behouden werden (zoals bepaald met het constante ingangssignaal).

Figuur 4.15: OTDR bron en een aantal intermediare signalen in het sigma-delta systeem

In Figuur 4.15 kan inderdaad geverifiëerd worden dat er geen zichtbaar verschil is tussen de blauwe en de rode grafiek. Dit betekent dat onze manier om het aantal relevante bits te bepalen op het eerste zicht correct werkt. Om dit kwantitatief te bepalen, maken we een grafiek van het verschil tussen het ingangssignaal en de twee uitgangssignalen (alle bits, enkel relevante bits). Deze grafiek staat in Figuur 4.16.

De afbuiging in deze grafiek wordt veroorzaakt door een fout op de uitlijning van het ingangs- en uitgangssignaal. Er zit namelijk een (kleine) vertraging op het uitgangssignaal ten opzichte van het ingangssignaal. We proberen dit op te lossen door een verschoven versie van het ingangssignaal te gebruiken, zodat de signalen wel correct uitgelijnd zijn. Dit is echter gokwerk en onnauwkeurig. Aangezien zowel ingangs- als uitgangssignaal in principe dezelfde exponen- tiele functies zijn, is hun verschil ook een exponentiële functie. We bepalen de exponentiële functie die zo goed mogelijk de grafiek in Figuur 4.16 volgt en gebruiken ze om de afbuiging te neutraliseren. We bekomen de grafiek in Figuur 4.17. 4.4 Sigma-Delta simulatie 42

Figuur 4.16: Verschil tussen de uitgang en de ingang bij een OTDR ingangssignaal

In deze twee grafieken zien we dat de uitgang van het CIC-filter met alle bits toch een klein beetje beter is dan wanneer enkel de relevante bits behouden worden. Om dit verschil beter te vergelijken, berekenen we de root-mean-square fout voor beide signalen. We doen dit voor verschillende waarden van het aantal bits in de sigma delta modulator. Vanaf een bepaald aantal bits zien we geen verbetering van deze fout meer. Dit komt door de hoge pieken die corresponderen met de sprongen in het OTDR signaal. De bijdrage van deze pieken in de som is zo groot dat de rest kan verwaarloosd worden. Om dit probleem op te lossen, berekenen we ook de RMS fout over een continu stuk van de grafiek. Deze vier waarden staan in Figuur 4.18

We zien dat enkel de relevante bits behouden toch zorgt voor een merkbaar verschil in de RMS fout op de signalen. We zien ook dat deze fout telkens begrensd wordt door externe factoren. Een nauwkeurigere ADC gebruiken voor sigma-delta modulatie heeft in dit geval geen zin. 4.4 Sigma-Delta simulatie 43

Figuur 4.17: Afbuiging in Figuur 4.16 gecorrigeerd

Figuur 4.18: RMS fout bij een OTDR bron 4.5 Andere ADC 44

4.5 Andere ADC

Een eenvoudig alternatief is een goedkopere ADC gebruiken. Zoals vermeld in sectie 4.1 is de huidige ADC overgedimensioneerd. Een ADC die maximaal aan 20 MHz kan werken, met een resolutie van 14 bits, kost slechts 1/4 van wat de huidige ADC kost. Dat is ongeveer evenveel als wat een 65 MHz 10-bits ADC en DAC samen kosten (dit zijn de componenten die gebruikt kunnen worden om een multibit sigma-delta convertor te maken). 45

Deel II

Implementatie DIGITALE HARDWARE 46

Hoofdstuk 5

Digitale hardware

In dit hoofdstuk wordt het digitale gedeelte van het glasvezel monitorsysteem besproken. Dit deel bestaat vooral uit het aanpassen en uitbreiden van de reeds bestaande VHDL-code. Concreet moet de VHDL-code uitgebreid worden met de volgende functionaliteit:

• Dynamisch doorgeven van de verschillende parameters en aanpassen van de hardware hieraan.

• De FPGA moet achtereenvolgens in twee verschillende modes werken: een meting met het uitsturen van een lichtpuls en een meting zonder lichtpuls. Dit is nodig om de transi¨entverschijnselen veroorzaakt door de analoge componenten te onderdrukken.

• Het programma moet tegelijk op het kanaal van de fotodiode en van de laserdiode kunnen meten.

• De gebruiker moet in de GUI kunnen kiezen van welk kanaal er data gelezen wordt.

• Een digitaal laagdoorlaatﬁlter is nodig om de ruis van de analoge front-end te onderdrukken.

• De woordbreedte in het geheugen moet verhoogd worden van 28 bits naar 32 bits om een gemiddelde over een groter aantal metingen te kunnen nemen.

Het eerste deel van dit hoofdstuk bevat een overzicht van het beschikbare hardwareplatform en een bespreking van de belangrijkste elementen van de originele VHDL-code. In de volgende 5.1 Hardwareplatform 47 secties van dit hoofdstuk wordt er dieper ingegaan op de eigenlijke implementatie van de verschillende onderdelen van de digitale hardware. In Sectie 5.2 bespreek ik het ontwerp van het digitaal laagdoorlaatﬁlter met behulp van Matlab. Het doorgeven van de verschillende parameters en het aanpasbaar maken van de verschillende deelsystemen komt aan bod in Sectie 5.3. Sectie 5.4 geeft een overzicht van de aanpassingen die nodig zijn om de dynamische selectie van het meetkanaal mogelijk te maken. Het laatste deel van dit hoofdstuk, Sectie 5.5, gaat dieper in op de nodige wijzigingen aan het communicatieprotocol om de data per 32 bits uit te sturen

5.1 Hardwareplatform

5.1.1 Hardware

Het OTDR-systeem bestaat uit drie verschillende onderdelen: een analoge front-end voor het uitsturen van de excitatiepuls en het opmeten van de backscattering, een digitaal gedeelte met twee Virtex II FPGA’s van Xilinx en de software op de pc. De belangrijkste componenten op de analoge front-end zijn de laserdiode en de fotodiode. De laserdiode wordt gebruikt om de lichtpuls uit te sturen, terwijl de fotodiode dient om het backscattersignaal op te meten. Beiden worden aangestuurd door vier I/O-pinnen van elke FPGA rechtstreeks met de schakelaars van de front-end te verbinden. Door de laserdiode invers te polariseren kan deze component ook gebruikt worden om het backscattersignaal op te meten. Op die manier onstaan er twee verschillende kanalen waarop het gereflecteerde signaal kan gemeten worden. Elk van deze kanalen wordt via een analoog naar digitaal-convertor (ADC) verbonden met éénvan de FPGA’s: de eerste FPGA is verbonden met de laserdiode, terwijl de tweede FPGA de data van de fotodiode inleest en verwerkt. Deze ADC’s hebben een resolutie van veertien bits en worden aangestuurd door een klok van 64 MHz. Het beschikbare hardwareplatform wordt afgebeeld in Figuur 5.1.

De FPGA’s lezen de data afkomstig van de laser- en fotodiode in en verwerken deze gegevens in real time. Na deze signaalverwerking wordt de data via een USB2.0 verbinding doorgestuurd naar de computer. Momenteel is de signaalverwerking in de FPGA’s beperkt tot het uitmiddelen van de data over een groot aantal metingen om de ruis te beperken. In de computer kan er dan eventueel nog verdere signaalverwerking gebeuren. Op het digitale hardwarebord is er een FX2-microcontroller voorzien die de communicatie tussen de computer en de eerste FPGA regelt. De FX2 zorgt ervoor dat de data die in USB-pakketjes toekomt, omgezet wordt naar een 5.1 Hardwareplatform 48

Figuur 5.1: Hardwareplatform

datastroom van zestien bits breed, die dan naar de eerste FPGA wordt doorgestuurd en omgekeerd. Daarnaast verzorgt de microcontroller ook het doorgeven van de nodige controlesignalen. Naast de parallelle USB verbinding is er ook nog een seriële verbinding tussen de microcontroller en de eerste FPGA. De computer kan deze seriële verbinding aansturen door USB-pakketjes te sturen naar een appart adres van de FX2-microcontroller. Deze verbinding wordt gebruikt om de parameters van de computer naar de FPGA’s te sturen. Meer informatie over de FX2- microcontroller is te vinden in [13]. De communicatie tussen de twee FPGA’s gebeurt door een rechtstreekse verbinding van zestien bits breed. Van deze zestien bits worden er twee gebruikt om controlesignalen van FPGA 1 naar FPGA 2 te versturen. De overige veertien pinnen worden gebruikt om de data in de omgekeerde richting te versturen. De FPGA’s maken gebruik van een klokinput van 64 MHz. Om de data in te lezen wordt een klok gebruikt van 32 MHz. Het is niet nodig om de data in te lezen aan een snelheid van 64 MHz, omdat de bandbreedte van het backscattersignaal beperkt is tot een vijftal megahertz. Naast de kloksignalen van 32 en van 64 MHz gebruikt de eerste FPGA lokaal ook een kloksignaal van 128 MHz om de data van beide kanalen samen te voegen tot ééndatastroom.

De softwareomgeving op de Linux-pc bestaat uit een aantal programma’s in C, die de basis- functies implementeren en een graﬁsche gebruikersinterface in Java, die gebruik maakt van deze C-programma’s. In Hoofdstuk 6 wordt dit verder uitgewerkt. 5.1 Hardwareplatform 49

5.1.2 Analoge front-end

De twee belangrijkste componenten op de analoge front-end zijn de laserdiode en de fotodiode. De laserdiode zorgt voor het uitsturen van de lichtpuls, terwijl de fotodiode het uitgestuurde licht opmeet. Dit is nodig om het uitgestuurde lichtvermogen van de laserdiode te kunnen controleren en eventueel bij te sturen. Deze twee componenten kunnen echter ook gebruikt worden om het gereflecteerde backscattersignaal op te meten. Dit gereflecteerde signaal is echter heel zwak en bevat veel ruis, zodat het niet direct naar de twee ADC’s kan verstuurd worden. De twee kanalen bevatten daarom een versterker, een analoog laagdoorlaatfilter en een versterker met regelbare gain. Deze gain kan via de I2C-verbinding ingesteld worden. Er zijn dus weinig bijkomende analoge componenten nodig om de kwaliteit van de glasvezel te gaan bewaken. De beide kanalen worden schematisch voorgesteld in Figuur 5.2.

(a) Laserdiode

(b) Fotodiode

Figuur 5.2: Analoge front-end 5.1 Hardwareplatform 50

De laserdiode, afgebeeld in Figuur 5.2(a), wordt aangestuurd door een laser driver. Deze laser driver zorgt ervoor dat de laser een constant lichtniveau uitstuurt, waarop de data dan kan gemoduleerd worden. Via de burst enable-ingang wordt er bepaald of er licht verstuurd wordt of niet. Het is dan ook dit signaal dat men via de eerste FPGA aanstuurt om de laser aan of af te schakelen. Daarnaast zijn er in het schema ook nog verschillende schakelaars aanwezig die kunnen gebruikt worden om de transiëntverschijnselen te onderdrukken. Schakelaar PL1 verbindt de laserdiode met de laserdriver, terwijl schakelaars PL3 en PL4 dienen om de uitgang van de laserdiode met de versterker en het laagdoorlaatfilter te verbinden. Met behulp van schakelaar PL2 wordt de spanning aan beide kanten van de laserdiode ingesteld op de voe- dingsspanning. Nadat deze schakelaar weer is afgeschakeld kan de laserdiode het gereflecteerde backscattersignaal opmeten.

Het kanaal van de fotodiode uit Figuur 5.2(b) is bijna identiek aan dat van de laserdiode, behalve dat er nu geen laser driver aanwezig is en dat de spanning aan de tweede klem van de fotodiode op een constante spanning V1 wordt gebracht.

5.1.3 Originele FPGA-code

De originele VHDL-code, die moet uitgebreid worden, is in staat om een vast aantal OTDR metingen uit te voeren op de twee kanalen tegelijk, de meetresultaten op te tellen en te bewaren en vervolgens het uitgemiddelde resultaat naar de computer te sturen. De code voor beide FPGA’s is gelijkaardig: ze bevatten beiden een component die de data inleest en uitmiddelt en een component die de signalen van de front-end aanstuurt. Het verschil tussen de code voor de FPGA’s ligt in de communicatiemogelijkheden. De tweede FPGA bevat enkel code om de uitgemiddelde data naar de eerste FPGA te sturen. De eerste FPGA moet niet alleen communiceren met de tweede FPGA, maar ook met de computer. In de volgende paragrafen zal ik de verschillende modules uitleggen en zal ik verder ingaan op de communicatie tussen beide FPGA’s.

Uitmiddeling

Een van de eerste taken bestond erin om een component te ontwikkelen die het gemiddelde kan berekenen van een groot aantal metingen. Deze component, de averager, heeft een woordbreedte 5.1 Hardwareplatform 51 van veertien bits aan de ingang en 28 bits aan de uitgang. In de huidige implementatie middelt de averager de data niet echt uit, maar worden de verschillende samples enkel bij elkaar opgeteld. Om een echt gemiddelde te nemen volstaat het om de minst significante bits weg te laten en enkel de meest significante bits uit te zenden. Door de minst significante bits toch uit te sturen bekomen we een hogere resolutie indien er voldoende is uitgemiddeld. De woordbreedte van het geheugen is ook vastgelegd op 28 bits. Dit legt een limiet op het maximaal aantal keer dat men een meting kan uitvoeren zonder dat er overflow kan optreden. Met een geheugen van 28 bits en inputwoorden van veertien bits kunnen er 214 of 16384 optellingen gebeuren zonder overflow. Naast de input voor de data is er ook een controle-input voorzien, namelijk het startsignaal. Telkens als dit startsignaal hoog komt, worden er 8192 monsters genomen aan de uitgang van de ADC. De waarde van deze samples wordt dan bij de corresponderende geheugenwaarde opgeteld. Als dit proces een vast aantal keer uitgevoerd is, begint de averager de data uit te sturen. Dit wordt aangegeven door het omhoog brengen van de output valid-pin. Dit signaal wordt dan verder gebruikt om een FIFO aan te sturen.

Om deze functionaliteit te implementeren bevat de averager een toestandsmachine. De gedetailleerde toestandsautomaat wordt voorgesteld in Figuur 5.3. Om de ﬁguur niet nodeloos te belasten zijn de overgangen die door het reset-signaal veroorzaakt worden niet getekend. De- ze toestandsautomaat bevindt zich in de idle-toestand totdat het startsignaal op hoog komt. Daarna neemt de averager een vast aantal monsterwaarden, L, en komt hij vervolgens in de sample wait-toestand terecht, waarin opnieuw wordt gewacht op het startsignaal. Als er voldoende metingen (N) zijn uitgevoerd, gaat de toestandsautomaat over naar de send-toestand waarin de data naar de FIFO wordt verstuurd. Na het versturen van de data komt de toestandsmachine terecht in de done-state. De toestandsautomaat blijft in deze done-state totdat de reset-ingang hoog is geworden. Als de reset-ingang hoog is, wordt er vanuit elke toestand asynchroon naar de idle-toestand overgegaan. De output valid-uitgang wordt hoog gezet als de toestandsmachine zich in de send-toestand bevint. Dit signaal wordt dan verderop in de code gebruikt om de write enable-ingang van de FIFO aan te sturen.

Aansturing front-end

De VHDL-modules die de front-end aansturen zijn ld driving op FPGA 1 en transient control op FPGA 2. Deze twee modules zijn heel gelijkaardig. Op FPGA 1 wordt enkel een bijkomend 5.1 Hardwareplatform 52

Figuur 5.3: Toestandsmachine van de averager

signaal gegeneerd dat een puls stuurt naar de module die zorgt voor de uitmiddeling van de data. Dit signaal wordt dan via éénvan de rechtstreekse pinnen naar de tweede FPGA gestuurd. De eerste FPGA is ook verantwoordelijk voor het aan- of afschakelen van de laserdiode. Om de duur van de verschillende pulsen te kunnen bepalen maken beiden modules gebruik van een teller, die vanuit de main-module wordt aangeleverd. Deze teller wordt gereset door het hold-signaal dat rechtstreeks van de computer komt. De computer is dus verantwoordelijk voor het starten van de verschillende metingen. Dit hold-signaal wordt net als de startpuls voor de uitmiddeling rechtstreeks naar FPGA 2 gestuurd. 5.2 Digitaal laagdoorlaatfilter 53

Communicatie

Omdat er al twee pinnen gebruikt worden om controlesignalen van de eerste FPGA naar de tweede sturen, resteren er slechts veertien pinnen voor de datatransfer in de andere richting. De gegevens van de averager moeten dus via een multiplexer samengevoegd worden tot één datastroom van veertien bits breed. Omdat er twee datastromen van 32 MHz samengevoegd worden, heeft deze datastroom een snelheid van 64 MHz. Ook in de eerste FPGA wordt de data samengevoegd tot éénstroom van veertien bits breed aan 64 MHz. Deze twee datastromen worden dan in een volgende multiplexer samengevoegd tot een datastroom van veertien bits breed aan een snelheid van 128 MHz. Deze data wordt dan in een FIFO op FPGA 1 opgeslagen. Als de pc aangeeft dat de data naar de USB2.0 interface mag geschreven worden, wordt de data in de FIFO uitgelezen aan een snelheid van 48 MHz. Omdat de data per twee bytes wordt verzonden naar de USB2.0 interface moet de data uit de FIFO nog uitgebreid worden tot zestien bits. Omdat de monsterwaarden in de twee-complement notatie voorgesteld zijn, kan dit eenvoudig door het tekenbit te kopiëren naar de twee hoogste bits. Figuur 5.4 geeft een schematische voorstelling van de communicatie tussen beide FPGA’s en de computer.

Figuur 5.4: Oorspronkelijk communicatieschema

5.2 Digitaal laagdoorlaatﬁlter

Het digitaal laagdoorlaatfilter moet de bandbreedte van het ingangssignaal beperken tot het interval tussen 0 en 5 MHz. Het digitaal filter dient als alternatief voor een gelijkaardig analoog 5.2 Digitaal laagdoorlaatfilter 54

filter op de front-end. De opdracht bestaat erin om een Infinite Impulse Response (IIR) filter van het type Chebyshev Type I te ontwerpen. Een IIR filter heeft als voordeel ten opzichte van een Finite Impulse Response (FIR) filter dat er minder berekeningen en minder geheugenelementen nodig zijn om het filter digitaal te implementeren op een FPGA-chip. Dit type filter heeft een heel goede frequentiekarakteristiek in de stopband: het frequentieantwoord daalt steil bij stijgende frequenties. Het nadeel van een Chebyshev Type I filter is het feit dat er een rimpel optreedt in de doorlaatband. Bij Chebyshev Type II filter treedt dit fenomeen niet op, maar er is wel rimpel aanwezig in de stopband. Voor deze toepassing is een goede onderdrukking van het signaal in de stopband belangrijker dan de (kleine) rimpel die optreedt in de doorlaatband bij een filter van het eerste type.

De opgegeven speciﬁcaties zijn:

• Einde passband = 5 MHz

• Begin stopband = 8 MHz

• Attenuatie in de stopband 40 dB

• Ripple in de passband ≺ 0.3 dB

Voor het ontwerp van dit filter wordt er gebruik gemaakt van Matlab. Met behulp van de Filter Design-toolbox [14] kan men uitgaande van de opgegeven specificaties de structuur van het filter en de filtercoëfficiënten bepalen. De Filter Design HDL Coder-toolbox [15] maakt dan automatisch VHDL-code aan voor de implementatie van het filter en de testbank. Als de specificaties in de Filter Design-GUI ingegeven worden, genereert Matlab een zevende-orde filter. Dit filter bestaat uit een cascade van drie tweede-orde secties en ééneerste-orde sectie. Figuur 5.5 toont de structuur van het gerealiseerde filter. Deze realisatie van het laagdoorlaatfilter maakt gebruik van vlottende kommagetallen met dubbele precisie. Voor de implementatie op een FPGA-chip is dit onbruikbaar. Daarom moet er een quantisatie van de filtercoëfficiënten gebeuren naar een voorstelling met vaste komma. In de eerste filterimplementatie hebben de coëffciënten een lengte van zestien bits. Deze omzetting kan in de Filter Design-toolbox uitgevoerd worden. De woordbreedte aan de ingang en de uitgang kan beperkt worden tot veertien bits, wat overeenkomt met het aantal bits aan de uitgang van de analoog-naar-digitaalconvertor. Voor de filtercoëfficiënten neem ik de woordbreedte gelijk aan de breedte van de ingangs- en de uitgangspoort. Na de quan- tisatiestap is de rimpel in de doorlaatband groter dan de 0.3 dB die gevraagd wordt. Dit kan 5.2 Digitaal laagdoorlaatfilter 55 eenvoudig opgelost worden door de toegelaten rimpel in de Filter Design-toolbox te reduceren naar 0.29 dB. Als laatste stap is er nog een herschaling en herordening van de filtercoëfficiënten nodig, zodanig dat het uitgangsniveau gelijk is aan het ingangsniveau in de doorlaatband. Door deze herschaling vallen de filtercoëfficiënten in het genormaliseerde bereik [-1,1]. Figuren 5.6 en 5.7 tonen het frequentieantwoord van het gerealiseerde filter. De streepjeslijn in Figuur 5.7 komt overeen met het originele filter met de vlottende kommagetallen, terwijl de volle lijn het gequantiseerde filter voorstelt.

Figuur 5.5: Chebyshev Type I laagdoorlaatﬁlter

Nu het ﬁlterontwerp klaar is, is het tijd om de VHDL-code te genereren en het systeem te simuleren in Modelsim. De door Matlab aangemaakte testbank bevat verschillende signalen zoals 5.2 Digitaal laagdoorlaatﬁlter 56

Figuur 5.6: Frequentieantwoord Chebyshev Type I laagdoorlaatﬁlter

Figuur 5.7: Frequentieantwoord Chebyshev Type I laagdoorlaatﬁlter (doorlaatband)

een stijgende rechte en een chirp-signaal. Om het frequentieantwoord nauwkeurig te kunnen bepalen, is echter een sinuso¨ıdaal ingangssignaal nodig. Dit kan in de Matlab GUI aangelegd worden, maar voor iedere ingangsfrequentie moet er een nieuwe testbank gegenereerd worden. Omdat dit nogal omslachtig is, wordt er een sinusgenerator aan de testbank toegevoegd. De Di- 5.2 Digitaal laagdoorlaatﬁlter 57 rect Digital Synthesizer (DDS) uit de bibliotheek van Xilinx is hiervoor de geschikte component. Door de uitgangsfrequentie van deze component te veranderen in de ontwikkelomgeving van Xi- linx kan het frequentieantwoord van de ﬁlter op sinusvormige ingangssignalen met verschillende frequenties eenvoudig berekend worden.

De simulaties in Modelsim tonen aan dat het filter niet volledig voldoet aan de specificaties. Zo worden bijvoorbeeld frequenties in de stopband onvoldoende onderdrukt. Aan het begin van de stopband (8 MHz), is de verzwakking slechts 30 dB, in plaats van de vooropgestelde 40 dB. Het frequentieantwoord in de Filter Design-toolbox toont zelfs een verzwakking van 50 dB. De situatie is nog veel erger als we het laagdoorlaatfilter in het volledige systeem invoegen en op de FPGA programmeren. Daar blijkt dat de FPGA niet snel genoeg is om het filter te laten werken aan een klokfrequentie van 32 MHz. Dit laatste probleem kan opgelost worden door een eenvoudiger filter te ontwerpen met kortere coëfficiënten. De tweede thesisbegeleider, ir. W. Chen, heeft enkele eenvoudiger laagdoorlaatfilters ontwikkeld. Het uiteindelijke filter is een derde-orde filter en maakt gebruik van filtercoëfficiënten van acht bits lang. Deze eenvoudige filter verstoort het opgemeten backscatter signaal veel te sterk. Zo’n dergelijk filter is dus onbruikbaar in het volledige OTDR-systeem. Wegens de problemen met de uitvoeringstijd van de grotere IIR filters en de slechte prestaties van de kleinere filters, is een IIR filter niet geschikt voor deze toepassing. Een andere oplossing voor het filterprobleem bestaat uit het pijplijnen van het IIR filter. Zoals te zien is in Figuur 5.5, bestaat het filter uit vier trappen. Door manueel registers tussen deze trappen te plaatsen, is het filter mogelijks toch snel genoeg.

Het nadeel van een FIR filter ligt in het feit dat er meer berekeningen moeten uitgevoerd worden en dat er meer geheugen nodig is. Op de FPGA’s is er echter voldoende capaciteit beschikbaar. In deze toepassing is enkel het geheugengebruik heel hoog: door het geheugen in de averager en de FIFO, worden bijna alle RAM-cellen op de eerste FPGA gebruikt. Een FIR filter heeft echter geen RAM-blokken nodig, zodat dit nadeel geen enkel probleem vormt voor de implementatie van het digitaal laagdoorlaatfilter. In de huidige opstelling wordt een FIR filter gebruikt met achttien coëfficiënten van veertien bits lang. Later kan dit filter gemakkelijk vervangen worden door een beter filter met meer coëfficiënten. 5.3 Dynamische configuratie van de FPGA’s 58

5.3 Dynamische conﬁguratie van de FPGA’s

De bedoeling van deze opdracht is het dynamisch configureerbaar maken van de FPGA. De gebruiker moet de belangrijkste parameters van de averager en van de module die de front- end aanstuurt vanuit de user interface kunnen wijzigen, zonder dat de FPGA opnieuw moet geprogrammeerd worden. Daarnaast moet de gebruiker ook de filtercoëfficiënten van het laagdoorlaatfilter kunnen ingeven. Deze opdracht bestaat uit verschillende onderdelen. Als eerste puntje moet er een standaard formaat voor het doorgeven van de parameters bepaald worden. Daarna moet er een nieuwe VHDL-module ontwikkeld worden die de parameters inleest via de seriële input op de eerste FPGA en ze doorstuurt naar de tweede FPGA via de rechtstreekse verbinding tussen beiden. Het laatste onderdeel van deze opdracht bestaat uit het aanpassen van de VHDL-componenten die configureerbaar moeten zijn.

De twee parameters bij de averager zijn het aantal metingen waarover er uitgemiddeld wordt, N, en het aantal monsterwaarden per meting, L. De waarde van L hangt af van de lengte van de glasvezel die men wil controleren. Bij een kortere vezel heeft het geen zin om langer dan nodig te meten, omdat de data na het einde van de vezel uitsluitend bestaat uit ruis. Omdat het beschikbare geheugen op de FPGA’s beperkt is, legt men een bovengrens van 8192 samples per meting op. Dit komt overeen met een vezellengte van meer dan 20 km, wat ruim voldoende is voor deze toepassing. De tweede parameter, N, is beperkt tot een waarde van 16384 om te vermijden dat er overﬂow optreedt in het geheugen van de averager.

De belangrijkste parameter bij de ld driving-module is de breedte, W, van de lichtpuls. De minimale breedte die nodig is voor het uitvoeren van een correcte meting wordt bepaald door de lengte van de glasvezel. Daarnaast bevat dit VHDL-blok ook een aantal parameters die het aan- en afschakelen van de verschillende schakelaars op de analoge front-end controleren. De betekenis van deze controlesignalen wordt uitgelegd in sectie 5.1.3. Figuur 5.8 toont het verband tussen de verschillende parameters en de controlesignalen die beide FPGA’s uitsturen. Alle signalen, behalve P0, zijn wel ge¨ınverteerd: als het signaal laag staat, is de corresponderende schakelaar gesloten.

Het volstaat om zestien bits per parameter te voorzien. De teller die in de module voor de aansturing van de front-end gebruikt wordt is beperkt tot 15 bits en de maximale waarde van N en L is kleiner dan 216 of 65536. De vereiste om het geheugen te vergroten tot 32 bits 5.3 Dynamische conﬁguratie van de FPGA’s 59

Figuur 5.8: Controleparameters

is er pas later bijgekomen. Door de woordbreedte te vergroten tot 32 bits, kunnen er 218 of 262144 gemiddelden genomen worden. Dit heeft tot gevolg dat N nu achttien bits lang is. Dit kan eenvoudig opgelost worden door de parameter N in twee keer uit te zenden: eerst de laagste zestien bits gevolgd door de hoogste twee bits. Iedere parameter wordt voorafgegaan door een controlebyte, zodat er dus 24 bits nodig zijn voor het verzenden van éénparameter. Het gebruik van een dergelijke controlebyte heeft verschillende voordelen: iedere parameter kan afzonderlijk doorgestuurd worden en de controlebyte laat toe om bijkomende signalen, zoals een resetsignaal voor de averager, naar de FPGA’s te sturen. Het nadeel van deze methode ligt in de grotere communicatieoverhead. Omdat de parameters ingesteld moeten worden voor de 5.3 Dynamische configuratie van de FPGA’s 60 metingen beginnen, vormt de grotere transmissietijd geen enkel probleem. Tabel 5.1 geeft een overzicht van de mogelijke waarden van de controlebyte en de betekenis ervan. De waarden 254 en 255 uit Tabel 5.1 dienen om een signaal dat aangeeft of er parameters verstuurd worden of niet, hoog of laag te brengen. Als dit signaal hoog staat, wil dit zeggen dat de FPGA geconfigureerd wordt en dat er dus geen metingen mogen uitgevoerd worden. Dit is ge¨ımplementeerd door het hold-signaal, dat normaalgezien een meting start, afhankelijk te maken van het feit of er parameters verstuurd worden of niet. De waarden 64 tot en met 67 zijn nodig om de selectie van het meetkanaal mogelijk te maken. Dit wordt verderop besproken in Sectie 5.4.

De eerste FPGA krijgt de parameters van de computer via een seri¨ele interface. Deze bestaat uit drie pinnen: de klok, een enable-signaal voor de klok en de datainput zelf. Deze klok heeft een snelheid van vier megahertz. De drie inkomende pinnen zijn verbonden met een schuifregister van 24 bits lang. Op het moment dat de computer een parameter begint te verzenden, krijgt de clock enable-input een hoge waarde. Vanaf nu wordt er bij elke stijgende overgang op de inkomende klok een nieuw bit in het schuifregister ingeschoven. Na 24 klokcycli is de computer klaar met het verzenden van de drie bytes en wordt de clock enable-pin opnieuw omlaag gebracht. De inhoud van het schuifregister wordt nu vastgelegd en de gegevens kunnen uitgelezen worden. Door de eerste acht bits te bekijken kan de FPGA onmiddelijk weten welke parameter moet doorgegeven worden of welke actie er moet ondernomen worden.

Via de seriële interface komen de parameters op de eerste FPGA toe. Nu is het nog nodig om deze parameters naar de tweede FPGA door te sturen. Hiervoor kunnen we de rechtstreekse verbinding tussen de twee FPGA’s gebruiken. Het is nu wel belangrijk om een goed communicatieprotocol te ontwikkelen, omdat de bus nu gebruikt wordt om gegevens in beide richtingen over te brengen: de meetgegevens van FPGA 2 naar FPGA 1 en de parameters in de omgekeerde richting. Daardoor moet de inputbuffer op de eerste FPGA en de outputbuffer op de tweede vervangen worden door een tri-state buffer. Het transfer enable, dat aangeeft of er parameters verzonden worden of niet, is geschikt als controle-signaal voor de tristate-buffer: als transfer enable hoog is, staan de tri-state buffers zo ingesteld dat er gegevens van de eerste naar de tweede FPGA kunnen gestuurd worden, staat dit signaal op nul, dan is er gegevensoverdracht in de andere richting mogelijk.

Het probleem is nu dat het transfer enable signaal enkel gekend is op de eerste FPGA. Er moet dus een manier gevonden worden om dit signaal naar de tweede FPGA te sturen. Hiervoor 5.3 Dynamische conﬁguratie van de FPGA’s 61

Controlebyte Betekenis 1 N (Deel 1) 2 W 3 L 4 T1 5 T2 6 T3 7 T4 8 T5 9 TT1 10 TT2 11 TT3 12 TT4 13 N (Deel 2) 64 Activeer lezen FPGA1 65 Deactiveer lezen FPGA1 66 Activeer lezen FPGA2 67 Deactiveer lezen FPGA2 68 Interleaved werking 69 Normale werking 70 Activeer laagdoorlaatfiler 71 Deactiveer laagdoorlaatfiler 128 - 191 Filtercoëfficiënten 253 Reset averager 254 Einde verzenden parameters 255 Start verzenden parameters

Tabel 5.1: Controlebyte 5.3 Dynamische configuratie van de FPGA’s 62 gebruik ik de twee controlepinnen tussen de twee FPGA’s: de pin gebruikt voor het hold-signaal en de pin voor het doorgeven van het startsignaal voor de averager. Tijdens de normale werking kunnen beiden nooit tegelijk hoog zijn, want het startsignaal is afhankelijk van het hold-signaal. Als het hold-signaal hoog staat wordt de teller die de startpuls aanstuurt gereset. Het is pas bij het opnieuw laag worden van hold dat de teller opnieuw gestart wordt en dat de startpuls één kan worden. Als beide signalen tegelijk hoog zijn, weet de tweede FPGA dat transfer enable hoog is en dat er geen data naar de eerste FPGA mag verstuurd worden. In de hoofdmodule van FPGA 2 moet de code aangepast worden zodat de twee inkomende controlesignalen enkel doorgegeven worden als ze niet beiden tegelijk éénzijn.

De databus tussen de FPGA’s is slechts veertien bits breed. De data moet dus eerst opgesplitst worden in twee keer twaalf bits vooraleer ze kan verstuurd worden. Omdat de parameters serieel toekomen, is dit geen enkel probleem: er is tijd genoeg om de twee delen te versturen voordat de nieuwe parameter volledig aangekomen is. Parameters.vhd moet dus uitgebreid worden met een module die de data opsplitst in twee delen en deze na elkaar verzendt. Hiervoor is er een eenvoudige toestandsmachine voorzien. Elk deel van twaalf bits wordt uitgebreid met twee bits die aangeven om welk deel van de data het gaat: “01” voor het eerste deel (met de controlebyte) en “10” voor het tweede deel van de parameter. In principe is er nog éénbit overschot, want het volstaat om éénbit te voorzien om het correcte deel aan te geven. Dit bijkomende bitje wordt verderop gebruikt in Sectie 5.4 voor het doorgeven van het controlesignaal dat aangeeft dat het verzenden van de data mag beginnen.. De parametersmodule op de tweede FPGA is heel gelijkaardig aan die van de eerste FPGA. Het verschil zit hem enkel in het feit dat de toestandsmachine de data nu moet inlezen en weer samenvoegen tot één geheel en dat er geen schuifregister voor de seriële communicatie nodig is.

Het laatste deel van deze opdracht bestaat uit het aanpassen van de averager, de module voor de front-end en het laagdoorlaatfilter, zodat ze afhankelijk worden van de waarden van de verschillende parameters. Dit kan eenvoudig gebeuren door extra inputpoorten toe te voegen aan de VHDL-componenten en de vergelijkingen met een constante waarde te vervangen door een vergelijking met een waarde afhankelijk van de parameter. Hierbij moeten de case-structuren vervangen worden door constructies bestaande uit if-statements. De Xilinx-omgeving kan niet overweg met case-structuren waarbij de mogelijke waarden niet statisch zijn. Omdat het aantal filtercoëfficiënten niet vastligt, moet dit onderdeel makkelijk uitbreidbaar zijn. Het gebruik van 5.4 Selectie van het meetkanaal 63

een apparte uitgangspoort voor iedere coëfficiënt is dus niet aan te raden. Om dit op te lossen maak ik een package aan met daarin de definitie van een nieuw type, dat bestaat uit een rij van vectoren van bits. Op die manier moet er dus maar één poort van het nieuwe type voorzien worden. Deze rij kan ook automatisch ge¨ındexeerd worden met behulp van het commando in de parametersinterface.

De averager en de ld driving-module moeten ook aangepast worden om interleaved metingen toe te laten. Als de opstelling in interleaved mode werkt, wordt er eerst een normale meting uitgevoerd waarbij er een lichtpuls door de glasvezel wordt uitgestuurd. De volgende meting wordt dan uitgevoerd zonder het uitsturen van deze lichtpuls. De meting zonder licht wordt dan afgetrokken van de meting met licht in plaats van erbij te worden opgeteld. Dit zorgt ervoor dat de transi¨ente verschijnselen die veroorzaakt worden door de analoge front-end uitgeschakeld worden. Een bijkomend voordeel van de werking in interleaved mode is het feit dat de curve na het einde van de glasvezel nu rond nul komt te liggen, zodat er hieruit direct een curve met een logaritmische schaal kan berekend worden in de graﬁsche gebruikersomgeving. Bij de normale werking moet er eerst overgeschakeld worden op het stapantwoord. Dit gebeurt in de post- processing stap op de computer door een volledige backscatter-curve te nemen, deze over een bepaalde tijd te verschuiven en af te trekken van de vorige niet-verschoven meting. De averager is aangepast zodat er bij werking in interleaved mode een onderscheid gemaakt wordt tussen de metingen met en zonder lichtpuls. De waarde van de oneven metingen (met licht) wordt telkens bij het geheugen opgeteld, terwijl de resultaten van de even metingen (zonder licht) worden afgetrokken van de opgeslagen waarden. De stuurmodule voor de front-end is aangepast zodanig dat P0, die de laserdiode aanstuurt, enkel bij de oneven metingen omhoog gebracht wordt. Bij de normale operatie werken beide componenten zoals voorheen. De keuze tussen interleaved en normale werking kan gemaakt worden in de GUI. Via de parameters-interface wordt de waarde doorgeven aan de averager en de component die de front-end aanstuurt.

5.4 Selectie van het meetkanaal

Het doel van deze opdracht bestaat uit twee delen: de gebruiker moet kunnen kiezen van welk kanaal er data gelezen wordt en de gebruiker moet de meetresultaten kunnen inlezen op aanvraag. Om de data te kunnen verzenden op aanvraag moet de toestandsmachine van de averager 5.4 Selectie van het meetkanaal 64 aangepast worden. Na het uitvoeren van N metingen mag de averager niet meer vanzelf beginnen met het uitsturen van de data. Daarom is er een nieuwe ingang, start output, aan de averager toegevoegd die aangeeft dat het zenden mag starten. Als de toestandsautomaat zich in de idle-toestand bevindt en start ouput is hoog dan begint het versturen van de data. Als er L waarden uit het geheugen zijn verstuurd, wordt er opnieuw naar de begintoestaan overgegaan. Als start ouput opnieuw omhoog gebracht wordt, dan worden dezelfde gegevens opnieuw naar de computer gestuurd. De aangepaste toestandsmachine wordt getoond in Figuur 5.9. De toestanden send en send 2 zijn nodig voor de implementatie van de verlengde woordbreedte. Dit onderdeel wordt verderop besproken in Sectie 5.5.

Figuur 5.9: Aangepaste toestandsmachine van de averager 5.4 Selectie van het meetkanaal 65

Als startsignaal kan het USB-trigger signaal gebruikt worden. Door het USB-triggersignaal hoog te brengen geeft de computer aan dat de FPGA data kan versturen. Dit signaal is nodig omdat er in het USB-protocol gewerkt wordt met een master (de computer) en een slave (de microcontroller die de verbinding tussen de pc en de FPGA’s controleert). De handleiding van de FX2-microcontroller [13] bevat een gedetailleerde uitleg van het USB-protocol. De slave kan enkel data versturen naar de master als de master hier expliciet toestemming voor heeft door het omhoog brengen van de USB-triggerpin. De USB-trigger moet gedurende de volledige communicatie hoog staan, anders wordt het verzenden gestaakt. Omdat de pc niet weet hoe lang er data zal verstuurd worden, wordt dit signaal vanuit de C-code langere tijd op hoog gezet. De averager zou dan opnieuw het startsignaal hoog zien staan en de averager zou beginnen met het opnieuw versturen van de data. De volgende keer dat er dan data zou moeten verstuurd worden, zou de ﬁfo vol zitten met (ongeldige) waarden. Om dit te voorkomen, moet de USB- trigger omgevormd worden tot een puls.

Deze puls moet ook naar de tweede FPGA verstuurd worden, zodat deze de data ook op aanvraag kan versturen. Omdat er geen pinnen tussen de beide FPGA’s meer beschikbaar zijn, maak ik gebruik van de parameters-interface. Als de USB-triggerpuls hoog is, worden de hold- en avg start pulse-pinnen samen met de eerste twee data bits omhoog gebracht. Bij het versturen van de parameters kunnen deze vier pinnen nooit tegelijk hoog worden (zie Sectie 5.3). De tweede FPGA kan dus uit deze vier ingangen de USB-triggerpuls reconstrueren.

Bij deze implementatie zijn er veel problemen met de stabiliteit: de startpositie van de hoogste en laagste bits van de data van het tweede kanaal ligt niet vast, waardoor het in de C-code niet altijd mogelijk is om de data te reconstrueren, en bij een groter aantal metingen komt de data van FPGA 2 bijna nooit door. Het eerste probleem is eenvoudig op te lossen door de eerste twee keer de veertien bits die men uitstuurt te vervangen door een vaste waarde. In de C-code kan men dan de positie van deze waarden opzoeken en vanaf die positie beginnen met het opnieuw samenvoegen van de meest en de minst signiﬁcante bits. De uiteindelijke datatransfer verloopt dan zoals weergeven in Figuur 5.4.

Het tweede stabiliteitsprobleem wordt veroorzaakt door het verloren gaan van een startpuls voor de averager of van de USB-triggerpuls. Dit probleem wordt verholpen door de starpuls op de tweede FPGA lokaal te genereren, op dezelfde manier als dit gebeurt op de eerste FPGA. In de oorspronkelijke code wordt de startpuls enkel op de eerste FPGA genereerd om er zeker 5.5 Verlengen van de woordbreedte 66 van te zijn dat beide FPGA’s op hetzelfde ogenblik beginnen met het bemonsteren van de backscattering. Omdat de modules die de front-end aansturen afgeleid zijn van een teller die door hetzelfde hold-signaal gestuurd wordt, vormt dit geen enkel probleem. Er moet enkel voor gezorgd worden dat het hold-signaal op de twee FPGA’s gesynchroniseerd is. Omdat dit signaal over de verbinding tussen de twee FPGA’s moet verstuurd worden, kan er een bijkomende vertraging ontstaan. Uit de experimenten bleek dat deze vertraging altijd gelijk is aan twee klokcycli. Door het hold-signaal, dat op de eerste FPGA gebruikt wordt, te vertragen met twee klokcycli, zijn beide FPGA’s perfect synchroon.

Omdat de startpuls voor de uitmiddeling nu op de tweede FPGA genereerd wordt, is het niet meer nodig om deze over ´e´envan de twee controlepinnen door te sturen. De vrijgekomen verbinding gebruik ik verder om het USB-triggersignaal door te sturen. Dit geeft een bijkomende bescherming tegen het verloren gaan van de smalle puls. Op FPGA twee moet het USB-triggersignaal omgevormd worden tot een puls, net zoals dit gebeurde op de eerste FPGA. Voor de rest verandert er niets aan de werking van de controlepinnen bij het versturen van de parameters van FPGA 1 naar FPGA 2 en het verzenden van de meetresultaten in de andere richting.

5.5 Verlengen van de woordbreedte

Door de woordbreedte in het geheugen van de averager te vergroten van 28 naar 32 bits, kan er nu uitgemiddeld worden over 218 in plaats van over 214 metingen. Deze bijkomende uitmiddelingen zorgen ervoor dat de ruis veroorzaakt door de analoge front-end en de quantisatieruis veroorzaakt door de analoog-naar-digitaalconvertor verder gereduceerd wordt. Door N keer uit te middelen √ wordt de standaardafwijking van witte ruis verminderd met N. Door de extra bits kan de maximale resolutie van de analoge front-end nauwkeuriger onderzocht worden.

Omdat de verbinding tussen de twee FPGA’s beperkt is tot veertien bits, moet het communicatieprotocol aangepast worden: het is niet langer mogelijk om de data in twee delen op te splitsen en deze zo over de bus tussen de FPGA’s te sturen. Daarom worden de 32 databits nu opgesplitst in vier keer acht bits. Om hetzelfde datadebiet te verkrijgen als in de oorspronkelijke code, zou het verzenden aan de dubbele kloksnelheid moeten gebeuren. Dit zou betekenen dat de data aan een snelheid van 128 MHz verstuurt wordt over de bus tussen de FPGA’s en dat 5.5 Verlengen van de woordbreedte 67 er op de eerste FPGA een klok van 256 MHz moet gebruikt worden. In de praktijk leidt dit tot ernstige problemen met de timing, zodat de rechtstreeks implementatie van deze methode onbruikbaar is.

Om aan de problemen met de timingvereisten te ontsnappen wordt de snelheid van het lezen gehalveerd. De averager is aangepast zodat er nu per klokcyclus van 32 MHz een half woord (zestien bits) naar buiten wordt gebracht. In de toestandsautomaat van Figuur 5.9 komt dit overeen met de toestanden send en send 2. In de send-toestand worden de meest-signiﬁcante bits aan de uitgang aangelegd, terwijl de laagste bits worden uitgestuurd vanuit toestand send 2. Enkel in toestand send 2 wordt het leesadres van het geheugen verhoogd, zodat de data gedurende twee klokcycli gelijk blijft. In de tweede FPGA worden deze zestien bits per acht bits verstuurd naar FPGA 1. De snelheid van deze datastroom is gelijk aan 64 MHz. Dit is dezelfde snelheid als in de oorspronkelijke implementatie. Op de tweede FPGA verandert er dus zo goed als niets aan het communicatieschema, zoals weergegeven wordt in Figuur 5.10.

In tegenstelling tot de tweede FPGA zijn er wel enkele veranderingen nodig aan het communicatieschema op de eerste FPGA. De verbinding met de FX2-microcontroller, die de USB- communicatie regelt, is zestien bits breed. De data van de tweede FPGA, die per acht bits toekomt, moet dus eerst nog samengevoegd worden tot een woord van zestien bits. Deze datastroom heeft dan opnieuw dezelfde snelheid van 32 MHz. De averager op FPGA 1 zendt zestien bits uit aan 32 MHz, net zoals op de averager op de andere chip. Op de eerste FPGA zijn er dus in totaal twee stromen van zestien bits breed met een kloksnelheid van 32 MHz. Met behulp van een multiplexer die werkt aan een kloksnelheid van 64 MHz, worden deze twee stromen samengevoegd tot ´e´endatastroom met een snelheid van 64 MHz. Deze datastroom wordt vervolgens rechtstreeks verbonden met de FIFO. In tegenstelling tot de oorspronkelijke situatie waar er een tweede multiplexer nodig is, die met een klok van 128 MHz werkt, volstaat een enkele multiplexer in deze situatie. Figuur 5.10 toont het uiteindelijke communicatieschema. Het nadeel van deze methode ligt in het feit dat het lezen van de data dubbel zo lang duurt. Omdat het lezen van de data niet in ware tijd dient te gebeuren, vormt dit geen echt probleem.

Van de veertien beschikbare communicatiepinnen tussen de twee FPGA’s worden er slechts acht gebruikt voor de data. Daarnaast gebruik ik nog éénbijkomende pin om aan te duiden of de ontvangen acht bits het meest- of de minst-significante deel van de zestien bits zijn. De vijf overblijfende pinnen zouden later kunnen gebruikt worden om het geheugen nog verder uit te 5.5 Verlengen van de woordbreedte 68 breiden, tot aan een maximum woordbreedte van 52 bits. De code op de eerste FPGA zou dan opnieuw moeten aangepast worden zoals in de eerste versie. In dit geval zijn er opnieuw twee multiplexers nodig om de data naar de FIFO te sturen: de ene aan 64 MHz en de andere aan 128 MHz. Samen met de vaste waarde die wordt toegekend aan de eerste symbolen (zie Sectie 5.4), zorgt deze extra bit ervoor dat de datastroom perfect kan gesynchroniseerd worden. De FPGA maakt gebruik van het bijkomende bitje dat aangeeft om welke acht bits het gaat om de data samen te voegen tot een stroom van zestien bits, terwijl de software op de computer gebruik maakt van de vaste waarde aan het begin om de positie van de meest- en de minst-significante bits te bepalen.

Figuur 5.10: Aangepast communicatieschema USER INTERFACE 69

Hoofdstuk 6

User interface

Dit hoofdstuk bespreekt de functionaliteit en de gebruikte technologie van alle pc-software voor het opmeten van een optische vezel. Sectie 6.1 bespreekt het beschikbare software platform en wat de doelstellingen voor de nieuwe user interface zijn. Hierna volgt een korte bespreking van de gebruikte technologie¨en met hun positieve en hun negatieve kanten, en waarom we die gekozen hebben. Het derde deel van dit hoofdstuk illustreert de werking van het programma vanuit het standpunt van de gebruiker. Als laatste onderwerp behandelen we het framework dat we ontwikkeld hebben. Dit laatste deel bevat nuttige info over hoe het programma makkelijk verder uitgebreid kan worden.

6.1 Software platform

De originele software bestaat uit 2 grote delen:

• Een Linux driver voor de FX2. Deze driver moet in de Linux kernel geladen worden en kan dan door andere programma’s gebruikt worden om gegevens te verzenden van en naar het hardware platform.

• Een aantal losstaande commando-lijn programma’s. Deze worden onder andere gebruikt om de FPGA te programmeren, data te verzenden, data te ontvangen en analoge componenten te conﬁgureren via een I2C bus. 6.2 Gebruikte technologie 70

Om het systeem te gebruiken met de originele software, moeten een reeks handelingen uitgevoerd worden. De gebruiker moet een aantal commando-lijn vensters openen en daarna, in correcte volgorde, verschillende programma’s oproepen. Een typische reeks acties die uitgevoerd moeten worden is deze:

• De FPGA programmeren.

• Andere componenten instellen via de I2C bus.

• De FPGA starten en de resultaten opslaan in een tekst bestand.

• Dit tekst bestand inlezen in Matlab en daar verwerken (bijv: graﬁek tekenen).

Deze functionaliteit moet ge¨ıntegreerd worden in ééngrafische omgeving. De afzonderlijke functionaliteit moet echter wel nog steeds beschikbaar zijn. Voor deze alleenstaande acties moet telkens een geschiedenis bijgehouden worden van de 10 laatst gebruikte bestanden en/of programma- argumenten. Het onderdeel met de ge¨ıntegreerde functionaliteit voert deze acties continu uit en toont een grafiek van de resultaten. De gebruiker kan een groot aantal parameters instellen vooraleer de metingen beginnen. Tijdens de metingen zelf kan de voorstelling van de grafiek gewijzigd worden. Er kan gekozen worden voor een stapantwoord of een impulsantwoord en voor een lineaire schaal of een logaritmische schaal. Deze keuze kan gewijzigd worden zonder de metingen te onderbreken, zonder de data te wijzigen en zonder merkbare vertraging.

6.2 Gebruikte technologie

6.2.1 Programmeertaal

Voor de communicatie met de hardware moet de fx2 driver gebruikt worden. We hebben al een aantal C-programma’s die hiervan gebruik maken. Waarschijnlijk is het ook mogelijk deze driver rechtstreeks vanuit Java aan te spreken, maar daar hebben we geen ervaring mee en dat zal dus veel opzoekwerk en -tijd met zich mee brengen. Een graﬁsche interface maken is echter een stuk makkelijker in Java dan in C. Java maakt het ons ook mogelijk om de graﬁsche omgeving zowel op Windows als op Linux te ontwikkelen. Een nadeel van Java is dat memory leaks moeilijker te detecteren en te voorkomen zijn. 6.2 Gebruikte technologie 71

Op basis van de argumenten in de vorige paragraaf besluiten we om de grafische omgeving in Java te programmeren en te communiceren met de hardware via C-code. Het enige nadeel van deze aanpak is dat we wat moeilijker feedback van de hardware communicatie in de user interface kunnen tonen. We kunnen wel de console-output van de C-code tonen en bij het beëindigen van de C-code kunnen we ééngetal doorgeven, waarmee eventuele fouten gemeld kunnen worden.

6.2.2 Externe bibliotheek : JChart2D

Voor het tekenen van een grafiek in Java maken we gebruik van de vrije bibliotheek JChart2D[16]. Er zijn veel verschillende Java bibliotheken beschikbaar om grafieken te tekenen. Een lijst met een aantal van deze bibliotheken kan online gevonden worden op [17]. De meeste van deze bibliotheken zijn vooral gericht op het presenteren van statische data. Ze bevatten dus veel mogelijkheden om het uitzicht en de vorm van het resultaat aan te passen. Ze zijn vooral te vergelijken met de “Maak een grafiek” mogelijkheden van software zoals Excel. Dit is niet echt wat we nodig hebben voor onze user interface. Wij hebben een bibliotheek nodig die gericht is op snelheid en nauwkeurigheid. Hiervoor is JChart2D ideaal. Ze bevat slechts een vijftal grafiekstijlen, maar ze is uitstekend geschikt om snel wijzigende data voor te stellen.

Van deze bibliotheek is ook de broncode vrij beschikbaar. Dit is een belangrijk positief punt, want daardoor kunnen we zelf wijzigingen aanbrengen of functionaliteit toevoegen die er niet standaard in zit. Deze toegevoegde functionaliteit zenden we door naar de auteur van JChart2D. Hieronder staan een aantal voorbeelden van zelf toegevoegde functionaliteit:

• Logschaal: Door op een klein aantal goedgekozen plaatsen de code te wijzigen, slagen we erin een graﬁek in een logaritmische schaal voor te stellen. Dit is functionaliteit die reeds vele gebruikers van de bibliotheek gevraagd hadden, maar waar de auteur nog geen tijd voor had om ze te implementeren.

• In- en uitzoomen: Standaard herschaalt deze bibliotheek de grafiek automatisch, zodat alle punten zichtbaar zijn. Er is echter ook een mogelijkheid om een vast bereik op te geven voor de assen. Door het toevoegen van een functie die muis coördinaten omzet in grafiek coördinaten, kunnen we nu relatief makkelijk in- en uitzoomen.

• De datapunten voor elke graﬁek kunnen op verschillende manieren bijgehouden worden. In de bibliotheek worden een aantal mogelijkheden aangeboden die Java Collection objecten 6.2 Gebruikte technologie 72

gebruiken. De gegevenspunten bevatten telkens een X en een Y waarde. Wanneer een datapunt toegevoegd wordt, wordt eventueel het “oudste” punt verwijderd om te vermijden dat de maximum capaciteit overschreden wordt. Voor ons is deze functionaliteit echter niet nodig om deze redenen:

– We hebben telkens een vast aantal punten.

– We voegen alle punten die getoond moeten worden in ´e´en keer toe, er is dus geen “oudste” punt en alle punten moeten getoond worden.

– De datapunten liggen op een constante afstand van elkaar op de X-as.

Hiervoor maken we een alternatief dat gebruik maakt van een normale array met vaste grootte. Op het ogenblik dat datapunten toegevoegd worden aan de graﬁek, doet hun X-waarde dienst als index in deze array. Hierna worden de X-waarden herschaald met een in te stellen factor, zodat de X-as ook een betekenisvolle schaal krijgt. Dit werkt veel sneller en herbruikt telkens dezelfde geheugenlocaties voor alle opeenvolgende graﬁeken.

Naast het toevoegen van functionaliteit is de beschikbaarheid van de broncode ook nuttig om een aantal problemen met deze bibliotheek op te lossen. In de eerste versie die we gebruiken zitten een aantal bugs (oa: een geheugenlek en foutieve interpolatie naar datapunten die buiten het scherm vallen). Wanneer we een oplossing vinden voor deze problemen, melden we ze (samen met de voorgestelde oplossing) aan de auteur. Een maand later is er een nieuwe versie van de bibliotheek beschikbaar die deze problemen voor iedereen oplost.

In de vorige paragrafen lag de focus vooral op de wijzigingen die we zelf aanbrengen aan deze bibliotheek. Dit betekent echter niet dat het gebruik van JChart2D een slechte keuze is. Het gebruik ervan bespaart ons een stuk tijd. De snelheid van het tekenen van de graﬁek is sterk geoptimaliseerd en daaraan wijzigen we niets. Ook aan vele “details” moeten we geen tijd besteden (zoals: de labels op de assen zetten, de legende erbij zetten, een rooster tekenen op de achtergrond, mogelijkheid om de kleuren aan te passen, ...). De code is speciﬁek gemaakt om ge¨ıntegreerd te worden in verschillende projecten, dit zal nuttig zijn wanneer iemand onze user interface wil uitbreiden. 6.3 Functionaliteit 73

6.3 Functionaliteit

In de volgende delen van dit thesis boek worden een aantal technische onderdelen van dit programma besproken. De onderdelen van sectie 6.4 bespreken telkens de implementatie van een deel van de functionaliteit. Deze sectie (6.3) zal eerst de volledige functionaliteit beschrijven.

Figuur 6.1: Overzicht userinterface

Figuur 6.1 is een voorbeeld van wat de gebruiker te zien krijgt. Bovenaan links staat de datum van de laatste wijziging en het logo van de vakgroep Intec Design, waar we aan deze thesis werken. Net daaronder, aangeduid met de letter A in de figuur, staat de frontend keuzemoge- lijkheid. Tijdens de ontwikkeling van deze software wordt ook de hardware verder ontwikkeld. Verschillende versies van deze hardware hebben andere componenten aan boord, dus de nuttige 6.3 Functionaliteit 74 functionaliteit verschilt voor elke versie. In Figuur 6.1 staat een voorbeeld van zo een verschil. Hier wenst de gebruiker de versterking aan te passen van éénvan de componenten via de I2C-bus. Dit is enkel mogelijk in versie vier van de hardware, want in vorige versies was deze component niet aanwezig. Op basis van de keuze die de gebruiker maakt bij A, wordt de navigatielijst, aangeduid met B in de figuur, aangepast. In deze navigatielijst kiest de gebruiker welk scherm zichtbaar moet zijn aan de rechterkant.

Figuur 6.2: Ge¨ıntegreerde functionaliteit

Figuur 6.2 toont het scherm met de ge¨ıntegreerde functionaliteit. Bovenaan staan een aantal opties die kunnen ingesteld worden vooraleer de metingen gestart worden. Deze komen overeen met de parameters die besproken werden in Sectie 5.3 in het hoofdstuk over de VHDL code. Hier worden ze echter in betekenisvolle eenheden getoond en worden omgezet naar een aantal klokcycli voor ze naar de FPGA gestuurd worden.

Naast deze instellingen staan drie knoppen: “Measure once”, “Read last” en “Run”. “Measure once” zal de FPGA programmeren, de gekozen parameters versturen en daarna de opdracht geven om N metingen uit te voeren. Hierna bevindt het resultaat (de som van N metingen) zich 6.3 Functionaliteit 75

Parameter Betekenis N Het aantal metingen die de hardware moet uitvoeren vooraleer hun som doorgezonden wordt naar de pc. W De lengte van de lichtpuls die uitgezonden wordt in de optische vezel vooraleer de meting gestart wordt. In het voorbeeld hier is dit een zeer lange tijd (langer dan de tijd die het licht nodig heeft om zich voort te planten tot het einde van de vezel en terug). Daardoor meten we eigenlijk een invers stapantwoord ipv een impulsantwoord. L Het gewenste meetbereik. Om de reflectie aan het eind van de vezel te zien, moet dit meetbereik een stukje groter zijn dan de effectieve lengte van de te meten vezel. Transiënt parameters Dit is een bestand dat de waarde van de parameters T1 ... T5 en TT1 ... TT4 bevat. Dit is een gewoon tekstbestand, met de waarde voor elke parameter op een nieuwe lijn. Deze waarden worden wel in “aantal klokcycli” verwacht. Zie Figuur 5.8 voor de betekenis van deze parameters. Filtercoëfficiënten Dit bestand bevat de waarde van de filtercoëfficiënten in een gelijkaardig formaat als dat voor de transiënt parameters. Channel 1 / 2 Met deze twee opties kan geselecteerd worden op welk van de twee kanalen een meting uitgevoerd moet worden. Interleaved Wanneer deze optie geselecteerd is, wordt elke meting afgewisseld door een meting waarbij de laserdiode niet aangestuurd wordt. Door deze laatste telkens af te trekken van de echte meting, kunnen een aantal ongewenste effecten geneutraliseerd worden. Filter Elke meting wordt eerst door een laagdoorlaatfilter gestuurd om zo- veel mogelijk ruis te verwijderen. Deze filter kan eventueel uitgeschakeld worden met deze optie op de user interface. Mov Avg Dit is een parameter die niet naar de hardware doorgestuurd wordt. In de user interface worden alle metingen nog eens verwerkt door een moving average filter. Hiermee kan je de moving average parameter instellen. Meer info hierover staat in Sectie 6.4.1 Tabel 6.1: Instellingen bovenaan de user interface 6.3 Functionaliteit 76 in het geheugen van de FPGA. Dit resultaat wordt uitgelezen naar een tekst bestand en getoond als grafiek wanneer “Read last” uitgevoerd wordt. Deze twee acties zijn gesplitst zodat identiek dezelfde gegevens meerdere keren uit de FPGA kunnen gelezen worden. Dit is onder andere nuttig om de stabiliteit van de communicatie tussen de hardware en de software te verifiëren. Terwijl deze acties uitgevoerd worden, worden de drie knoppen onbruikbaar gemaakt zodat het niet mogelijk is om twee taken tegelijkertijd uit te voeren. Dat zou de communicatie tussen de pc en de hardware verstoren en onverwachte resultaten geven.

De knop “Run” start de continue metingen. De gebruiker ziet twee grafieken per kanaal die continu (zo snel mogelijk) aangepast worden. Eén grafiek toont telkens de laatste nieuwe meting, op de andere grafiek kan de gebruiker een uitgemiddelde versie zien. Eerst wordt éénmaal de FPGA geprogrammeerd en worden de gekozen parameters verstuurd. Hierna wordt continu een lus uitgevoerd, tot de gebruiker deze knop (die nu het opschrift “Stop” heeft) nog eens indrukt. De lus bestaat uit een aantal taken: (a) het signaal zenden naar de FPGA om te starten met meten, (b) het resultaat lezen uit het geheugen van de FPGA en wegschrijven naar een aantal tekstbestanden en tenslotte (c) deze tekstbestanden lezen en de twee grafieken op het scherm aanpassen. De grafiek met het extra gemiddelde zal na de eerste meting uiteraard identiek zijn aan de meting zelf. Elke keer dat er volgende resultaten binnenkomen op de pc, zal de ruis op de grafiek van het extra gemiddelde verminderen. In Figuur 6.2 is dit zichtbaar als respectievelijk de lichtblauwe en de donkerblauwe grafiek. De lichtblauwe grafiek toont de laatste meting die de hardware naar de pc gezonden heeft, de donkerblauwe toont het gemiddelde van alle resultaten die reeds ontvangen werden (114). Meer gedetailleerde info over dit extra uitmiddelen staat in 6.4.1.

Onder deze parameter instellingen staan de graﬁeken. Aan de rechterkant staan verschillende items: feedback over de voortgang van de metingen, parameters om het uitzicht van de graﬁek aan te passen en mogelijkheden om de gegevens te exporteren. De feedback staat op drie verschillende plaatsen. In het bovenste tekstveld staat een aanduiding van welke C-code laatst gestart of gestopt werd (meer info hierover in 6.4.4). In het tweede tekstveld staat een teller die bijhoudt hoeveel resultaten de user interface reeds ontvangen heeft van de hardware. Helemaal onderaan staat een knop “show log”. Deze zorgt ervoor dat er onderaan een tekstvak verschijnt (+/- 6 regels hoog), waarin de volledige output van de C-code getoond wordt.

De gegevens kunnen op twee verschillende manieren ge¨exporteerd worden: als afbeelding in een 6.3 Functionaliteit 77 png-bestand of als data in een tekstbestand. Bij exporteren als afbeelding wordt telkens een afbeelding gemaakt van hoe de graﬁeken op dat moment op het scherm staan. Bij exporteren naar een tekstbestand kan de gebruiker een aantal opties kiezen.

De derde soort items in deze balk aan de rechterkant bieden mogelijkheden om het uitzicht van de grafiek te wijzigen. Eerst en vooral kan er gekozen worden voor excitatie van de vezel met een invers stapantwoord of een impulsantwoord. Hierbij gaan we uit van de veronderstelling dat de gebruiker een zeer lange puls gekozen heeft, zodat de glasvezel volledig gesatureerd is vooraleer de laser uitgeschakeld wordt. Het opgemeten resultaat is nu een invers stapantwoord. Dit kunnen we zeer eenvoudig omvormen tot een impulsantwoord voor een puls van willekeurige lengte. Hiervoor maken we eerst een verschoven versie van de grafiek (verschoven over de gewenste lengte van de puls). Het verschil van deze twee grafieken is dan het impulsantwoord. Meer info over deze techniek staat in het artikel [2]. De gebruiker kan eenvoudig wisselen tussen beide voorstellingsmethoden met de knop “Step resp” of “Pulse Resp”. Het opschrift duidt telkens aan welke grafieken nu op het scherm staan. Net daaronder kan gekozen worden tussen een lineaire schaal op de Y-as (zoals in Figuur 6.2) of een logaritmische schaal. Een logaritmische schaal is nuttig omdat een OTDR meting normaal gezien een exponentieel resultaat heeft, wat zorgt voor een rechte in een log-schaal. Dit is echter enkel het geval wanneer de exponentiële daalt naar nul. Bij de metingen is dit slechts in uitzonderlijke gevallen zo. Normaal hebben beide kanalen een verschillende offset, die zowel positief als negatief kan zijn. De “interleaved” optie biedt hier geen oplossing, want deze neutraliseert enkel de offset veroorzaakt door de elektronica. Het negatief impulsantwoord is echter opgebouwd uit de som van een constante en een exponentiële. Deze constante component wordt niet geneutraliseerd bij “interleaved” meten, want die is niet aanwezig als de vezel niet geëxciteerd wordt. Bij het tonen van een impulsantwoord daarentegen, heeft de grafiek wel altijd een horizontale asymptoot die voldoende dicht bij nul ligt. Om deze reden is het enkel mogelijk om een logaritmische schaal te gebruiken om het impulsantwoord voor te stellen. In Figuur 6.3 staat aangegeven wat de twee knoppen precies doen in verschillende gevallen.

Met de derde knop, “Conﬁg”, kunnen een aantal parameters ingesteld worden voor de om- vormingen naar impulsantwoord en logaritmische schaal. De mogelijkheden staan afgebeeld in Figuur 6.4. De eerste parameter is de breedte van de puls voor het omvormen van stapantwoord naar impulsantwoord. Deze parameter wordt niet geschaald naar een lengte of een tijd, 6.3 Functionaliteit 78

Figuur 6.3: Overgangen tussen de drie mogelijke conﬁguraties

Figuur 6.4: Instellingen voor het impulsantwoord en de logaritmische schaal maar duidt het aantal meetpunten aan waarover de graﬁek moet verschoven worden voordat het verschil genomen wordt. Dit aantal is uiteraard gelijk aan het aantal klokcycli dat de laser zou moeten aangeschakeld worden om een zelfde resultaat te krijgen indien we rechtstreeks een impulsantwoord opmeten.

De volgende parameters hebben allemaal te maken met het omvormen van een lineaire waarde naar een logaritmische waarde. De basis formule die gebruikt wordt staat in 6.1

ylog = A · log10 (max (ylin, ylin,min)) (6.1)

De functie log10 kan enkel uitgevoerd worden op getallen groter dan 0. Dit geeft problemen op het eind van de graﬁek, waar typisch enkel witte ruis gemeten wordt, met gemiddelde 0. Om dergelijke problemen te vermijden, wordt ylin naar beneden begrensd door een kleine waarde

(0,0010 in de Figuur 6.4 , ylin,min in vergelijking 6.1). Dit heeft echter als resultaat dat meer dan 50% van de ruis zomaar weggesneden wordt. Normaal is dit niet echt een probleem, tenzij de signal-to-noise ratio bepaald moet worden. Daarom is er een extra optie voorzien, “use absolute values”, die eerst de absolute waarde neemt van ylin. Deze twee opties worden ge¨ıllustreerd in Figuur 6.5. De laatste parameter die hier kan ingesteld worden, is A. Dit is de A uit vergelijking 6.3 Functionaliteit 79

6.1. In normale omstandigheden is A altijd 5.

(a) Enkel ondergrens (b) Absolute waarde + ondergrens

Figuur 6.5: Het eﬀect van de parameter ylin,min en het gebruik van absolute waarden.

Verder kan het uitzicht van de grafiek interactief gewijzigd worden door de zoom functionaliteit. Er zijn drie zoom statussen: zoom in, zoom uit en verplaats. Deze kunnen ofwel vrij zijn in de twee dimensies, ofwel beperkt tot enkel horizontaal of verticaal wijzigen van het zichtbare gebied. Om ervoor te zorgen dat de grafiek nooit zoekraakt, is er de “Reset” knop. Deze zet beide assen terug op hun standaardwaarde. Voor de X-as is dit van 0 tot de lengte van de glasvezel (opgegeven bij parameter L), voor de Y-as is dit het volledige bereik van de ADC op de hardware. Deze grenzen zijn meteen ook de absolute minima en maxima die op de grafiek te zien zijn. Zelfs al probeert de gebruiker de grafiek op te schuiven of uit te zoomen zodat negatieve X-waarden in beeld zouden komen, de actie zal beperkt worden zodat dit niet gebeurt. Idem voor de andere grenzen (xmax, ymin, ymax). Dit helpt om de grafiek niet uit beeld te verliezen en om de grafiek tot precies op de grenswaarde in beeld te hebben. 6.4 Implementatie 80

6.4 Implementatie

Dit is een meer technisch onderdeel van deze scriptie. Hierin wordt de achterliggende code toegelicht. Eerst en vooral volgt er wat meer info over het moving average filter dat gebruikt wordt voor extra uitmiddeling in de user interface. Daarna bespreken we het framework van de user interface in drie delen. In onderdeel 6.4.2 wordt uitleg gegeven over het config.xml bestand dat we gebruiken om zowel de algemene configuratie van de user interface als de geschiedenis van de verschillende parameters in op te slaan. Vervolgens bespreken we het framework dat we gebruiken voor de verschillende schermen aanwezig in deze gui (6.4.3), en het framework voor het uitvoeren van acties (6.4.4). Deze twee staan uiteraard niet los van elkaar, maar zijn eigenlijk één geheel (bijv: als de gebruiker wisselt van scherm, worden automatisch alle actieve acties afgebroken).

6.4.1 Moving average ﬁlter

In deze sectie zal meer uitleg gegeven worden over het extra gemiddelde in de user interface dat kort aangehaald werd in de bespreking van de functionaliteit. Dit is geen normaal rekenkundig gemiddelde, maar een moving average ﬁlter. Een rekenkundig gemiddelde kan makkelijk gemaakt worden op dezelfde manier als in de FPGA:

• Telkens de nieuwe resultaten bij het vorige sub-totaal optellen.

• Bij het tekenen van de graﬁeken rekening houden met het aantal resultaten dat gesommeerd werd om de schaal aan te passen.

Deze manier van werken is geheugen efficiënt. Er kan gewerkt worden met data elementen van het type long, die 64 bits lang zijn. Hierin kunnen 232 resultaten van de hardware gesommeerd worden vooraleer er kans is op overflow. Het nadeel ervan echter, is dat alle resultaten even- waardig zijn. Wanneer er een breuk optreedt in de glasvezelkabel na 10000 “normale” metingen, zal het nog 10000 metingen extra duren vooraleer het effect voor 50% zichtbaar is in de uitgemiddelde versie. Om dit probleem niet te hebben, willen we een soort “venster” instellen dat aangeeft hoeveel metingen moeten uitgemiddeld worden. Het probleem bij deze aanpak echter, is dat we elke meting afzonderlijk moeten bijhouden. Dit vraagt meteen een heel stuk meer 6.4 Implementatie 81 geheugen. Bij een relatief klein venster van 100 metingen hebben we dan reeds 3200 bits per datapunt nodig (in vgl met 64 bits per datapunt in de vorige methode). De methode die wij gebruiken, een moving average filter, werkt op een andere manier, aangegeven met vergelijking 6.2. a − 1 1 avg = · avg + · new (6.2) new a old a De a in deze vergelijking is de Mov Avg parameter uit Tabel 6.1. Deze manier van werken zorgt ervoor dat de bijdrage van de laatste grafiek telkens 1/a is. Het belang van de bijdrages van de vorige metingen daalt exponentieel, afhankelijk van de parameter a. De bijdrage van een meting na a nieuwe metingen is ongeveer 36%, na 2a nieuwe metingen is dit nog ongeveer 13% (ten opzichte van 100% voor de laatste nieuwe meting). Ter vergelijking: indien we alle laatste a metingen afzonderlijk bijhouden en er een rekenkundig gemiddelde van berekenen, dan is de bijdrage van de laatste a metingen gelijk aan 100% en van deze daarvoor 0%. Bij de keuze van deze parameter a wordt dus een afweging gemaakt tussen ruisonderdrukking in de extra uitgemiddelde grafiek en de snelheid waarmee deze grafiek reageert op plotse wijzigingen in de glasvezelkabel. Dit algemene moving average filter heeft wel een probleem bij de initialisatie: avgold bestaat nog niet. avgold initialiseren op 0 is geen goede oplossing, want dan “klimt” de uitgemiddelde grafiek als het ware traag omhoog vanaf de X-as. Om dit te vermijden passen we de a in vergelijking 6.2 aan, zodat a niet de parameter is die ingesteld wordt in de user interface, maar het minimum van deze parameter en het aantal metingen die reeds gedaan werden op de

FPGA. Deze aanpassing zorgt ervoor dat a start als 1, waardoor avgnew = 0 · avgold + 1 · new. 1 1 De volgende keer wordt a gelijk aan 2, waardoor avgnew = 2 · avgold + 2 · new. ... Zolang er dus nog geen a metingen uitgevoerd zijn, gebruiken we toch een normaal rekenkundig gemiddelde.

Een laatste voordeel van deze aanpak is dat er nooit overﬂow kan optreden, want de grootte van avgnew wordt beperkt door de grootte van de inputs.

6.4.2 XML

Er moeten een aantal gegevens onthouden worden voor de goede werking van het programma. Er zijn hiervan 2 categorie¨en:

• Conﬁguratie: Dit zijn alle instellingen die normaal niet vaak wijzigen, zoals de frequentie van de elektronica, de brekingsindex van de glasvezel en de locatie van de verschillende 6.4 Implementatie 82

C-programma’s die opgeroepen worden.

• Geschiedenis: Dit zijn alle instellingen die eventueel voor elke meting aangepast kunnen worden, zoals het aantal keer dat er in de FPGA moet uitgemiddeld worden en welk scherm open stond toen het programma afgesloten werd. In een aantal gevallen worden de laatste 10 instellingen onthouden, bijvoorbeeld bij de keuze van het bestand met transi¨ent tijden.

De configuratie gegevens zijn constanten die door elk scherm gebruikt kunnen worden. Deze constanten worden bij het opstarten van het programma ingelezen in een aantal publieke sta- titische variabelen van Main.java. In het “config” scherm kunnen deze constanten aangepast worden. Hiermee worden de variabelen in Main.java aangepast, maar een aantal van deze waarden worden enkel gebruikt bij de initialisatie en zullen dus niet meteen effect hebben. Daarom wordt aangeraden om het programma af te sluiten en te herstarten na het wijzigen van deze parameters.

De gegevens in verband met geschiedenis worden ook bijgehouden in het xml bestand. Deze staan geordend per “frontend” en per “scherm”. Elk scherm komt overeen met een element in het xml bestand. Deze elementen kunnen drie sub-elementen hebben:

• : Sommige schermen in dit programma hebben, vanuit de java architectuur gezien, een aantal sub-schermen. Bijvoorbeeld het “debug” scherm bestaat uit een deel om de FPGA the programeren en een deel om code uit te voeren op de pc. Dit zijn twee sub-panels van het debug panel.

• : Gegevens waarvan enkel de vorige waarde onthouden wordt. Deze staan als argumenten in ´e´enelement .

• : Als laatste volgen de lijsten voor de gegevens waarvan een uitgebreidere geschiedenis moet bijgehouden worden.

Ook de ordening van de verschillende panel- en frontend-elementen is van belang. Wanneer het programma opstart zal het scherm getoond worden dat als eerste in het xml bestand voorkomt. In Figuur 6.6 staat een sterk ingekort bestand om deze structuur te verduidelijken. Het “grafiek” scherm van “Frontend4” stond laatst open toen het programma afgesloten werd. Dit scherm heeft éénsub-scherm, “extChart”. 6.4 Implementatie 83

Figuur 6.6: Een sterk ingekort voorbeeld om de xml-structuur te verduidelijken

De hulpklasse XMLLogic.java neemt het gros van deze taken op zich.

• “getFrontEndIndex()” is een functie die een lijst van frontends als argument neemt. Ze geeft als resultaat de positie in deze lijst van de laatst gebruikte frontend. Om het laatst gebruikte scherm te vinden in een lijst is er de gelijkaardige functie “getPanelIndex()”. Natuurlijk zijn ook de inverse functies “storeCurrentFrontEnd()” en “storeCurrentPanel()” aanwezig.

• De constanten worden van het XML-bestand naar de variabelen in Main.java gelezen door de functie “loadConstants()”. De omgekeerde bewerking gebeurt uiteraard door “storeConstants()”.

• Om de geschiedenis lijst in een dropdown selectie te laden, wordt de functie “loadCom- boBox()” gebruikt. Hiervoor moet uiteraard meegegeven worden over welke frontend, welk scherm en welke lijst het precies gaat. Wanneer een nieuw item aan deze lijst moet toegevoegd worden, kan de functie “addComboBoxItem()” gebruikt worden.

• Soms moeten ook extra gegevens bijgehouden worden per item in zo’n geschiedenis lijst. 6.4 Implementatie 84

Bijvoorbeeld bij het debug-scherm, moeten naast de laatst gekozen programma’s ook de gebruikte argumenten bewaard worden. Hiervoor zijn er opnieuw twee nuttige functies: “loadAttributes()” en “storeAttributesLastUsed()”. Beide hebben als argumenten het gekozen item in een bepaalde lijst, en een tabel die de namen van de xml-attributen linkt met componenten op de user interface.

• Voor de gegevens waarvan enkel de laatste waarde bewaard wordt, zijn er de functies “loadSingleValues()” en “storeSingleValues()”. Beide nemen als argument een tabel die de namen van de xml-attributen linkt met componenten op de user interface.

6.4.3 JOtdrPanel

Deze klasse wordt gebruikt als superklasse van alle “schermen” die gebruikt worden in dit programma. Hier bespreken we enkel de belangrijkste functionaliteit die deze superklasse realiseert voor het framework. Een instantie van deze klasse is wat betreft layout nog steeds een normale JPanel in de swing bibliotheek van Java. Dit betekent dat er andere componenten opgeplaatst kunnen worden net als op een gewone JPanel. Een JOtdrPanel kan dus als gewone component op een andere JOtdrPanel geplaatst worden. In dit laatste geval spreken we van een ouder-kind relatie. Het bijhouden van deze ouder-kind relaties is belangrijk voor een aantal functionalitei- ten. E´envoorbeeld waar dit belangrijk is, is voor de werking van het xml bestand. Zoals in 6.4.2 besproken, wordt deze ouder-kind relatie daar ook gebruikt. Een ander voorbeeld waar dit nodig is, is bij het afsluiten van een scherm. Op dat moment moeten alle lopende acties afgebroken worden, ook die die gestart zijn in alle sub-panels. Om dit mogelijk te maken worden er drie belangrijke lijsten bijgehouden per scherm:

• “parentPanels”: Dit is een geordende lijst van JOtdrPanels die de ouder-kind hi¨erarchie doorloopt, van de top tot de rechtstreekse ouder van de huidige JOtdrPanel. Voor de JOtdrPanels aan de top is deze lijst dus leeg.

• “childPanels”: Dit is een ongeordende lijst van alle sub-panels.

• “running”: Dit is een ongeordende lijst van alle OtdrActions die gestart werden vanuit dit scherm en op dit moment aan het uitvoeren zijn. Dit zijn de acties die moeten afgebroken worden wanneer het scherm afgesloten wordt. 6.4 Implementatie 85

Deze lijsten worden voor het grootste deel door het framework zelf beheerd. De lijsten “parent- Panels” en “childPanels” worden automatisch aangepast door de constructor van het subpanel. De constructor van een JOtdrPanel heeft als argument (onder andere) zijn ouder. Indien er geen ouder is (er wordt een top-level JOtdrPanel aangemaakt), gebeurt er niets. Indien er wel een ouder is, wordt de “parentPanels” lijst gekopieerd van de ouder naar het kind en wordt de ouder zelf er achteraan aan toegevoegd. Ook wordt het net aangemaakte JOtdrPanel toegevoegd aan de “childPanels” lijst van de ouder. Deze twee acties zijn voldoende om de lijsten voor de ouder-kind relaties te beheren.

De derde lijst, die de acties bijhoudt die op dit moment uitgevoerd worden, wordt aangepast door de twee functies “addAction” en “removeAction”. Deze twee functies worden opgeroepen door de acties zelf, maar meer info hierover staat in 6.4.4.

Deze klasse bevat ook nog twee andere functies die gebruik maken van deze lijsten:

• “loadConfig”: Dit is een functie die opgeroepen wordt wanneer een scherm getoond moet worden. Het is de bedoeling dat deze functie overschreven wordt door de subklassen van JOtdrPanel en dat ze hierin alle componenten initialiseren met behulp van de xml-functies beschreven in 6.4.2. In de subklassen moet als eerste commando super.loadConfig() opgeroepen worden. Dit zorgt ervoor dat eerst de code hier, in de functie loadConfig van de klasse JOtdrPanel, uitgevoerd wordt. Het enige wat deze code doet is loadConfig() oproepen op alle elmenten in de lijst “childPanels”.

• “cancelAll”: Deze functie moet opgeroepen worden wanneer een scherm afgesloten wordt of wanneer een nieuwe actie gestart wordt. Eerst wordt cancelAll() uitgevoerd op alle elementen in de lijst “childPanels”, daarna wordt cancel() (zie 6.4.4) uitgevoerd op alle elementen in de lijst “running”.

De functies “addAction”, “removeAction” en “cancelAll” zijn samengevoegd in een interface: CancelInterface.

6.4.4 OtdrAction

Dit is de superklasse van alle acties die uitgevoerd kunnen worden. De echte functionaliteit om de actie uit te voeren is enkel aanwezig in de subklassen. Deze superklasse zorgt ervoor dat 6.4 Implementatie 86 een aantal acties in een wachtlijst geplaatst kunnen worden om dan één voor éénuitgevoerd te worden. Het is mogelijk een tijdsvertraging mee te geven tussen deze en de volgende actie. Elke actie kan blokkerend gestart worden, wat betekent dat de thread die de actie start wacht tot deze actie uitgevoerd is. Er kan echter ook niet-blokkerend gewerkt worden. In dat laatste geval wordt een nieuwe thread opgestart die de actie uitvoert. Een voordeel hiervan is dat de user interface blijft reageren op input van de gebruiker. Voor sommige acties die continu uitgevoerd moeten worden, moet er sowieso op een dergelijke manier gewerkt worden. Alle acties kunnen het signaal krijgen om meteen te stoppen. In dat geval mogen alle volgende acties in de wachtlijst ook niet gestart worden. Soms staat er echter een actie in de wachtlijst die in elk geval moet uitgevoerd worden, ook als een van de vorige acties geannuleerd werd. Al deze functionaliteit wordt voorzien in deze superklasse, samen met het geven van feedback over wat er precies gebeurt.

Om dit allemaal te realiseren moeten een aantal gegevens bijgehouden worden:

• “next” is een referentie naar de actie die uitgevoerd moet worden nadat de huidige actie afgelopen is. De tijd die moet gewacht worden tussen beide acties, wordt bewaard in “wait”.

• “blocking” en “no cancel” zijn twee waarden die respectievelijk bijhouden of de huidige thread moet wachten tot de actie gedaan is en of de actie echt moet geannuleerd worden wanneer dat gevraagd wordt.

• Feedback over de status van deze actie wordt geplaatst in het tekstveld “feedback”. Om duidelijk te maken van welke actie deze feedback komt, bevat “feedbackString” de naam van deze actie (of een andere willekeurige tekst die deze actie duidelijk identiﬁceert).

• “iCancel” is de link tussen de klasse OtdrAction en de klasse JOtdrPanel die in 6.4.3 besproken wordt. Deze variabele bevat een referentie naar het JOtdrPanel waaraan de actie verbonden is. De functies addAction en removeAction worden op iCancel uitgevoerd om bij te houden welke acties op dit moment in uitvoering zijn.

Elke subklasse van OtdrAction moet de echte functionaliteit zelf implementeren. Hiervoor moeten ze de twee functies “startAction” en “stopAction” implementeren. Om de superklasse Otdr- Action goed te laten werken, moet “startAction” een referentie teruggeven naar een Thread die stopt wanneer de actie voorbij is. 6.4 Implementatie 87

De drie belangrijkste functies hier zijn “start”, “cancel” en “ﬁnish”. Hieronder staat kort wat er gebeurt wanneer deze functies opgeroepen worden:

• start

– Meld aan het JOtdrPanel dat deze actie nu gestart is.

– Indien een tekstveld opgegeven werd voor feedback, zet daarin de tekst : “feedback- String started”.

– Roep de functie startAction op die ge¨ımplementeerd is door de speciﬁeke subklasse. Bewaar de referentie naar het Thread-object.

– Wacht tot de Thread gedaan is en start dan de functie ﬁnish (zie verder). Afhankelijk van de waarde van ”blocking”, zal dit gebeuren in de huidige thread of in een nieuwe Thread.

• ﬁnish

– Indien een tekstveld opgegeven werd voor feedback, zet daarin de tekst : “feedback- String ﬁnished”.

– Indien er een tijdsvertraging opgegeven werd voor de volgende actie, wacht.

– start de volgende actie (met de functie start, niet met startAction rechtsreeks).

– Meld aan het JOtdrPanel dat deze actie nu gestopt is.

• cancel

– Indien deze actie niet kan geannuleerd worden, doe niets.

– Indien de volgende actie kan geannuleerd worden, annuleer ze. In het andere geval, start ze.

– Indien een tekstveld opgegeven werd voor feedback, zet daarin de tekst : “feedback- String cancelled”.

– Roep de functie stopAction op die ge¨ımplementeerd is door de speciﬁeke subklasse.

Een aantal voorbeelden van ge¨ımplementeerde subklassen hiervan zijn de volgende :

• RunC : Hiermee wordt een uitvoerbaar bestand gestart, met eventueel argumenten. 6.4 Implementatie 88

• ProgramFPGA : Dit is een subklasse van RunC, en zorgt ervoor dat de FPGA geprogrammeerd wordt.

• JavaMethod : Deze klasse kan gebruikt worden om een willekeurige Java methode (die geen argumenten heeft) uit te voeren. Dit kan handig zijn voor het geval een functie moet opgeroepen worden nadat een bepaalde actie uitgevoerd is.

• FileToArray : Hiermee wordt een tekstbestand geopend en worden de getallen uitgelezen en bewaard in een array.

• ArrayToTraces : Deze actie gebruikt de array gemaakt door FileToArray, en voegt de elementen toe als punten op een graﬁek. BESLUIT 89

Hoofdstuk 7

Besluit

In deze thesis zijn er drie belangrijke verbeteringen aan het oorspronkelijke kwaliteitsbewakingssysteem aangebracht. Door de dynamische configuratie van de FPGA’s kan men de eigenschappen van de meting veranderingen tijdens de uitvoering. In de vorige implementatie moest daarvoor telkens de VHDL code aangepast en opnieuw gesynthetiseerd worden. The grafische user interface integreert de functionaliteit van verschillende programma’s die normaalgezien via de commando lijn opgeroepen worden. De grafische user interface zorgt er ook voor dat de data grafisch wordt voorgesteld. De derde verbetering aan het monitorsysteem is de mogelijkheid om continu OTDR-metingen uit te voeren. Daarnaast werden er ook een aantal nieuwe technieken ge¨ıntroduceerd die de kwaliteitsbewaking in de toekomst zouden kunnen verbeteren.

Het belangrijkste resultaat van deze thesis is echter het feit we nu gewapend zijn met een pak praktische ervaring. We kregen de kans om enkele nieuwe technologieën te onderzoeken en konden veel ervaring opdoen bij de implementatie van de digitale elektronica en de grafische user interface. Een belangrijke factor om deze thesis tot een goed einde te brengen was de samenwerking tussen de verschillende personen. Dit was vooral belangrijk om de elektronica en de software te integreren tot ééngeheel. BIBLIOGRAFIE 90

Bibliograﬁe

[1] John Powers. An introduction to ﬁber optic systems. Irwin Professional Publishing, 2 edition, October 1996.

[2] Bert De Mulder. Non-intrusive performance monitoring of tdm optical networks. December 2005.

[3] Agilent Technologies. Optical time-domain reﬂectometers pocket guide, April 2001.

[4] GigaSURF. Aansluiten van woningen met glasvezels, 1.1 edition, November 2001.

[5] David A. Patterson and John L. Hennessy. Computer Organization and Design. Morgan Kauﬀmann Publishers, 2 edition, 1998.

[6] Xilinx. MicroBlaze Processor Reference Guide, 5.3 edition, October 2005.

[7] Xilinx. Answer Record 19539, February 2006.

[8] Xilinx. EDK 7.1 MicroBlaze Tutorial in Spartan, 3.0 edition, April 2005.

[9] Ph. D. Sangil Park. Principles of Sigma-Delta Modulation for Analog-to-Digital Converters. Motorola, June 1997.

[10] J. C. Candy and G. C. Temes. Oversampling Delta-Sigma Data Converters Theory, Design and Simulation. IEEE Press., New York, August 1991.

[11] Uwe Beis. An Introduction to Delta Sigma Converters. http://www.beis.de/Elektronik/ DeltaSigma/DeltaSigma.html, December 2005.

[12] MathWorks. FIRCEQRIP Demo, 1.2 edition, April 2002. BIBLIOGRAFIE 91

[13] Cypress Semiconductor Corporation. EZ-USB FX2 Technical Reference Manual, 2.1 edition, 2003.

[14] The MathWorks. Filter Design Toolbox User’s Guide, 3.4 edition, March 2006.

[15] The MathWorks. Filter Design HDL Coder User’s Guide, 1.4 edition, March 2006.

[16] Achim Westermann. JChart2D v1.1.1. http://jchart2d.sourceforge.net/, April 2006.

[17] Askalon, University of Innsbruck, http://www.dps.uibk.ac.at/projects/askalon/ visualization/links.html. Links to non-commercial and commercial charting software.