FPGA-ontwerp Audio-Netwerk voor VoIP-telefoon Prototype

Transcriptie

1 FPGA-ontwerp Audio-Netwerk voor VoIP-telefoon Prototype Ontwerprapport Bachelor Thesis Studenten: H. Syed F. Schilders C.C. Chi T. Kaserer Begeleiders: J.S.S.M. Wong A.J. van Genderen Computer Engineering, afdeling Electrical Engineering 1

2 Plaatje op de voorpagina Bron:

3 Voorwoord De R&D afdeling van PhoneTU heeft de opdracht gekregen een mobiele telefoon te ontwikkelen. R&D heeft besloten eerst een ontwerp te maken op basis van een FPGA-bord als eerste prototype. Dit rapport is het ontwerprapport van de onderdelen netwerk en audio en de koppeling van deze twee onderdelen. Lezers die vooral geïnteresseerd zijn in de uitwerking van de deelfuncties, kunnen het ontwerp vinden in hoofdstuk 5. In bijlage B en C is de broncode te vinden van het audio-, het netwerkdeel en de main -functie die gebruikt is in de testopstelling. Het ontwerpteam wil de afdelinghoofden S. Wong en A. van Genderen bedanken voor het creëren van een goede werksfeer door adequaat te handelen bij het optreden van problemen. Ook de andere ontwerpteams waarmee we nauw hebben samengewerkt voor dit project willen we bedanken voor hun insteek en hulp. Delft, 18 juni 2007 C.C. Chi T. Kaserer F. Schilders H. Syed

4 Samenvatting Steeds meer mensen bellen via internet en de trend is om dit draadloos te kunnen door middel van een mobiele telefoon. De dekking van VoIP is helaas nog lang niet vergelijkbaar met dat van gsm. Omdat er nog geen apparaat is die dit gat opvult, wil PhoneTU een dual mode telefoon op de markt zetten. Met deze telefoon kan de uitgebreide dekking van het gsm-netwerk worden gecombineerd met het goedkoop bellen van VoIP. PhoneTU heeft de opdracht om de dual mode telefoon te ontwikkelen gegeven aan haar R&D afdeling, welke het project Prototype is gestart. Prototype heeft als doel een FPGA-ontwerp van de telefoon te creëren om meer inzicht te krijgen in de haalbaarheid van een mobiele dual mode telefoon en de eventuele knelpunten. Het hoofdproject is opgedeeld in een aantal deelprojecten. Het doel van het deelproject Audio-Netwerk is een ontwerp te presenteren van de audio- en netwerkfunctionaliteit met de gebruikte koppeling als basis voor het hoofdproject Prototype. Na een aantal iteratieve gesprekken met de projectleiding is duidelijk geworden dat de verwachting van het deelproject Audio-Netwerk is een flexibele basis te ontwerpen voor het hoofdproject Prototype binnen een tijdsbestek van 7 weken. De basis dient als een proof-of-concept voor de VoIP functionaliteit van de telefoon en een fundament voor verdere ontwikkeling. Met de wensen van de projectleiding, heeft het deelproject een aantal concepten onderzocht. Hieruit is gebleken dat een concept waarbij een deel van de FPGA gebruikt wordt voor een general purpose processor en de functies voornamelijk softwarematig te ontwerpen, het best bij de wensen van de projectleiding past. In de uitwerking van dit concept is een Nios-systeem gebruikt. Een Nios-systeem is een configureerbare embedded platform. De configuratie in dit ontwerp bestaat uit een Nios II general purpose processor en een aantal blokjes voor communicatie met andere chips op het Altera DE2 FPGA-bord. Vooral de communicatie met de WM8731-audiochip en de DM9000A-netwerkchip is van belang. Met dit Nios-systeem is een platform gerealiseerd met C-capable processor dat in verbinding staat met de audio- en netwerkchip. De functionele koppeling is door het gebruik van het Niossysteem mogelijk in een interrupt gebaseerde C-applicatie. De testen met betrekking tot de gesprekskwaliteit blijven ruim binnen de gestelde eisen. De vertraging van het hele traject zender Altera FPGA 1- Altera FPGA 2- ontvanger bedraagt 22 ms, ruim binnen de gestelde 100ms. Ook de SNR-degradatie is met 10dB veilig binnen de marge van <15 db. Alleen de bitrate van het audiosignaal is vrij kritiek. Deze blijft net binnen de gestelde 128kbps. De conclusie is dat een software-implementatie voor de audio- en netwerkfunctionaliteiten voldoet aan de gestelde eisen Uit de testresultaten blijkt dat dit ontwerp zeer geschikt is voor verzenden en ontvangen van audiosignalen over twee Altera DE2 borden. Omdat het ontwerp binnen de gestelde performance eisen valt en volgens een softwarematig concept is uitgevoerd, kunnen makkelijk nieuwe functies toegevoegd worden. Functionaliteiten als een zwaardere audiocodering, ondersteuning voor SIP, een draadloze verbinding en een verbeterde gebruikersinterface vallen binnen de mogelijke uitbreidingen van dit ontwerp.

5 Inhoudsopgave 1 INLEIDING PROGRAMMA VAN EISEN PvE deelfunctie audio Functioneringcriteria Randvoorwaarden De deelfunctie netwerk Functioneringscriteria Randvoorwaarden CONCEPTEN VAN HET AUDIO- EN HET NETWERKDEEL Concepten van de audioverwerking Een softwareontwerp met minimale hardwaretoepassing Een specifieke processor voor de audioverwerking Een software ontwerp met hardwarematige versnelling Concepten van de netwerkfunctie Een softwareoplossing Een hardwareoplossing Een deels software- en deels hardwareoplossing CONCEPTKEUZE EN VERANTWOORDING Conceptkeuze voor de deelfunctie audio Toelichting criteria en weging Waardering en Conceptkeuze Conceptkeuze voor de deelfunctie netwerk Toelichting criteria Conclusie UITWERKING VAN HET AUDIO- EN HET NETWERKDEEL Gebruikte apparatuur Gebruikte software De onderdelen op het Altera DE2 bord De deelfunctie audio Hardware Software De deelfunctie netwerk Hardware Software De koppeling van de softwarefuncties ISR audio interrupt ISR DM9000A interrupt Main functie TESTEN VAN HET SYSTEEM Gebruikte testopstellingen Meetopstelling Meetopstelling Meetopstelling Meetopstelling

6 6.1.5 Meetopstelling Meetopstelling Geteste criteria en testresultaten Audio Netwerk CONCLUSIES EN AANBEVELINGEN Conclusies Aanbevelingen BRONVERMELDING BIJLAGE A: VERILOG CODE VAN DE TOP MODULE NIOS-SYSTEEM BIJLAGE B: GEBRUIKTE AUDIO EN NETWERK C-CODE B1 Alt_up_audio.c B2 Alt_up_audio_video_config.c B3 Audio.c B4 DM9000A.c B5 G711.c BIJLAGE C: GEBRUIKTE MAIN C-CODE BIJLAGE D: ZELFEVALUATIE D1 C.C.Chi studienummer D2 T.Kaserer studienummer D3 H.Syed studienummer D4 F.Schilders studienummer

7 1 Inleiding Steeds meer mensen bellen via internet en de trend is om dit draadloos te kunnen door middel van een mobiele telefoon. De dekking van VoIP is helaas nog lang niet vergelijkbaar met dat van gsm. Omdat er nog geen apparaat is die dit gat opvult, wil PhoneTU een dual mode telefoon op de markt zetten. Met deze telefoon kan de uitgebreide dekking van het gsm-netwerk worden gecombineerd met het goedkoop bellen van VoIP. Hoewel de ambitie van PhoneTU groot is, zit het bedrijf nog in de ontwerpfase. Om een stap te zetten naar een daadwerkelijke lancering, is de R&D-afdeling gestart met het project Prototype. Prototype heeft als doel een FPGA-ontwerp van de telefoon te creëren om meer inzicht te krijgen in de haalbaarheid van een mobiele dual mode telefoon en de eventuele knelpunten. In dit rapport wordt antwoord gegeven op de vraag: wat is de beste methode om de deelfuncties audioverwerking en netwerkfunctionaliteit van de dual mode telefoon op een FPGA te creëren en samen te laten functioneren? Op basis van literatuuronderzoek is het beste concept uitgewerkt voor de twee deelfuncties. Als laatste zijn deze functies gekoppeld en getest. Hierbij wordt vanuit gegaan dat het deelproject afgerond moet zijn in zeven weken en het ontwerp op een Altera De2 bord gemaakt moet worden. De opbouw van dit rapport is als volgt. In hoofdstuk 2 wordt het programma van eisen opgesteld. Vervolgens wordt er in hoofdstuk 3 een aantal mogelijke concepten voorgesteld om in hoofdstuk 4 de afweging tussen de verschillende concepten te kunnen maken. In hoofdstuk 5 volgt een gedetailleerde uitwerking van de deelfuncties en de koppeling hiertussen. In Hoofdstuk 6 zal de testmethode worden toegelicht en de resultaten worden besproken. Hoofdstuk 7 bevat conclusies over de beste methode dat binnen de gestelde eisen gerealiseerd kan worden en aanbevelingen over uitbreidingen van de gerealiseerde methode. 7

8 2 Programma van Eisen Aangezien PhoneTU zich in de startfase van het ontwerptraject bevindt, hebben de R&Dafdelingshoofden van PhoneTU besloten een prototype van de VoIP-telefoon te maken. Het project Prototype is opgesplitst in deelprojecten. Na een aantal iteratieve gesprekken met de projectleiding is duidelijk geworden dat de verwachting van het deelproject Audio-Netwerk is een flexibele basis te ontwerpen voor het hoofdproject Prototype binnen een tijdsbestek van 7 weken. Er is uiteindelijk een Programma van Eisen van de deelfuncties opgesteld. In het Programma van Eisen zien we twee hoofdcategorieën, nl. de functioneringscriteria en de randvoorwaarden. In de eerste staan de criteria waaraan de oplossing van het probleem aan moet voldoen en dat zijn de gekwantificeerde wensen van de afdelingshoofden. De randvoorwaarden komen direct van de projectleiding af en zijn een afbakening van het zoekveld voor het uitwerken van de systeemconcepten. In paragraaf 2.1 zal het Programma van Eisen van de audioverwerking besproken worden en in paragraaf 2.2 zal de deelfunctie Netwerk besproken worden. Per paragraaf zal een onderverdeling gemaakt worden in functioneringscriteria en randvoorwaarden. 2.1 PvE deelfunctie audio In deze paragraaf zal het Programma van Eisen van de audioverwerking van de VoIP telefoon besproken worden Functioneringcriteria Aan de volgende functioneringscriteria moet het audio-gedeelte van de VoIP-telefoon voldoen: F1.1 Het audio-gedeelte moet ondersteuning bieden voor de G.711 audio codec. F1.2 De bandbreedte van het geluid moet minimaal 3,5 khz bedragen. F1.3 De SNR-degradatie van de audioverwerking mag in de frequentieband tot 3,5 khz maximaal 15 db bedragen F1.4 De THD mag maximaal 5% bedragen F1.5 De vertraging mag maximaal 60 ms voor het traject in de FPGA s. De tijd die het netwerkdeel nodig heeft voor het versturen en ontvangen, wordt hierbij niet meegenomen. F1.6 Het audio gedeelte moet zonder problemen te integreren zijn in het hoofdproject, de gehele VoIP-telefoon. F1.7 De bitrate van het audiosignaal mag maximaal 128kbps bedragen Randvoorwaarden Het ontwerp van de audiobewerking moet aan de volgende randvoorwaarden voldoen: 8

9 R1.1 Als wordt gekozen om functies in C te implementeren, moet er gebruik gemaakt worden van de Nios-processor. R1.2 Het FPGA-ontwerp van het audiodeel mag niet meer dan LE s in beslag nemen. R1.3 Het prototype moet op een Altera DE2 bordje draaien. R1.4 Het prototype moet binnen 7 weken af zijn. 2.2 De deelfunctie netwerk In deze paragraaf zal het Programma van Eisen van het netwerkdeel van de VoIP telefoon besproken worden Functioneringscriteria Aan de volgende functioneringscriteria moet het netwerk gedeelte van de VoIP telefoon zich aan voldoen: F2.1 Het netwerkdeel moet datapakketjes met een grootte van 64 tot 1024 Bytes kunnen verzenden en ontvangen. F2.2 De pakketjes moeten verzonden en ontvangen worden over een bedrade ethernetverbinding. F2.3 Het netwerkdeel moet minimaal 520 kb/s tegelijkertijd kunnen versturen en ontvangen. F2.4 De vertraging van het verzenden en ontvangen van data tussen 2 FPGA s, mag maximaal 40 ms bedragen. F2.5 Het netwerkdeel moet zonder problemen te integreren zijn in het hoofdproject, de gehele VoIP-telefoon Randvoorwaarden De randvoorwaarden voor de netwerkfuncties zijn hetzelfde als die van het audiodeel: R2.1 Er moet een protocol gebruikt worden om verbinding op te zetten en af te sluiten. R2.2 Als wordt gekozen om functies in C te implementeren, moet er gebruik gemaakt worden van de Nios-processor. R2.3 Het prototype moet op een Altera DE2 bordje draaien. R2.4 Het FPGA-ontwerp van het netwerkdeel mag niet meer dan LE s in beslag nemen. R2.5 Het prototype moet binnen 7 weken af zijn. 9

10 3 Concepten van het audio- en het netwerkdeel In paragraaf 3.1 en 3.2 van dit hoofdstuk zullen verschillende mogelijke concepten besproken worden voor respectievelijk de audioverwerking en de netwerkfunctie. Aan de hand van de functioneringscriteria en randvoorwaarden in hoofdstuk 2, zijn de audioverwerking en de netwerkfunctie opgedeeld in deelfuncties. In paragraaf 3.1.1, en worden verschillende combinaties van de deelfuncties van de audioverwerking gebruikt voor het maken van concepten. In paragraaf 3.2.1, en worden verschillende combinaties van deelfuncties van de netwerkfunctie ook gecombineerd tot concepten. 3.1 Concepten van de audioverwerking Aan de hand van het PvE opgesteld uit hoofdstuk 2 is een morfologische kaart gemaakt (zie tabel 1). In een morfologische kaart wordt aan hand van de functie-eisen en de randvoorwaarden een aantal deelfuncties opgesteld en voor elke deelfunctie worden er een of meerdere Beginsel Oplossingen (BO's) opgesteld. Door deze BO's verticaal te combineren worden er verschillende systeemconcepten verkregen. Tabel 1: Morfologische kaart van de audioverwerking BO's BO's Samples brengen Hardware Software Samples ophalen Hardware Software Coderen Hardware Software Zoals te zien is in tabel 1, is er voor elk van de deelfuncties een hardware- en een softwareoplossing te bedenken. Hieruit zijn er drie concepten ontwikkeld: 1. Een grotendeels software ontwerp voor Nios-processor met minimale toevoeging van hardware componenten 2. Een grotendeels hardware ontwerp met minimaal gebruik van de Nios-processor 3. Een deels software ontwerp voor de Nios-processor met hardwarematige versnelling voor rekenintensieve delen. In paragraaf t/m wordt een toelichting van de concepten en de beschrijving van hun eigenschappen gegeven Een softwareontwerp met minimale hardwaretoepassing - Beschrijving In dit concept worden de functies van de audioverwerking geprogrammeerd in een programmeertaal zoals C of C++ om deze vervolgens te laten draaien op de Nios-processor en deze zal dus geprogrammeerd moeten worden op de FPGA. Alleen voor de communicatie van de Nios-processor met de audio chip is er een extra functieblok (interface) nodig. Deze functieblok moet beschreven 10

11 worden in een hardwaretaal zoals VHDL of Verilog. Deze functieblok is nodig om de communicatie tussen de processor en de audiochip te versimpelen. In figuur 1 is een schematisch schema van dit concept te zien. De deelfuncties worden uitgevoerd door de Nios-processor. - Voor- en nadelen Dit ontwerp is flexibel tijdens maar ook na het ontwikkelen. Op elk moment is het relatief gemakkelijk om functies te wijzigen, te verbeteren of toe te voegen. Ook is dit concept een stuk minder complex in de uitwerking. Door de flexibiliteit en de geringe complexiteit is de ontwerptijd relatief laag. Deze oplossing functioneert echter trager dan een in hardware gemaakt ontwerp waardoor alle randvoorwaarden betreffende de gesprekskwaliteit in het geding komen. Figuur 1: Blokschema van concept 1 van de audioverwerking Een specifieke processor voor de audioverwerking - Beschrijving In dit concept wordt een specifieke processor voor de audioverwerking ontworpen. Het ontwerp dient volledig in een hardwaretaal gemaakt te worden. De audioprocessor heeft alleen een interface waarmee de Nios-processor deze audioprocessor kan aansturen, maar voert verder onafhankelijk zijn taken uit.. In figuur 2 is een schematisch schema van dit concept te zien. De deelfuncties worden uitgevoerd door de specifieke processor. - Voor- en nadelen Een groot voordeel van dit concept is dat de Performance/Watt verhouding vele malen groter is dan een ontwerp in software. Dit is ideaal voor mobiele apparaten die lang mee moeten gaan. Echter, de ontwikkeltijd van deze oplossing is lang en de functionaliteit is moeilijk te wijzigen. 11

12 Figuur 2: Blokschema van concept 2 van de audioverwerking Een software ontwerp met hardwarematige versnelling - Beschrijving Het laatste concept is een tussenvorm van concept 1 en 2. De meeste functies zullen door de Niosprocessor worden uitgevoerd. Alleen de functies die significant versneld kunnen worden, krijgen een hardwarematig ontwerp. De hardware accelerator (zie figuur 3) is verbonden met de Niosprocessor en de rekenintensieve data zullen door dit blok uitgevoerd worden. De rekenintensieve onderdelen kunnen geïdentificeerd worden door eerst de functies in C/C++ te beschrijven om vervolgens de tijdrovende elementen eruit te halen. In figuur 3 is een schema van dit concept te zien. De rekenintensieve taken worden uitbesteed door de Nios-processor aan de hardware accelerator. - Voor- en nadelen Dit ontwerp is op alle fronten een tussenvorm van concept 1 en 2. De performance is beter dan de softwarematige oplossing maar slechter dan een hardware oplossing, etc. Dit ontwerp wordt vaak gebruikt wanneer men het beste van twee werelden wilt hebben. Figuur 3: Blokschema van concept 3 van de audioverwerking 12

13 3.2 Concepten van de netwerkfunctie Net zoals in hoofdstuk 3.1 wordt er een morfologische kaart opgesteld aan de hand van de verschillende deelfuncties. In tabel 2 zijn de verschillende deelfuncties en de bijpassende beginseloplossingen (BO s) te vinden. De deelfuncties zijn aan de hand van de functioneringscriteria en de randvoorwaarden opgesteld en voor elke deelfunctie worden er een of meerdere BO's opgesteld. Door deze verticaal te combineren, worden er verschillende systeemconcepten verkregen. Tabel 2: Morfologische kaart van de netwerkfunctionaliteit BO's Data versturen Hardware Software Data ontvangen Hardware Software Netwerk initialiseren Hardware Software Zoals te zien is in tabel 2, is er voor elk van de deelfuncties een hardware- en een softwareoplossing te bedenken. Hieruit zijn er drie concepten ontwikkeld: 1. Een grotendeels softwareontwerp processor met minimale toevoeging van hardware componenten, uitgezonderd de Nios-processor 2. Een hardwareontwerp met geen gebruik van de Nios-processor 3. Een deels software ontwerp met gebruik van de Nios-processor maar met hardwarematige versnelling voor rekenintensieve taken. In paragraaf t/m wordt een toelichting van de concepten met de voor- en nadelen gegeven Een softwareoplossing - Beschrijving In dit concept worden alle deelfuncties geprogrammeerd in C of C++ om deze software vervolgens te laten draaien op de Nios-processor. Deze zal dus geprogrammeerd moeten worden op de FPGA. Voor de communicatie van de Nios-processor met de DM9000A netwerkchip is er tevens een extra functieblok (interface) nodig, die in een hardwaretaal zoals VHDL/Verilog beschreven moet worden. Deze functieblok is nodig om communicatie tussen de processor en de netwerkchip mogelijk te maken. Echter, deze interface wordt als noodzakelijk beschouwd en dus wordt dit concept wel als een softwareoplossing beoordeeld. In figuur 4 is een schematisch schema van dit concept te zien. De deelfuncties worden uitgevoerd door de Nios-processor. 13

14 Figuur 4: Blokschema van concept 1 van de netwerkfunctie - Voor- en nadelen Dit concept heeft een grote flexibiliteit tijdens het ontwikkelen. Software kan immers snel gewijzigd en gehercompileerd worden in tegenstelling tot hardware. Want deze moet onder andere opnieuw gesynthetiseerd en op de FPGA geprogrammeerd worden. Dit is een relatief tijdrovend proces, zeker wanneer het gaat om grote en complexe hardwareblokken. Tevens is dit concept een stuk minder complex in de uitwerking. Door de flexibiliteit en de geringe complexiteit is de ontwerptijd relatief kort. Een mogelijk nadeel van een softwareoplossing is het gebrek aan Logical Elements (LE s) die aan het netwerkdeel ter beschikking zijn gesteld. Over het algemeen neemt een processor op een FPGA veel ruimte in. Echter de snelste versie van de Nios-processor neemt slechts 1800 LE s in beslag en dit betekent dat er nog 7200 LE s over zijn voor de DM9000A-controller en dat is ruim voldoende. Een ander mogelijk nadeel van een softwareoplossing is de snelheid van verwerking van de deelfuncties. In tegenstelling tot de audioverwerking heeft echter het netwerkdeel niet te maken met rekenintensieve taken en een softwareoplossing zou dus in dit geval snel genoeg moeten zijn. Het versturen en ontvangen van data is een vrij simpele bewerking en ook het initialiseren van de DM9000A-netwerkchip is zonder problemen uitvoerbaar in software. (Bron: Vahid & Givargis 2002, p. 9) 14

15 3.2.2 Een hardwareoplossing - Beschrijving Bij dit ontwerp wordt het product helemaal in hardware gemaakt. Bij het ontwerp zullen dus verschillende functieblokken ontworpen moeten worden in een hardwaretaal die het initialiseren van de DM9000A netwerkchip en het verzenden/ontvangen van data op zich nemen. Deze functieblokken nemen bij elkaar dus de hele netwerkfunctionaliteit op zich. In figuur 5 is een blokschema met de verschillende deelfuncties in hardware weergegeven. Figuur 5: Blokschema van concept 2 van de netwerkfunctie - Voor- en nadelen Het voordeel van de hardwareoplossing is dat o.a. het klaarzetten van de data voor verzending en de initialisatie een stuk sneller kan worden uitgevoerd dan in vergelijking met de softwareoplossing. Echter, volgens onze functioneringscriteria hoeft het netwerkdeel maar 520 kb/s tegelijkertijd te kunnen versturen en ontvangen. Dus als de volle snelheid benut kan worden met het gebruik van de Nios-processor, kan de verwerkingssnelheid van hardware ten opzichte van software niet als voordeel gerekend worden. Tevens is de flexibiliteit van de ontwikkeling van een complete hardwareoplossing beperkt. Wijzigingen in het ontwerp nemen meer tijd in beslag dan wijzigingen in software. Ook is dit concept een redelijk complex in de uitwerking. Voor de ontwikkeling van de VoIP-prototype is een beperkte tijd beschikbaar en de langere ontwikkeltijd in hardware als gevolg van de complexiteit en de beperkte flexibiliteit wordt dan ook als een groot nadeel beschouwd. 15

16 3.2.3 Een deels software- en deels hardwareoplossing - Beschrijving In dit concept wordt voor een deel van de deelfuncties een hardwareoplossing bedacht en voor het andere deel wordt er gebruik gemaakt van software. De hardwareoplossing zal gebruikt worden voor de rekenintensieve taken en de Nios-processor zal deze taken dus uitbesteden aan de hardwareaccelerator. In figuur 6 is een schematisch overzicht gegeven van de uitbesteding van de rekenintensieve taken door de Nios-processor. Figuur 6: Blokschema van concept 3 van de netwerkfunctie - Voor- en nadelen Het voordeel van de hardwareacceleratie is het toenemen van de verwerkingssnelheid. Zoals echter in paragraaf al is beschreven, is hardwareversnelling niet nodig omdat het netwerkdeel geen rekenintensieve taken bevat. De processor kan snel genoeg de data aan de netwerkchip aanbieden en afnemen. Een nadeel van dit concept is een lange ontwerptijd o.a. als gevolg van de hoge complexiteit en daarnaast is de functionaliteit moeilijk te wijzigen. 16

17 4 Conceptkeuze en verantwoording In hoofdstuk 3 zijn drie concepten besproken per functie en er moet één uitgekozen worden voor het ontwerp. Dat wordt in paragraaf 4.1 en 4.2 gedaan aan de hand van criteria en weegfactoren voor respectievelijk de audiofunctionaliteit en de netwerkfunctionaliteit. 4.1 Conceptkeuze voor de deelfunctie audio In tabel 3 zijn de criteria tegenover de concepten gezet en opgeteld na vermenigvuldiging met een weegfactor. Een hoog cijfer correspondeert met een hoge waardering en een laag cijfer met een lage waardering. In paragraaf worden de criteria en de weging toegelicht en in paragraaf wordt de uiteindelijke conceptkeuze gemaakt. Tabel 3: Criteria tegenover de audioverwerkingconcepten Weeg factor Concept 1: Software Concept 2: Hardware Concept 3: Software/Hardware Ontwerptijd Flexibiliteit Performance/Watt Totaal Toelichting criteria en weging Ontwerptijd is de tijd die nodig is om het concept te implementeren. We hebben 7 weken voor de implementatie. Als het concept 100 % zeker in die tijd af kan dan krijgt het concept een 10 als cijfer en als het 100% zeker niet in die 7 weken is te implementeren dan krijgt het concept een 0 als cijfer. De Flexibiliteit geeft weer in hoeverre het ontwerp te wijzigen is gedurende het ontwerpproces en daarna. Want bijvoorbeeld een ontwerp louter in hardware is haast niet te wijzigen na het ontwerpproces zonder veel tijdsverlies en daarmee kosten. Als een concept op elke moment te wijzigen is, dan krijgt het een 10 als cijfer. Een lager cijfer wordt toegekend afhankelijk van hoe moeilijk of tijdrovend het is om het ontwerp te wijzigen. Performance/Watt is de verhouding tussen de behaalde gesprekskwaliteit binnen de maximale datarate van 128 kbps en het opgenomen vermogen. Omdat het opgenomen vermogen op de FPGA nagenoeg gelijk is voor elk concept valt deze weg uit de vergelijking. De gesprekskwaliteit wordt bepaald door de mate van aanwezigheid van de functioneringscriteria F1.1 t/m F1.5 en F1.7 opgesteld in hoofdstuk De functioneringscriteria F1.1 t/m F1.5 en F1.7 representeren respectievelijk de codering, bandbreedte, SNR-degradatie, THD, vertraging, en bitrate. Deze afzonderlijke elementen zijn samengenomen, omdat ze uit dezelfde bron putten namelijk de beschikbare rekenkracht. Elk element moet in voldoende mate aanwezig zijn om een goede gesprekskwaliteit te verkrijgen. Voor Performance/Watt wordt een 10 gegeven wanneer het concept de maximale gesprekskwaliteit weet te halen binnen de eis van 128 kbps. Een 6 wordt toegekend aan acceptabele gesprekskwaliteit. 17

18 Een 1 wordt toegekend wanneer de gesprekskwaliteit zo laag is dat het totaal niet mogelijk is een gesprek te voeren. Aan de hand van deze drie criteria wordt het concept gewogen. De criteria hebben echter niet dezelfde prioriteit. Om een ordening hierin te geven is de weegfactor ingevoerd. In Tabel 3 is te zien dat de ontwerptijd het belangrijkste criterium is, gevolgd door de flexibiliteit. Aan de performance/watt verhouding wordt minder belang gehecht, zolang deze voldoende is. De ordening is voortgekomen uit de iteratieve gesprekken met de projectleiding Waardering en Conceptkeuze In tabel 3 is te zien dat concept 2 een 10 scoort op performance. Wanneer goed uitgewerkt is dit concept niet te evenaren op dit criterium. Desondanks scoort deze het minste totaal aantal punten, omdat op de andere twee punten matig wordt gepresteerd. Het concept scoort namelijk weinig punten voor ontwerptijd en flexibiliteit. Het ontwerptraject is altijd langer dan de andere concepten en het ontwerp is specifiek gemaakt voor een bepaalde configuratie. In het geval van een verandering van configuratie is er vrijwel altijd sprake van een herontwerp. Dit concept valt af, omdat er niet naar de snelste oplossing gezocht wordt. De scores van concept 1 en 3 verschillen niet veel. Concept 3 heeft een betere performance dan concept 1 omdat de rekenintensieve delen in hardware zijn geïmplementeerd. Nadeel hiervan is dat het minder flexibel is en een langere ontwerptijd heeft. Concept 1 heeft echter ondanks de slechtste performance de hoogste score. Doordat dit concept minder complex en makkelijker aan te passen is, scoort het hoog op de criteria ontwerptijd en flexibiliteit. Conclusie Er is voornamelijk door de grote weging van de ontwerptijd gekozen voor concept 1. Mocht de performance toch een bottleneck worden dan kan er altijd nog overgestapt worden op concept 3, omdat deze praktisch voortborduurt op concept 1. Er gaat geen tijd verloren door deze eventuele overstap. 18

19 4.2 Conceptkeuze voor de deelfunctie netwerk Net als in paragraaf 4.1 zal er voor het netwerkdeel ook een conceptkeuze gemaakt worden aan de hand van een weging. In paragraaf worden de criteria toegelicht en in paragraaf wordt het definitieve concept gekozen. In tabel 4 staan de concepten in de kolommen en de criteria staan in de rijen. In de vakken wordt met een getal een weegfactor gegeven voor het desbetreffende criterium. De weegfactor dient ervoor om de verschillende criteria met een bepaalde factor mee te tellen, want zo heeft de ontwerptijd een hogere prioriteit dan bijvoorbeeld de performance omdat ons project binnen zeven weken afgerond moet zijn en performance altijd nog verbeterd kan worden in een eventueel vervolgproject. Een hoog cijfer correspondeert met een hoge waardering en een laag cijfer met een lage waardering. Uiteindelijk worden de getallen per criterium vermenigvuldigd met de desbetreffende weegfactor en opgeteld in laatste rij totaal. Tevens moet vermeld worden dat de beschikbare ruimte op de FPGA (uitgedrukt in LE s) ook een criterium is. Deze is alleen weggelaten omdat door de overvloed aan ruimte, alle concepten binnen de ruimte blijven en ze dus als gevolg allemaal hetzelfde cijfer krijgen. Tabel 4: Criteria tegenover de netwerkfunctieconcepten Weeg factor Concept 1: Software Concept 2: Hardware Concept 3: Software/Hardware Ontwerptijd Flexibiliteit Performance Totaal Toelichting criteria Ontwerptijd is de tijd die nodig is om het concept te implementeren. We hebben 7 weken voor het ontwerp, het testen en de documentatie. Als het concept 100 % zeker in die tijd af kan, krijgt het concept het cijfer 10 en als het 100% zeker niet in die 7 weken is te af te ronden, krijgt het concept een 0 als cijfer. De verwachting is dat concept 1 de kortste ontwerptijd heeft en scoort daarom het hoogst. Dit concept maakt alleen gebruik van software en dit reduceert sterk de ontwerptijd. Concept 3 krijgt een 5 omdat hier deels gebruik gemaakt wordt van hardware en dit maakt het concept behoorlijk tijdrovend. Aan de haalbaarheid binnen 7 weken valt met dit concept te twijfelen en dit concept krijgt daarom een 5. Concept 2 scoort het slechts op ontwerptijd. Dit concept moet volledig in hardware gemaakt worden, wat een ingewikkelde en tijdsintensieve taak is. Om hardware aan te passen en opnieuw te testen, kost o.a. veel tijd vanwege het opnieuw synthetiseren. De verwachting is dat dit concept niet te halen is binnen 7 weken en krijgt daarom een 3. De Flexibiliteit geeft weer in hoeverre het ontwerp te wijzigen is gedurende het ontwerpproces en eventueel in het proces erna. Want bijvoorbeeld een ontwerp louter in hardware is tijdsintensiever 19

20 om te wijzigen na het ontwerpproces dan een oplossing gemaakt met software. Als een concept op elke moment te wijzigen is, krijgt deze een 10 en als het een lange tijd in beslag neemt, dan krijgt het concept voor dit criterium een lager cijfer, afhankelijk hoe moeilijk of tijdrovend het is om het ontwerp te wijzigen. Omdat de flexibiliteit van software groot is en aangezien concept 1 compleet in software gemaakt wordt, scoort concept 1 een 9. Omdat hardware moeilijk te wijzigen is gedurende het ontwerpproces en concept 2 compleet in hardware gemaakt wordt, scoort concept 2 laag met een 4. In concept 3 is het mogelijk de meeste onderdelen in software en de rest in hardware te maken. Dit concept zit tussen concept 1 en concept 2 in, maar omdat er waarschijnlijk meer software gebruikte wordt, scoort dit concept net een voldoende met een 6. De Performance is een maat voor de snelheid waarmee de pakketjes verstuurd en ontvangen kunnen worden. De eis zegt dat het netwerkdeel minimaal 520kb/s tegelijkertijd moet kunnen ontvangen en versturen. Als het netwerkdeel met het betreffende concept dat haalt, wordt er een 10 toegekend. Voor een lagere ontvangst- of verzendsnelheid, wordt er een lager cijfer gegeven. Aan alle drie de concepten wordt een 10 toegekend, omdat verwacht wordt dat er geen rekenintensieve onderdelen in het netwerkdeel voorkomen en dus de performance van alle drie de concepten goed is. Dit zijn de drie belangrijke criteria waaraan een concept moet voldoen. In de laatste rij van tabel 3 worden de totalen van de concepten weergegeven. Het concept met het grootste totaal zal gebruikt worden voor het ontwerp Conclusie Concepten 2 en 3 maken gebruik van hardware en dat heeft een negatieve invloed op de flexibiliteit en ontwerptijd. De performance van deze concepten zijn wel goed. Concept 1maakt compleet gebruik van software en haalt net als de andere concepten de eis van ontvangst- en verstuursnelheid. Daarbij heeft het ook het grote voordeel van grote flexibiliteit en korte ontwerptijd. Concept 1 heeft daardoor de meeste punten en wordt om deze reden gebruikt. 20

21 5 Uitwerking van het audio- en het netwerkdeel In hoofdstuk 4 is het beste concept voor elk van de twee deelfuncties vastgesteld. In dit hoofdstuk is de uitwerking te vinden van deze concepten. In paragraaf 5.1 en 5.2 zal respectievelijk de gebruikte apparatuur en de gebruikte software besproken worden. In paragraaf 5.3 worden de onderdelen op het Altera DE2 bord besproken en in 5.4 en 5.5 worden de uitwerkingen van de deelfuncties audio en netwerk behandeld. 5.1 Gebruikte apparatuur Voor het ontwerp is gebruikt gemaakt van een Altera DE2 FPGA-bord. De Altera DE2 heeft naast de Cyclone II FPGA o.a. aansluitingen naar de aansturingchip voor audio en ethernet. Deze zijn handig om een prototype te maken van een Internet Protocol telefoon. In figuur 7 staan de veelvuldig gebruikte onderdelen genummerd. Verder is gebruikt gemaakt van Windows XP machines voor aansturing van de DE2 via een USB interface. Veel informatie over deze Altera DE2 bord is te vinden op 3 Figuur 7: De lay-out van de Altera DE2. Een aantal onderdelen zijn gemarkeerd: 1. Cyclone II FPGA 2. Audio codec chip WM Audio in- en uitgangpoorten 4. DM9000A netwerkchip 21

22 5. Netwerkaansluiting RJ-45 Bron: Gebruikte software Om van het FPGA-bord gebruik te kunnen maken is de Windows variant van de volgende software gebruikt: Quartus II 6.0, Modelsim 6.1c, Altera debug-client, Nios IDE 6.1. Quartus biedt de mogelijkheid hardware beschreven in VHDL of Verilog te compileren en te programmeren voor de Altera DE2. Een veelgebruikt onderdeel van Quartus is de SOPC Builder. Met de SOPC Builder kan een Nios II embedded processor geconfigureerd worden om vervolgens een VHDL beschrijving van de Nios te genereren. Modelsim is gebruikt voor de simulatie van Verilog en VHDL code. Met dit programma is het mogelijk om gemakkelijk zelf geschreven code te testen. Door middel van signalen te creëren op basis van de zelf gedefinieerde ingangen en code kan de ontwerper zien of het ontwerp werk. In Nios IDE en Altera debug client kan software in de programmeertalen C, C++ en assembly worden ontwikkeld en ingeladen. Het inladen werkt alleen wanneer een Nios II is geprogrammeerd op de FPGA. Webverwijzingen voor meer informatie van het Altera DE2 bord en de gebruikte software bevinden zich in bijlage B en C. 5.3 De onderdelen op het Altera DE2 bord Het blokschema in figuur 8 geeft weer welke blokken op altera DE2 bord zitten en hoe deze onder andere verbonden zijn met de audio chip en de netwerkchip. Het gedeelte binnen het Altera Cyclone II FPGA kader is zelf te programmeren. Er is gekozen om een Nios systeem te programmeren op de FPGA. 22

23 Figuur 8: Een blokschema van de geprogrammeerde FPGA Het Nios-systeem is een platform waarop C/C++ code kan draaien. De afzonderlijk blokjes van het Nios-systeem kunnen worden samengesteld in de Quartus functie SOPC Builder. De Nios II processor, JTAG UART en de Avalon Switch Fabric vormen de essentie van het Nios systeem. Deze onderdelen alleen kunnen al een werkend systeem opleveren. De andere onderdelen geven het systeem extra mogelijkheden. De onderdelen zijn zo gekozen dat het een werkende test-opstelling oplevert wanneer twee van deze systemen met elkaar verbonden worden via het Ethernet blokje. We zullen in deze paragraaf kort ingaan op de functie van de Nios-processor, Avalon Switch Fabric en de JTAG UART. - Nios-processor De Nios-processor is een General Purpose Processor. Een programmeertaal als C wordt ondersteund voor het beschrijven van functies voor de Nios. Dit vereenvoudigt het werk, omdat C zich makkelijker daarvoor leent dan Verilog of VHDL. In paragraaf en is dit uitvoerig besproken. De Nios komt in de varianten economy, standard en full featured. Wij hebben gekozen voor de full featured versie. De full featured versie is de enige die voldeed aan de performance eisen. Alle functies van de telefoon kunnen gebruik maken van de Nios-processor. 23

24 - Avalon Switch Fabric De Switch Fabric is de systeembus van het Nios-systeem. Alle communicatie tussen de componenten verloopt via deze bus. Elk onderdeel van de telefoon dat een aparte module vereist, kan deze verbinden met deze bus. - JTAG UART De JTAG UART staat voor Joint Test Action Group Universal Asynchronous Receiver Transmitter en heeft als functie het Nios-systeem te verbinden met de PC. Met deze verbinding kan via de Nios IDE C/C++ programma s ingeladen worden in het Nios systeem. Ook biedt JTAG UART de mogelijkheid om hardwarematig te debuggen. - Overige onderdelen De overige onderdelen behalve de audio en DM9000A onderdelen zijn niet direct van belang voor het begrijpen van het ontwerp. Het is wel aan te raden om in de literatuur van deze overige onderdelen te verdiepen wanneer dit ontwerp wordt gebruikt in een eigen implementatie. Voor informatie over alle onderdelen verwijzen we naar De deelfunctie audio Het doel van de audioverwerking is van een analoog audiosignaal te digitaliseren en vervolgens te encoderen volgens de G.711 standaard. Ook moet de weg terug van geëncodeerde data naar een analoog signaal ook mogelijk zijn. Uit hoofdstuk 4 Conceptkeuze en verantwoording is de keuze voortgekomen om zoveel mogelijk onderdelen in software te implementeren. Deze paragraaf is onderverdeeld in de subparagrafen: Hardware en Software waarin de gedetailleerde uitwerking van de audioverwerking staat Hardware De oranje gekleurde blokken in figuur 9 zijn specifiek voor deze deelfunctie. De Audio Config en Audio Interface worden meegeprogrammeerd in het Nios Systeem. De WM8731 audio chip zit los op het DE2 bord. De oranje gekleurde blokjes zullen verder worden toegelicht in deze paragraaf. De blauwe blokken zijn andere onderdelen op de FPGA. De blokken die buiten de Altera Cyclone II FPGA bevinden, zijn als losse componenten aanwezig op het Altera DE2 bord. 24

25 Figuur 9: Blokschema Audio - Audio Interface De functie van de Audio Interface is de Nios-processor op een makkelijke manier verbinden met de audiochip. Er wordt o.a. een buffer geplaatst tussen de Nios-processor en de audiochip. De interface levert voordelen op voor de overhead en de timing. Zo kunnen er nu in een keer maximaal 128 samples opgehaald worden in plaats van elke sample apart op te halen. De Audio Interface levert ook de kloksignalen die de WM8731 nodig heeft. In figuur 10 staat schematisch weergeven uit welke onderdelen het buffer gedeelte van de Audio Interface bestaat. 25

26 Figuur 10: De audio interface (Bron: De werking is gebaseerd op FIFO buffers. FIFO staat voor First in First out, wat praktisch betekent dat de data die het eerst binnenkomt het eerst verwerkt wordt. De audiodata komt binnen en wordt verzonden via respectievelijk de input from ADC en output to DAC. De Deserializer en Serializer zorgen er voor dat geluid van het rechter en linker kanaal respectievelijk samengevoegd en van elkaar gescheiden worden. De data die door de Deserializer komt, wordt opgeslagen in de Left en Right FIFO. De FIFO s bieden ruimte voor 128 samples. Wanneer één van deze FIFO s voor 75% vol is, genereert de Audio Interface over de Avalon slave port een interrupt (signaal naar de processor). Software kan geschreven worden om deze interrupts, in dit geval met een leeshandeling, af te handelen. Hetzelfde geldt voor de FIFO s van de output, maar dan wordt er een interrupt gegenereerd wanneer deze voor 75% leeg is. Hierbij geldt uiteraard dat er een schrijfhandeling verricht kan worden. De WM8731 heeft 4 kloksignalen, XCLK, BCLK, ADCLRC en de DACLRC nodig om correct te functioneren. Deze signalen worden ook door de Audio Interface geleverd. De XCLK bedraagt en is de systeemklok van de WM8731. BCLK bedraagt een waarde van XCLK/4 en op deze klokworden debits van de het digitale signaal verstuurd en gelezen. De ADCLRC is de samplerate van de audio ingang (Analoog-Digitaal Conversie) en DACLRC is de samplerate van de audio uitgang (Digitaal- Analoog Conversie). De Audio Interface geeft ondersteuning aan een aantal C-functies voor o.a. het lezen en schrijven van/naar de FIFO s. Ook worden functies ondersteund voor het schrijven en lezen van de Audio Registers. Zie bijlage B voor de functie prototypes. (Bron: 2 ) - Audio Config De functie van Audio Config is de audiochip te configuren door naar de audio configuratie registers te schrijven. Deze registers zijn helaas niet direct vanuit Nios te bereiken. Om de registers te bereiken is een I²C bus verbinding nodig. Dit houdt in dat de data serieel verstuurd moet worden op een klok van 26

27 maximaal 400 khz. De data verbinding is de seriële I²C data lijn en de klok verbinding is I²C clock (zie figuur 11). In software dit proberen te bewerkstelligen kan voor timing problemen zorgen. Er is daarom gekozen om de SOPC component Audio Config te gebruiken. De werking van Audio Config is tijdens het initialiseren standaard instellingen in de audio chip te laden via de I 2 C. De standaard instellingen kunnen gedefinieerd worden tijdens het aanmaken van het component in SOPC builder. Tevens biedt de Audio Config ondersteuning voor C-functies voor het wijzigen van register instellingen. Zie bijlage B voor de functie prototypes. (Bron: 4 ) Figuur 11: WM8731 verbinding met Nios Systeem - Audiochip WM8731 De functie van de audiochip is een analoog- digitaal conversie maken van het analoge inkomende geluidssignaal en vice versa voor digitale audiosignalen afkomstig van de Nios-processor. Tevens voert de WM8713 de volumeaanpassingen uit. Het volume kan worden geregeld op twee verschillende plaatsen: de lijningang en de lijnuitgang. De lijningang kan worden ingesteld tussen +12 db en -34 db en de lijnuitgang tussen 6 db en 73dB. Tevens kunnen beide poorten in de mute stand gezet worden. Voor het instellen van de audiochip moet er data geschreven worden naar de audioregisters. De instellingen worden door de Nios II doorgegeven aan de Audio Config die ze vervolgens via de I 2 C bus inlaadt. De werking van de audiochip berust op de kloksignalen BCLK en DACLRC/ADCLRC(zie figuur 12). 27

28 De kloksignalen worden gebruikt om het lezen en schrijven van data te synchroniseren. Er zijn drie manieren om de data te synchroniseren: Left Justified Mode, Right Justified Mode en DSP mode. Er is gekozen voor de Left Justified Mode (zie figuur 12). In deze mode wordt de MSB (most significant bit) van een sample aangeboden na een event van de DACLRC of ADCLRC en een neergaande flank van BCLK. De bits worden vervolgens uitgelezen of verstuurd op de opgaande BCLK flanken. De ADCLRC en DACLRC zorgen voor synchronisatie van de audiodata voor het linker en rechter audiokanaal en moet gelijk zijn aan de samplerate ingesteld in de WM8731 registers. De chip ondersteunt samplerates van 8-48 khz met grootte van bits. Er is gekozen voor een instelling van een 8 khz samplerate met 16 bits samplegrootte voor de analoog- digitaal en digitaalanaloog conversie. Door gebruik van deze instellingen, wordt voldaan aan F1.2 en F1.7. Een hogere samplerate is met deze samplegrootte niet wenselijk omdat dit een te hoge bitrate als gevolg heeft. Tevens wordt met deze instellingen aan de G.711 standaard gehouden. Figuur 12: Left Justified Mode (Bron: Software In deze paragraaf worden de C-functies van de audio.c, alt_up_audio.c en de G.711.c files behandeld, die gebruikt worden in de main. Deze C-bestanden bevinden zich in bijlage C. - Audio.c void audio_initialize() In deze functie worden de instellingen in de registers van de WM8731 geschreven. Instellingen zoals power on, samplerate, samplegrootte, volume etc kunnen in deze functie ingesteld worden. - Alt_up_audio.c int alt_up_audio_read_left_channel (alt_u32 * buf, unsigned len) int alt_up_audio_read_right_channel (alt_u32 * buf, unsigned len) In deze twee functies worden de audiosamples opgehaald van het rechter- en linkeraudiokanaal. Variabele len geeft aan hoeveel samples maximaal gelezen mogen worden en buf is de pointer van het gereserveerde geheugen. De return waarde is het aantal gelezen samples 28

29 int alt_up_audio_write_left_channel (alt_u32 *buf, unsigned len) int alt_up_audio_write_right_channel (alt_u32 * buf, unsigned len) In deze twee functies worden de audiosamples geschreven naar het rechter- en linkeraudiokanaal. Variabele len geeft aan hoeveel samples geschreven wenst te worden en buf is de pointer van de eerste waarde dat geschreven moet worden. De return waarde is het aantal geschreven samples. - G.711.c unsigned char _af_linear2ulaw (int pcm_val) In deze functie wordt een 2 s complement 16 bits integer gecomprimeerd naar een unsigned char. int _af_ulaw2linear (unsigned char u_val) In deze functie wordt een 8 bits u-law waarde gedecodeerd naar een 16 bits PCM waarde. De codering wordt gedaan via de G.711 standaard. De G.711 standaard comprimeert PCM samples, die met een samplerate van 8kHz zijn genomen, tot 8-bit waardes. De bitrate resulteert in 64 kbits/s. Binnen de standaard bestaan twee algoritme, het zogenoemde μ-law algoritme en het A-law algoritme. Beide algoritmes gebruiken een logaritmische van de bits. De lagere samplewaarden worden met meer precisie gecodeerd dan de hogere samplewaarden. Hierdoor kan je een zacht signaal toch goed verstaan, maar zijn de hardere signalen minder onderscheidend. A-law is makkelijker voor een computer uit te voeren. Er is toch gekozen om de μ-law algoritme te gebruiken, omdat deze in onze implementatie een hoorbaar beter geluid produceert dan de A-law variant. Deze informatie is gebaseerd op de ITU-T G.711. (Bron: Voor uitleg over C-code is er gebruik gemaakt van C: The Complete Reference. (Bron: Schildt 2000) 5.5 De deelfunctie netwerk In deze paragraaf staat de gedetailleerde uitwerking van de netwerkfunctie. Uit paragraaf is de keuze voortgekomen om alles in software te implementeren. Een randvoorwaarde was wel wanneer we softwarematig functies van de telefoon wilden implementeren dat deze voor de Nios-processor ontwikkeld moet worden. Het doel van het netwerkdeel is het kunnen versturen en ontvangen van data over ethernet. Op deze manier is het mogelijk audio te versturen van het ene Altera-bordje naar het andere. Als het audioen het netwerkdeel beiden functioneren, is het dus mogelijk met elkaar te praten via de twee bordjes. Het netwerkdeel bestaat uit verschillende onderdelen: 1. De DM9000A controller die de processor met de netwerkchip verbindt. 2. De DM9000A netwerkchip die zich al op het Altera-bordje bevindt. Deze onderdelen worden aangestuurd door software om datapakketjes te versturen en te ontvangen. Dit hoofdstuk is onderverdeeld in twee subparagrafen: in komt de werking van de verschillende hardwarecomponenten aan de orde en in wordt de geschreven software uitgelegd. 29

30 5.5.1 Hardware De oranje gekleurde blokken in figuur 13 zijn specifiek voor de netwerkfunctie. Deze zullen verder worden toegelicht in deze paragraaf. Figuur 13: Blokschema netwerk. Dit is een schematisch overzicht van de FPGA en de componenten. Het oranje gekleurde blokje representeert de DM9000A controller. Deze is verbonden aan de Avalon Switch Fabric en d.m.v. deze bus kan de Nios II processor naar de controller schrijven. - DM9000A controller De functie van deze controller is de Nios-processor via de Avalon-bus te verbinden met de DM9000A netwerkchip. Zoals te zien is in figuur 14, bestaat het grootste deel van de controller uit het simpelweg aansluiten van de in- en uitgangen. Echter om het mogelijk te maken over één bus te lezen en te schrijven (ENET_DATA[15 0]) zonder kortsluiting te maken, is er logica aan toegevoegd. De functionaliteit hiervan, weergegeven in figuur 14, maakt de complete ENET_DATA bus hoog impedant aan de processor zijde als er geschreven wordt van de DM9000A zijde. Als iwr_n laag is, wordt de ENET_DATA poort gebruikt als uitgang. data geschreven naar de DM9000A-chip. 30

31 Figuur 14: Een schematische werking van de DM9000A Controller - DM9000A netwerkchip De Dm9000A netwerkchip regelt het netwerkverkeer. Deze chip is in te stellen door naar de Control and Status Registers (CSRs) te schrijven en door deze registers uit te lezen, kan de status van het netwerk uitgelezen worden. Na een reset krijgen deze registers hun oorspronkelijke waarden en dus na elke start van de FPGA, moeten de CSRs ingesteld worden. Dit gebeurt middels een reeks C- functies. In paragraaf zullen deze functies besproken worden. (Bron: 1 ) 31

32 Figuur 15: DM9000A in- en uitgangpinnen (bron: In figuur 15 zijn de aansluitingen van de DM9000A netwerkchip te zien. Aan de linkerkant staan de aansluitingen die aan de DM9000A controller (Nios-systeemzijde) worden aangesloten. In de EEPROM kunnen de initialisatie-instellingen geschreven worden, zodat na een reset automatisch de netwerkchip goed ingesteld wordt. Op de RJ-45 aansluiting wordt een netwerkkabel aangesloten. Interne SRAM Buffer In figuur 16 is de buffer van de DM9000A van in totaal 16 KB schematisch weergegeven en deze heeft een Transmit (Tx) en een Receive (Rx) gedeelte. 3KB wordt gebruikt voor de Tx-buffer en 13KB voor de Rx-buffer. De buffers hebben een zogenaamde loopback: als bijvoorbeeld de Tx-buffer het geheugenadres 0BFF heeft bereikt, zal de netwerkchip verder schrijven vanaf Ongeacht of er al data op deze plek aanwezig is. Voor Rx geldt hetzelfde, maar begint deze na de loopback weer op 0C00. 32

33 Figuur 16: Dit is een schematisch overzicht van het SRAM die zich in de DM9000A bevindt. Zoals te zien is onderscheidt de TX en de RX buffer zich door een ander adres in het SRAM. (bron: Interrupts Zoals te zien is in figuur 15, heeft de DM9000A een INT-pin. Deze is er om de processor te laten weten dat bijvoorbeeld een pakketje ontvangen of een pakketje verstuurd is. Op welke acties de INTpin verhoogd wordt, is afhankelijk van welke interrupts aangezet zijn in de Interrupt Mask Register. In de Interrupt Status Register is uit te lezen waarom de INT-pin verhoogd is. Communicatie met de DM9000A Alle communicatie verloopt via de twee registers op de DM9000A: de INDEX- en de DATA-register. Het geheugenadres van de INDEX register is gelijk aan het basisadres van de DM9000A. De DATAregister zit hier achter met een offset van 4 bytes. De Nios-processor kan via de Avalon Switch Fabric deze registers adresseren. Door middel van de CMD-pin wordt één van deze twee registers geselecteerd voor het gebruik aan de DM9000A zijde. Via deze registers kunnen niet alleen de interne Control and Status Registers (CSR s) uitgelezen en geschreven worden, maar ook het lezen en schrijven van datapakketjes kan gedaan worden. Wanneer een CSR geadresseerd dient te worden, moet het nummer van de te bewerken register in INDEX geschreven worden. Voor een schrijfactie moet de nieuwe inhoud van de register in de DATApoort geschreven zijn. Na een nwr signaal wordt de data door de DM9000A uit de DATA-registers in de desbetreffende CSR geschreven. Bij een leesactie hoeft er geen data op de DATA-register gezet worden, maar moet alleen een nrd signaal geleverd worden. Na dit signaal heeft de DM9000A de in houd van de desbetreffende CSR geschreven in de DATA-register. Het Nios-systeem kan de data vervolgens lezen uit de DATA-register. 33

34 Het bereiken van de interne SRAM buffer gebeurt op een iets andere manier. I.p.v. het nummer van de register in INDEX te schrijven, wordt het nummer van één van de memory read or write commando registers in de INDEX geschreven. De commando registers bevinden zich ook in de DM9000A en hebben de eigenschap om wanneer geadresseerd niet ervan te schrijven of te lezen. Er wordt echter een actie aan verbonden, zoals het schrijven of lezen van de interne buffer. De data in de buffer is niet direct aan te spreken. Welke data geselecteerd wordt, hangt af van naar welke geheugenadres de interne bufferpointer wijst. Voor meer informatie over de CSR en de Commando registers wordt verwezen naar de DAVICOM DATA SHEET ( Software In deze paragraaf zullen verschillende belangrijke functieprototypes behandeld worden die in de Main()-functie aangeroepen worden die betrekking hebben op het netwerkdeel. Initialisatie van de DM9000A unsigned int DM9000_init(unsigned char *mac_address) In deze functie wordt de DM9000a netwerkchip geinitialiseerd. Er worden onder andere een power on en een soft-reset uitgevoerd, de interrupts worden aangezet en het MAC-adres wordt in de DM9000a geprogrammeerd. Het MAC-adres dient een lengte van 6 bytes te hebben. De return value is 0 als de initialisatie gelukt is anders is het een 1. Verzenden van data unsigned int TransmitPacket(unsigned char *data_ptr, unsigned int tx_len) Deze functie wordt gebruikt om een pakket te verzenden. De argumenten zijn de char pointer van data_ptr en tx_len de grootte van het pakket. Voor het verzenden van de data over het netwerk wordt in deze functie een aantal stappen ondernomen. 1. De interrupt van de DM9000A wordt tijdelijk uitgezet om te voorkomen dat dit proces niet onderbroken wordt. 2. Het nummer van de memory write commando with adress increment register wordt in INDEX geschreven. 3. Daarna kan de data in de TX FIFO SRAM geschreven worden. 4. Nu kan er een transmit commando gegeven worden en zal de DM9000A de data in de TX buffer verzenden. 5. Wachten tot de data verzonden is. 6. De interrupt van de DM9000A wordt weer aangezet. Als het verzenden is gelukt, is de return value een 0 en anders is het een 1. 34

35 Het ontvangen van data unsigned int ReceivePacket(unsigned char *data_ptr, unsigned int *rx_len) Deze functie wordt gebruikt om een pakket te ontvangen van de buffer. De argumenten zijn de char pointer van data_ptr en de integer pointer van rx_len waarin de grootte van het ontvangen pakket wordt op geslagen. Voor het ontvangen van data van het netwerk wordt in deze functie een aantal stappen ondernomen: 1. De interrupt van de DM9000A wordt tijdelijk uitgezet om te voorkomen dat dit proces niet onderbroken wordt. 2. Er wordt gecheckt of er een pakket binnengekomen is door een dummy read te doen. 3. Als de dummy read een 0x01 vindt wordt het nummer van het memory read commando with adress increment register in INDEX geschreven. In alle andere gevallen wordt een herinitialisatie van het ontvang gedeelt van de DM9000a registers gedaan. 4. Alle data wordt een voor een geschreven naar data_ptr[i]. 5. De interrupt van de DM9000A wordt weer aangezet. Let wel op dat bij deze functie de interrupt niet weer aangezet wordt. De functie aanroep moet altijd vergezeld zijn met de lijnen code dm9000a_iow(isr, 0x3F); dm9000a_iow(imr, INTR_set); voor het weer aanzetten van de interrupts. De return value is 0 als het ontvangen is gelukt anders is het een 1. (bron: 2 ) 5.6 De koppeling van de softwarefuncties Het netwerkdeel en de audioverwerking zijn delen van een systeem waarbij spraak de ene FPGA ingaat en de andere weer uitkomt. Om een werkend systeem te krijgen moet de software van de deelfuncties gekoppeld worden. De koppeling gebeurt in de main.c file (bijlage C). De methode van koppelen is gebaseerd op interrupts afkomstig van de WM8731 audiochip en de DM9000A netwerkchip. In deze paragraaf wordt de methode van koppelen toegelicht. De paragraaf is onderverdeeld in software componenten die aanwezig moeten zijn in de main.c file voor een werkend systeem. In wordt de ISR van een audio interrupt besproken, zal de ISR van de netwerk interrupt toelichten en als laatst wordt in worden de main functie ontleed. 35

36 5.6.1 ISR audio interrupt De audio_interrupt_handler is een mogelijke routine, wanneer een interrupt van de WM8731 aangeeft dat het genoeg samples heeft. De actie van de ISR is stapsgewijs uiteengezet. De nummering van de stappen correspondeert met stappen in de C-code. 1. Uitzetten van de read_interrupt. 2. De transmit_buffer van de juiste header voorzien. Afhankelijk van de gewenste codering G.711 codering samples van het rechterkanaal ophalen en opslaan in de codec_buffer samples van het linkerkanaal ophalen en opslaan achter de samples van het rechterkanaal in dezelfde codec_buffer. 5. Alle 128 samples encoderen en opslaan in de transmit_buffer na de header. 6. Verzenden van heel de transmit_buffer. 7. Read_interrupt aanzetten. Geen codering samples van het rechter en linkeraudiokanaal direct in de transmit_buffer schrijven achter de header 9. Verzenden van heel de transmit_buffer. 10. Read_interrupt aanzetten. static void audio_interrupt_handler() [1] alt_up_audio_disable_read_interrupt(); [2] transmit_buffer[0]=0x01; transmit_buffer[1]=0x01; transmit_buffer[2]=0x01; transmit_buffer[3]=0x01; transmit_buffer[4]=0x00; transmit_buffer[5]=0x00; transmit_buffer[6]=0x00; transmit_buffer[7]=0x00; if (codecselect == G711) [3] alt_up_audio_read_right_channel((alt_u32)&codec_buffer[0],64); [4] alt_up_audio_read_left_channel((alt_u32)&codec_buffer[128],64); [5] for(i=0;i< 128 ;i++) transmit_buffer[i+ PAYLOAD_OFFSET]= _af_linear2ulaw(codec_buffer[(i<<1)]); [6] TransmitPacket(transmit_buffer,136); else [8] alt_up_audio_read_right_channel((alt_u32)&transmit_buffer[8],64); alt_up_audio_read_left_channel((alt_u32)&transmit_buffer[264],64); 36

37 [9] TransmitPacket(transmit_buffer,520); [7]/[10] alt_up_audio_enable_read_interrupt(); De codec_buffer is een short int array met lengte 256. De transmit_buffer is een char array met lengte 520. Hoewel de er per keer maar 128 samples van 16 bits opgeslagen moeten worden zijn beide buffers twee keer zo groot. Dit is toch noodzakelijk omdat de samples in de Altera type alt_u32 worden opgeslagen ISR DM9000A interrupt De ethernet_interrupt_handler is een mogelijke routine voor het afhandelen van een ontvang interrupt. De actie van de ISR is stapsgewijs uiteengezet. De nummering van de stappen correspondeert met stappen in de C-code. 1. Datapakket lezen en schrijven in receivebuffer met de ReceivePacket() functie. Zie hoofdstuk voor details over de ReceivePacket functie. Afhankelijk van de gewenste codering G.711 codering 2. De audiodata decoderen en de gedecodeerde data schrijven in de codec_buffer. 3. De eerste helft van de codec_buffer naar het rechterkanaal van de audiochip sturen en de tweede helft naar het linkerkanaal. 4. DM9000A packet receive interrupt aanzetten. Geen codering 5. De eerste helft van de receive_buffer naar het rechterkanaal van de audiochip sturen en de tweede helft naar het linkerkanaal. 6. DM9000A packet receive interrupt aanzetten. X. Op deze plek kunnen de headerchecks plaatsvinden. static void ethernet_interrupt_handler() [1] ReceivePacket(receive_buffer, &receive_buffer_length); if ( [X] //Hiertussen kan de header check plaatvinden met een gerelateerde //actie. In bijlage C is een voorbeeld headercheck meegenomen. else if (codecselect == G711) [2] int x=0; for(i=0;i< 128 ;i++) codec_buffer[x+1]=0; codec_buffer[x]= _af_ulaw2linear(receive_buffer[i+ PAYLOAD_OFFSET]); x = x+2; [3] alt_up_audio_write_right_channel((alt_u32) &codec_buffer[0],64); 37

38 alt_up_audio_write_left_channel((alt_u32) &codec_buffer[128],64); else [4] alt_up_audio_write_right_channel((alt_u32) &receive_buffer[8],64); alt_up_audio_write_left_channel((alt_u32) &receive_buffer[264],64); [5] dm9000a_iow(isr, 0x3F); dm9000a_iow(imr, INTR_set); Main functie Met ISR s van de audio en netwerk interrupts zijn de handelende delen van het systeem gerealiseerd. Er zijn een aantal taken dat de main op zich moet nemen om de ISR s te kunnen gebruiken. De taken van de mainfunctie zijn stapsgewijs uiteengezet. De nummering van de stappen correspondeert met stappen in de C-code. 1. Transmit_buffer leeg maken. 2. Initialiseren van de DM9000A netwerkchip. In de functie DM9000_init wordt ook de interrupt aangezet. 3. Initialiseren van de WM8731 audiochip. 4. De ISR van de DM9000A registreren als interrupt handler van de DM9000A interrupts. 5. De ISR van de WM8731 registreren als interrupt handler van de WM8731 interrupts. 6. De audio interrupts aanzetten. 7. Wachten op interrupts. X. User interface code int main() // clear the transmit_buffer [1] for (i= 0; i<520;i++) transmit_buffer[i]=0; [X] LCD_Init(); LCD_Show_Text("4840 Lab 2"); // Clear the LEDs to zero (will display interrupt count) outport(seg7_display_base, 0); /* Enable all 4 button interrupts. */ IOWR_ALTERA_AVALON_PIO_IRQ_MASK(BUTTON_PIO_BASE, 0xf); /* Reset the edge capture register. */ IOWR_ALTERA_AVALON_PIO_EDGE_CAP(BUTTON_PIO_BASE, 0x0); /* Register the interrupt handler. */ alt_irq_register( BUTTON_PIO_IRQ, NULL, handle_button_interrupts ); // Initalize the DM9000 and the Ethernet interrupt handler [2] DM9000_init(mac_address); //dm9000a_iow(imr, INTR_set); 38

39 interrupt_number = 0; // initialize audio k=0; codecselect=1; [3] audio_initialize(); //alt_up_audio_read_right_channel((alt_u32)&transmit_buffer[8],64); //alt_up_audio_read_left_channel((alt_u32)&transmit_buffer[264],64); [4] alt_irq_register(dm9000a_irq, NULL, (void*) ethernet_interrupt_handler); [5] alt_irq_register(10, NULL, (void*)audio_interrupt_handler); [6] alt_up_audio_disable_read_interrupt(); [X] printf( "ready"); [7] while(1) return 1; 39

40 6 Testen van het systeem In dit hoofdstuk zullen de testen worden besproken voor het audio- en het netwerkdeel. In paragraaf 6.1 zullen de verschillende testopstellingen beschouwd worden en in paragraaf 6.2 zullen de geteste criteria en testresultaten besproken en beoordeeld worden. 6.1 Gebruikte testopstellingen Er zijn verschillende testopstellingen gebruikt tijdens het testen. Deze zullen in deze paragraaf allemaal besproken worden. De opstellingen worden genummerd en in paragraaf 6.2 zal er per functioneringscriterium naar deze testopstellingen verwezen worden. Er zijn tijdens de metingen verschillende apparaten gebruikt: Een pc met een geluidskaart, Visual Analyser 8 software en NCH Tone Generator software geïnstalleerd - De geluidskaart wordt gebruikt om m.b.v. de Tone Generator software sinusen deltapulsvormige signalen op de line out te zetten. De mic-ingang van de geluidskaart wordt gebruikt om signalen te ontvangen en m.b.v. de Visual Analyser software te analyseren. Met Visual Analyser is het mogelijk om de Total Harmonic Distortion (THD), het signaalvermogen, de signaal-ruisverhouding (SNR) en frequentie- en tijdspectra te meten. Twee Altera DE2 borden Deze borden hebben een mic-ingang (microfoon ingang), een line out en een netwerkaansluiting. De inkomende signalen op de mic-ingang worden bemonsterd met 8 khz. Afhankelijk van de opstelling wordt het inkomende signaal bemonsterd, geëncodeerd en op het netwerk gezet of bemonsterd, geëncodeerd, gedecodeerd en naar de line out verstuurd. Ook is het mogelijk met de Altera DE2 netwerkpakketjes te ontvangen, te decoderen en het signaal naar de line out te sturen. Een Tektronix TDS2024 oscilloscoop - Met de oscilloscoop kunnen door middel van twee probes twee signalen tegelijkertijd bekeken en vergeleken worden om zo het fase/tijdverschil hiertussen te bepalen. Een regelbare sinusgenerator - Met deze generator is het mogelijk sinusvormige signalen en signalen van andere vorm (zoals een deltapuls) te genereren op diverse frequenties en deze signalen dienen ervoor om elektrische audiosignalen na te bootsen. Diverse audiokabels en een splitter 40

41 6.1.1 Meetopstelling 1 - Opstelling Bij meetopstelling 1 is de sinus generator aangesloten op de mic-ingang van het Altera DE2 bord. Na verwerking (bemonsteren, encoderen en decoderen) van het binnengekomen signaal van de sinus generator door de Altera DE2, wordt het signaal naar de line out gestuurd. Een kabel sluit deze uitgang aan op de mic-ingang van de geluidskaart van de pc. Op de pc wordt het signaal met Visual Analyser geanalyseerd. In figuur 17 is een schematische opstelling van meetopstelling 1 te zien. - Metingen Met deze opstelling is het mogelijk de kwaliteit van de overdracht van de mic-ingang van het Altera bord naar de line out-uitgang te analyseren. Door signalen met verschillende frequenties door de Altera te laten verwerken en te analyseren op de pc, is zichtbaar met welke bandbreedte van het inkomende signaal, de Altera nog kan reconstrueren. Omdat er op het Altera bord maar met een beperkte snelheid bemonsterd wordt, zullen signalen met meer dan de helft van deze frequentie ongewenste vouwvervormingen introduceren (Nyquist-Shannon bemonsteringstheorema). Ook kan met deze opstelling het signaal- en ruisvermogen gemeten worden als gevolg van de Altera DE2 bord. Figuur 17: Meetopstelling 1 41

42 6.1.2 Meetopstelling 2 - Opstelling Bij meetopstelling 2 is de sinusgenerator door middel van een kabel aangesloten op de mic-ingang van de pc. Op deze pc is Visual Analyser geïnstalleerd om diverse metingen mogelijk te maken. In figuur 18 is een schematische opstelling te zien van meetopstelling 2. - Metingen Met deze opstelling is het mogelijk het ruisvermogen te meten die de sinusgenerator, de kabel en de geluidskaart van de pc introduceren. Door de sinusgenerator uit te zetten, is m.b.v. Visual Analyser het ruisvermogen vast te stellen. Door een signaal met een bepaalde frequentie van de generator naar de pc te sturen en die te analyseren met Visual Analyser, is zichtbaar met welk signaalvermogen deze frequentie ontvangen wordt en welke frequenties nog meer aanwezig zijn. Met deze gegevens samen kan de SNR van het signaal berekend worden en deze SNR kan later gebruikt worden bij het berekenen van de SNR-degradatie van de Altera borden. Figuur 18: Meetopstelling Meetopstelling 3 - Opstelling Bij deze opstelling wordt er gebruik gemaakt van een regelbare sinusgenerator, twee Altera borden en een pc met Visual Analyser. Het door de sinusgenerator gemaakte signaal wordt naar de Altera 1 gestuurd en daar wordt het signaal omgezet in netwerkpakketjes. Deze worden via de netwerkkabel verstuurd van de ethernetpoort van Altera 1 naar de ethernetpoort van Altera 2. Door Altera 2 worden de ontvangen netwerkpakketjes verwerkt naar een audiosignaal. Dit signaal gaat via de line out van Altera 2 naar de mic-ingang van de pc. Hier kan het signaal geanalyseerd worden door de software op de pc. In figuur 19 is een schematische opstelling te zien van de gebruikte onderdelen en de verbindingen van meetopstelling 3. 42

43 - Metingen Met deze opstelling is het mogelijk het ontvangen signaalvermogen te meten. Door de sinusgenerator uit te zetten, is het mogelijk de ruis die het hele systeem introduceert, te meten. Door van dit ruisvermogen het ruisvermogen van de generator, kabel en pc (uit meetopstelling 2) hiervan af te trekken, ontstaat het ruisvermogen als gevolg van de twee Altera borden. Door van het gemeten signaalvermogen het signaalvermogen uit meetopstelling 2 af te trekken, volgt de afname van het signaalvermogen als gevolg van de Altera borden. Omdat dezelfde referentie ruisvermogen gebruikt wordt, is het meteen de SNR-degradatie. Figuur 19: Meetopstelling Meetopstelling 4 - Opstelling Bij deze opstelling worden er twee sinusgeneratoren, twee pc s met Visual Analyser en twee Altera borden gebruikt. Het signaal van sinusgenerator 1 gaat via de mic-ingang van Altera bord 1 bewerkt en in pakketjes over het netwerk naar Altera bord 2. Daar wordt dit signaal weer bewerkt en aan de line out aangeboden. Dit wordt gemeten door de geluidskaart van pc 2. Hetzelfde traject wordt tegelijkertijd ook andersom gelopen. Sinusgenerator 2 stuurt een signaal naar Altera 2 om vervolgens daar het signaal naar Altera 1 te sturen. Daarna wordt het signaal via de line out naar pc 1 gestuurd. Een schematisch overzicht van deze meetopstelling is in figuur 20 te zien. 43

44 - Metingen Met deze meting is te zien of de Altera borden snel genoeg zijn om de data twee kanten op gelijk te verwerken. De Altera borden moeten audio bemonsteren, coderen, in pakketjes stoppen en over het netwerk zenden en tegelijkertijd de pakketjes ontvangen, decoderen en omzetten naar een analoog signaal. Met deze meting te concluderen of de kwaliteit van het ontvangen signaal nog goed genoeg is en of dus het ontwerp snel genoeg is om tegelijkertijd al deze taken te verrichten. Figuur 20: Meetopstelling Meetopstelling 5 - Opstelling Bij deze opstelling wordt er gebruik gemaakt van een regelbare sinus generator, een Altera bord, een oscilloscoop en een splitter. Het door de sinus generator gemaakte signaal wordt door een splitter verdeeld. Eén signaal gaat via de mic-ingang naar de Altera en wordt daar verwerkt en vervolgens naar de line out gezonden. Dit signaal wordt gemeten door de oscilloscoop op kanaal 2. Het signaal afkomstig van de splitter, wordt rechtstreeks door de oscilloscoop gemeten op kanaal 1. In figuur 21 is een schematische opstelling te zien van meetopstelling 5. - Metingen Met deze opstelling is het mogelijk de vertraging te meten als gevolg van het encoderen en het decoderen. Een deltapuls wordt van de sinus generator rechtstreeks en via het Altera bord naar de oscilloscoop gestuurd. Op deze oscilloscoop is de vertraging vast te stellen door verschillende frequenties te gebruiken. 44

45 Figuur 21: Meetopstelling Meetopstelling 6 - Opstelling Bij deze opstelling wordt er gebruik gemaakt van een regelbare sinus generator, twee Altera borden, een oscilloscoop en een splitter. Het door de sinus generator gemaakte signaal wordt door een splitter verdeeld. Eén signaal gaat via de mic-ingang naar Altera 1, wordt daar verwerkt en vervolgens over het netwerk verzonden. Het signaal wordt gedetecteerd door Altera 2 en wordt na verwerking op de line out gezet. Dit signaal wordt gemeten door de oscilloscoop op kanaal 2. Het signaal afkomstig van de splitter, wordt rechtstreeks door de oscilloscoop gemeten op kanaal 1. In figuur 22 is een schematische opstelling te zien van meetopstelling 6. - Metingen Met deze opstelling is het mogelijk de vertraging te meten als gevolg van het encoderen, het decoderen en het netwerk. Een deltapuls wordt van de sinus generator rechtstreeks en via de Altera borden naar de oscilloscoop gestuurd. Op deze oscilloscoop is de vertraging van heel het traject te zien. Na aftrek van de vertraging van het encoderen en het decoderen (uit meting 5) volgt de vertraging van het netwerk. 45

46 Figuur 22: Meetopstelling Geteste criteria en testresultaten In paragraaf 6.1 zijn alle gebruikte meetopstellingen behandeld. In de komende paragrafen worden de functioneringscriteria en randvoorwaarden getoetst. Per criterium zal gebruikte testopstelling uit paragraaf 6.1 genoemd worden en de testmethode en testresultaten uitgelegd worden. In paragraaf zullen eerst de gekwantificeerde en later de niet-gekwantificeerde criteria van het audiodeel behandeld worden. In paragraaf worden de criteria van het netwerkdeel ook in deze volgorde behandeld Audio - Gekwantificeerde criteria F1.2 De bandbreedte van het geluid moet minimaal 3,5 khz bedragen. Voor het testen van dit criterium is er gebruik gemaakt van meetopstelling 1. De regelbare sinus Generator levert een sinus van 3,5 khz. In figuur 23 is het resultaat op de pc te zien. Zoals te zien is, wordt een sinus van 3,5 khz zonder problemen door het Altera bord verwerkt en er wordt dus voldaan aan dit criterium. 46

47 Figuur 23: Visual Analyser op 3,5 khz F1.3 De SNR-degradatie van de audioverwerking mag in de frequentieband tot 3,5 khz maximaal 15 db bedragen. Voor dit criterium zijn meetopstelling 1 en 2 gebruikt. Uit meetopstelling 2 volgt de SNR van het signaal zonder het Altera bord. Uit meetopstelling 1 volgt de SNR van het signaal met het Altera bord. Door de SNR uit opstelling 2 af te trekken van de SNR uit opstelling 1, volgt de SNR-degradatie ten gevolge van de Altera DE2. Er werd 10 db SNR-degradatie berekend en dat is ruim onder de geëiste 15dB. Er wordt dus voldaan aan dit criterium. F1.4 De THD mag maximaal 5% bedragen Voor het testen van dit criterium is meetopstelling 1 gebruikt. De Visual Analyser software kan de THD berekenen. Zoals te zien is in de figuren 24, 25 en 26, zijn er op verschillende frequenties metingen verricht. De THD blijft ruim binnen de geëiste 5% en er wordt dus voldaan aan dit criterium. 47

48 Figuur 24: De THD op 2 khz Figuur 25: De THD op 1 khz 48

49 Figuur 26: De THD op 100 Hz F1.5 De vertraging mag maximaal 60 ms voor het traject in de FPGA s. De tijd die het netwerkdeel nodig heeft voor het versturen en ontvangen, wordt hierbij niet meegenomen. Voor het testen van dit criterium is er gebruik gemaakt van meetopstelling 5. Door twee probes te gebruiken van de oscilloscoop en deltapulsen maken met de sinus generator, kan de vertraging worden afgelezen op de oscilloscoop. In figuren 27 en 28 is het directe signaal zonder vertraging (de gele lijn) en het signaal afkomstig van de Altera DE2 (de blauwe lijn). Zoals te zien is in de figuren, heeft het audiodeel een vertraging van ~20 ms. Dit is ruim onder de gestelde eis van 60 ms. Er wordt dus voldaan aan dit criterium. 49

50 Figuur 27: De vertraging van de audioverwerking op een deltapulsfrequentie van 50 Hz Figuur 28: De vertraging van de audioverwerking op een deltapulsfrequentie van 40 Hz F1.7 De bitrate van het audiosignaal mag maximaal 128 kbps bedragen. Als er gebruik wordt gemaakt van de G.711 codec, wordt er maar 8 bits per sample gebruikt. Dit resulteert in een bitrate van 8000*8*2 = 128 kbps. Er wordt dus voldaan aan dit criterium. 50

51 R1.2 Het FPGA-ontwerp van het audiodeel mag niet meer dan LE s in beslag nemen. Figuur 29: Compilatie verslag. Door na het compileren van de hardware door Quartus naar het compilatie verslag te kijken, kan afgelezen worden hoeveel LE s er gebruikt worden in het ontwerp. In figuur 29 is een afbeelding van dit compilatie verslag te zien. In dit figuur is zichtbaar dat het totale project slechts 5268 LE s in beslag neemt. Het audiodeel is een deel hiervan en dus kleiner dan LE s. Er wordt dus voldaan aan dit criterium. R1.4 Het prototype moet binnen 7 weken af zijn. De technische realisatie is binnen 7 weken afgerond. Dus er wordt voldaan aan dit criterium. - Niet gekwantificeerde criteria F1.1 Het audio-gedeelte moet ondersteuning bieden voor de G.711 audio codec. Zoals te lezen is in paragraaf is de G.711 audio codec gebruikt in het ontwerp. Er wordt dus voldaan aan dit criterium. F1.6 Het audio gedeelte moet zonder problemen te integreren zijn in het hoofdproject, de gehele VoIP-telefoon. Het hoofdproject met de onderdelen audioverwerking en netwerkfunctie werkt en dit is het bewijs dat het audio gedeelte te integreren is het hoofdproject. Er wordt dus voldaan aan dit criterium. R1.1 Als wordt gekozen om functies in C te implementeren, moet er gebruik gemaakt worden van de Nios-processor. Omdat er gebruik is gemaakt van het software-concept, is een Nios-processor op de FPGA geprogrammeerd. Er wordt dus voldaan aan dit criterium. 51