FPGA-ontwerp Audio-Netwerk voor VoIP-telefoon Prototype

FPGA-ontwerp Audio-Netwerk voor VoIP-telefoon Prototype Ontwerprapport

Bachelor Thesis Studenten: H. Syed 9820108 F. Schilders 1144197 C.C. Chi 1242784 T. Kaserer 1144081 Begeleiders: J.S.S.M. Wong A.J. van Genderen Computer Engineering, afdeling Electrical Engineering

1

Plaatje op de voorpagina Bron: www.terasic.com.tw

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

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 audioen 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 audioen 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 audioen 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.

Inhoudsopgave 1 INLEIDING............................................................................................................................................... 7 2 PROGRAMMA VAN EISEN .................................................................................................................. 8 2.1 PvE deelfunctie “audio” ............................................................................................................ 8 2.1.1 Functioneringcriteria .............................................................................................................8 2.1.2 Randvoorwaarden ..................................................................................................................8 2.2 De deelfunctie “netwerk” ......................................................................................................... 9 2.2.1 Functioneringscriteria...........................................................................................................9 2.2.2 Randvoorwaarden ..................................................................................................................9

3 CONCEPTEN VAN HET AUDIO- EN HET NETWERKDEEL ...................................................... 10 3.1 Concepten van de audioverwerking ................................................................................. 10 3.1.1 Een softwareontwerp met minimale hardwaretoepassing ................................ 10 3.1.2 Een specifieke processor voor de audioverwerking.............................................. 11 3.1.3 Een software ontwerp met hardwarematige versnelling .................................... 12 3.2 Concepten van de netwerkfunctie ..................................................................................... 13 3.2.1 Een softwareoplossing ....................................................................................................... 13 3.2.2 Een hardwareoplossing ..................................................................................................... 15 3.2.3 Een deels software- en deels hardwareoplossing................................................... 16

4 CONCEPTKEUZE EN VERANTWOORDING.................................................................................. 17 4.1 Conceptkeuze voor de deelfunctie “audio” .................................................................... 17 4.1.1 Toelichting criteria en weging ........................................................................................ 17 4.1.2 Waardering en Conceptkeuze ......................................................................................... 18 4.2 Conceptkeuze voor de deelfunctie “netwerk” ............................................................... 19 4.2.1 Toelichting criteria .............................................................................................................. 19 4.2.2 Conclusie .................................................................................................................................. 20

5 UITWERKING VAN HET AUDIO- EN HET NETWERKDEEL ................................................... 21 5.1 Gebruikte apparatuur ............................................................................................................ 21 5.2 Gebruikte software ................................................................................................................. 22 5.3 De onderdelen op het Altera DE2 bord............................................................................ 22 5.4 De deelfunctie “audio” ........................................................................................................... 24 5.4.1 Hardware ................................................................................................................................. 24 5.4.2 Software ................................................................................................................................... 28 5.5 De deelfunctie “netwerk” ...................................................................................................... 29 5.5.1 Hardware ................................................................................................................................. 30 5.5.2 Software ................................................................................................................................... 34 5.6 De koppeling van de softwarefuncties ............................................................................. 35 5.6.1 ISR audio interrupt .............................................................................................................. 36 5.6.2 ISR DM9000A interrupt ..................................................................................................... 37 5.6.3 Main functie ............................................................................................................................ 38

6 TESTEN VAN HET SYSTEEM............................................................................................................ 40 6.1 Gebruikte testopstellingen .................................................................................................. 40 6.1.1 Meetopstelling 1 ................................................................................................................... 41 6.1.2 Meetopstelling 2 ................................................................................................................... 42 6.1.3 Meetopstelling 3 ................................................................................................................... 42 6.1.4 Meetopstelling 4 ................................................................................................................... 43

6.1.5 Meetopstelling 5 ................................................................................................................... 44 6.1.6 Meetopstelling 6 ................................................................................................................... 45 6.2 Geteste criteria en testresultaten ...................................................................................... 46 6.2.1 Audio.......................................................................................................................................... 46 6.2.2 Netwerk .................................................................................................................................... 52

7 CONCLUSIES EN AANBEVELINGEN ............................................................................................... 56 7.1 Conclusies ................................................................................................................................... 56 7.2 Aanbevelingen .......................................................................................................................... 56

BRONVERMELDING ............................................................................................................................... 57 BIJLAGE A: VERILOG CODE VAN DE TOP MODULE NIOS-SYSTEEM ..................................... 59 BIJLAGE B: GEBRUIKTE AUDIO EN NETWERK C-CODE ............................................................ 67 B1 Alt_up_audio.c ............................................................................................................................ 67 B2 Alt_up_audio_video_config.c ................................................................................................. 68 B3 Audio.c .......................................................................................................................................... 68 B4 DM9000A.c .................................................................................................................................. 69 B5 G711.c ........................................................................................................................................... 73

BIJLAGE C: GEBRUIKTE MAIN C-CODE ........................................................................................... 77 BIJLAGE D: ZELFEVALUATIE .............................................................................................................. 82 D1 C.C.Chi studienummer 1242784 ........................................................................................ 82 D2 T.Kaserer studienummer 1144081 ................................................................................... 82 D3 H.Syed studienummer 9820108 ......................................................................................... 84 D4 F.Schilders studienummer 1144197 ................................................................................. 85

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

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.

2.1.1 Functioneringcriteria Aan de volgende functioneringscriteria moet het audio-gedeelte van de VoIP-telefoon voldoen: F1.1 F1.2 F1.3 F1.4 F1.5

F1.6 F1.7

Het audio-gedeelte moet ondersteuning bieden voor de G.711 audio codec. De bandbreedte van het geluid moet minimaal 3,5 kHz bedragen. De SNR-degradatie van de audioverwerking mag in de frequentieband tot 3,5 kHz maximaal 15 dB bedragen De THD mag maximaal 5% bedragen 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. Het audio gedeelte moet zonder problemen te integreren zijn in het hoofdproject, de gehele VoIP-telefoon. De bitrate van het audiosignaal mag maximaal 128kbps bedragen

2.1.2 Randvoorwaarden Het ontwerp van de audiobewerking moet aan de volgende randvoorwaarden voldoen: 8

R1.1 R1.2 R1.3 R1.4

Als wordt gekozen om functies in C te implementeren, moet er gebruik gemaakt worden van de Nios-processor. Het FPGA-ontwerp van het audiodeel mag niet meer dan 10.000 LE’s in beslag nemen. Het prototype moet op een Altera DE2 bordje draaien. 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.

2.2.1 Functioneringscriteria Aan de volgende functioneringscriteria moet het netwerk gedeelte van de VoIP telefoon zich aan voldoen: F2.1 F2.2 F2.3 F2.4 F2.5

Het netwerkdeel moet datapakketjes met een grootte van 64 tot 1024 Bytes kunnen verzenden en ontvangen. De pakketjes moeten verzonden en ontvangen worden over een bedrade ethernetverbinding. Het netwerkdeel moet minimaal 520 kb/s tegelijkertijd kunnen versturen en ontvangen. De vertraging van het verzenden en ontvangen van data tussen 2 FPGA’s, mag maximaal 40 ms bedragen. Het netwerkdeel moet zonder problemen te integreren zijn in het hoofdproject, de gehele VoIP-telefoon.

2.2.2 Randvoorwaarden De randvoorwaarden voor de netwerkfuncties zijn hetzelfde als die van het audiodeel: R2.1 R2.2 R2.3 R2.4 R2.5

Er moet een protocol gebruikt worden om verbinding op te zetten en af te sluiten. Als wordt gekozen om functies in C te implementeren, moet er gebruik gemaakt worden van de Nios-processor. Het prototype moet op een Altera DE2 bordje draaien. Het FPGA-ontwerp van het netwerkdeel mag niet meer dan 10.000 LE’s in beslag nemen. Het prototype moet binnen 7 weken af zijn.

9

3 Concepten van het audioen 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, 3.1.2 en 3.1.3 worden verschillende combinaties van de deelfuncties van de audioverwerking gebruikt voor het maken van concepten. In paragraaf 3.2.1, 3.2.2 en 3.2.3 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 Samples brengen Samples ophalen Coderen

BO's

BO's

Hardware Hardware Hardware

Software Software 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 3.1.1 t/m 3.1.2 wordt een toelichting van de concepten en de beschrijving van hun eigenschappen gegeven.

3.1.1 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

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

3.1.2 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


3.1.3 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.


12

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 Data ontvangen

Hardware Hardware

Software 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 3.2.1 t/m 3.2.2 wordt een toelichting van de concepten met de voor- en nadelen gegeven.

3.2.1 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

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

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.


-

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

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.


-

Voor- en nadelen

Het voordeel van de hardwareacceleratie is het toenemen van de verwerkingssnelheid. Zoals echter in paragraaf 3.2.1 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

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 4.1.1 worden de criteria en de weging toegelicht en in paragraaf 4.1.2 wordt de uiteindelijke conceptkeuze gemaakt. Tabel 3: Criteria tegenover de audioverwerkingconcepten Weeg factor

Concept 1: Software

Concept 2: Hardware

Concept 3: Software/Hardware

Ontwerptijd

4

8

3

6

Flexibiliteit Performance/Watt Totaal

3 2

9 6 71

4 10 44

7 8 61

4.1.1 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 2.1.1. 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

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.

4.1.2 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

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 4.2.1 worden de criteria toegelicht en in paragraaf 4.2.2 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

Ontwerptijd Flexibiliteit Performance Totaal

Weeg factor

Concept 1: Software

Concept 2: Hardware

Concept 3: Software/Hardware

4 3 2

8 9 10 79

3 4 10 44

5 6 10 58

4.2.1 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

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.

4.2.2 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

5 Uitwerking van het audioen 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 www.altera.com3

Figuur 7: De lay-out van de Altera DE2. Een aantal onderdelen zijn gemarkeerd: 1. Cyclone II FPGA 2. Audio codec chip WM8731 3. Audio in- en uitgangpoorten 4. DM9000A netwerkchip

21

5. Netwerkaansluiting RJ-45 Bron: www.terasic.com.tw

5.2 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

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 3.1.1 en 3.2.1 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

-

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 www.altera.com1

5.4 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: 5.4.1 Hardware en 5.4.2 Software waarin de gedetailleerde uitwerking van de audioverwerking staat.

5.4.1 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

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

Figuur 10: De audio interface (Bron: www.altera.com2)

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 12.288 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 (DigitaalAnaloog 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: www.altera.com2)

-

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

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 I2C. 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: www.altera.com4)

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 I2C bus inlaadt. De werking van de audiochip berust op de kloksignalen BCLK en DACLRC/ADCLRC(zie figuur 12). 27

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 16-32 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: www.btdesigner.com)

5.4.2 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

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: http://www.itu.int) 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 4.2.2 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 5.5.1 komt de werking van de verschillende hardwarecomponenten aan de orde en in 5.5.2 wordt de geschreven software uitgelegd. 29

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

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 Cfuncties. In paragraaf 5.6.2 zullen deze functies besproken worden. (Bron: www.cs.columbia.edu1)

31

Figuur 15: DM9000A in- en uitgangpinnen (bron: www.altera.com)

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 0000. Ongeacht of er al data op deze plek aanwezig is. Voor Rx geldt hetzelfde, maar begint deze na de loopback weer op 0C00.

32

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: www.cs.columbia.edu)

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

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 (www.davicom.com.tw).

5.5.2 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

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: http://www.cs.columbia.edu/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 5.6.1 wordt de ISR van een audio interrupt besproken, 5.6.2 zal de ISR van de netwerk interrupt toelichten en als laatst wordt in 5.6.3 worden de ‘main’ functie ontleed.

35

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 3. 64 samples van het rechterkanaal ophalen en opslaan in de codec_buffer. 4. 64 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 8. 64 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]

[6] } else { [8]

for(i=0;i< 128 ;i++) transmit_buffer[i+ PAYLOAD_OFFSET]= _af_linear2ulaw(codec_buffer[(i<<1)]); TransmitPacket(transmit_buffer,136);

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

[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.

5.6.2 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 5.5.2 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

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); }

5.6.3 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

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

6 Testen van het systeem In dit hoofdstuk zullen de testen worden besproken voor het audioen 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

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

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.


6.1.3 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

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.


6.1.4 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

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.


6.1.5 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


6.1.6 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


6.2 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 6.2.1 zullen eerst de gekwantificeerde en later de niet-gekwantificeerde criteria van het audiodeel behandeld worden. In paragraaf 6.2.2 worden de criteria van het netwerkdeel ook in deze volgorde behandeld.

6.2.1 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

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

Figuur 24: De THD op 2 kHz

Figuur 25: De THD op 1 kHz

48

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

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

R1.2

Het FPGA-ontwerp van het audiodeel mag niet meer dan 10.000 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 10.000 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 5.4.2 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

R1.3 Het prototype moet op een Altera DE2 bordje draaien. De VoIP-telefoon prototype werkte uiteindelijk op een Altera DE2 bordje. Er wordt dus voldaan aan dit criterium.

6.2.2 Netwerk -

Gekwantificeerde criteria

F2.1

Het netwerkdeel moet datapakketjes met een grootte van 520 en 136 Bytes kunnen verzenden en ontvangen.

Twee aan elkaar verbonden Altera DE2’s konden met elkaar communiceren. Er konden dus audiosamples verstuurd en ontvangen worden. Deze hebben afhankelijk van het gebruik van de G.711 codec een grootte van 520 en 136 Bytes. Er wordt dus voldaan aan dit criterium. F2.3

Het netwerkdeel moet minimaal 520 kb/s tegelijkertijd kunnen versturen en ontvangen.

Twee aan elkaar verbonden Altera DE2’s konden met elkaar communiceren zonder het gebruik van de G.711 codec. Er wordt dan 520 kb/s verstuurd. Er wordt namelijk gesampled op 8 kHz, met 16 bits (opgeslagen in een 32 bits formaat) en 2 kanalen. Per netwerkpakketje komt er nog een header van 12 Bytes (96 bits) bij en er worden 125 pakketjes per seconde verstuurd. Als gevolg van alleen de header worden er 12000 bits per seconde verstuurd. Dit resulteert in een snelheid van 524 kb/s en dit is meer dan de geëiste 520kb/s. Er wordt dus voldaan aan dit criterium. F2.4

De vertraging van het verzenden en ontvangen van data tussen 2 FPGA’s, mag maximaal 40 ms bedragen.

Voor het berekenen van deze vertraging is er gebruik gemaakt van meetopstelling 5 en 6. De vertraging van de audioverwerking volgt uit meetopstelling 5 en is ~20 ms (zie criterium F1.5 uit paragraaf 6.2.1). Zoals te zien is in figuren 30, 31 en 32 heeft het complete traject een vertraging van ~22 ms. Hier blijft dus een vertraging over voor het netwerkdeel van ~2 ms. Deze vertraging is ruim onder de gestelde 40 ms. Er wordt voldaan aan dit criterium.

52

Figuur 30: De vertraging van het complete systeem op een deltapulsfrequentie van 20 Hz


53


R2.4

Het FPGA-ontwerp van het netwerkdeel mag niet meer dan 10.000 LE’s in beslag nemen.

In figuur 29 is een afbeelding van het compilatie verslag te zien. In dit figuur is zichtbaar dat het totale project slechts 5268 LE’s in beslag neemt. Het netwerkdeel is een deel hiervan en dus kleiner dan 10.000 LE’s. Er wordt dus voldaan aan dit criterium. R2.5

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

F2.2

De pakketjes moeten verzonden en ontvangen worden over een bedrade ethernetverbinding.

Twee met een netwerkkabel aan elkaar verbonden Altera DE2’s konden met elkaar communiceren. Er wordt dus voldaan aan dit criterium. F2.5

Het netwerkdeel 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 netwerkdeel te integreren is het hoofdproject. Er wordt dus voldaan aan dit criterium.

54

R2.1

Er moet een protocol gebruikt worden om verbinding op te zetten en af te sluiten.

Hoewel er wel een poging is gedaan om dit werkend te krijgen, is door tijdgebrek deze functionaliteit beperkt. Het is wel mogelijk berichten over het netwerk te sturen, maar een actie daaraan koppelen geeft nog problemen. Dit is misschien een leuke uitdaging voor een vervolgproject. R2.2

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. R2.3

Het prototype moet op een Altera DE2 bordje draaien.

De VoIP-telefoon prototype werkte uiteindelijk op een Altera DE2 bordje. Er wordt dus voldaan aan dit criterium.

55

7 Conclusies en aanbevelingen 7.1 Conclusies Onderzocht is wat de beste methode is om audioen netwerkfunctionaliteiten van een VoIP-telefoon op een FPGA te laten functioneren. Het onderzoek heeft de volgende resultaten opgeleverd: 1. Voor de audioen netwerkfunctionaliteiten is gebleken dat een software-implementatie voldoet aan de eisen. Uit de testresultaten blijkt dat dit ontwerp zeer geschikt is voor

communicatie over twee Altera DE2 borden. 2. Het gemaakte ontwerp is een uitbreidbare basis is voor de VoIP-telefoon prototype. Omdat het ontwerp ruim binnen de gestelde eisen m.b.t. de vertraging en de rekencapaciteit is gebleven en het ontwerp volgens een softwarematig concept is uitgevoerd, kunnen makkelijk nieuwe functies toegevoegd worden.

7.2 Aanbevelingen Om dit ontwerp meer op een VoIP-telefoon te laten lijken, verdient het de aanbeveling om de volgende functies toe te voegen:

1. Het audiodeel kan uitgebreid worden met ondersteuning voor meer geavanceerdere audiocodecs, zoals GSM EFRC en Speex. Hierdoor wordt de geluidskwaliteit verbeterd en toch de bitrate te verlagen. Eventueel kunnen delen van deze codecs in hardware uitgevoerd worden. 2. De gebruikersinterface is nog vrij beperkt en kan uitgebreid worden met volumeregeling, kleurenscherm en een toetsenpaneel. 3. Het netwerkdeel kan uitgebreid worden met de ondersteuning voor een verbindingsprotocol zoals SIP. 4. Het huidige ontwerp kan alleen over een bedrade point-to-point connectie communiceren. Een uitbreiding met draadloze functionaliteit is aan te bevelen.

56

Bronvermelding •

[1] Altera University Program IP Cores www.altera.com/education/univ/ip-cores/unv-ip-cores.html Geraadpleegd op 12 mei 2007

•

[2] Altera Audio Core for Altera DE2/DE1 Boards ftp://ftp.altera.com/up/pub/University_Program_IP_Cores/Audio.pdf Geraadpleegd op 14 mei 2007

•

[3] Altera Altera DE2 Development Board http://www.altera.com/education/univ/materials/boards/unv-de2-board.html/ Geraadpleegd op 1 mei 2007.

•

[4] Altera Audio- video config IP core ftp://ftp.altera.com/up/pub/University_Program_IP_Cores/AudioVideoConfig.pdf/ Geraapleegd 10 mei 2007

•

[1] Davicom Semiconductor, Inc. (2005) DM9000A. 16/8 Bit Ethernet Controller with General Processor Interface. Application Notes V1.20 http://www1.cs.columbia.edu/~sedwards/classes/2007/4840/Davicom-DM9000AApplication-Notes.pdf Geraadpleegd op 12 mei 2007

•

Davicom Semiconductor, Inc. (2006) DM9000A. Ethernet Controller with General Processor Interface. Data Sheet http://www.davicom.com.tw/big5/download/Data%20Sheet/DM9000A-DS-F01-101906.pdf Geraadpleegd op 12 mei 2007

•

[2] Edwards, S.(2007), Embedded system design http://www1.cs.columbia.edu/~sedwards/classes/2007/4840/index.html/ Geraadpleegd 10 mei 2007

•

International Telecommunication Union Pulse Code Modulation (PCM) of Voice Frequencies. ITU-T Recommendation G.711 http://www.itu.int /rec/dologin_pub.asp?lang=e&id=T-REC-G.711-198811-I!!PDFE&type=items 57

Geraadpleegd op 12 juni 2007 •

Schildt, H. (2000), C: The Complete Reference 4e dr. California: McGraw-Hill

•

Terasic Technologies http://www.terasic.com.tw/attachment/archive/56/image/DE2_1280.jpg Geraadpleegd op 12 mei 2007.

•

Vahid, F. & Givargis, T. (2002), Embedded System Design. A Unified Hardware/Software Introduction John Wiley & Sons, Inc.

•

Wolfson Microelectronics plc (2004) WM8731/WM8731L Portable Internet Audio CODEC with Headphone Driver and Programmable Sample Rates http://www.btdesigner.com/pdfs/WM8731_WM8731L.pdf Geraadpleegd op 12 mei 2007

58

Bijlage A: Verilog code van de top module Nios-systeem In deze bijlage wordt de top module van het gebruikte Nios-systeem in de testopstelling gegeven en verder toegelicht. De functie van de top module is het verbinden van het gecreëerde systeem met SOPC builder te verbinden met de pinnen van het FPGA bord. Deze pinnamen staan niet vast voor elke configuratie. Het is daarom belangrijk dit de controleren wanneer u foutmeldingen krijgt bij het gebruik van de code. In de top module staan de signalen die van en naar de componenten buiten de FPGA gaan. Deze componenten zijn in groen aangegeven in de tekst. Een aantal componenten zijn echter niet nodig geweest in de test opstelling. Deze zijn niet verwijderd, omdat andere ontwerpteams er mogelijk wel van gebruik van hebben gemaakt. Wel is aangegeven welke dat zijn in de module door een “nvt”. In de module is ook extra toelichting dikgedrukt geplaatst. module DE2_NET ( // Onboard Oscilator OSC_27, OSC_50, // Push Button KEY, // DPDT Switch nvt DPDT_SW, // 7-SEG Display HEX0, HEX1, HEX2, HEX3, HEX4, HEX5, HEX6, HEX7, // LED nvt LED_GREEN, LED_RED, // UART UART_TXD, UART_RXD, // Flash Interface FL_DQ, // 8 Bits FL_ADDR, // 22 Bits FL_WE_N, FL_RST_N, FL_OE_N, 59

FL_CE_N, // SRAM Interface SRAM_DQ, // 16 Bits SRAM_ADDR, // 18 Bits SRAM_UB_N, SRAM_LB_N, SRAM_WE_N, SRAM_CE_N, SRAM_OE_N, // ISP1362 USB Interface nvt OTG_DATA, // 16 Bits OTG_ADDR, // 2 Bits OTG_CS_N, OTG_RD_N, OTG_WR_N, OTG_RST_N, USB Full Speed, 0 = Enable, Z = Disable OTG_FSPEED, // OTG_LSPEED, // USB Low Speed, 0 = Enable, Z = Disable OTG_INT0, OTG_INT1, OTG_DREQ0, OTG_DREQ1, OTG_DACK0_N, OTG_DACK1_N, // Ethernet Interface ENET_DATA, ENET_CMD, ENET_CS_N, ENET_WR_N, ENET_RD_N, ENET_RST_N, ENET_INT, ENET_CLK, // LCD Module 16X2 LCD_ON, // LCD ON/OFF LCD_BLON, // LCD Back Light ON/OFF LCD_RW, LCD_EN, LCD_RS, LCD_DATA, // SD_Card Interface nvt SD_CMD, SD_CLK, SD_DATA, // I2C 60

I2C_DATA, I2C_CLK, // PS2 PS2_DATA, PS2_CLK, // AUDIO AUD_ADCLRCK, // 8 kHz AUD_ADCDAT , // data naar de processor AUD_DACLRCK, // 8khz AUD_DACDAT, // data naar de audiochip AUD_XCK , // 12.228 MHz clock AUD_BCLK , // 3 MHz clock TD_RESET ); // // input input // input // input // output output output output output output output output // output output // output input // inout output output output output

definities van in- en uitgangen On Board Oscilator OSC_27; OSC_50; Push Button [3:0] KEY; DPDT Switch [17:0] DPDT_SW; 7-SEG Display [6:0] HEX0; [6:0] HEX1; [6:0] HEX2; [6:0] HEX3; [6:0] HEX4; [6:0] HEX5; [6:0] HEX6; [6:0] HEX7; LED [8:0] LED_GREEN; [17:0] LED_RED; UART UART_TXD; UART_RXD; Flash Interface [7:0] FL_DQ; // 8 Bits [21:0] FL_ADDR; // 22 Bits FL_WE_N; FL_RST_N; FL_OE_N; 61

output // inout output output output output output output // inout output output output output output output output input input input input output output // inout output output output output output input output // inout output output output output output // inout output output //

FL_CE_N; SRAM Interface [15:0] SRAM_DQ; // 16 Bits [17:0] SRAM_ADDR; // 18 Bits SRAM_UB_N; SRAM_LB_N; SRAM_WE_N; SRAM_CE_N; SRAM_OE_N; ISP1362 Interface USB [15:0] OTG_DATA; [1:0] OTG_ADDR; OTG_WR_N; OTG_RD_N; OTG_CS_N; OTG_RST_N; OTG_FSPEED; // USB Full Speed, 0 = Enable, Z = Disable OTG_LSPEED; //USB Low Speed, 0 = Enable, Z =Disable OTG_INT0; OTG_INT1; OTG_DREQ0; OTG_DREQ1; OTG_DACK0_N; OTG_DACK1_N; Ethernet Interface [15:0] ENET_DATA; ENET_CMD; ENET_CS_N; ENET_WR_N; ENET_RD_N; ENET_RST_N; ENET_INT; ENET_CLK; LCD Module 16X2 [7:0] LCD_DATA; LCD_ON; // LCD ON/OFF LCD_BLON; // LCD Back Light ON/OFF LCD_RW; LCD_EN; LCD_RS; SD_Card Interface SD_DATA; SD_CLK; SD_CMD; I2C 62

inout inout // inout inout

I2C_DATA; I2C_CLK; PS2 PS2_DATA; PS2_CLK;

//audio inout input inout output output inout

AUD_ADCLRCK; AUD_ADCDAT; AUD_DACLRCK; AUD_DACDAT; AUD_XCK; AUD_BCLK;

output

TD_RESET;

assign

TD_RESET

=

1'b1;

////////////////////////////////////////////////////////// // wires en assigns worden gebruikt in situaties wanneer de port map van de top // module niet geheel overkomt met de SOPC builder gegenereerde nios_0 module. wire [31:0] mSEG7_HEX; wire [15:0] DATA_to_OTG; wire [15:0] DATA_to_SRAM; // I2C wire SCL_OE_N; wire SDA_OE_N; wire SCL; wire SDA; // CPU wire CPU_RESET; reg always@(posedge OSC_50)

ENET_CLK; ENET_CLK=~ENET_CLK;

// assign assign assign assign

= = = =

16*2 LCD Module LCD_ON LCD_BLON FL_RST_N FL_ADDR[21:20]

// I2C Tri-inout assign I2C_CLK assign I2C_DATA

=

1'b1; // 1'b1; // 1'b1; 2'b00; //

SCL_OE_N ? = SDA_OE_N 63

LCD ON LCD Back Light Fixed 1M-Byte FLASH

1'bz ?

: 1'bz

SCL :

; SDA

;

Reset_Delay

rst

(OSC_50,CPU_RESET);

// port mappen van de nios_0 module naar de pinnen van de DE2 FPGA nios_0 u0 ( // 1) global signals: .clk(OSC_50), .reset_n(CPU_RESET), // the_DE_board_0 .AUD_XCK_from_the_DE_board_0(AUD_XCK), // the_DM9000A .ENET_CMD_from_the_DM9000A(ENET_CMD), .ENET_CS_N_from_the_DM9000A(ENET_CS_N), .ENET_DATA_to_and_from_the_DM9000A(ENET_DATA), .ENET_INT_to_the_DM9000A(ENET_INT), .ENET_RD_N_from_the_DM9000A(ENET_RD_N), .ENET_RST_N_from_the_DM9000A(ENET_RST_N), .ENET_WR_N_from_the_DM9000A(ENET_WR_N), // the_I2C_0 .scl_pad_i_to_the_I2C_0(I2C_CLK), .scl_pad_o_from_the_I2C_0(SCL), .scl_padoen_o_from_the_I2C_0(SCL_OE_N), .sda_pad_i_to_the_I2C_0(I2C_DATA), .sda_pad_o_from_the_I2C_0(SDA), .sda_padoen_o_from_the_I2C_0(SDA_OE_N), // the_ISP1362 .OTG_ADDR_from_the_ISP1362(OTG_ADDR), .OTG_CS_N_from_the_ISP1362(OTG_CS_N), .OTG_DACK0_N_from_the_ISP1362(OTG_DACK0_N), .OTG_DACK1_N_from_the_ISP1362(OTG_DACK1_N), .OTG_DATA_to_and_from_the_ISP1362(OTG_DATA), .OTG_DREQ0_to_the_ISP1362(OTG_DREQ0), .OTG_DREQ1_to_the_ISP1362(OTG_DREQ1), .OTG_INT0_to_the_ISP1362(OTG_INT0), .OTG_INT1_to_the_ISP1362(OTG_INT1), .OTG_RD_N_from_the_ISP1362(OTG_RD_N), .OTG_RST_N_from_the_ISP1362(OTG_RST_N), .OTG_WR_N_from_the_ISP1362(OTG_WR_N), .OTG_FSPEED_from_the_ISP1362(OTG_FSPEED), .OTG_LSPEED_from_the_ISP1362(OTG_LSPEED), 64

.iFSPEED_to_the_ISP1362(1'bz), .iLSPEED_to_the_ISP1362(1'bz), // the_SEG7_Display .oSEG0_from_the_SEG7_Display(HEX0), .oSEG1_from_the_SEG7_Display(HEX1), .oSEG2_from_the_SEG7_Display(HEX2), .oSEG3_from_the_SEG7_Display(HEX3), .oSEG4_from_the_SEG7_Display(HEX4), .oSEG5_from_the_SEG7_Display(HEX5), .oSEG6_from_the_SEG7_Display(HEX6), .oSEG7_from_the_SEG7_Display(HEX7), // the_audio_0 .AUD_ADCDAT_to_the_audio_0(AUD_ADCDAT), .AUD_ADCLRCK_to_and_from_the_audio_0(AUD_ADCLRCK), .AUD_BCLK_to_and_from_the_audio_0(AUD_BCLK), .AUD_DACDAT_from_the_audio_0(AUD_DACDAT), .AUD_DACLRCK_to_and_from_the_audio_0(AUD_DACLRCK), // the_audio_and_video_config_0 .I2C_SCLK_from_the_audio_and_video_config_0(I2C_CLK), .I2C_SDAT_to_and_from_the_audio_and_video_config_0(I2C_DATA), // the_button_pio .in_port_to_the_button_pio(KEY), // the_lcd_16207_0 .LCD_E_from_the_lcd_16207_0(LCD_EN), .LCD_RS_from_the_lcd_16207_0(LCD_RS), .LCD_RW_from_the_lcd_16207_0(LCD_RW), .LCD_data_to_and_from_the_lcd_16207_0(LCD_DATA), // the_led_green .out_port_from_the_led_green(LED_GREEN), // the_led_red .out_port_from_the_led_red(LED_RED), // the_ps2_0 .PS2_CLK_to_and_from_the_ps2_0(PS2_CLK), .PS2_DAT_to_and_from_the_ps2_0(PS2_DATA), // the_sram_0 .SRAM_ADDR_from_the_sram_0(SRAM_ADDR), 65

.SRAM_CE_N_from_the_sram_0(SRAM_CE_N), .SRAM_DQ_to_and_from_the_sram_0(SRAM_DQ), .SRAM_LB_N_from_the_sram_0(SRAM_LB_N), .SRAM_OE_N_from_the_sram_0(SRAM_OE_N), .SRAM_UB_N_from_the_sram_0(SRAM_UB_N), .SRAM_WE_N_from_the_sram_0(SRAM_WE_N), // the_switch_pio .in_port_to_the_switch_pio(DPDT_SW), // the_tri_state_bridge_0_avalon_slave .select_n_to_the_cfi_flash_0(FL_CE_N), .tri_state_bridge_0_address(FL_ADDR), .tri_state_bridge_0_data(FL_DQ), .tri_state_bridge_0_readn(FL_OE_N), .write_n_to_the_cfi_flash_0(FL_WE_N), // the_uart_0 .rxd_to_the_uart_0(UART_RXD), .txd_from_the_uart_0(UART_TXD) ); endmodule

66

Bijlage B: Gebruikte audio en netwerk C-code In deze bijlage wordt toelichting gegeven over de code van de bestanden alt_up_audio.c en alt_up_audio_video_config.c, audio.c, DM9000A.c en G711.c. De bestanden alt_up_audio.c en alt_up_audio_video_config.c behoren bij de University IP cores Audio en Audio_config van de DE2. Uit deze bestanden zullen alleen de functie prototypes toegelicht worden, die gebruikt zijn in de zelf geschreven audio.c. De bestanden audio.c, DM9000A.c en G.711.c worden wel geheel gegeven.

B1 Alt_up_audio.c #include "alt_up_audio.h" int alt_up_audio_enable_read_interrupt () //enable read interrupt int alt_up_audio_disable_read_interrupt () //disable read interrupt int alt_up_audio_read_left_channel (alt_u32 * buf, unsigned len) //lezen van len aantal samples van de linker audio ingang FIFO en slaat ze op //beginnende op geheugenadres buf. Alt_u32 is een unsigned 32 bit integer. int alt_up_audio_read_right_channel (alt_u32 * buf, unsigned len) //idem voor rechts int alt_up_audio_write_left_channel (alt_u32 *buf, unsigned len) //schrijven van len aantal samples op de linker audio uitgang FIFO beginnende op //geheugenadres buf int alt_up_audio_write_right_channel (alt_u32 * buf, unsigned len) // idem voor rechts

67

B2 Alt_up_audio_video_config.c int alt_up_av_config_write_audio_reg(alt_u32 data) //in data worden alleen de laatste 16 bits gebruikt. Bit 0-8 zijn de data bits en de bit //9-15 zijn de offset adres bits van de desbetreffende audioregister. In de Register //map zijn de registers en registerinhoud weergegeven.

B3 Audio.c #include <stdio.h> #include #include #include "alt_up_audio.h" #include "alt_up_audio_video_config.h" #include "audio.h"

int audio_initialize() { alt_up_av_config_write_audio_reg(0x1200); alt_up_av_config_write_audio_reg(0x0c00); alt_up_av_config_write_audio_reg(0x0117); alt_up_av_config_write_audio_reg(0x0a00); alt_up_av_config_write_audio_reg(0x100a);

//disable interface //powerdown disable //disable mute data //disable soft mute //sample rate 68

R9= ‘000000000’ R6= ‘000000000’ R0= ‘100010111’ R5= ‘000000000’ R8= ‘000001100’

alt_up_av_config_write_audio_reg(0x0810); //bypass disable R4= ‘000010000’ alt_up_av_config_write_audio_reg(0x1201); //set R9= ‘000000000’ alt_up_audio_enable_read_interrupt(); return 0; }

// er zijn een aantal instellingen die al ingesteld kunnen worden in SOPC builder, // bij geschreven om fouten door instellingen te voorkomen

int readLR(alt_u32 *buffer, unsigned int size) { alt_up_audio_read_right_channel(&buffer,size); alt_up_audio_read_left_channel(&buffer+size,size); return 0; } //size aantal samples rechts en links worden achter elkaar geschreven beginnende //op &buffer

int writeLR(alt_u32 *buffer, unsigned int size) { alt_up_audio_write_right_channel(&buffer,size); alt_up_audio_write_left_channel(&buffer+size, size); return 0; } //size aantal samples rechts en links worden achter elkaar geschreven op de audio //FIFO registers beginnende op &buffer. Rechts moet eerst aangeboden worden.

B4 DM9000A.c #include <stdio.h> #include "DM9000A.h" #include "basic_io.h" void dm9000a_iow(unsigned int reg, unsigned int data) { IOWR(DM9000A_BASE, IO_addr, reg); IOWR(DM9000A_BASE, IO_data, data); } unsigned int dm9000a_ior(unsigned int reg) { IOWR(DM9000A_BASE, IO_addr, reg); return IORD(DM9000A_BASE, IO_data); }

69

void phy_write(unsigned int reg, unsigned int value) { /* set PHY register address into EPAR REG. 0CH */ dm9000a_iow(0x0C, reg | 0x40); /* PHY register address setting, and DM9000_PHY offset = 0x40 */ /* fill PHY WRITE data into EPDR REG. 0EH & REG. 0DH */ dm9000a_iow(0x0E, ((value >> 8) & 0xFF)); /* PHY data high_byte */ dm9000a_iow(0x0D, value & 0xFF); /* PHY data low_byte */ /* issue PHY + WRITE command = 0xa into EPCR REG. 0BH */ dm9000a_iow(0x0B, 0x8); /* clear PHY command first */ IOWR(DM9000A_BASE, IO_data, 0x0A); /* issue PHY + WRITE command */ usleep(STD_DELAY); IOWR(DM9000A_BASE, IO_data, 0x08); /* clear PHY command again */ usleep(50); /* wait 1~30 us (>20 us) for PHY + WRITE completion */ } /* DM9000_init I/O routine */ unsigned int DM9000_init(unsigned char *mac_address) { unsigned int i; /* set the internal PHY power-on (GPIOs normal settings) */ dm9000a_iow(0x1E, 0x01); /* GPCR REG. 1EH = 1 selected GPIO0 "output" port for internal PHY */ dm9000a_iow(0x1F, 0x00); /* GPR REG. 1FH GEPIO0 Bit [0] = 0 to activate internal PHY */ msleep(5); /* wait > 2 ms for PHY power-up ready */ /* software-RESET NIC */ dm9000a_iow(NCR, 0x03); /* NCR REG. 00 RST Bit [0] = 1 reset on, and LBK Bit [2:1] = 01b MAC loopback on */ usleep(20); /* wait > 10us for a software-RESET ok */ dm9000a_iow(NCR, 0x00); /* normalize */ dm9000a_iow(NCR, 0x03); usleep(20); dm9000a_iow(NCR, 0x00); /* set GPIO0=1 then GPIO0=0 to turn off and on the internal PHY */ dm9000a_iow(0x1F, 0x01); /* GPR PHYPD Bit [0] = 1 turn-off PHY */ dm9000a_iow(0x1F, 0x00); /* PHYPD Bit [0] = 0 activate phyxcer */ msleep(10); /* wait >4 ms for PHY power-up */ /* set PHY operation mode */ phy_write(0,PHY_reset); /* reset PHY registers back to the default state */ usleep(50); /* wait >30 us for PHY software-RESET ok */ phy_write(16, 0x404); /* turn off PHY reduce-power-down mode only */ phy_write(4, PHY_txab); /* set PHY TX advertised ability: ALL + Flow_control */ phy_write(0, 0x1200); /* PHY auto-NEGO re-start enable (RESTART_AUTO_NEGOTIATION + AUTO_NEGOTIATION_ENABLE) to auto sense and recovery PHY registers */ msleep(5); /* wait >2 ms for PHY auto-sense linking to partner */ /* store MAC address into NIC */ for (i = 0; i < 6; i++) dm9000a_iow(16 + i, mac_address[i]);

70

/* clear any pending interrupt */ dm9000a_iow(ISR, 0x3F); /* clear the ISR status: PRS, PTS, ROS, ROOS 4 bits, by RW/C1 */ dm9000a_iow(NSR, 0x2C); /* clear the TX status: TX1END, TX2END, WAKEUP 3 bits, by RW/C1 */ /* program operating registers~ */ dm9000a_iow(NCR, NCR_set); /* NCR REG. 00 enable the chip functions (and disable this MAC loopback mode back to normal) */ dm9000a_iow(0x08, BPTR_set); /* BPTR REG.08 (if necessary) RX Back Pressure Threshold in Half duplex moe only: High Water 3KB, 600 us */ dm9000a_iow(0x09, FCTR_set); /* FCTR REG.09 (if necessary) Flow Control Threshold setting High/ Low Water Overflow 5KB/ 10KB */ dm9000a_iow(0x0A, RTFCR_set); /* RTFCR REG.0AH (if necessary) RX/TX Flow Control Register enable TXPEN, BKPM (TX_Half), FLCE (RX) */ dm9000a_iow(0x0F, 0x00); /* Clear the all Event */ dm9000a_iow(0x2D, 0x90); /* Switch LED to mode 1 0x80*/ /* set other registers depending on applications */ dm9000a_iow(ETXCSR, ETXCSR_set); /* Early Transmit 75% */ /* enable interrupts to activate DM9000 ~on */ dm9000a_iow(IMR, INTR_set); /* IMR REG. FFH PAR=1 only, or + PTM=1& PRM=1 enable RxTx interrupts */ /* enable RX (Broadcast/ ALL_MULTICAST) ~go */ dm9000a_iow(RCR , RCR_set | RX_ENABLE | PASS_MULTICAST); /* RCR REG. 05 RXEN Bit [0] = 1 to enable the RX machine/ filter */ /* RETURN "DEVICE_SUCCESS" back to upper layer */ return (dm9000a_ior(0x2D)==0x80) ? DMFE_SUCCESS : DMFE_FAIL; } unsigned int TransmitPacket(unsigned char *data_ptr, unsigned int tx_len) { unsigned int i; /* mask NIC interrupts IMR: PAR only */ dm9000a_iow(IMR, PAR_set); /* issue TX packet's length into TXPLH REG. FDH & TXPLL REG. FCH */ dm9000a_iow(0xFD, (tx_len >> 8) & 0xFF); /* TXPLH High_byte length */ dm9000a_iow(0xFC, tx_len & 0xFF); /* TXPLL Low_byte length */ /* wirte transmit data to chip SRAM */ IOWR(DM9000A_BASE, IO_addr, MWCMD); /* set MWCMD REG. F8H TX I/O port ready */ for (i = 0; i < tx_len; i += 2) {// 2 in 4 veranderd IOWR(DM9000A_BASE, IO_data, (data_ptr[i+1]<<8)|data_ptr[i] ); } /* issue TX polling command activated */ dm9000a_iow(TCR , TCR_set | TX_REQUEST); /* TXCR Bit [0] TXREQ auto clear after TX completed */

71

/* wait TX transmit done */ while(!(dm9000a_ior(NSR)&0x0C)) usleep(STD_DELAY); /* clear the NSR Register */ dm9000a_iow(NSR,0x00); /* re-enable NIC interrupts */ dm9000a_iow(IMR, INTR_set); /* RETURN "TX_SUCCESS" to upper layer */ return DMFE_SUCCESS; } unsigned int ReceivePacket(unsigned char *data_ptr, unsigned int *rx_len) { unsigned char rx_READY, GoodPacket; unsigned int Tmp, RxStatus, i; RxStatus = rx_len[0] = 0; GoodPacket=FALSE; /* mask NIC interrupts IMR: PAR only */ dm9000a_iow(IMR, PAR_set); /* dummy read a byte from MRCMDX REG. F0H */ rx_READY = dm9000a_ior(MRCMDX); /* got most updated byte: rx_READY */ rx_READY = IORD(DM9000A_BASE,IO_data)&0x03;

/* check if (rx_READY == 0x01): Received Packet READY? */ if (rx_READY == DM9000_PKT_READY) { /* got RX_Status & RX_Length from RX SRAM */ IOWR(DM9000A_BASE, IO_addr, MRCMD); /* set MRCMD REG. F2H RX I/O port ready */ RxStatus = IORD(DM9000A_BASE,IO_data); rx_len[0] = IORD(DM9000A_BASE,IO_data); /* Check this packet_status GOOD or BAD? */ if ( !(RxStatus & 0xBF00) && (rx_len[0] < MAX_PACKET_SIZE) ) { /* read 1 received packet from RX SRAM into RX buffer */ for (i = 0; i < rx_len[0]; i += 2) { Tmp = IORD(DM9000A_BASE, IO_data); data_ptr[i] = Tmp & 0xFF; data_ptr[i+1] = (Tmp>>8) & 0xFF; } GoodPacket = TRUE; } else { /* this packet is bad, dump it from RX SRAM */ for (i = 0; i < rx_len[0]; i += 2) { //usleep(STD_DELAY); Tmp = IORD(DM9000A_BASE, IO_data); } printf("\nError\n"); rx_len[0] = 0; } } else if (rx_READY) { /* status check first byte:

72

rx_READY Bit[1:0] must be "00"b or "01"b */ /* software-RESET NIC */ dm9000a_iow(NCR, 0x03); /* NCR REG. 00 RST Bit [0] = 1 reset on, and LBK Bit [2:1] = 01b MAC loopback on */ usleep(20); /* wait > 10us for a software-RESET ok */ dm9000a_iow(NCR, 0x00); /* normalize */ dm9000a_iow(NCR, 0x03); usleep(20); dm9000a_iow(NCR, 0x00); /* program operating registers~ */ dm9000a_iow(NCR, NCR_set); /* NCR REG. 00 enable the chip functions (and disable this MAC loopback mode back to normal) */ dm9000a_iow(0x08, BPTR_set); /* BPTR REG.08 (if necessary) RX Back Pressure Threshold in Half duplex moe only: High Water 3KB, 600 us */ dm9000a_iow(0x09, FCTR_set); /* FCTR REG.09 (if necessary) Flow Control Threshold setting High/Low Water Overflow 5KB/ 10KB */ dm9000a_iow(0x0A, RTFCR_set); /* RTFCR REG.0AH (if necessary) RX/TX Flow Control Register enable TXPEN, BKPM (TX_Half), FLCE (RX) */ dm9000a_iow(0x0F, 0x00); /* Clear the all Event */ dm9000a_iow(0x2D, 0x80); /* Switch LED to mode 1 */ /* set other registers depending on applications */ dm9000a_iow(ETXCSR, ETXCSR_set); /* Early Transmit 75% */ /* enable interrupts to activate DM9000 ~on */ dm9000a_iow(IMR, INTR_set); /* IMR REG. FFH PAR=1 only, or + PTM=1& PRM=1 enable RxTx interrupts */ /* enable RX (Broadcast/ ALL_MULTICAST) ~go */ dm9000a_iow(RCR , RCR_set | RX_ENABLE | PASS_MULTICAST); /* RCR REG. 05 RXEN Bit [0] = 1 to enable the RX machine/ filter */ } return GoodPacket ? DMFE_SUCCESS : DMFE_FAIL; }

(bron: http://www.cs.columbia.edu/2)

B5 G711.c /* * This source code is a product of Sun Microsystems, Inc. and is provided * for unrestricted use. Users may copy or modify this source code without * charge. * * SUN SOURCE CODE IS PROVIDED AS IS WITH NO WARRANTIES OF ANY KIND INCLUDING * THE WARRANTIES OF DESIGN, MERCHANTIBILITY AND FITNESS FOR A PARTICULAR * PURPOSE, OR ARISING FROM A COURSE OF DEALING, USAGE OR TRADE PRACTICE. * * Sun source code is provided with no support and without any obligation on * the part of Sun Microsystems, Inc. to assist in its use, correction, * modification or enhancement. * * SUN MICROSYSTEMS, INC. SHALL HAVE NO LIABILITY WITH RESPECT TO THE

73

* INFRINGEMENT OF COPYRIGHTS, TRADE SECRETS OR ANY PATENTS BY THIS SOFTWARE * OR ANY PART THEREOF. * * In no event will Sun Microsystems, Inc. be liable for any lost revenue * or profits or other special, indirect and consequential damages, even if * Sun has been advised of the possibility of such damages. * * Sun Microsystems, Inc. * 2550 Garcia Avenue * Mountain View, California 94043 */ #define SUPERCEDED /* * g711.c * * u-law, A-law and linear PCM conversions. */ #define SIGN_BIT (0x80) /* Sign bit for a A-law byte. */ #define QUANT_MASK (0xf) /* Quantization field mask. */ #define NSEGS (8) /* Number of A-law segments. */ #define SEG_SHIFT (4) /* Left shift for segment number. */ #define SEG_MASK (0x70) /* Segment field mask. */ /* copy from CCITT G.711 specifications */ unsigned char _u2a[128] = { /* u1, 1, 2, 2, 3, 3, 4, 5, 5, 6, 6, 7, 7, 8, 9, 10, 11, 12, 13, 14, 15, 17, 18, 19, 20, 21, 22, 23, 25, 27, 29, 31, 33, 34, 35, 37, 38, 39, 40, 41, 42, 43, 46, 48, 49, 50, 51, 52, 53, 55, 56, 57, 58, 59, 60, 61, 64, 65, 66, 67, 68, 69, 70, 72, 73, 74, 75, 76, 77, 78, 81, 82, 83, 84, 85, 86, 87, 89, 90, 91, 92, 93, 94, 95, 97, 98, 99, 100, 101, 102, 103, 105, 106, 107, 108, 109, 110, 111, 113, 114, 115, 116, 117, 118, 119, 121, 122, 123, 124, 125, 126, 127,

to A-law conversions */ 4, 8, 16, 24, 36, 44, 54, 62, 71, 79, 88, 96, 104, 112, 120, 128};

unsigned char _a2u[128] 1, 3, 5, 16, 17, 18, 24, 25, 26, 32, 32, 33, 36, 37, 38, 44, 45, 46, 50, 51, 52, 58, 59, 60, 65, 66, 67, 73, 74, 75, 80, 81, 82, 88, 89, 90, 96, 97, 98, 104, 105, 106, 112, 113, 114,

to u-law conversions */ 15, 23, 31, 35, 43, 49, 57, 64, 72, 79, 87, 95, 103, 111, 119,

= { 7, 19, 27, 33, 39, 47, 53, 61, 68, 76, 83, 91, 99, 107, 115,

9, 20, 28, 34, 40, 48, 54, 62, 69, 77, 84, 92, 100, 108, 116,

11, 21, 29, 34, 41, 48, 55, 63, 70, 78, 85, 93, 101, 109, 117,

74

/* A13, 22, 30, 35, 42, 49, 56, 64, 71, 79, 86, 94, 102, 110, 118,

120,

121,

122,

123,

124,

125,

126,

127};

/* see libst.h */ #ifdef SUPERCEDED static short seg_end[8] = {0xFF, 0x1FF, 0x3FF, 0x7FF, 0xFFF, 0x1FFF, 0x3FFF, 0x7FFF}; static int search(val, table, size) int val; short *table; int size; { int i; for (i = 0; i < size; i++) { if (val <= *table++) return (i); } return (size); }

#define

BIAS

(0x84)

/* Bias for linear code. */

/* * linear2ulaw() - Convert a linear PCM value to u-law * * In order to simplify the encoding process, the original linear magnitude * is biased by adding 33 which shifts the encoding range from (0 - 8158) * to (33 - 8191). The result can be seen in the following encoding table: * * Biased Linear Input Code Compressed Code * -------------------------------------* 00000001wxyza 000wxyz * 0000001wxyzab 001wxyz * 000001wxyzabc 010wxyz * 00001wxyzabcd 011wxyz * 0001wxyzabcde 100wxyz * 001wxyzabcdef 101wxyz * 01wxyzabcdefg 110wxyz * 1wxyzabcdefgh 111wxyz * * Each biased linear code has a leading 1 which identifies the segment * number. The value of the segment number is equal to 7 minus the number * of leading 0's. The quantization interval is directly available as the * four bits wxyz. * The trailing bits (a - h) are ignored. * * Ordinarily the complement of the resulting code word is used for * transmission, and so the code word is complemented before it is * returned. * For further information see John C. Bellamy's Digital Telephony, 1982, * John Wiley & Sons, pps 98-111 and 472-476. */ /* 2's complement (16-bit range) */ unsigned char _af_linear2ulaw (int pcm_val) { int mask; int seg;

75

unsigned char

uval;

/* Get the sign and the magnitude of the value. */ if (pcm_val < 0) { pcm_val = BIAS - pcm_val; mask = 0x7F; } else { pcm_val += BIAS; mask = 0xFF; } /* Convert the scaled magnitude to segment number. */ seg = search(pcm_val, seg_end, 8); /* * Combine the sign, segment, quantization bits; * and complement the code word. */ if (seg >= 8) /* out of range, return maximum value. */ return (0x7F ^ mask); else { uval = (seg << 4) | ((pcm_val >> (seg + 3)) & 0xF); return (uval ^ mask); } } /* * ulaw2linear() - Convert a u-law value to 16-bit linear PCM * * First, a biased linear code is derived from the code word. An unbiased * output can then be obtained by subtracting 33 from the biased code. * * Note that this function expects to be passed the complement of the * original code word. This is in keeping with ISDN conventions. */ int _af_ulaw2linear (unsigned char u_val) { int t; /* Complement to obtain normal u-law value. */ u_val = ~u_val; /* * Extract and bias the quantization bits. Then * shift up by the segment number and subtract out the bias. */ t = ((u_val & QUANT_MASK) << 3) + BIAS; t <<= ((unsigned)u_val & SEG_MASK) >> SEG_SHIFT; return ((u_val & SIGN_BIT) ? (BIAS - t) : (t - BIAS)); } #endif

76

Bijlage C: Gebruikte main C-code In deze bijlage bevindt zich het bestand main.c. met toelichting. #include "altera_avalon_pio_regs.h" #include "basic_io.h" #include "DM9000A.h" #include #include "alt_up_ps2_port.h" #include "ps2_keyboard.h" #include "ps2_mouse.h" #include "LCD.h" #include "audio.h" #include "g711.h" #define MAX_MSG_LENGTH 270 #define PAYLOAD_OFFSET 8 #define G711 1

unsigned char mac_address[6] = { 0x01, 0x60, 0x6E, 0x11, 0x02, 0x01 unsigned int interrupt_number, codecselect; unsigned int receive_buffer_length; unsigned char transmit_buffer[520]; unsigned char receive_buffer[1600]; short int codec_buffer[256]; unsigned int k, i,j; unsigned char edge_capture, last_received_msg, last_send_msg, audio_intr_status, received_ack; int tmp;

};

static void audio_interrupt_handler() { alt_up_audio_disable_read_interrupt(); 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) { alt_up_audio_read_right_channel((alt_u32)&codec_buffer[0],64); alt_up_audio_read_left_channel((alt_u32)&codec_buffer[128],64); for(i=0;i< 128 ;i++) transmit_buffer[i+ PAYLOAD_OFFSET]= _af_linear2ulaw(codec_buffer[(i<<1)]); TransmitPacket(transmit_buffer,136); } else { alt_up_audio_read_right_channel((alt_u32)&transmit_buffer[8],64); alt_up_audio_read_left_channel((alt_u32)&transmit_buffer[264],64);

77

TransmitPacket(transmit_buffer,520); } alt_up_audio_enable_read_interrupt(); }

static void ethernet_interrupt_handler() { ReceivePacket(receive_buffer, &receive_buffer_length); if (interrupt_number++ >125) { interrupt_number=0; outport(SEG7_DISPLAY_BASE, k++); } if (receive_buffer[5] != 0) { last_received_msg= receive_buffer[5]; if (last_received_msg == 0x01) { LCD_Init(); LCD_Show_Text("Receiving Call"); } else if (last_received_msg == 0x02) { if (last_send_msg == 0x01) { LCD_Init(); LCD_Show_Text("Call Accepted"); } else { printf("no call send"); printf("\n"); } } else if (last_received_msg == 0x04) { last_received_msg = 0x04; last_send_msg= 0x04; LCD_Init(); LCD_Show_Text("Call terminated"); } else { LCD_Init(); LCD_Show_Text("Received non-identified message"); } } else if (codecselect == G711) { int x=0; for(i=0;i< 128 ;i++) { codec_buffer[x+1]=0;

78

codec_buffer[x]= _af_ulaw2linear(receive_buffer[i+ PAYLOAD_OFFSET]); x = x+2; } alt_up_audio_write_right_channel((alt_u32) &codec_buffer[0],64); alt_up_audio_write_left_channel((alt_u32) &codec_buffer[128],64); } else { alt_up_audio_write_right_channel((alt_u32) &receive_buffer[8],64); alt_up_audio_write_left_channel((alt_u32) &receive_buffer[264],64); } dm9000a_iow(ISR, 0x3F); dm9000a_iow(IMR, INTR_set); } static void handle_button_interrupts(void* context, alt_u32 id) { IOWR_ALTERA_AVALON_PIO_IRQ_MASK(BUTTON_PIO_BASE, 0x0); /* Store the value in the Button's edge capture register in *context. */ edge_capture = IORD_ALTERA_AVALON_PIO_EDGE_CAP(BUTTON_PIO_BASE); /* Reset the Button's edge capture register. */ IOWR_ALTERA_AVALON_PIO_EDGE_CAP(BUTTON_PIO_BASE, 0); transmit_buffer[0]=0x01; transmit_buffer[1]=0x01; transmit_buffer[2]=0x01; transmit_buffer[3]=0x01; transmit_buffer[4]=0x00; j=100; if (edge_capture== 0x01) { last_send_msg= 0x01; transmit_buffer[5]= 0x01; TransmitPacket(transmit_buffer,30);

//0x01 code for sending call

LCD_Init(); LCD_Show_Text("Calling"); } else if (edge_capture== 0x02) { if (last_received_msg == 0x01) { last_send_msg= 0x02; transmit_buffer[5]= 0x02;

// 0x02 code for acknowledge

TransmitPacket(transmit_buffer,30);

LCD_Init(); LCD_Show_Text("Accepted Call"); } else printf("no call to accept"); } else if (edge_capture== 0x04) { last_send_msg= 0x04; transmit_buffer[5]= 0x04;

// 0x04 code for acknowledge

79

TransmitPacket(transmit_buffer,30); LCD_Init(); LCD_Show_Text("Call terminated"); } else if (edge_capture == 0x08) { if (audio_intr_status) { alt_up_audio_disable_read_interrupt(); audio_intr_status=0; } else { alt_up_audio_enable_read_interrupt(); audio_intr_status=1; } } else { LCD_Init(); LCD_Show_Text("Error"); } dm9000a_iow(ISR, 0x3F); dm9000a_iow(IMR, INTR_set); IOWR_ALTERA_AVALON_PIO_IRQ_MASK(BUTTON_PIO_BASE, 0xf); } int main() { // clear the transmit_buffer for (i= 0; i<520;i++) { transmit_buffer[i]=0; } LCD_Init(); LCD_Show_Text("4840 Lab 2"); k=0; // 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 DM9000_init(mac_address); //dm9000a_iow(IMR, INTR_set); interrupt_number = 0; // initialize audio audio_initialize(); // select codec codecselect=1; alt_irq_register(DM9000A_IRQ, NULL, (void*)ethernet_interrupt_handler); alt_irq_register(10, NULL, (void*)audio_interrupt_handler);

80

alt_up_audio_disable_read_interrupt(); last_received_msg =0x04; last_send_msg = 0x04; audio_intr_status=0; printf( "ready"); while(1) {} return 1; }

81

Bijlage D: Zelfevaluatie D1 C.C.Chi studienummer 1242784 Tijdens het bachelor afstudeerproject heb ik veel ervaring opgedaan in projectmatig groepswerken. Ook heb ik veel nieuwe vaardigheden opgedaan en een aantal vaardigheden verbeterd. Wat ik heb ervaren m.b.t. het groepswerken • Het belang van een goede groepsbalans • Belang helderheid in taakverdeling • Aan de bel trekken bij niet functionerende groepsgenoten • Niet het aantal collega’s van belang is maar welke • Het combineren van het BaAP en 3 vakken een flinke opgave is • 7 weken een erg korte tijd is Een aantal vaardigheden zijn: Nieuwe: • Het ontwerptraject PvW – PvE – concepten- ontwerpen- testen leren hanteren • Verilog programmeren • Schrijven van een ontwerprapport Verbeterd: • Opzoeken van informatie (datasheets, broncodes, IP cores, handleidingen • C programmeren en lezen van documentatie • VHDL programmeren • Communicatie gerelateerd aan groepswerken • Overbrengen van ideeën • Teksten schrijven Al met al was het een hele leuke ervaring. Ik kon me technisch goed vinden in dit project. Ik was gemotiveerd en had veel vrijheid en daardoor ook veel verantwoordelijkheid, maar dat is goed ingevuld. Aan het project heb ik het gevoel eraan over gehouden dat het resultaat het hoogst haalbare was in de omstandigheden. Wat voor de volgende keer beter kan is meer tijd uittrekken voor het vinden van gemotiveerde mensen met wie samen het project gedaan wordt. Het is belangrijk geen ‘ballast’ in het team te hebben. Dat geldt dubbel voor een klein team. Ook het strenger en eerder opgetreden, wanneer men de afspraken niet nakomt, heeft een hogere prioriteit. Wat voor mezelf gezien beter kan is toch iets minder hooi op mijn vork te nemen. Ik heb dit kwartaal nog 3 extra vakken gevolgd wat heeft geleid tot min of meer roofbouw op mezelf.

D2 T.Kaserer studienummer 1144081

82

Tijdens het bachelorproject heb ik een hoop dingen geleerd en vaardigheden verbeterd. Voornamelijk op het gebied van samenwerken, is mij een hoop duidelijk geworden. Helaas hebben we te maken gehad met twee niet meewerkende groepsgenoten, wat ons een hoop extra werk heeft opgeleverd. Niet alleen moest hun werk worden opgevangen door de rest van de groep, maar ook de lange gesprekken over het verbeteren van het gedrag van de twee in kwestie heeft een heleboel tijd gekost. Achteraf gezien hadden we eerder harde maatregelen moeten treffen, maar het algemene gevoel was dat het wel bij zou trekken. Dit weerhield ons om stappen te ondernemen. Maar ik heb ook leuke dingen geleerd over groepswerken. Al snel wordt iedereen´s sterke punten duidelijk. Frank bleek binnen de groep goed als leider te functioneren en Chi was op technisch gebied enorm sterk. Ik heb van mijzelf gemerkt dat mijn krachten o.a. liggen op het gebied van het communiceren tussen de groepsleden en het nauw samenwerken met een groepslid. We hebben veel tijd verloren met het Business Plan vanwege het veranderen van heel het concept (als gevolg van het ontbreken van goede Unique Selling Points). Dit was in het begin van kwartaal 4 en helaas waren de docenten die wij hierover wouden spreken op dat moment niet op de TUDelft. Het veranderen van dit concept zou ook invloed hebben gehad op het technische deel. We hebben uiteindelijk toch gekozen om met het oude concept verder te werken. Ik heb ook op technisch gebied een hoop geleerd. Het werken met FPGA’s is een stuk duidelijker geworden dan voorheen. Ook het gericht zoeken naar informatie over FPGA´s zoals IP cores, gaat nu een stuk beter. In de terminologie wordt ik al langzaam bekend. Tevens het werken met software als Quartus en SoPC builder kost minder moeite. We hebben wel rare dingen meegemaakt m.b.t. software. Zo gaf Nios IDE vaak foutmeldingen op één pc, terwijl op een andere pc met exact dezelfde instellingen, de functies wel uitgevoerd werden. Het gebruiken van één enkele laptop voor het programmeren van de FPGA’s en het draaien van software bleek de oplossing te zijn. Dat de VoIP-prototype uiteindelijk werkte, gaf een hoop voldoening. En het is een leuk idee dat we dat als groep voor elkaar gekregen hebben! Ik heb het idee dat ons project goed als basis kan dienen voor andere projecten. Er zijn immers nog een hoop functionaliteiten, zoals het implementeren van slimmere codecs en het meer in hardware laten uitvoeren van taken, die de VoIP-telefoon kunnen uitbreiden.

83

D3 H.Syed studienummer 9820108 In het begin had ik een ander onderwerp gekozen wat te maken had met energietechniek. Ik wil namelijk mijn Master richting Power Engineering doen. Maar helaas ging die niet door omdat de opdracht niet compleet was. Er waren toen weinig opdrachten over. We kozen toen voor de VoIP telefoon. Onze onderwerp VoIP telefoon vond ik naarmate we vorderden interessant. Wel vond ik jammer dat er alleen vakken van Computersystemen nodig waren. Ik had graag wat vakken toe willen die ik interessant vond. Samenwerking met de groep was naar mening goed verlopen. Ieder deed zijn werk. Problemen werden samen goed opgelost. Bepaalde problemen werden aan onze begeleider Dhr Wong voorgelegd. Hij was erg behulpzaam. Ik werkte samen met Chi Ching Chi aan de voice codec gedeelte. We konden het goed samen vinden. Het project was in het begin wat hectisch omdat het niet altijd duidelijk was wat er moest gebeuren omdat een aantal regels veranderden. Maar uiteindelijk was alles goed gekomen. Ik heb, denk ik, nu geleerd hoe het echte werk in een bedrijf later ongeveer eruit ziet. Ik heb geleerd hoe problemen samen op te lossen en hoe een goed rapport te schrijven. Verder vond ik het aangenaam om samen met Chi, Frank en Tobias te werken.

84

D4 F.Schilders studienummer 1144197 Evaluatie totale project De afgelopen maanden heb ik tijdens het bachelor eindproject en het schrijven van een business plan veel geleerd over het werken in en met een groep. De insteek van mij in deze projecten was om zoveel mogelijke opgedane kennis van de afgelopen jaren samen te laten komen in deze twee projecten. Uiteindelijk bleek dit toch even anders te lopen. Voor het business plan begonnen we na veel veranderingen toch met zes man. De bedoeling was om met deze zes man een business plan te schrijven voor een nog op te starten bedrijf en daarna met vijf man het bachelor eindproject te maken. Al gauw bleek dat er drie, waarvan twee in het bijzonder niet actief aan het meehelpen waren. Na een goed gesprek heeft één van deze drie het goed opgepakt en goed meegedaan met de rest. De overige twee toonden echter geen enkele verbetering. Deze twee hebben dan ook twee weken voor het einde, na overleg met de begeleider en de hoofddocent de groep verlaten. In deze laatste twee weken heeft de groep extra hard moeten werken om toch nog de gewenste doelstellingen te halen. Dit is gelukt! De organisatie van beide projecten was redelijk tot goed voor een eerste keer. Het was af en toe duidelijk te merken dat zowel het business plan als het bachelor eindproject nog niet volledig op elkaar waren afgestemd. Dit heeft af en toe voor verwarring gezorgd. Vooral het tijdsschema is een paar keer veranderd tijdens het project. Dit leverde veel verwarring op. Zeker omdat voor het bachelor eindproject drie weken waren ingeroosterd voor de ontwerpfase. Na deze drie weken kregen we bericht dat dit toch maar één week had moeten zijn. Dit zette behoorlijk wat druk op de implementatiefase. Gelukkig waren de docenten wel bereid om bij problemen met een oplossing te komen die in het voordeel lag van de studenten. Daarvoor mijn complimenten!

Evaluatie Bachelor Eindproject Tijdens het bachelor eindproject was het de bedoeling om een prototype telefoon te maken, die via SIP en een SIP-server kon telefoneren met een andere toestel. De bedoeling was om deze op een Altera DE2 bordje te implementeren. Er moest gebruik gemaakt worden van een ethernetverbinding en de audio moest gecodeerd worden. Uiteindelijk is het een toestel geworden dat alleen direct verbinding met een ander DE2 bordje kan maken, zonder tussenkomst van een server. Ook het SIP gedeelte kon gezien de tijd niet meer geïmplementeerd worden. Daar later meer over. Tijdens de implementatiefase denk ik dat de overgebleven groepsleden goed hebben samengewerkt. We hebben als groep tot het einddoel gewerkt en met elkaar de problemen opgelost, zowel technisch, als groepstechnisch. Het eindproduct is voor mij een bevredigend product geworden. Natuurlijk had ik meer voor elkaar willen krijgen maar door alle omstandigheden was dit qua tijd niet meer mogelijk. Bij deze wil ik Stephan Wong in het bijzonder bedanken voor zijn hulp bij problemen en vragen. Zonder hem was het project een stuk lastiger geweest. Ook zonder de hulp van Arjen van Genderen was het niet gelukt. Hij heeft voor ons de FPGA-bordjes en bijbehorende software geregeld.

85

Evaluatie van het netwerkgedeelte Het netwerkgedeelte was het stuk waar Tobias en ik aan hebben gewerkt. De eerste weken zijn we bezig geweest om ons in te lezen in de materie en met de ontwerpfase. Na de drie weken van de ontwerpfase zijn we begonnen met de implementatie. Dit viel niet mee, omdat er voor de netwerkcontroller geen IP-cores waren. In eerste instantie hebben we geprobeerd om zelf een interface voor de netwerkcontroller te schrijven, maar dit was te tijdrovend. Uiteindelijk hebben we na veel zoeken een interface op de site van Columbia University gevonden. Deze was echter niet heel duidelijk, omdat deze werd gebruikt als ondersteuning bij een practicum en voor ons moest het een hoofddoel worden. Nadat het netwerkgedeelte werkte, zijn we begonnen met het koppelen aan het audiogedeelte. Dit was behoorlijk tijdrovend, omdat beide gedeeltes gebruik maakte van interrupts. Uiteindelijk zijn we gekomen tot het huidig werkende product en de laatste week hebben we hard aan de verslagen moeten werken. Tijdens de implementatie fase heb ik veel geleerd over de Nios-processor. De aansturing van deze processor en benodigde componenten voor ons eindproduct. Wat me op viel is dat de software op de PC niet altijd op dezelfde manier werkte, iets wat behoorlijk tijdrovend kan zijn. Uiteindelijk zijn we, jammer genoeg, niet meer aan het SIP gedeelte toe gekomen. Dit was qua tijd niet meer mogelijk. Zeker niet, omdat ook het business plan nog afgemaakt moest worden. Tijdens het gehele eindproject is mij opgevallen, dat ondanks je hard werkt vanaf het begin van het project (in januari) je uiteindelijk toch altijd tijd te kort komt. Zelfs als je een planning maakt en je er aan houd, is het lastig om alles wat je wilt bereiken ook zover te krijgen. Er zijn altijd onvoorziene situaties die extra tijd kosten. Ik heb dan ook het meeste geleerd van het werken met een groep.

86

FPGA-ontwerp Audio-Netwerk voor VoIP-telefoon Prototype

Recommend Documents