Hardwareontwerpproject: USB 2.0 oscilloscoop

Transcriptie

1 Hardwareontwerpproject: USB 2.0 oscilloscoop 20 mei 2005 Frederick Bossuyt Steven De Bock Sven Duchatelet Steven Werbrouck Promotor: J. Vandewege Begeleider: K. Van Renterghem

2 Inhoudsopgave 1 Probleemstelling AD-convertor FPGA USB-controller Schema van de probleemstelling Doel van het project Functionaliteit in de hardware Functionaliteit in de software Aanpak 6 4 Gepresteerd werk Hardware Software De datalaag De GUI-laag Demonstratie Wat kunnen we en wat kunnen we niet? i

3 Hoofdstuk 1 Probleemstelling Figuur 1.1: 8-lagenkaart waarmee we een oscilloscoop wensen op te bouwen. Recent werd in het ontwerplabo INTEC design een achtlagenbord ontwikkeld dat, naast een USB 2.0 controller (Cypress FX2), twee krachtige FPGA bouwstenen kan bevatten (één ervan is bestukt onder de koelvin, de andere is op deze figuur nog niet bevestigd), SDRAM, twee AD-convertoren en één DA-convertor. De kaart beschikt over een bijzonder accurate sampleklok. De bedoeling is deze kaart, door toevoeging van real-time software, om te toveren tot een oscilloscoop met buitengewone performantie. 1

4 HOOFDSTUK 1. PROBLEEMSTELLING AD-convertor Helemaal rechts op figuur 1.1 zien we twee coax-aansluitingen. De onderste aansluiting dient om analoge signalen uit de kaart te sturen; aan de bovenste kunnen we een analoog signaal aanleggen. Dit analoog ingangssignaal moet uiteraard omgezet worden naar het digitaal domein. De AD-convertor die we hiervoor gebruiken, kan een samplerate aan van 64 Msps (i.e. per seconde worden er 64 miljoen samplewaardes genomen van het analoog signaal). Vóór de AD-convertor staat een anti-aliasing filter met een bandbreedte van 12 MHz. Iedere samplewaarde bestaat uit 14 bits, zodat we zeer nauwkeurige en gedetailleerde meetresultaten kunnen verkrijgen. Wanneer we deze samplewaardes onmiddellijk aan een PC willen leveren, dan hebben we een interface nodig die een datadebiet van ongeveer 1 Gbps aankan! De overvloed aan samplewaardes kan dus niet zomaar doorgezonden worden naar een PC. We beschikken immers slechts over een USB 2.0 connectie van 480 Mbps. Voor deze oscilloscooptoepassing is dan ook een slim gebruik van triggering, decimatie en buffering nodig. De hogesnelheid DA-convertor op de kaart kan desgewenst worden gebruikt om een stimulus-signaal aan te maken (bv. een sinus waarmee een versterker kan worden doorgemeten). Merk op dat de bovenste twee convertoren afgeschermd zijn door een metalen omhulsel. Dit zorgt ervoor dat de invloeden van overspraak en stoorsignalen beperkt worden (kooi van Faraday-principe). 1.2 FPGA Op de testkaart die voor het project beschikbaar is, zijn twee FPGA s aanwezig (van het type Xilinx VirtexII XC2V1500) die bestukt zijn met elk 1,5 miljoen equivalente gates en meer dan een megabit aan snelle inwendige SDRAM, zodat zelfs lange samplerijen snel kunnen worden opgeslaan en intensieve digitale signaalverwerking mogelijk is. In dit project zal blijken dat slechts één van de twee FPGA s hoeft te worden gebruikt. 1.3 USB-controller De pinnen van de FPGA die we gebruiken, worden geconnecteerd aan een USB-controller. De Cypress FX2 is een combinatie van een USB 2.0 transceiver en een 8051 microcontroller. Deze is nodig om de signalen op een correcte manier aan de PC af te geven. De controller vormt dus de interface tussen de kaart en de PC. We merken op dat hoewel de USB 2.0 interface niet volstaat om het hoge datadebiet te kunnen verwerken die we met deze kaart kunnen halen, ze toch een hoge snelheid van 480 Mbps heeft. In vergelijking met USB 1.1 werkt deze interface 40 keer sneller. De FX2 is wel backward compatibel, zodat het ook kan werken aan Low Speed en Full Speed: Low Speed (1.5 Mbps): voor muis, keyboard en joystick

5 HOOFDSTUK 1. PROBLEEMSTELLING 3 Full Speed (12 Mbps): voor modem, speakers en scanner High Speed (480 Mbps): voor hard disk drives, cd-rom, videocamera, high resolution scanner Schema van de probleemstelling Figuur 1.2: Schematische afbeelding van de probleemstelling. Een analoog signaal komt binnen via een coax-aansluiting. Eenmaal gepasseerd door het anti-aliasing filter, wordt het signaal gesampled door de AD-convertor en naar de FPGA s gestuurd. Hierop wordt het signaal opgeslaan, verwerkt en op aanvraag van de USBcontroller doorgestuurd naar de PC. Ook hier dient signaalverwerking te gebeuren. Een human interface zorgt daarna voor een duidelijke en gebruiksvriendelijke afbeelding van het ontvangen signaal.

6 Hoofdstuk 2 Doel van het project Als einddoelstelling wensen we een demonstratie van een oscilloscoopwerking te kunnen geven. We streven naar 20MHz bandbreedte voor eenmalige signalen (single shot). Single shot betekent dat we slechts één momentopname van het analoog signaal hoeven te maken. Wanneer we een bepaald opgegeven triggerniveau bereiken, worden de daaropvolgende samples van het signaal opgeslaan en doorgegeven aan de PC. Het tijdsvenster kan bijvoorbeeld een periode van het signaal omvatten. Het voordeel van het werken met single shot signalen is dat we niet constant de samples van het signaal moeten bijhouden tot ze afgegeven zijn aan de PC. We onthouden slechts de samplewaardes vanaf het moment dat het triggerniveau bereikt is tot aan het eind van het beoogde tijdsvenster. Uiteraard zijn korte reactietijden in dit ontwerp belangrijk. Wanneer de gebruiker bijvoorbeeld de amplitude van een spanningssignaal verhoogt, dan wenst hij/zij dit onmiddellijk op het scherm te zien. Zoniet lijkt de oscilloscoop vervelend traag te werken. Verder is een efficiënt gebruik van de beschikbare FPGA hardware evident: hoewel de FPGA heel veel equivalente poorten bevat, is het ingebed geheugen nog steeds een schaars goed. De opdracht omvat het ontwikkelen en testen van functies die in VHDL code geschreven worden, zodat we de FPGA s kunnen configureren. Verder moeten we aan de hand van C++ code de communicatie met en de gebruikersinterface op de PC verzorgen. De opdracht is dus opgesplitst in een hardware- en software-gedeelte. 2.1 Functionaliteit in de hardware In eerste instantie moeten we uiteraard een geheugenstructuur voorzien: de binnenkomende samplewaardes dienen we immers op te slaan. Verder moeten we een trigger implementeren die aangeeft vanaf welke samplewaarde de bits moeten doorgegeven worden. We moeten hierbij ook rekening houden met het feit dat het signaal dit triggerniveau op een rising of een falling edge kan bereiken. Differentiatie hiertussen is een vereiste. Ook een pretrigger is gewenst. Wanneer we bijvoorbeeld een momentopname nemen van één periode van een sinussignaal, dan is het interessant om ook vlak vóór en vlak na dit tijdsvenster een aantal samplewaardes af te beelden op het scherm. De gebruiker kan dan 4

7 HOOFDSTUK 2. DOEL VAN HET PROJECT 5 eventueel het afgebeelde signaal nog wat verschuiven naar links of rechts om te zien hoe het signaal net buiten het beoogde venster eruit ziet. De pretrigger houdt deze functionaliteit in. Een belangrijke functionaliteit in de hardware is de mogelijkheid om at runtime instellingen aan te passen. Zo is het de bedoeling dat we de samplerate van 64 Msps kunnen downscalen naar 32/16/8/4/2/1 Msps, en dit nádat de FPGA s geconfigureerd zijn. Daarvoor moeten we een omgekeerde datastroom mogelijk maken: bits moeten niet enkel van de FPGA s naar de PC kunnen worden verzonden (samplewaardes), maar ook vanuit de PC naar de FPGA s (controlebits). Ten slotte moeten we nog enkele connecties tussen de FPGA s en de USB-controller realiseren. Daarbij moeten we de juiste poorten op de FPGA s lokaliseren en draadjes solderen op de corresponderende pinnen. Als extra opgave kan een anti-aliasing filter ontworpen worden die een grotere bandbreedte heeft. De huidige filter stopt immers signalen af vanaf ongeveer 12 MHz. De einddoelstelling ( signalen kunnen verwerken van 20 MHz ) kan op die manier onmogelijk bereikt worden. Verder kan er in VHDL ook nog een digitaal ruisonderdrukkingsfilter geïmplementeerd worden. Op die manier zijn de afgebeelde signalen minder behept met ruis omwille van stoorsignalen vanuit de omgeving. Om deze functionaliteit in de hardware te voorzien, kunnen we gebruik maken van Xilinx ISE 6.0. Hierin kunnen we de VHDL-code schrijven, compileren en simuleren. De bijhorende simulator (ModelSim) kan meer dan louter de pure VHDL-code simuleren. Een dergelijke simulatie is snel en noodzakelijk om het gedrag van een hardwarebeschrijving te controleren, maar het levert ons nog absoluut geen zekerheid op een betrouwbare werking in realiteit. Daarom is het met ModelSim ook mogelijk om de beschreven componenten te plaatsen en te routeren op een virtuele FPGA ( Post Place and Route ). Op die manier worden wire delays en parasitaire effecten in rekening gebracht. Deze delays hebben hun invloed op de timing en bepalen de maximale klokfrequentie waaraan een circuit kan draaien. Eenmaal een dergelijke simulatie aantoont dat de hardwarebeschrijving naar behoren werkt, kunnen we een bitstream aanmaken die de FPGA kan configureren. 2.2 Functionaliteit in de software Het belangrijkste doel van de software is het aanbieden van een graphical user interface (GUI) die de gebruiker toelaat om onze oscilloscoop op een intuïtieve manier te hanteren. De graphical user interface voorziet de gebruiker van een display om de golfvorm voor te stellen, de nodige knopjes en sliders om zaken als markers en triggerniveau in te stellen, een extra display om het frequentiespectrum van de golfvorm voor te stellen... Om deze functionaliteit in de software te voorzien maakten we dankbaar gebruik van KDevelop 1 (een geïntegreerde ontwikkelingsomgeving) en enkele beschikbare bibliotheken. 1

8 Hoofdstuk 3 Aanpak Aangezien we met vier zijn in onze groep, kunnen we twee mensen zetten op de software en twee op de hardware. Sven Duchatelet en Steven Werbrouck staan in voor de implementatie van de functionaliteit op de FPGA s. Aangezien de toestandsmachines die in de VHDL-code geschreven moeten worden niet zo eenvoudig zijn, werken zij steeds samen aan de hardwarebeschrijving. Frederick Bossuyt en Steven De Bock verzorgen de softwarekant. Hierbij legt Frederick zich vooral toe op het afbeelden van het resultaat. Een gebruiksvriendelijke human interface en een aangename layout zijn zijn doelstellingen. Steven De Bock houdt zich bezig met het ontvangen, omzetten en interpreteren van de bits op de PC. De seriële bitstroom die door de USB-poort ontvangen wordt, is immers nog niet meteen interpreteerbaar en moet nog omgezet worden naar interpreteerbare en verwerkbare doubles. Hoewel de taken strikt omlijnd zijn, is een goede communicatie tussen de groepen van cruciaal belang. Duidelijke afspraken zijn nodig omtrent wanneer, hoe en onder welke vorm data getransporteerd wordt. De hardwarekant moet bijvoorbeeld aangeven hoeveel invalid bytes er doorgezonden worden na iedere initialisatie van het gehele systeem. Deze bytes worden dan aan softwarezijde genegeerd. Verder dienen we ook af te spreken hoe we de bits interpreteren (vb: 1 doorgezonden sample = 16 bit, in 2-complementsnotatie...). Ten slotte zijn afspraken nodig omtrent het protocol voor de realtime instellingen. De PC zal bepaalde controlesignalen moeten verzenden om duidelijk te maken welke instelling ze wil veranderen en op welke waarde die bepaalde instelling gezet moet worden. Figuur 3.1: Overleg en afspaken zijn noodzakelijk. 6

9 Hoofdstuk 4 Gepresteerd werk 4.1 Hardware Figuur 4.1: Schema van de VHDL-code. Het volledige schema van de hardware-implementatie wordt gegeven in figuur 4.1. We kunnen 2 blokken onderscheiden: het data-blok en het controle-blok. Het data-blok zorgt voor de doorstroming van de samples naar de usb-controller. Deze doorstroming gebeurt aan een instelbare samplerate (64, 32, 16, 8, 4, 2 of 1 Msps). De binnenkomende samples worden eerst uitgebreid tot 16 bit, aangezien de usb-controller 7

10 HOOFDSTUK 4. GEPRESTEERD WERK 8 met een geheel aantal bytes werkt. Het FIR-filter zorgt dan voor een zinvolle reductie van het aantal samples (het acteert als ruisonderdrukkingsfilter) en geeft zelf aan wanneer de FIFO deze samples mag inklokken. We implementeren het FIR-filter zó dat het een datasignaal en een klok transformeert in een nieuw gedownscaled datasignaal (factor 2) en een nieuwe klok die aan de halve frequentie loopt. Op die manier is het mogelijk verschillende FIR-filters in cascade te laten werken. Het uiteindelijke circuit werkt met de klok en het datasignaal van het laatste filter uit de cascade. De FIFO zal de samples echter pas inlezen als hij de toestemming van het controle-blok gekregen heeft via wr en (na detectie van het triggerniveau). De inhoud van de FIFO wordt uitgelezen door de usbcontroller. We moeten de samples dus omzetten in een seriele bitstroom. Dit gebeurt aan de hand van een schuifregister (shifter out). We hebben ook een uitgangsbuffer (buffer out) voorzien. Deze uitgangsbuffer krijgt een waarde van de FIFO als het schuifregister bijna leeg is zodat de waarde stabiel is op het ogenblik dat het schuifregister moet gevuld worden. Het controle-blok interpreteert de controlesignalen van de PC at runtime en configureert aan de hand hiervan het data-blok. We kunnen zowel het triggerniveau als de samplerate instellen en zullen, telkens de PC nieuwe instellingen doorgeeft, het data-blok resetten. Het signaal control geeft aan wanneer de instellingen doorgegeven zijn en mogen gebufferd worden. Dit schema werd dan geïmplementeerd in VHDL (met behulp van Xilinx ISE 6.0). Elk bouwblok werd omgezet in een of meerdere processen, waarbij we zeer goed moesten onderzoeken welk deel van de functionaliteit in een synchroon proces kon geïmplementeerd worden en welk deel door een combinatorisch proces gerealiseerd kon worden. Om onze code te kunnen simuleren, schreven we een testbank die het gedrag van de usb-controller en van de DAC nabootste. Eenmaal dit correct functioneerde, voerden we een Post Place and Route uit om de werkelijke timing te modelleren. Als laatste stap konden we dan het geheel testen. Metingen met een Logic Analyser gaven echter aan dat er nog een verschil zat tussen de simulaties met onze testbank en de fysische implementatie (een tijdsverschuiving van 2 klokcycli). Dit kwam doordat de testbank niet 100% met de realiteit overeenstemde (een perfecte testbank schrijven is een opgave op zich). Dit probleem was echter vrij eenvoudig op te lossen. In figuur 4.2 zien we een simulatie (d.m.v. Modelsim) waarbij we via de testbank de DAC modelleren als een teller. De usb-klok wordt gemodelleerd als een intermitterende klok die 8 bit per keer opvraagt. We zien dat de FIR-filters (in cascade) inderdaad zorgen voor een halvering van de klokfrequentie. De data-uitgangen van de FIR-filters zijn het gemiddelde van de ingangen. In figuur 4.3 zien we een simulatie waarbij we de controle-informatie modelleren die door de usb-controller geleverd wordt. De instelling-vector bevat zowel de samplerate als het triggerniveau. We zien dat deze vector bit per bit uitgelezen wordt (cf. schuifregister buffer in). Na deze schuifoperatie hebben de signalen samplerate en triggerniveau de juiste waarde. Het control-signaal wordt hoog gebracht en het data-blok wordt geconfigureerd.

11 HOOFDSTUK 4. GEPRESTEERD WERK 9 Figuur 4.2: Post Place and Route simulatie van de DATA.

12 HOOFDSTUK 4. GEPRESTEERD WERK 10 Figuur 4.3: Post Place and Route simulatie van de CONTROLE.

13 HOOFDSTUK 4. GEPRESTEERD WERK Software Figuur 4.4: Architectuur van de software. We zullen nu even dieper ingaan op de realisaties in software en de problemen die daarbij kwamen kijken. Zoals reeds eerder vermeld, hebben we ons ontwikkelingswerk gedaan in KDE, een geïntegreerde ontwikkelingsomgeving die te gebruiken is onder het Linuxbesturingssysteem. De eerste praktische problemen die bij het gebruik van Linux/KDE kwamen kijken, staken al een stokje voor de snelle start van het project. Zo waren er onder andere de nodige compileer-problemen die veroorzaakt werden door Makefiles. Makefiles worden onder Linux gebruikt om de compiler te vertellen wat de relaties zijn tussen de verschillende bronbestanden en objecten die gecompileerd moeten worden. Een slechte Makefile kan dus onmogelijk leiden tot een goed werkend programma en dat hebben we dan ook mogen ondervinden. Ook hadden we nooit een software-ontwerp van een dergelijke omvang gedaan en dit leidde tot moeilijkheden wat betreft het includeren van de nodige bibliotheken. Van zodra we deze zaken helemaal begrepen konden we pas echt van start gaan met het ontwikkelen van specifieke code voor ons project. Op figuur 4.4 is te zien dat de software die wij hebben geïmplementeerd, valt op te splitsen in 2 lagen, dewelke hieronder in meer detail worden besproken De datalaag. De functie van de datalaag bestaat er enerzijds in om de samplewaarden aanwezig in de geheugenstructuur van de FPGA op een eenvoudige wijze en onder correcte vorm aan de GUI aan te bieden. Anderzijds staat deze laag ook in om communicatie in omgekeerde richting mogelijk te maken zodat instellingen van de GUI aan de FPGA kunnen doorgegeven worden. Ook het programmeren van de FPGA gebeurt op dit niveau. Om deze functionaliteit te verwezenlijken, hebben we onder andere gebruik gemaakt van de fx2 lib bibliotheek en voorbeeldcode die ons ter beschikking werden gesteld. De fx2 lib bibliotheek bezit de nodige functies om de FX2 microcontroller aan te sturen zodat communicatie in beide richtingen tussen de FPGA en GUI mogelijk wordt. Voorts moeten we er rekening mee houden dat de communicatie tussen de FPGA en GUI onderling gebeurt met bytes. Dit heeft onder andere tot gevolg dat bij het doorgeven

14 HOOFDSTUK 4. GEPRESTEERD WERK 12 van de samplewaarden van de FPGA aan de GUI telkens 2 bytes dienen samengevoegd te worden tot 1 enkele waarde, aangezien elke samplewaarde wordt gecodeerd in 2 bytes. De samplewaarde die we op deze manier bekomen is echter een gehele waarde in het bereik van tot 8191 en dus dienen we dit nog met een gepaste schaalfactor te corrigeren. Op die manier bekomen we de signaalwaarde die aan de ingang van AD-omzetter werd aangelegd, op een quantisatiefout na. Dit alles resulteert in een klasse Data. Deze klasse voorziet in de nodige variabelen en functies om aan de bovenstaande functionaliteiten te voldoen. Bij het instantiëren van deze klasse, wordt een object gecreëerd dat naast een gegeven aantal samplewaarden ook een aantal instellingen voor de FPGA kan bevatten. Door het aanroepen van de juiste functies is het dan mogelijk om samplewaarden in te lezen vanuit de FPGA of instellingen door te geven aan de FPGA De GUI-laag. Deze laag vormt de interface met de gebruiker. Het moet alle voorgaande opgenoemde functionaliteiten die eigen zijn aan een oscilloscoop samenbundelen en op een eenvoudige manier aanbieden aan de gebruiker. De belangrijkste taak van deze laag is dus het weergeven van de opgemeten data en er voor zorgen dat de data gemakkelijk interpreteerbaar wordt door extra functionaliteiten aan te bieden zoals het aanpassen van de weergaveinstellingen en het weergeven van de eigenschappen van de data. Het zal ook via deze laag zijn dat de gebruiker zijn gewenste instellingen kan meedelen aan de hardware en de hardware de opdracht kan geven het meten van data te starten. We zijn gestart van een bibliotheek van klasse s die speciaal ontworpen is voor het weergeven van grafische data. Deze bibliotheek is te vinden op net en bevat bijna alle functionaliteiten die voor dit project nodig zijn. We gebruikten hoofdzakelijk de klasse qwt plot die het weergeven van 2-dimensionele data als hoofddoel heeft en dit op een manier die het de gebruiker aangenaam maakt. Er kunnen markers worden geplaatst, schalen en assen kunnen worden ingesteld, zowel lineaire als logaritmische weergave is mogelijk... De mogelijkheden zijn legio en vergemakkelijken ons werk enorm. In ons project hebben we 2 grafische weergaves geïmplementeerd: één die de opgemeten data toont in het tijdsdomein en een andere die het fourierspectrum weergeeft. Alle instellingen kunnen worden gewijzigd door knoppen, schuifknoppen, menu s, enz. Deze werden geïmplementeerd door gebruik te maken van kant en klare klassen waarvan de beschrijving te vinden is op Er wordt gebruik gemaakt van zogenaamde widgets die de eigenlijke user interface objecten voorstellen. Naast het instellen van hun eigenschappen (coordinaten, grootte, tekst, kleur...), kunnen verschillende widgets aan elkaar gelinkt worden door middel van het signal-slot mechanisme. Dit houdt in dat we 2 objecten kunnen linken en de ene doen reageren op signalen van de andere. We hebben dit mechanisme bijvoorbeeld gebruikt bij het instellen van de schalen. Wanneer aan een knop gedraaid wordt, moet de grafische weergave realtime veranderen. Ook bij het drukken op een knop moet een bepaalde procedure gestart worden. Deze procedure zal uitgevoerd worden, als ze aan dat object gelinkt werd.

15 HOOFDSTUK 4. GEPRESTEERD WERK 13 Bij de uiteindelijke implementatie hebben we 2 klassen gemaakt, waarbij de ene de dataplot-klasse is en de grafische weergave verzorgt. De andere klasse is het eigenlijke venster waar grafische weergave en user interface in zijn samengebracht. Naast knoppen voor het aanpassen van de weergave, zijn er knoppen geïmplementeerd die de instellingen van de hardware verzorgen. De acquire-knop zal het hardwaregedeelte de opdracht geven om te beginnen inlezen, rekening houdend met de instellingen die we via de interface kunnen veranderen. Zo is het de bedoeling dat de gebruiker het gewenste triggerniveau en de samplerate realtime kan kiezen. De user interface zet dit dan om naar een signaal dat door de onderliggende lagen telkens wordt doorgegeven, zodat het uiteindelijk een sequentie bits wordt die door de hardware correct geïmplementeerd kan worden. Voor het implementeren van een frequentieanalyse van de data, hebben we gebruik gemaakt van een klasse die te vinden is op Deze stelt ons in staat om van de ingelezen array van data, het fourierspectrum te berekenen, die we dan op het scherm weergeven. Om ruis te onderdrukken was het nodig een Hanning/Hamming venster op de opgemeten data toe te passen. Dit houdt in dat we elk ingelezen sample vermenigvuldigen met een welbepaalde cosinus-functie, zodat het ingelezen signaal periodiek uitbreidbaar wordt. Op de figuren in 4.3 is de uiteindelijke grafische realisatie te zien van de user interface. Verschillende besproken onderdelen zijn duidelijk op de figuur terug te vinden. 4.3 Demonstratie Wat kunnen we... De user interface is op het einde van onze werkzaamheden in staat om het commando te geven aan de hardware om data in te lezen. Even later verschijnt dan op het scherm de data, waarvan de weergave kan verbeterd worden door de schalen te wijzigen. Als voorbeeld van de goede werking van het inlezen van het signaal, verwijzen we graag naar figuur 4.5. Hierbij hadden we een sinus van 400mVpp en frequentie van 100kHz aangelegd aan de ingang van de scoop. In het signaalvenster merken we dat de amplitude van de sinus de correcte waarde heeft (200 mv). Ook zien we dat de frequentie waarheidsgetrouw wordt weergegeven: over een tijdsinterval van 0.1 ms merken we 10 perioden. Dit komt overeen met een sinus met een frequentie van 100 khz. Onder het signaalvenster is ook het fourierspectrum te zien van het opgemeten signaal, zodat we alle aanwezige frequentiecomponenten kunnen onderscheiden. Op figuur 4.6 zien we bijvoorbeeld dat onze scoop ook werkt voor een blokgolf, maar ook zien we bij de frequentiecomponenten verschillende harmonischen optreden. Onder het signaalvenster is ook de piekspanning van het signaal af te lezen. Het programma dat op de FPGA geladen moet worden kan via een menu ingesteld worden. Bij het opstarten wordt een default programma ingeladen.

16 HOOFDSTUK 4. GEPRESTEERD WERK en wat kunnen we niet? Het instellen van het triggerniveau en de samplerate werken (ondanks alle verwoede pogingen) nog net niet helemaal. Aan de software en hardware kant is alles in orde gebracht voor een goede communicatie, maar helaas loopt het toch nog ergens fout. Nader onderzoek met een Logic Analyser tussen de usb-controller en de FPGA toont aan dat de controller niet de signalen uitzendt die we verwachten: de controlelijn, de instellingsklok en de instellingsdatalijn geven hun (soms foutieve) waarden op verkeerde momenten af aan de hardware. Bijgevolg worden samplewaardes vanuit de FPGA op een ongecontroleerde manier doorgezonden naar de PC, zodat het signaal dat verschijnt, niet meer interpreteerbaar is. Deze fout kon helaas door ons niet meer binnen het tijdsbestek opgelost worden. Verdere mankementjes zijn te vinden bij de frequentiebepaling van het signaal. Zo zijn de schalen van de x- en y-as van het frequentiespectrum nog niet helemaal in orde. Ook de frequentiewaarde onder het signaalvenster voor een sinusgolf geeft niet de correcte waarde weer. We merken nog op dat er geen pretrigger werd geïmplementeerd. Achteraf gezien bleek een pretrigger slechts realiseerbaar, wanneer we aan continue triggering zouden doen (dus geen single shot signaal). Omdat deze vorm van geheugenbeheer een redelijk grote stap in complexiteit betekende (en het in eerste instantie ook niet opgegeven werd), hebben we besloten om die pretrigger dan maar achterwege gelaten.

17 HOOFDSTUK 4. GEPRESTEERD WERK 15 Figuur 4.5: Grafische interface van de oscilloscoop met een opgemeten sinus. Figuur 4.6: Grafische interface van de oscilloscoop met een opgemeten blokgolf.

18 HOOFDSTUK 4. GEPRESTEERD WERK 16 We willen ten slotte nog opmerken dat we het jammer vinden dat we pas op het einde konden werken met echte signalen, omdat dit een extra dimensie gaf aan ons werk. Dit project spitste zich immers voornamelijk toe op het programmeren in C++ of VHDL, misschien net iets te veel voor een BE-project. De thesisstudenten die zich echter aan deze thesis wagen, hebben nu evenwel een mooi uitgangspunt om een prachtige SuperScoop te ontwikkelen.