HiSPARC FPGA & Software Aanpassingen

HiSPARC FPGA & Software Aanpassingen

Rais Mense Instituut voor Informatica Hogeschool van Amsterdam Student nummer: 500502966 E-mail: [email protected]

14 juni 2011

Dit document is één van de eindproducten die ik oplever voor het afronden van mijn afstudeerstage voor de opleiding Technische Informatica aan de Hogeschool van Amsterdam. Ik heb tijdens deze stage van februari 2011 t/m juni 2011 gewerkt aan het verbeteren van de software voor het High School Project on Astrophysics Research with Cosmics (HiSPARC) bij het Nationaal Instituut voor subatomaire fysica (NIKHEF).

Commissie:

B. van Eijk (Bedrijfsbegeleider Nikhef) F. Rietveld (Stagebegeleider HvA & examinator) J.G.M. Derriks (2de examinator)

Inhoudsopgave VERKLARENDE WOORDENLIJST.............................................................................................................................. 4 LIJST VAN FIGUREN ................................................................................................................................................ 6 SAMENVATTING .................................................................................................................................................... 7 1. INLEIDING .......................................................................................................................................................... 8 1.1 NIKHEF ........................................................................................................................................................... 8 1.2 HISPARC........................................................................................................................................................ 9 2. HUIDIGE SITUATIE ............................................................................................................................................ 12 2.1 HARDWARE ................................................................................................................................................... 12 2.2 BESCHRIJVING DATA ACQUISITIE SYSTEEM .............................................................................................................. 15 3. OPDRACHT OMSCHRIJVING ............................................................................................................................. 17 3.1 AUTOMATISCH LADEN FPGA BINARY .................................................................................................................... 17 3.2 VERWERKEN CONFIGURATIE BITS VOOR GPS .......................................................................................................... 18 3.3 HERSTARTEN FPGA ......................................................................................................................................... 19 4. AANPAK ........................................................................................................................................................... 20 4.1 AUTOMATISCH LADEN FPGA BINARY .................................................................................................................... 20 4.2 VERWERKEN CONFIGURATIE BITS VOOR GPS .......................................................................................................... 21 4.2.1 Testen en validatie .............................................................................................................................. 25 5. CONCLUSIE....................................................................................................................................................... 28 5.1 LEERDOELEN .................................................................................................................................................. 28 5.2 VERLOOP VAN DE WERKZAAMHEDEN .................................................................................................................... 30 5.3 VOORUITZICHT ............................................................................................................................................... 31 BIJLAGEN ............................................................................................................................................................. 32 A. DOCUMENTATIE VOOR DLL ................................................................................................................................. 32 B. DOCUMENTATIE VOOR GPS BIT ............................................................................................................................ 34 C. OVERZICHT BLOKSCHEMA FPGA CODE ................................................................................................................... 36

Verklarende woordenlijst FPGA - Een Field-programmable gate array is een geïntegreerde schakeling bestaande uit programmeerbare logische componenten. Deze logische componenten kunnen geprogrammeerd worden met logische functies zoals AND, XOR, enzovoorts. Deze functies kunnen ook bijvoorbeeld decoders of eenvoudige wiskundige functies zijn. VHDL – (Very High Speed Integrated Circuit) Hardware Description Language. Dit is een hardware beschrijvingstaal waarmee digitale geïntegreerde schakelingen en programmeerbare logica in een FPGA kan worden beschreven en gemodelleerd. LabVIEW – (Laboratory Virtual Instrumentation Engineering Workbench) is een grafische programmeeromgeving, ontwikkeld door National Instruments. Het is een omgeving die vooral geschikt is voor besturingstechniek, data-acquisitie, en het communiceren met meetinstrumenten LabWindows/CVI – Een programmeeromgeving geproduceerd door National Instruments. Het biedt een platform voor het ontwikkelen van test- en meetopstellingen. CVI staat voor C Virtual Instruments, de programmeertaal die gebruikt wordt is ANSI C. VI – Virtual Instrument. Dit is de naam gebruikt binnen LabVIEW voor het aanduiden van een virtueel meetinstrument of blok code. DLL – Een Dynamically Linked Library, is een bibliotheek met functies, die door meerdere applicaties gebruikt kunnen worden. PMT – Een fotomultiplicator, of photomultiplier tube. Een elektronenbuis waarmee zeer zwakke lichtsignalen of zelfs individuele fotonen kunnen worden gemeten. Foton – De verschijningsvorm van elektromagnetische straling. Afhankelijk van de gebruikte meetopstelling zal de straling zich voordoen als golven of als een stroom van massaloze deeltjes, de fotonen. UART – (Universal asynchronous receiver/transmitter). Een stuk hardware wat seriële naar parallelle communicatie om kan zetten.

4

RS-232/RS-442 – Verschillende standaarden voor seriële communicatie die onder anderen elementen als de elektrische karakteristieken van de signalen, de snelheid van signalen en voltages definiëren. A/D converter – Een analoog-digitaalomzetter of AD-converter zet een analoog signaal om in een digitaal signaal.

5

Lijst van figuren Figuur

Onderschrift

Pagina

1.1.1

Organigram NIKHEF, met aan de rechter zijde HiSPARC onder leiding van Bob van Eijk.

9

1.2.1

Schematische weergave van de ontwikkeling van een deeltjeslawine die ontstaat nadat het primaire deeltje in de atmosfeer een kettingreactie van botsingen teweeg brengt.

10

2.1.1

Een plastic scintillator licht op onder een ultraviolette lamp.

12

2.1.2

De binnenkant van de HiSPARC unit, met in het midden de Altera FPGA.

14

2.2.1

Datastroom van detector tot opslag op NIKHEF.

15

2.2.2

Proces stroom LabVIEW applicatie.

16

4.2.1

Voorbeeld van een LabVIEW Virtual Instrument. Dit instrument kan gebruikt worden voor het lezen en versturen van Bytes.

22

4.2.2

De opbouw van de data stroom, de byte waarin de benodigde configuratie bits staan is aangegeven in het rood. De start en stop bytes van het bericht zijn weergegeven in blauw. De byte nummers komen overeen met de nummering in fig. 4.2.3.

23

4.2.3

In deze tabel is weergegeven welke informatie te vinden is in het data pakket wat gekenmerkt wordt door de start bytes “8F AB”.

23

4.2.4

Een deel van de VHLD code voor het lezen van de GPS data. Op regel 541 wordt de byte met de GPS configuratie data (de negende byte van dit bericht) opgeslagen in een variabele om later verwerkt te worden.

24

4.2.5

Een deel van het blokdiagram van de VHDL code voor de FPGA. In de groene omlijning lopen de twee interne signalen die de waardes van de benodigde GPS configuratie bits doorgeven aan het blok wat ze zal verzenden naar de PC.

24

4.2.1.1

voorbeeld uit de Questasim software. Te zien is 300 nanoseconden van gesimuleerde kloksignalen.

26

4.2.1.2

Een voorbeeld uit de Quartus II software. Hier is het zogeheten ‘floorplan’ te zien, waar men kan bekijken en wijzigen welke logische elementen en geheugenblokken gebruikt zullen worden door de FPGA.

27

6

Samenvatting Ik heb deze stage de volgende producten opgeleverd: Een DLL die het mogelijk maakt om het programma van de FPGA automatisch in de FPGA te schrijven wanneer het LabVIEW programma gestart wordt. Dit maakt het mogelijk om die nieuwe versie van de HiSPARC unit in gebruik te nemen bij de diverse meetstations, zonder dat de gebruikers ter plaatse iedere keer de software opnieuw handmatig naar de FPGA moeten schrijven wanneer deze herstart moet worden, of wanneer er een nieuwe versie beschikbaar is. Ik heb ook aanpassingen gemaakt in zowel de software van de FPGA als in de LabVIEW software die het mogelijk maken om een eerder bestaand probleem met de weergave van de tijd op metingen te verhelpen door het verwerken van de huidige configuratie van de GPS module in de HiSPARC unit. Dit zorgt ervoor dat de meetresultaten de correcte tijdsmeting met zich mee dragen en dus correct verder verwerkt kunnen worden. Ik heb met veel plezier aan het HiSPARC project gewerkt, en het heeft mij een kans gegeven om te werken met technieken waar ik eerder nog niet in aanraking mee geweest was gekomen. Ook heb ik kunnen werken aan een echt wetenschappelijk project, en samen kunnen werken met wetenschappers. Het Nikhef heeft een zeer vriendelijke omgeving geboden om in te kunnen werken, en veel mogelijkheden geboden om mij te ondersteunen tijdens mijn werk aan het project.

7

1. Inleiding In dit document zullen een aantal dingen uiteengezet worden. Allereerst zal ik een inleiding geven over het bedrijf waar ik werkzaam geweest ben(Nikhef) en het project waar ik aan gewerkt heb (HiSPARC). Vervolgens zal ik een overzicht geven van hoe de huidige situatie was op het moment dat ik met het project begonnen ben, en wat de opdracht precies geweest is. Verder zal ik in gaan op hoe ik de opdracht aangepakt heb, en hoe dit uiteindelijk verlopen is, en uiteindelijk zal ik hieruit een conclusie formuleren waar ik verder in ga op wat ik op deze stage geleerd heb, en of dit overeenstemt met de doelen die ik aan het begin van de stageperiode had gesteld.

1.1 Nikhef Het Nikhef is een samenwerkingsverband tussen de stichting voor Fundamenteel Onderzoek der Materie (FOM) en vier universiteiten: de Radboud Universiteit Nijmegen, de Universiteit van Amsterdam, de Universiteit Utrecht en de Vrije Universiteit Amsterdam. Het Nikhef heeft ruim tweehonderd medewerkers in dienst, dit zijn naast wetenschappers en promovendi, technici en ondersteunende stafleden. Het grootste deel van deze medewerkers is werkzaam in Amsterdam, een aantal is ook werkzaam aan de universiteiten van Amsterdam, Nijmegen of Utrecht. De missie van het Nikhef is het bestuderen van de interactie en structuur van elementaire deeltjes en krachtenvelden op de kleinst mogelijke afstand. De bevindingen worden gebruikt om de ontwikkeling van het vroege universum te achterhalen. Binnen het Nikhef lopen een aantal projecten parallel, waaronder het HiSPARC project (zie fig. 1.1.1). Verder loopt er een relatief groot aantal projecten in samenwerking met CERN (Conseil Européen pour la Recherche Nucléaire in Genève), waaronder ALICE (A Large Ion Collider Experiment), ATLAS (A Toroidal LHC ApparatuS) en LHCb (Large Hadron Collider beauty experiment), drie van de grote experimenten bij de LHC (Large Hadron Collider).

8

Fig. 1.1.1: Organigram NIKHEF, met aan de rechter zijde HiSPARC onder leiding van Bob van Eijk.

1.2 HiSPARC HiSPARC is een project waarbij middelbare scholen samen met wetenschappelijke instellingen een netwerk vormen om kosmische straling met extreem hoge energie te kunnen meten. Op de daken van de scholen die meedoen aan het HiSPARC project staan meetopstellingen welke via het internet verbonden zijn met een centrale computer bij een wetenschappelijke instelling. Zo vormen zij een lokaal netwerk. In Nijmegen worden al sinds 2002 gegevens verzameld en in Amsterdam sinds 2004. Ook in de regio's Eindhoven, Leiden, Utrecht, Enschede en Groningen staan HiSPARC detectoren. 9

Bij de botsing van een hoogenergetisch kosmisch deeltje op atoomkernen in de atmosfeer worden nieuwe deeltjes gemaakt. Deze nieuwe deeltjes bewegen in dezelfde richting als het primaire deeltje, en botsen vervolgens waarbij weer nieuwe deeltjes ontstaan. Dit leidt zo tot een kettingreactie waarin een cascade van secundaire en een grote hoeveelheid daarvan afgeleide deeltjes ontstaat (zie fig. 1.2.1). In deze kettingreactie ontstaat als het ware een pannenkoek van deeltjes; dit wordt een lawine, of “shower” genoemd. Alle deeltjes, die in zo een lawine naar beneden komen, bewegen met bijna de lichtsnelheid. Zolang de energie van de deeltjes hoog genoeg is om nieuwe deeltjes te produceren, blijft de lawine groeien door inelastische botsingen. Daarna zijn er alleen nog elastische verstrooiingsprocessen en neemt het aantal deeltjes lager in de atmosfeer af. Het grootste deel van de energie van het primaire deeltje wordt geabsorbeerd in de atmosfeer. Een beperkt deel bereikt het aardoppervlak. Het zijn deze deeltjes waar men in het HiSPARC project naar op zoek is.

Fig. 1.2.1: Schematische weergave van de ontwikkeling van een deeltjeslawine die ontstaat nadat het primaire deeltje in de atmosfeer een kettingreactie van botsingen teweeg brengt.

10

De opstelling van elke meetlocatie bestaat uit een aantal onderdelen, waarvan de belangrijkste de scintillator plaat is. Dit is de plaat waardoor de geladen deeltjes passeren, en in deze plaat wordt licht geproduceerd. Er wordt er een groot aantal licht deeltjes geproduceerd, dit aantal ligt tussen de ongeveer honderd en duizend deeltjes. Het precieze aantal is afhankelijk van de hoeveelheid energie die het geladen deeltje kwijt raakt op zijn pad door het scintillatie materiaal. Wanneer dit licht het uiteinde van de scintillator plaat bereikt, valt het op een PMT (photomultiplier tube) waar het licht met behulp van het foto-elektrisch effect omgezet wordt in een elektrisch signaal. Het elektrische signaal loopt over een coax kabel naar de HiSPARC unit, het eerste deel van het data acquisitie systeem. Per unit kunnen er twee scintillator platen aangesloten worden, maar elke unit kan ook een zogeheten ‘Slave’ hebben, dit is een tweede unit, met daaraan nog een tweetal scintillator platen. Zo kunnen er dus in totaal vier scintillator platen in één meetopstelling opgenomen worden. In de unit worden deze signalen uitgelezen door A/D converters. De hoogte van het signaal ligt tussen de nul en min tien Volt, en wordt vierhonderd miljoen keer per seconde gesampled. Wanneer de eerste analyse van de data is gedaan, stuurt de unit alleen de interessante data over USB naar een PC. Op deze PC draait LabVIEW software die de verdere opslag en transport naar een lokale database verzorgt.

11

2. Huidige situatie Op dit moment wordt een tweede versie van de HiSPARC data acquisitie elektronica gebruikt binnen het HiSPARC project. Dit is een unit met daarin onder anderen een FPGA, een GPS module, een aantal A/D converters en een chip voor communicatie over USB. Er is recentelijk een derde versie ontwikkeld waarin een aantal aanpassingen gemaakt zijn. Mede om deze nieuwe hardware in te kunnen gaan zetten moeten er ook een aantal aanpassingen gemaakt worden in zowel de VHDL software van de FPGA als het bijbehorende LabVIEW data acquisitie programma.

2.1 Hardware De hardware in het HiSPARC project bestaat uit drie delen; de detectors, het data acquisitie systeem en de opslag. De detectors bestaan uit scintillator platen, PMT's, voedings- en signaalkabels (coax). De scintillator platen zijn voor het registreren van de geladen deeltjes. Deze platen zijn gemaakt van een speciaal plastic, wat er voor zorgt dat wanneer een deeltje een scintillator plaat passeert, de plaat een deel van de energie van dit deeltje absorbeert en vervolgens weer uitstraalt in de vorm van fotonen (zie fig. 2.1.1). De scintillator is lichtdicht verpakt in Aluminiumfolie en zwart plastic om zo te voorkomen dat er licht van buitenaf in de plaat terecht komt. Dit zorgt er ook voor dat de scintillator plaat van binnen beter reflecteert. Omdat de plaat van binnen reflecteert, worden de fotonen die geproduceerd worden in de plaat ook terug de plaat in gereflecteerd wanneer deze de zijkant van de plaat bereiken. De fotonen blijven net zo lang door de plaat weerkaatsen tot deze op de PMT vallen.

Fig. 2.1.1: Een plastic scintillator licht op onder een ultraviolette lamp.

12

Wanneer een foton de PMT raakt, produceert deze met behulp van een foto-elektrisch materiaal een elektron. Één enkele elektron is op zichzelf erg moeilijk om te meten, en is niet over een lange draad te versturen. Daarom versterkt de PMT het signaal met behulp van secundaire emissie. Dit wil zeggen dat er gebruik wordt gemaakt van het effect dat een metalen oppervlak meerdere elektronen uitzend wanneer er een enkele elektron op valt. Door dit meerdere malen te herhalen kan het signaal van een enkele elektron vele malen versterkt worden, en zo sterk genoeg worden om over een kabel verstuurd te worden. Wanneer het signaal van de PMT over een coax kabel de HiSPARC unit bereikt, is het aangekomen bij het data acquisitie deel van de meetopstelling. In de HiSPARC unit vindt de eerste data verwerking plaats. Om de data snel genoeg te kunnen verwerken is de HiSPARC unit speciaal ontworpen en geprogrammeerd voor dit doel. Het hart is een Altera Cyclone III FPGA (fig. 2.1.2) met daarin een programma wat speciaal voor de meetopstelling is gemaakt. Deze FPGA beschikt over 39600 logische elementen, 126 programmeerbare geheugenblokken van 1125 bytes, 141 kilobyte RAM en kan tot 535 inputs en outputs aan. Verder bevat de unit een GPS module op basis van een Texas Instruments Digital Signal Processor (TMS320VC5509AZHH). Deze chip verzorgt de verwerking van het GPS signaal en de communicatie met de rest van de hardware. Verder bevat de unit vier analoog/digitaal converters voor het uitlezen van de signalen van de PMT.

13

Fig. 2.1.2: De binnenkant van de HiSPARC unit, met in het midden de Altera FPGA.

De FPGA loopt op een 200 MHz klok, en leest de waardes van de A/D converters uit op zowel de opgaande als de neergaande flank van de klok. Dit betekent dus dat de waarde van de AD converters vierhonderd miljoen keer per seconde uitgelezen wordt door de FPGA. Wanneer de data de FPGA binnen komt, wordt het opgeslagen in een circulaire buffer. Tegelijk wordt de eerste analyse op de data gedaan om te bepalen of er een coïncidentie is opgetreden tussen de twee scintillator platen. Als dit het geval is wordt een van tevoren bepaalde hoeveelheid data van zowel voor, tijdens als na de coïncidentie in een nieuwe buffer geschreven. Ook wordt er met behulp van de GPS de precieze tijd bepaald waarop de coïncidentie heeft plaatsgevonden. Vervolgens wordt deze data via USB weggeschreven naar een PC met daarop een LabVIEW programma, wat ook weer speciaal voor de meetopstelling gemaakt is. Dit LabVIEW programma verzorgd tijdelijke opslag van de verzamelde data zodat deze verder verstuurd kan worden naar de permanente opslag op het NIKHEF. 14

2.2 Beschrijving data acquisitie systeem Binnen het HiSPARC project wordt een LabVIEW programma gebruikt om de data vanuit de FPGA uit te lezen en op te slaan. Dit programma draait op een PC die op locatie bij elke detector aanwezig is. De uitwisseling van de data gebeurd via een USB verbinding tussen de PC en de HiSPARC unit. Het programma zorgt voor tijdelijke data opslag. Via een aantal andere processen wordt de data vervolgens doorgestuurd naar een centrale database bij nikhef (fig. 2.2.1). Verder biedt het programma een gebruikersinterface voor het analyseren en configureren van een aantal verschillende aspecten van de hardware in de HiSPARC unit. Ook kan er met deze interface in real time gekeken worden naar de kwaliteit van de binnenkomende data, en of zich een fout heeft voorgedaan in de unit.

Fig. 2.2.1: Datastroom van detector tot opslag op NIKHEF.

Het verloop van het programma is sequentieel, en wordt grotendeels gedreven door de verzamelde data (fig. 2.2.2). Het programma heeft een aantal standaard configuratie waarden die gebruikt worden wanneer er geen expliciete waarde door de gebruiker opgegeven wordt. Met deze startwaarden wordt het HiSPARC II proces gestart. Hieronder valt ook hoeveel toegang de gebruiker heeft tot de configuratie mogelijkheden van het programma. Wanneer de gebruiker kiest voor uigebreide mogelijkheden voor configuratie en diagnostiek, is een wachtwoord nodig om het programma te starten. Vervolgens begint de hardware initialisatie, waarbij via USB contact wordt gezocht met de HiSPARC elektronica. 15

Wanneer deze hardware initialisatie succesvol is wordt de hoofdloop van het programma gestart. In deze loop zal het programma blijven tot er op de stop knop gedrukt wordt in de gebruikers interface, of totdat er een fout optreedt waar het programma zich geen raad mee weet. In dit geval wordt er getracht opnieuw te starten met het uitvoeren van het programma vanaf de eerste configuratie. Wanneer het programma in de hoofdloop is, zijn er vier taken waar het programma zich voornamelijk mee bezig houdt. In het main loop blok wordt het uitlezen en doorvoeren van configuratie gedaan, en het beslissen welke acties er verder uitgevoerd moet worden. Dit kan één van de volgende drie acties zijn; Read bytes, in deze modus leest het programma bytes in van USB. In het Process data blok gebeurt het verwerken van de ingelezen data om te kunnen bepalen wat voor berichten er binnengekomen zijn, en wat er met de bijbehorende data gedaan moet worden. Wanneer het Store data blok actief is, worden de verzamelde gegevens doorgestuurd naar de database op het NIKHEF om daar opgeslagen te worden voor verdere analyse.

Fig. 2.2.2: Proces stroom LabVIEW applicatie.

16

3. Opdracht omschrijving In dit hoofdstuk zal ik een beschrijving geven van elke onderdeel van mijn opdracht bij het Nikhef, zoals deze bij mij neergelegd waren aan het begin van mijn stage. Verder zal ik een opsomming geven van de op te leveren producten voor elk van deze onderdelen.

3.1 Automatisch laden FPGA binary 3.1.1 Omschrijving In de tweede versie van de HiSPARC units, is een EEPROM chip aanwezig waar de FPGA zijn programma uit laadt wanneer deze gestart wordt. Bij de derde versie is de EEPROM chip niet meer aanwezig, en moet de FPGA zijn programmatuur over een USB poort aangeleverd krijgen wanneer deze opstart. Er bestaat een applicatie die geschreven is voor het programmeren van de HiSPARC units, en deze werkt met zowel versie twee als versie drie, echter is het niet erg gebruiksvriendelijk om iedere keer wanneer de HiSPARC unit start handmatig de programmatuur erin te moeten laden met behulp van deze applicatie. Om het proces voor de gebruiker te vereenvoudigen, moet de functionaliteit van deze applicatie direct in het LabVIEW programma terecht komen zodat vanuit daar de programmatuur automatisch in de FPGA van de unit geladen kan worden wanneer dit nodig is. Er moet uitgezocht worden of de bestaande applicatie aan te passen is of dat er nieuwe software geschreven moet worden om de gewenste functionaliteit los te verkrijgen. Hierna zal, afhankelijk van de uitkomst, een nieuwe applicatie geschreven, of de bestaande aangepast worden.

3.1.2 Op te leveren producten DLL – Er zal een DLL aangemaakt worden met daarin de functionaliteit van de stand alone applicatie. Dit wil zeggen dat met behulp van deze DLL de FPGA geprogrammeerd moet kunnen worden zonder dat hier verdere software of interactie met de gebruiker voor nodig is. Documentatie – Een beknopte handleiding met daarin de uitleg over hoe de code voor de DLL aangepast kan worden, hoe een DLL gebouwd kan worden vanuit de code, hoe de DLL als bibliotheek in LabVIEW geïmporteerd en gebruikt kan worden en wat welke foutcodes betekenen (zie bijlage A).

17

3.2 Verwerken configuratie bits voor GPS 3.2.1 Omschrijving In de HiSPARC unit is een GPS module aanwezig om de locatie van de unit, en vooral de tijd zeer nauwkeurig te kunnen bepalen. Het zeer precies kunnen bepalen van de tijd is erg belangrijk omdat toleranties hiervoor slechts enkele nanoseconden zijn. Echter kan de tijd weergegeven zijn in zowel de GPS-, als UTC-tijdsaanduiding. Dit is afhankelijk van de configuratie van de GPS module. Het is belangrijk om te weten in welke modus het bordje staat, omdat de twee tijdsaanduidingen enkele seconden van elkaar verschillen. Het GPS bordje geeft iedere seconde een aantal gegevens door aan de FPGA, waaronder een byte waarin de huidige configuratie van de GPS weergegeven wordt. Op dit moment wordt er nog niets gedaan met deze configuratie status byte. De FPGA moet deze byte ook gaan uitlezen en de relevante informatie over de configuratie van de GPS over een USB verbinding doorgeven aan de LabVIEW applicatie. De LabVIEW applicatie moet ook aangepast worden om deze nieuwe informatie correct te verwerken. Er moet een weergave bij komen zodat de gebruiker kan zien in welke tijdsconfiguratie de GPS module staat, en deze configuratie moet verwerkt worden in de opslag van de gegevens zodat achteraf de correcte tijd nagegaan kan worden.

3.2.2 Op te leveren producten FPGA code – De aangepaste VHDL code die ervoor zorgt dat de configuratie van de GPS module in de HiSPARC unit beschikbaar wordt voor de PC applicatie. LabVIEW code – De aangepaste LabVIEW code die de configuratie van de GPS module mee neemt in het verwerken van de tijdsstempel waarop coïncidenties plaats vinden. Documentatie – Een korte technische beschrijving die verkaart waar de GPS data opgehaald wordt, hoe de configuratie wordt verkregen en waar de code hiervoor te vinden is, zodat aanpassingen navolgbaar zijn, en ook in nieuwere versies van de software toegepast kunnen worden (zie bijlage B).

18

3.3 Herstarten FPGA Dit deel van mijn stage opdracht is wegens tijdsbeperkingen helaas buiten de scope van het project gevallen. Het was echter wel een deel van de initiële opdracht, daarom is voor de volledigheid de omschrijving wel toegevoegd, maar deze opdracht later niet meer terug komen in het hoofdstuk over de aanpak.

3.3.1 Omschrijving De FPGA in de HiSPARC unit heeft geen zelfdiagnostiek, dit betekent dat er geen waarschuwing is wanneer er iets spaak loopt in het proces. Wanneer de FPGA niet correct functioneert, kunnen er metingen verloren gaan, en dit is uiteraard geen wenselijke situatie. Om hier verbetering in aan te brengen moet de er een controle komen. Wanneer er een fout optreedt of er geen resultaten meer binnen komen, moet het LabVIEW programma kunnen beslissen om de FPGA opnieuw op te starten om het probleem zo eventueel te kunnen verhelpen, zonder dat hier een persoon voor aanwezig hoeft te zijn bij de meetopstelling, of er gebruik gemaakt moet worden van een login op afstand omdat dit niet altijd betrouwbaar werkt. Verder is de tijd tussen het vaststellen van een probleem situatie en het herstarten van de FPGA zo te minimaliseren.

3.3.2 Op te leveren producten LabVIEW code – De aangepaste LabVIEW code welke het mogelijk maakt dat de LabVIEW applicatie de FPGA opnieuw opstart wanneer er geen, of foutieve data wordt ontvangen van de FPGA. Een deel van deze code zal ingepakt zijn in een LabVIEW Virtual Instrument zodat deze zowel in de huidige applicatie als in nieuwere versies van het programma gebruikt kan worden. De rest van de code zal moeten worden ingevoegd in het bestaande Virtual Instrument wat het verwerken van de ontvangen data doet. Documentatie – Een technische beschrijving van de gemaakte aanpassingen en toevoegingen in de LabVIEW code, en hoe het LabVIEW Virtual Instrument gebruikt dient te worden.

19

4. Aanpak 4.1 Automatisch laden FPGA binary Omdat de volledige broncode van de stand alone applicatie is beschikbaar is, heb ik ervoor gekozen om de bestaande code van deze applicatie aan te passen zodat hier een DLL van gemaakt kan worden. Hiervoor is het nodig om de broncode van de bestaande applicatie zodanig aan te passen dat deze autonoom kan werken, waar de bestaande applicatie gebruikers interactie vereist. Om deze autonomie te kunnen bereiken heb ik alle code van de oude applicatie die interactie nodig had, opnieuw geschreven om met directe input te kunnen werken. Verder heb ik alle stappen die de gebruiker voorheen moest doorlopen ook moeten automatiseren. Deze DLL kan vervolgens in LabVIEW geïmporteerd worden als bibliotheek. Echter brengt dit wel met zich mee dat de DLL in de eerste instantie afhankelijk zal zijn van de LabWindows bibliotheek voor het maken van een gebruikersinterface. Dit is niet gewenst omdat deze bibliotheek op de meeste computers niet beschikbaar zal zijn. Het is dus nodig om de code dusdanig aan te passen dat deze afhankelijkheid niet langer aanwezig is. Met behulp van een definitie in de code is het mogelijk gemaakt om voor het compileren van het project aan te geven of het project als DLL of als stand alone applicatie gecompileerd zal worden. Om dit te bereiken moet alle code die nodig is voor het opbouwen van de gebruikers interface conditioneel gemaakt worden, zodat deze enkel opgenomen wordt bij het compileren wanneer dit ook echt nodig is. Hierdoor zal de oude functionaliteit van stand alone applicatie beschikbaar blijven, terwijl het ook mogelijk is om een DLL zonder afhankelijkheid van de LabWindows bibliotheken te maken. Om de DLL gemakkelijker in het gebruik te maken kan men vanuit LabVIEW de locatie opgeven van het bestand wat gebruikt moet worden om de FPGA te programmeren. Dit brengt wel met zich mee dat het nodig is om vast te kunnen stellen wanneer er een foutieve locatie opgegeven is. Om deze mogelijke fout, en een aantal andere fouten die tijdens het programmeren van de FPGA op kunnen treden van elkaar te kunnen onderscheiden is het zeer belangrijk dat de DLL ook aan LabVIEW weer een signaal terug geeft waar aan af te lezen is hoe het programmeren verlopen is. Dit wordt gedaan door een nul terug te sturen wanneer de FPGA succesvol geprogrammeerd is, of een negatieve waarde, afhankelijk van wat er fout gegaan is (zie tabel 4.1.1). Hieraan kan de programmeur of gebruiker afleiden wat er aan de hand is, en waar het probleem mogelijkerwijs kan liggen.

20

Return code

Meaning

Possible reasons

0

FPGA code was successfully written to device.

No error.

-1

No suitable USB device was found.

HiSPARC box is not connected or not receiving power.

-2

USB device could not be initialized.

Missing drivers or faulty hardware.

-3

Cannot set program clock.

Driver error or hardware failure.

-4

Could not open .rbf file.

File is not where it’s expected or the current user does not have sufficient permissions to open it.

-5

Read error occurred in .rbf file.

Corrupted or truncated .rbf file.

-6

Unable to set FPGA into configuration mode.

-7

No FPGA detected.

-8

Memory allocation error.

-9

FPGA configuration failed.

-10 -11 -12

FPGA does not have power or hardware is faulty. Not enough free memory is available for the application. Write error or faulty hardware.

FPGA configuration appears successful, but FPGA is not ready. FPGA configuration was interrupted, file could not be completely written. Unknown fatal error occurred during FPGA configuration.

Corrupted or truncated .rbf file. FPGA lost power during configuration or corrupted or truncated .rbf file. Reason for the error is unknown.

Tabel 4.1.1: In deze tabel is te zien wat de betekenis is van de verschillende waardes die ontvangen kunnen worden na het aanroepen van de DLL functie voor het programmeren van de FPGA. Deze tabel is ook terug te vinden in de documentatie voor dit onderdeel van mijn project (zie bijlage A).

Ik heb voor deze aanpak gekozen omdat dit het snelste resultaat zorgt, omdat een deel van de oude code opnieuw gebruikt kan worden. Ook is deze code al reeds getest en in de praktijk bewezen, wat ervoor zorgt dat de hoeveelheid tijd die nodig is voor het testen bij dit onderdeel gereduceerd wordt.

4.2 Verwerken configuratie bits voor GPS De benodigde byte van de GPS data wordt verzonden in een reeks bytes die al door de FPGA opgepakt wordt, maar de bewuste byte wordt niet uitgelezen. Het uitlezen van deze byte zal dan ook in de 21

bestaande structuur van het FPGA programma meegenomen en vervolgens met de rest van de data meegezonden worden naar de LabVIEW applicatie om daar verder verwerkt te worden. Om dit te kunnen realiseren, is het wel een vereiste dat ik leer programmeren in zowel VHDL als LabVIEW, omdat deze beide uitvoerig gebruikt worden. Ook is het belangrijk om een goed inzicht te krijgen in het bestaande project. Gezien de omvang van het bestaande project (±33 duizend regels VHDL code en ruim honderd LabVIEW Virtual Instruments) is het nodig om hier enige tijd voor uit te trekken (fig. 4.2.1).

Fig. 4.2.1: Voorbeeld van een LabVIEW Virtual Instrument. Dit instrument kan gebruikt worden voor het lezen en versturen van Bytes.

Om het gewenste resultaat te bereiken zal eerst uit de datastroom van de GPS de benodigde byte gehaald moeten worden, uit deze byte zullen vervolgens twee bits uitgelezen worden om de huidige configuratie te kunnen bepalen. De GPS module zit intern in de HiSPARC unit verbonden met de FPGA door middel van een seriële verbinding die direct aangestuurd wordt door de UART op de GPS ontvanger zonder dat daar een RS-232 of RS-422 line driver voor nodig is. Eens per seconde wordt over deze verbinding een aantal berichten verzonden. Het type bericht kan bepaald worden door de eerste bytes van het bericht. Voor elk type bericht is er een bekende serie bytes(fig. 4.2.2). Voor elk type bericht is ook bekend wat voor gegevens er in staan(fig. 4.2.3), en welke serie bytes het einde van het bericht aanduid. Op deze manier kan uit het bericht de byte met de GPS configuratie data onderscheiden worden van de rest (fig. 4.2.4), en kunnen de twee benodigde bits worden verkregen. Wanneer deze twee bits uitgelezen zijn, zullen deze binnen de FPGA in een intern signaal omgezet worden. 22

Dit interne signaal kan dan verbonden worden aan het blok van de FPGA code wat verantwoordelijk is voor de communicatie met de PC (fig. 4.2.5). In dit blok moeten de twee extra bits verwerkt worden in een bericht wat iedere seconde verzonden wordt om de LabVIEW applicatie te informeren over de status van de GPS. Op deze manier is het mogelijk om de twee extra bits met de huidige datastroom mee te sturen naar LabVIEW.

Fig. 4.2.2: De opbouw van de data stroom, de byte waarin de benodigde configuratie bits staan is aangegeven in het rood. De start en stop bytes van het bericht zijn weergegeven in blauw. De byte nummers komen overeen met de nummering in fig. 4.2.3.

Fig. 4.2.3: In deze tabel is weergegeven welke informatie te vinden is in het data pakket wat gekenmerkt wordt door de start bytes “8F AB”.

23

Fig. 4.2.4: Een deel van de VHLD code voor het lezen van de GPS data. Op regel 541 wordt de byte met de GPS configuratie data (de negende byte van dit bericht) opgeslagen in een variabele om later verwerkt te worden.

Fig. 4.2.5: Een deel van het blokdiagram van de VHDL code voor de FPGA. In de groene omlijning lopen de twee interne signalen die de waardes van de benodigde GPS configuratie bits doorgeven aan het blok wat ze zal verzenden naar de PC. Zie bijlage C voor het volledige blokdiagram.

In LabVIEW wordt ook voor een deel de reeds bestaande structuur gebruikt voor het uitlezen van de data. Omdat de VI's die nodig zijn voor het lezen van de data die over de USB verbinding van de HiSPARC 24

unit komt reeds bestaat, is deze aangepast om de extra bits goed af te handelen. De interpretatie van de data en de weergave zal wel in een aparte VI gedaan worden om het makkelijker te maken om deze code zonodig in een ander project of in een volgende versie van de software opnieuw te kunnen gebruiken.

4.2.1 Testen en validatie Om zowel tijdens het ontwikkelen als achteraf te kunnen valideren dat de FPGA code naar behoren werkt, heb ik een aantal software en hardware tools tot mijn beschikking gehad. Aan de kant van de hardware heeft de HiSPARC unit zelf een oplossing geboden voor het valideren van signalen. Binnen in de unit zijn een aantal LEDs aanwezig die gebruikt kunnen worden voor diagnostiek. Het is mogelijk om in de FPGA software een signaal aan deze LEDs te verbinden, en zo in real time te kunnen zien wat een signaal doet, en hoe het reageert op bepaalde inputs. Dit is zeer waardevol om te hebben, omdat het een duidelijke en zeer ondubbelzinnige weergave is van een signaal binnen de FPGA. De software die ik tot mijn beschikking had voor het testen en valideren van de werking van de code bestond voornamelijk uit een tweetal programma’s. De eerste hiervan is Questasim, een programma wat gebruikt kan worden om de werking van de FPGA op een PC te simuleren. Dit maakt het mogelijk om als het ware in de FPGA te kijken, en te zien wat de signalen doen, en hoe deze op elkaar reageren (zie fig. 4.2.1.1). Hoewel ik enige tijd nodig gehad heb om dit programma te leren gebruiken, is het zeer nuttig gebleken in het beter kunnen nagaan waar een fout optreed wanneer het programma van de FPGA niet werkt zoals verwacht. Het enige nadeel van deze software was dat niet alle functionaliteit van de FPGA correct gesimuleerd werd. Zo werd de PLL, een onderdeel van de FPGA wat deling of vermenigvuldiging van een kloksignaal verzorgd, niet gesimuleerd. Hiervoor moest dan ook extra VHDL geschreven worden, om dit alsnog te simuleren.

25

Fig. 4.2.1.1: Een voorbeeld uit de Questasim software. Te zien is 300 nanoseconden van gesimuleerde kloksignalen.

Verder heb ik gebruik gemaakt van de Quartus II software. Dit programma wordt voornamelijk gebruikt voor het compileren, fitten en het zorgen van de gewenste timing behaald wordt. Het is echter ook mogelijk om dit programma voor diagnostiek te gebruiken. Zo kan men zien welke logische elementen en geheugen blokken gebruikt zullen worden (zie fig. 4.2.1.2). Verder heeft dit programma een zeer goede foutopsporing. Zo is er bijvoorbeeld de mogelijkheid om te detecteren wanneer een signaal maar één maal gebruikt wordt, en het dus waarschijnlijk om een typefout gaat. Dit soort foutopsporing is zeer nuttig om logische fouten in de programmatuur te voorkomen.

26

Fig. 4.2.1.2: Een voorbeeld uit de Quartus II software. Hier is het zogeheten ‘floorplan’ te zien, waar men kan bekijken en wijzigen welke logische elementen en geheugenblokken gebruikt zullen worden door de FPGA.

27

5. Conclusie 5.1 Leerdoelen 5.1.1 Programmeren van een FPGA in VHDL Het programmeren van een FPGA is tijdens mijn opleiding helaas niet aan de orde geweest, echter worden FPGA's in een aantal beroepsvelden wel vaak gebruikt. Daarom leek het mij een nuttige toevoeging aan mijn kennis, en een uitdagende nieuwe taal om in te programmeren. Aangezien VHDL een industrie standaard is voor het programmeren van een FPGA, was het een logische keuze om daarmee te werken. Zoals al eerder aangegeven zijn deze twee onderwerpen in mijn opleiding niet aan bod gekomen. Hierdoor was dan ook de verwachting dat ik enige tijd kwijt zou zijn om bekend te raken met de structuur en werking. Helaas heeft dit uiteindelijk een stuk meer tijd in beslag genomen dan in de eerste plaats verwacht was. Dit was hoofdzakelijk doordat de structuur en onderdelen van VHDL meer verschillen van traditionele PC programmeertalen dan ik verwacht had. Ik heb tijdens mijn project zeer veel geleerd over programmeren in VHDL en de werking van een FPGA. Verder heb ik ook kennis opgedaan met een aantal gerelateerde software pakketten die voor dit project gebruikt worden, waaronder EASE, een programma waarin met behulp van een combinatie van VHDL en grafisch programmeren FPGA programma’s geschreven kunnen worden, Questasim, waarmee de VHDL code uitgevoerd kan worden op een gesimuleerde FPGA (fig. 4.3.1.1), en Quartus II, het programma wat gebruikt wordt om de VHDL code te compileren, te fitten en ervoor zorgt dat de beoogde timing voor de applicatie gehaald kan worden (fig. 4.3.1.2).

5.1.2 Programmeren in LabVIEW Ook LabVIEW is niet aan bod geweest in mijn opleiding. Grafisch programmeren is iets wat ik zeer weinig gedaan heb, maar deze methode van programmeren wordt wel steeds vaker toegepast, en LabVIEW is bij de ontwikkeling van portotypes ook vaak aan de orde. Vandaar dat ook dit mij een zeer nuttig onderwerp leek om meer over te weten te komen, en ervaring mee op te doen.

28

Hoewel ik in het verleden al eens kort met LabVIEW gewerkt had, was ook dit grotendeels nieuw voor mij. Echter was door mijn eerdere gebruik van LabVIEW, de inschatting voor de benodigde tijd om ermee bekent te raken relatief eenvoudig. Verder volgt LabVIEW grotendeels de gangbare regels en structuren van meer traditionele programmeertalen, en is het dus voornamelijk een kwestie van bekend raken met de interface en werking van het programma. Tijdens mijn stage heb ik verschillende malen met LabVIEW gewerkt, en ik heb er dan ook een redelijke hoeveelheid ervaring mee op kunnen doen. Omdat LabVIEW vaak gebruikt wordt voor het testen van prototypes en het schrijven van data acquisitie software, is dit voor mij een zeer waardevolle toevoeging aan mijn kennis. Ook heb ik nog via National Instruments de mogelijkheid gekregen om deel te nemen aan een korte introductie les over LabVIEW. Hier heb ik kennis kunnen maken met nieuwe aspecten van het programma, en hoe LabVIEW met hardware kan communiceren.

5.1.3 Projectmatig werken Projectmatig werken is natuurlijk iets wat in mijn opleiding al vaak naar voren gekomen is, maar vrijwel altijd zijn de projecten op school zo ingedeeld dat men vanaf het begin zelf alles moet opbouwen. Dit is alleen niet altijd wat men in de praktijk tegen komt, vaak wanneer je aan een project begint, is het een voortzetting op een eerder project. Dit precies is wat ik bij Nikhef zal gaan doen, is het voor mij ook zeer nuttig om ervaring op te doen met op deze manier in een project stappen. Ik verwachtte dat het mij vooral zou helpen om te leren hoe ik snel in een project in kan stappen en mijn tijdsverlies bij het inlezen op het project kan minimaliseren. Op het gebied van projectmatig werken was deze stage ook zeer leerzaam voor mij. Hoewel ik in de eerste plaats wel enkele inschattingsfouten gemaakt had voor de benodigde tijd voor het mijzelf inlezen in het project en het oppakken van de benodigde software, heb ik hierdoor wel een beter inzicht gekregen in een aantal van de factoren die de benodigde tijd bepalen. Verder heb ik veel geleerd op het gebied van communicatie binnen een bedrijf, en waarom dit belangrijk is voor het slagen van een project.

29

5.2 Verloop van de werkzaamheden Het verloop was in de eerste instantie redelijk moeizaam, dit lag vooral aan het feit dat ik nog geen ervaring had met de benodigde technieken voor het project. Ik wist van tevoren uiteraard dat ik hier enige tijd aan zou moeten besteden, maar de tijd die ik hiervoor ingeruimd had bleek niet voldoende te zijn, en dreigde zodanig de planning van het project in gevaar te brengen. De voornaamste misrekening kwam voort uit het onderschatten van de omvang bestaande code van het project. Waar ik een redelijk substantieel project verwacht had, schoten mijn verwachtingen toch te kort. Dit in combinatie van het moeten leren van VHDL, en de structuur van het programmeren van een FPGA, zowel als het nog moeten leren omgaan met, en programmeren in LabVIEW zorgden voor een substantieel tijdsverlies. Na dit besproken te hebben met mijn bedrijfs- en stagebegeleider hebben we een aangepaste planning gemaakt en is het verlies zodanig weer ingelopen. Het leren van VHDL heb ik voornamelijk zelfstandig ondernomen, wel heb ik enkele malen bij collega’s aan kunnen kloppen voor hulp met een specifiek probleem omterend de bestaande code, en heb ik de mogelijkheid gehad om met auteur van de code te gaan zitten om de structuur van het project duidelijker te krijgen. Ook LabVIEW heb ik voornamelijk zelfstandig geleerd, echter heb ik wel een korte introductie sessie kunnen volgen, welke was opgezet door National Instruments. Hoewel ik ook uitvoerig heb moeten werken met LabVIEW was dit minder problematisch om te leren dan het programmeren van een FPGA, omdat LabVIEW een structuur aanhoud die meer lijkt op die van conventionele programmeertalen. Het uitvoeren van een status check op de FPGA, en zonodig herstarten daar van is een onderdeel van de beoogde verbeteringen die helaas buiten de scope van het project gevallen is. Hoewel ik in de eerste plaats wel verwacht had om hier ook aan te kunnen werken, is later toch gebleken dat de werkzaamheden voor de andere verbeteringen dusdanig veel tijd in beslag zouden gaan nemen dat voor dit onderdeel geen tijd meer beschikbaar zou zijn tijdens mijn stageperiode.

30

5.3 Vooruitzicht Ik heb tijdens mijn stage bij het Nikhef veel geleerd, en heb ook werk gedaan waar het Nikhef baadt bij heeft. Echter paste in het tijdsframe van mijn stage niet al het werk wat er nodig is voor de aanpassingen die aan de software gedaan moeten worden. Daarom zal ik na mijn stageperiode nog enkele weken bij het Nikhef in dienst blijven om ook de laatste aanpassingen door te voeren en te zorgen dat er uiteindelijk een product aanwezig is waar het Nikhef mee vooruit kan. Deze tijd zal voornamelijk gebruikt worden voor het in de bestaande gebruikersinterface implementeren van de functionaliteiten die ik tijdens mijn stage gemaakt heb.

31

Bijlagen A. Documentatie voor DLL

Compiling .dll from LabWindows/CVI To compile the fpgaConfigApp as a .dll for use with LabView, the following steps are required: 1. Setting the target type to .dll: Build → Target type → Dynamic Link Library. 2. Add file include symbol for fpgaConfigApp.h: Build → Target settings → Exports → Change → include file symbols → check fpgaConfigApp.h In order to compile the .exe with the original functionality and user interface, set the target type back to Executable in the Build menu.

Importing .dll as LabView library Either in a new project, or directly in the project you want to use it, go to: Tools → Import → Shared library (.dll)… This will open the “Import shared library” wizard. From there you can choose to create a new VI or update an existing one. In the next screen you can select the .dll (fpgaConfigApp.dll) and the header file (fpgaConfigApp.h). The header file is selected automatically if it’s in the same directory as the DLL. In the next window you can include extra paths and specify preprocessor definitions. This is usually not needed. The following window allows methods from the DLL to be imported into the LabView library. Functions which cannot be selected here are usually callback functions. Only functions for which the prototype is in the header file will be available. The next windows will allow you to specify error handling options, names and directory where the library will be stored as well as a few other settings. In most cases the default settings will work, even though in the “Configure VI and Controls” window, changing the thread settings to “Run in any thread” rather than “Run in UI thread” to avoid the LabView applications user interface from freezing when the library routine is running. After them import is done, the library can be used as any other LabView library. The latest version of the .dll allows you to specify your path from LabVIEW as input to the VI.

32

Return codes Return code 0

Meaning

Possible reasons

FPGA code was successfully written to device.

No error. HiSPARC box is not connected or not receiving power. Missing drivers or faulty hardware. Driver error or hardware failure. File is not where it’s expected or the current user does not have sufficient permissions to open it. Corrupted or truncated .rbf file.

-1

No suitable USB device was found.

-2 -3

USB device could not be initialized. Cannot set program clock.

-4

Could not open .rbf file.

-5 -6

Read error occurred in .rbf file. Unable to set FPGA into configuration mode.

-7

No FPGA detected.

-8

Memory allocation error.

-9

FPGA configuration failed. FPGA configuration appears successful, but FPGA is not ready. FPGA configuration was interrupted, file could not be completely written. Unknown fatal error occurred during FPGA configuration.

-10 -11 -12

FPGA does not have power or hardware is faulty. Not enough free memory is available for the application. Write error or faulty hardware. Corrupted or truncated .rbf file. FPGA lost power during configuration or corrupted or truncated .rbf file. Reason for the error is unknown.

Adding methods to the DLL DLL functions are the same as normal C functions. The only extra caveat is that the function prototypes must be specified in the header file (fpgaConfigApp.h).

[Deprecated] Changing the default location for the RBF-file In the LabWindows code, in fpgaConfigApp.c there is a #define used to specify the file location. (Line 47 in the current version.) #define FILENAME "C:\\fpga\\rbf_files\\FPGA_v18_Final.rbf"

Note that directory separators (backslashes) need to be escaped with a backslash to prevent the directory separators being interpreted as an escape character themselves. Practically this means that the file and directory names will have double backslashes instead of single ones. This setting is no longer used. The RBF location is specified as a parameter to the autoFill function. 33

B. Documentatie voor GPS bit In this document you will find the technical details for capturing the GPS timing configuration data as it was implemented as of June 2011.

Data stream

HiSPARC III unit GPS chip

PC LabView application

FPGA

USB chip

USB driver

This diagram illustrates the data path. The data is first acquired from the GPS module, and sent to the FPGA over an internal serial connection. The FPGA processes the data and parses out the relevant configuration bits, which are passed on to the PC by means of a USB connection between the two. From there the LabVIEW application handles the interpretation of the data and acts accordingly.

GPS status message The GPS board sends a one Pulse Per Second or PPS, containing several messages with various data. The type of message is defined by the first three bytes of the message. In the case of the configuration message, these bytes are 0x80, 0x8F and 0xAB. In this message, the 9 th byte is the byte that contains the time configuration. The first two bits of this byte are the time setting (0 for GPS time, 1 for UTC time) and the PPS time setting (0 for GPS time, 1 for UTC time). Though 34

a mixed setting is a possibility, under normal circumstances, both these setting should be set to either GPS or UTC time. In the VHDL code, the extraction of the bits is done in the ‘GPS_STUFF’ block. The output signals that carry the configuration values are ‘UTC_TIME’ and ‘UTC_PPS’.

35

C. Overzicht blokschema FPGA code

36

37