Lijst van figuren

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