Implementationen av sändaren gjordes i tre olika versioner anpassade för olika datatakter. Grundidén med de olika versionerna är att systemklockan på 100 MHz som FPGA:n och DA/AD-omvandlarna använder ska vara en jämn multi- pel av datatakten, 5x ger en datatakt på 20 Mbit/s och 10x ger 10 Mbit/s. Den tredje versionen av sändaren är anpassad för en systemklocka på 120 MHz och en datatakt på 30 Mbit/s vilket ger en multipel på 4x.
En systemklocka med godtycklig frekvens genererad av samma enhet som genererar indatan skulle även kunna användas med restriktionerna att denna klocka är en jämn multipel på 4x, 5x eller 10x av datatakten och givetvis att FPGA:n klarar av denna frekvens samt att respektive version av sändaren an- vänds. Alla tre versionerna har klarat en frekvens upp till 150 MHz enligt Quar- tus tidsanalysering.
Med tre olika versioner av sändaren kan upplösningen på de genererade I(t) och Q(t)-signalerna ökas vid låga datatakter då pulsformningsfiltret arbetar med fler koefficienter per databit. En annan möjlighet istället för att öka upp- lösningen är att använda 4x-versionen vid låga datatakter vilket innebär en lägre frekvens på systemklockan och det ger en minskad effektförbrukning.
En kompromiss mellan upplösning och energieffektivitet är 5x-versionen som kan användas i intervallet 0-30 Mbit/s.
Tab. 3.2 visar hur mycket av FPGA:ns resurser som de olika versionerna använder. Fig. 3.12 visar ett funktionsblockschema över hårdvaruimplementa- tionen av sändarmodellerna.
Resursutnyttjande
Modell Logiska element [st] Minne [bitar]
4x 1,734 212,992
5x 1,951 212,992
10x 2,705 212,992
Tabell 3.2: Resursutnyttjande för de olika sändarmodellerna.
3.2.2.1 Lysdioder Insignaler Utsignaler Namn Routning clk clkctrlglobal.outclk Namn Routning leds[3] PIN_AA7 leds[2] PIN_AA6 leds[1] PIN_AB4 leds[0] PIN_AC3
Tabell 3.3: I/O-beskrivning för Lysdioder.
Funktionen av detta block är att låta lysdioderna på testkoret rinna upp och ner. Detta gjordes för att se om designen som kortet programmerats med faktiskt kördes. Eftersom det inte finns något direkt sätt, utan att använda sig av externa instrument såsom ett oscilloskop, är det smidigaste sättet att se om designen körs av kortet. På grund av att systemklockan är för snabb att kunna direkt driva dioderna med, delas klockan ned (ca 5,000,000 ggr) för att förändingar i ljuset ska kunna uppfattas.
Detta block är implementerat i filen powerled.vhd.
3.2.2.2 Dataströmssynkroniserare Insignaler Namn Routning clk clkctrlglobal.outclk enable PIN_AE16 clksetin[2..0] clkset.clkset[2..0] datain datagen.dataout Utsignaler Namn Routning alpha[1..0] FIRXX.ast_sink_data[1..0] nforcelow Används Ej noeb Används Ej dataout Används Ej
Tabell 3.4: I/O-beskrivning för dataströmssynkroniserare.
Dataströmssynkroniserarblocket är till för att klocka in data till det efter- följande systemet enligt enable-signalen och med datatakten designen är gjord för. Den innefattar även funktionen att differentialkoda och mappa om indatan till alpha-pulser. Dessa kodningar görs i enighet med standarden [19]. Enable stänger av inklockningen till systemet, detta görs för att inte få en självsväng- ande indata på grund av att differentialkodaren är rekursiv med minne på två bitar. När enable går låg kommer utdatan från blocket att ligga låg.
Clkset-bussen sätts endast till statisk indata för att ställa in blocket på vil- ken datatakt som ska användas. Datain-signalen är dataströmmen som använ- daren vill modulera, d.v.s. informationen som kommer att skickas från sändaren.
Ut från blocket finns ett antal signaler som inte används i designen, p.g.a. att de endast används i felsökningssyfte och inte har någon funktion utöver att kontrollera signalvägarna.
Alpha-bussen är den kodade datan från blocket. Eftersom αi∈ {−1, 0, 1} är
utdatan från blocket representerad som en 2-bitars signerad signalbuss. Detta block är implementerat i blockschemat datastreamerblock.bdf och i filerna datastreamer.vhd, clkctrl.vhd & precoder.vhd.
3.2.2.3 Pulsformningsfilter Insignaler Namn Routning clk clkctrlglobal.outclk reset_n PIN_AE16 enable VCC ast_sink_data[1..0] datasteamerblock.alpha[1..0] ast_sink_valid VCC ast_sink_ready VCC ast_sink_error[1..0] GND Utsignaler Namn Routning ast_source_data[31..0] accumulator.data[31..0] ast_sink_ready Används Ej ast_source_valid Används Ej ast_source_error[1..0] Används Ej
Tabell 3.5: I/O-beskrivning för pulsformningsfilter.
Beroende på vilken version som används kommer pulsformningsfiltret att ha olika antal koefficienter. För 4x-versionen används 32 koefficienter, för 5x finns 40 koefficienter och i 10x-versionen är det 80 koefficienter.
Pulsformningsfiltret är ett linjärt FIR-filter och är ett av Alteras IP-block. Koefficienterna representeras som signerade fraktionstal med en upplösning på 31 fraktionsbitar (Q0.31 format). Koefficienterna är genererade i MATLAB och är samma som används i simuleringarna, dock med en liten modifikation. Ef- tersom upplösningen på fraktionsformatet Q0.31 är begränsat kommer ett litet avrundningsfel att introduceras, men eftersom utsignalen integreras i ackumu- latorn kommer felet att växa och måste därför kompenseras för. En manuell justering av koefficienterna har därför utförts så att summan av alla fraktions- koefficienter blir 1
2.
Filtrets funktion beskrivs genom ekv. 3.3 [7] där L är antal filterkoefficienter och x[n] är insignalen.
y[n] = x[n] ∗ f [n] =
L−1X k=0
f [k]x[n − k] (3.3)
Filtrets impulssvar, (fT G(t)), som ges av ekv. 2.16 finns illustrerat i fig. 2.13.
3.2.2.4 Ackumulator Insignaler Namn Routning clk clkctrlglobal.outclk reset_n PIN_AE16 dataI[31..0] FIRXX.ast_source_data[31..0] Utsignaler Namn Routning dataO[31..0] ncolut.phase_mod_i[31..0] Tabell 3.6: I/O-beskrivning för φ-ackumulator.
Blocket integrerar utsignalen från pulsformningsfiltret, se ekv. 2.14, och läg- ger även till en fasoffset, φ0= π4, för att anpassa sig med SOQPSK-TG [19].
Insignalen, dataI, till blocket är representerat av ett fraktionstal i tvåkom- plementform med 31 fraktionsbitar (Q0.31-format). Utdatan från blocket är ett fraktionstal i tvåkomplementform med en heltalsbit och 30 fraktionsbitar (Q1.30-format).
Detta block är implementerat i filen accumulator.vhd.
3.2.2.5 COS/SIN Uppslagstabell Insignaler Namn Routning clk clkctrlglobal.outclk reset_n PIN_AE16 phi_inc_i[31..0] Används Ej clken VCC phase_mod_i[31..0] accumulator.dataO[31..0] Utsignaler Namn Routning fsin_o[13..0] dacformat.sinI[13..0] fcos_o[13..0] dacformat.cosI[13..0] out_valid Används Ej
Tabell 3.7: I/O-beskrivning för COS/SIN Uppslagstabell.
Uppslagstabellen som används i modulatorn är ett IP-block från Altera. Den kan generera en sinusoidal-signal beroende på insignalen, phi_inc_i, med en godtycklig fas, phase_mod_i. Efter ackumulatorblocket beräknas signalerna
I(t) och Q(t) enligt ekv. 3.1 och ekv. 3.2. Resultatet av dessa beräkningar ges
sedan av utsignalen, fsin_o och fcos_o, som är kodade i ett 14-bitars tvåkom- plementsformat.
3.2.2.6 D/A-formaterare Insignaler Namn Routning clk clkctrlglobal.outclk sinI[13..0] ncolut.fsin_o[13..0] cosI[13..0] ncolut.fcos_o[13..0] Utsignaler Namn Routning
sinO[13..0] dffbuffer.data[13..0] (inst. 29) cosO[13..0] dffbuffer.data[13..0] (inst. 30) Tabell 3.8: I/O-beskrivning för D/A-formaterare.
D/A-formateraren omvandlar indatan i tvåkomplement, till ‘straight bina- ry’5. Detta görs för att D/A-omvandlaren endast tar emot data i detta formatet.
Detta block är implementerat i filen dacformat.vhd.
3.2.2.7 DFFbuffer (inst. 29) Insignaler Utsignaler Namn Routning clk clkctrlglobal.outclk data[13..0] dacformat.sinO[13..0] Namn Routning q[13] PIN_T25 q[12] PIN_V25 q[11] PIN_W26 q[10] PIN_W25 q[9] PIN_V24 q[8] PIN_Y24 q[7] PIN_P23 q[6] PIN_T23 q[5] PIN_B24 q[4] PIN_V21 q[3] PIN_V20 q[2] PIN_U20 q[1] PIN_M5 q[0] PIN_M4
Tabell 3.9: I/O-beskrivning för DFF-buffer (inst. 29).
DFF-Buffrarna används för att förbättra signalkvaliten från FPGA:n, ge- nom att buffra utdatan med snabba register, som är inställda till s.k. ‘Fast-IO’- utgångar i Quartus.
Detta block är genererat med hjälp av Alteras IP-block DFF.
5Ett binärt nummersystem där 00. . . 00 representerar det minsta möjliga talet och 11. . . 11
3.2.2.8 DFFbuffer (inst. 30) Insignaler Utsignaler Namn Routning clk clkctrlglobal.outclk data[13..0] dacformat.cosO[13..0] Namn Routning q[13] PIN_P6 q[12] PIN_R5 q[11] PIN_U7 q[10] PIN_P3 q[9] PIN_V6 q[8] PIN_V5 q[7] PIN_AA5 q[6] PIN_Y4 q[5] PIN_T2 q[4] PIN_U3 q[3] PIN_AD3 q[2] PIN_AE3 q[1] PIN_AA1 q[0] PIN_AB1
Tabell 3.10: I/O-beskrivning för DFF-buffer (inst. 30).
3.2.2.9 Funktionstest
För att verifiera sändarens funktion användes ett oscilloskop och Signal Tap för att spela in modulerad data. Inspelningarna gjordes när utvecklingskortens inbyggda oscillator på 100 MHz användes och sändarversionen anpassad för da- tatakten 5x systemklockan. Detta innebär att den inspelade modulerade datan har en takt på 20 Mbit/s.
Fig. 3.13 visar ett ögondiagram skapat med inspelad data från logikanalysa- torn. Inspelningen är gjord precis före DFF-buffrarna och indatan genererades med en pseudo-slumpgenerator. Fig. 3.14 visar motsvarande scatterplot för sam- ma inspelade sekvens.
Figur 3.13: Ögondiagram för hårdvarumodulatorn.
3.2.3
Blockfunktioner för mottagaren
Implementationen av mottagaren är anpassad för en systemklocka med en fre- kvens som är en 5x-multipel av datatakten. Detta innebär att mottagaren kom- mer att sampla tio värden per symbol. Med den inbyggda 100 MHz oscillatorn blir mottagaren anpassad för en datatakt på 20 Mbit/s och det är datatakten som har använts för verifiera mottagarens funktion samt för att spela in data med logikanalysatorn. Enligt Quartus tidsanalysering klarar mottagardesignen en systemklocka upp till 150 MHz vilket ger en datatakt på 30 Mbit/s. Prak- tiska tester med datatakt på 30 Mbit/s har dock inte kunnat utföras eftersom A/D-omvandlarna endast klarar 125 MSampels/s. Tab. 3.11 visar resursutnytt- jandet för mottagardesignen och fig. 3.15 visar ett funktionsblockschema över hårdvaruimplementationen av mottagaren.
Resursutnyttjande
Logiska element [st] Minne [bitar]
7,691 2,048
Tabell 3.11: Resursutnyttjande för mottagaren.
3.2.3.1 A/D-initiering Insignaler Utsignaler Namn Routning clk PIN_N2 Namn Routning adc_a_oe PIN_F7 adc_b_oe PIN_R2 adcreset PIN_T24
Tabell 3.12: I/O-beskrivning för A/D-initieraren.
För att A/D-omvandlaren i mottagaren ska fungera korrekt måste en ‘reset’- puls skickas till den. Detta gör A/D-initieringsblocket med lämplig fördröjning.
Detta block är implementerat i filen adc_init.vhd.
3.2.3.2 Kanalfördröjning Insignaler Utsignaler Namn Routning clk GlobalClkBuffer.outclk idata[13] PIN_A22 idata[12] PIN_C22 idata[11] PIN_B23 idata[10] PIN_A23 idata[9] PIN_A21 idata[8] PIN_B22 idata[7] PIN_D13 idata[6] PIN_B12 idata[5] PIN_C11 idata[4] PIN_A9 idata[3] PIN_A8 idata[2] PIN_B7 idata[1] PIN_C6 idata[0] PIN_C5 Namn Routning odata[13..0] MFBank.Idata[13..0]
Tabell 3.13: I/O-beskrivning för Kanalfördröjning.
Eftersom SOQPSK innefattar en fördröjning, 1Tb, på antingen I(t) eller
Q(t), fördröjs en av kanalerna i demodulatorn. Blocket fördröjer I[n] i fem
klockcykler så den är i synk med den inkommande Q[n]. Detta block är implementerat i filen ChannelDelay.vhd.
3.2.3.3 MF-bank Insignaler Namn Routning clk GlobalClkBuffer.outclk Idata[13..0] ChannelDelay.odata[13..0] Qdata[13] PIN_D20 Qdata[12] PIN_D21 Qdata[11] PIN_E20 Qdata[10] PIN_E18 Qdata[9] PIN_G18 Qdata[8] PIN_F18 Qdata[7] PIN_B21 Qdata[6] PIN_A20 Qdata[5] PIN_B20 Qdata[4] PIN_B19 Qdata[3] PIN_C19 Qdata[2] PIN_D18 Qdata[1] PIN_D17 Qdata[0] PIN_F17 Utsignaler Namn Routning
I_Filter1[13..0] convTCSB.dataI1[13..0] (inst. 5) I_Filter2[13..0] convTCSB.dataI2[13..0] (inst. 5) I_Filter3[13..0] convTCSB.dataI3[13..0] (inst. 5) I_Filter4[13..0] convTCSB.dataI4[13..0] (inst. 5) Q_Filter1[13..0] convTCSB.dataI1[13..0] (inst. 6) Q_Filter2[13..0] convTCSB.dataI2[13..0] (inst. 6) Q_Filter3[13..0] convTCSB.dataI3[13..0] (inst. 6) Q_Filter4[13..0] convTCSB.dataI4[13..0] (inst. 6)
Tabell 3.14: I/O-beskrivning för MF-Bank.
MF-banken innehåller två matchade FIR-korskorreleringsfilter för varje ka- nal med ett impulssvar enligt Medelvärdesfilter A och B i fig. 3.9. Indatan till filterna kommer direkt från A/D-omvandlarna och är i form av en 14-bitars tvåkomplementsbuss. Filterkoefficienterna är representerade med ett signerat 13-bitars fraktionstal (Q0.13 format). Utsignalen från filterna är en tvåkomple- menterad 14-bitarsbuss. Filternas funktion kan beskrivas med ekv. 3.3.
Detta block är implementerat i blockschemat MFbank.bdf och i filen FilterNegatives.vhd samt IP-blocket FIR Compiler.
3.2.3.4 Filternegativ (inst. 4)
Insignaler
Namn Routning
clk GlobalClkBuffer.outclk
Filter1[13..0] Filter1.ast_source_data[13..0] (inst. 0) Filter2[13..0] Filter2.ast_source_data[13..0] (inst. 1)
Utsignaler Namn Routning F1[13..0] convTCSB.dataI1[13..0] (inst. 5) F2[13..0] convTCSB.dataI2[13..0] (inst. 5) F3[13..0] convTCSB.dataI3[13..0] (inst. 5) F4[13..0] convTCSB.dataI4[13..0] (inst. 5)
Tabell 3.15: I/O-beskrivning för Filternegativ (inst. 4).
För att spara logiska element i mottagaren kan man halvera antalet filter som används i MF-banken. Detta kan man göra på grund av att hälften av filterna är de negativa motsvarigheterna till varandra (se fig. 3.9). Blocket används för att multiplicera korrelleringsresultaten från A och B-filterna (fig. 3.9) med −1 som bildar C och D-filterna.
Detta block är implementerat i filen FilterNegatives.vhd.
3.2.3.5 Filternegativ (inst. 5)
Insignaler
Namn Routning
clk clkctrlglobal.outclk
Filter1[13..0] Filter1.ast_source_data[13..0] (inst. 8) Filter2[13..0] Filter2.ast_source_data[13..0] (inst. 9)
Utsignaler Namn Routning F1[13..0] convTCSB.dataI1[13..0] (inst. 6) F2[13..0] convTCSB.dataI2[13..0] (inst. 6) F3[13..0] convTCSB.dataI3[13..0] (inst. 6) F4[13..0] convTCSB.dataI4[13..0] (inst. 6)
Tabell 3.16: I/O-beskrivning för Filternegativ (inst. 5).
3.2.3.6 Symbolsynkronisering
Insignaler
Namn Routning
clk GlobalClkBuffer.outclk
Syncfilter[13..0] convTCSB.dataU1[13..0] (inst. 5) Utsignaler Namn Routning Leds[3] PIN_E22 Leds[2] PIN_F20 Leds[1] PIN_B3 Leds[0] PIN_E5 vitdecclk MLSEClkBuffer.inclk
Tabell 3.17: I/O-beskrivning för Symbolsynkronisering.
Symbolsynkroniseringsblocket läser in utdatan från A-filtret i MF-banken. Blocket hittar toppvärden från MF-filtret och skapar en symbolklocka med sti- gande flank i samma ögonblick som nästa toppvärde infaller och en periodmul- tipel som rymms mellan två av toppvärdena. Eftersom symbolklockan = 1
10×
systemklockan genereras symbolklockan kontinuerligt efter det att det första
toppvärdet detekterats. Symbolklockan har en statisk fördröjning som gör att nästa stigande flank inträffar när nästa toppvärde från något av MF-filterna infaller, d.v.s. symbolklockan har en stigande flank när de matchade filternas impulssvar är synkroniserade med I(t) och Q(t).
Om ett toppvärde skulle förskjutas en eller flera klockcyckler fram eller bak p.g.a. klockdrift mellan mottagaren och sändaren kommer symbolklockan att förskjutas på liknande sätt.
Toppvärdena detekteras genom att kontrollera om signalen stiger under minst 6 eller mest 10 klockcyckler, sedan måste signalen minska under de efter- följande 10 klockcycklerna och då har ett toppvärde detekterats.
Beroende på hur insignalen ser ut så kommer dessa toppvärden inte att inträffa varje symbolperiod från MF-filter A, men symbolklockan fortsätter att genereras tills det detekteras ett nytt toppvärde. Som mest kan dessa toppvärden inträffa varannan symbolperiod för MF-filterna A och C.
3.2.3.7 Datakonvertering (inst. 5) Insignaler Namn Routning clk GlobalClkBuffer.outclk dataI1[13..] MFbank.I_Filter1[13..0] dataI2[13..] MFbank.I_Filter2[13..0] dataI3[13..] MFbank.I_Filter3[13..0] dataI4[13..] MFbank.I_Filter4[13..0] Utsignaler Namn Routning dataU1[13..0] SymbolSyncronizer.Syncfilter[13..0] dataU1[13..0] FourStateMLSE3.binA[13..0] (inst. 7) dataU2[13..0] FourStateMLSE3.binB[13..0] (inst. 7) dataU3[13..0] FourStateMLSE3.binC[13..0] (inst. 7) dataU4[13..0] FourStateMLSE3.binD[13..0] (inst. 7) Tabell 3.18: I/O-beskrivning för Datakonvertering (inst. 5).
Utsignalen från MF-banken är formaterad som en tvåkomplementsbuss. För att uträkningar och jämförelser mellan olika värden ska vara så enkel som möjlig omvandlas utdatan från MF-banken till ‘straight binary’. Detta görs i datakon- verteringblocket enligt ekv. 3.4.
y[n] = x[n] ⊕ 2bussbredd−1 (3.4)
Detta block är implementerat i filen convTCSB.vhd.
3.2.3.8 Datakonvertering (inst. 6) Insignaler Namn Routning clk GlobalClkBuffer.outclk dataI1[13..] MFbank.Q_Filter1[13..0] dataI2[13..] MFbank.Q_Filter2[13..0] dataI3[13..] MFbank.Q_Filter3[13..0] dataI4[13..] MFbank.Q_Filter4[13..0] Utsignaler Namn Routning
dataU1[13..0] FourStateMLSE3.binA[13..0] (inst. 8) dataU2[13..0] FourStateMLSE3.binB[13..0] (inst. 8) dataU3[13..0] FourStateMLSE3.binC[13..0] (inst. 8) dataU4[13..0] FourStateMLSE3.binD[13..0] (inst. 8) Tabell 3.19: I/O-beskrivning för Datakonvertering (inst. 6).
3.2.3.9 MLSE (inst. 7)
Insignaler
Namn Routning
MLSEclk MLSEClkBuffer.outclk
binA[13..0] convTCSB.dataU1[13..0] (inst. 5) binB[13..0] convTCSB.dataU2[13..0] (inst. 5) binC[13..0] convTCSB.dataU3[13..0] (inst. 5) binD[13..0] convTCSB.dataU4[13..0] (inst. 5)
Utsignaler
Namn Routning
state DifferentialDecoder.stateI
Tabell 3.20: I/O-beskrivning för MLSE (inst. 7).
För att förbättra prestandan i mottagaren har en MLSE-algoritm imple- menteras. Uppgiften är att leta upp vägen signalen ‘sannolikt’ har propagerat genom trellisträdet (se fig. 3.10). Den tar in information från MF-banken och utvärderar med tidigare värden den sparat. När den summerat ihop sannolikhe- terna för varje möjlig väg genom trellisträdet kan den utvärdera vilken av dessa som har störst sannolikhet att ha inträffat. MLSE:n sparar tre tidigare värden från MF-banken, vilket kan sägas är dess ‘djup’. Detta resulterar i totalt 24
möjliga signalvägar vars sannolikhet har uppskattats av MLSE-blocket. Djupet kan ändras, men antal möjliga signalvägar dubbleras för varje linjär ökning i djup och efter utvärderingar av olika djup i mottagaren är tre värden en bra avvägning.
Detta block är implementerat i filen FourStateMLSE3.vhd.
Detta blocket är utbytbart till andra mottagaralgoritmer. Utöver MLSE:n
som är implementerad finns ett ‘symbol-by-symbol’-mottagarblock i filen SymbolBySymbol.vhd. Se fig. 3.11 för en simulering av prestandaskillnaden mellan typerna.
3.2.3.10 MLSE (inst. 6)
Insignaler
Namn Routning
MLSEclk MLSEClkBuffer.outclk
binA[13..0] convTCSB.dataU1[13..0] (inst. 6) binB[13..0] convTCSB.dataU2[13..0] (inst. 6) binC[13..0] convTCSB.dataU3[13..0] (inst. 6) binD[13..0] convTCSB.dataU4[13..0] (inst. 6)
Utsignaler
Namn Routning
state DifferentialDecoder.stateQ
Tabell 3.21: I/O-beskrivning för MLSE (inst. 6).
3.2.3.11 Differentialavkodare
Insignaler
Namn Routning
MLSEclk MLSEClkBuffer.outclk
stateI FourStateMLSE3.state (inst. 7) stateQ FourStateMLSE3.state (inst. 8)
Utsignaler
Namn Routning
decDataA doubleBuffer.decDataA decDataB doubleBuffer.decDataB
Tabell 3.22: I/O-beskrivning för Differentialavkodare.
Efter MLSE:n har maximerat sannolikheten för en signalväg måste diffi- rentialavkodaren avkoda de inspelade tillstånden. Diffirentialavkodaren lägger ihop utdatan från MLSE:n enligt formen; ({I[n] : Q[n − 1]}, {I[n] : Q[n]}), vil- ket resulterar i ett par tillstånd. Anledningen till att ihopsättningen sker enligt formeln ovan är på grund av fördröjningen på en av data-kanalerna, d.v.s. off- seten i modulationen. Efter att tillstånden är funna avkodas den faktiska datan från skillanden mellan tillstånden, d.v.s. om förra tillståndet inte ändrats så är avkodningen ‘02’, annars ‘12’.
Varje symbolklockcykel genererars ett par tillstånd (som ovan) vilket gör att två bitar avkodas parallellt (decDataA & decDataB).
Detta block är implementerat i filen DifferentialDecoder.vhd.
3.2.3.12 Dubbelbuffer Insignaler Utsignaler Namn Routning clk GlobalClkBuffer.outclk MLSEclk MLSEClkBuffer.outclk decDataA DifferentialDecoder.decDataA decDataB DifferentialDecoder.decDataB Namn Routning dataOut <Utdata>
Tabell 3.23: I/O-beskrivning för Dubbelbuffer.
Diffenrentialavkodaren ger två parallella databitar p.g.a. att varje konstella- tionspunkt motsvarar två bitar. Dessa måste sättas ihop till en seriell dataström för att kunna matas vidare från demodulatorn. I mottagaren används en dub- belbuffer för att synkronisera inklockningen med symbolklockan, och för att konvertera den parallella datan till en seriell dataström.
Datan klockas först in i buffer-A (en av buffrarna i blocket) med den synkro- niserade symbolklockan. När buffern är full kommer blocket att börja fylla upp buffer-B (andra buffern i blocket), samtidigt som datan klockas ut från buffer-A med systemklockan o.s.v.
3.2.3.13 Funktionstest
Fig. 3.16 och fig. 3.17 visar bilder över ett ögondiagram och en ‘scatter’-plot re- spektive. Datan som figurerna är skapade med är inspelad data från mottagaren efter A/D-omvandlarna. Demodulatorn kan avkoda signalerna (med antingen MLSE eller ‘symbol-by-symbol’-blocket) felfritt även fast insignalen till motta- garen är mycket dämpad relativt den skickade. Tester med olika datalängder och slumpmässing information har gjorts och verifierat mottagarens integritet. Dock ska det noteras att datasekvenser med många efterföljande ‘02’:er kom-
mer resultera i bitfel, anledningen till detta och varför signalen har deformerats i mottagaren disskuteras mer ingående i Kap. 4.
Figur 3.16: Ögondiagram för hårdvarudemodulatorn.
Kapitel 4
Analys & Diskussion
Utvärderingar av de slutgiltiga designerna, både mottagaren och sändaren, visar på att de stämmer bra överrens med informationen som finns tillgänglig om SOQPSK-TG.
De två huvudmålen har varit att skapa och implementera algoritmer för mo- dulation samt demodulation av SOQPSK-TG-signaler. Dock har delmålet att implementera en EQ i mottagaren inte gjorts p.g.a. tidsbrist. För att genomfö- ra delmålet skulle mer tid behövts för en tillräckligt noggrann implementation. För att kunna testa och utvärdera EQ:n skulle en verklighetstrogen kommuni- kationskanal behövts skapats som kan simulera effekten av flervägsutbredning, vilket det inte fanns tillräckligt med tid för.
Förstudien till projektet har varit en viktigt del. Det har varit svårt att få tag på relevant information angående modulationen men en lagom samling doku- ment har ackumulerats och bildat en god bas för kunskap. Många av artiklarna och papperna är hämtade från IEEE. Alla dokument som användts är i en teore- tisk inriktining vilket gjort att de resultat som funnits endast varit simulerade. Referenser med verkliga resultat att verifiera projektets resultat med hade va- rit positivt. Bristen på referenser kring implementationer har även påverkat att mycket som utvecklats har vuxit fram ur ‘trial-and-error’ eller ändrats under projektets gång beroende på vad som fungerat i den faktiska hårdvaruimple- mentationen.
I början av implementationsfasen togs det fram en MATLAB-modell över både mottagaren och sändaren. Några olika tekniker testades tills designen var färdigställd och till viss del omgjord så de skulle vara lätta att översätta till realtidsimplementationer i hårdvara. Det underlättade implementationen, men hårdvarudesignen har förändrats mycket under projektets gång. MATLAB- modellerna har varit en konstant referenspunkt att jämföra resultat mot.
För att utvärdera implementationerna finns det några nyckelgrafer att se på:
Ögondiagram visar alla möjliga symbolkombinationer överlagrade under en begränsad tid. Det finns mycket karakteristik för överföringen att läsa i detta diagramet.
Spektraltäthet visar hur signalen breder ut sig i frekvensplanet och vilken bandbredd den ockuperar vid en viss effektnivå.
Bitfelssannolikhet visar hur stor sannolikhet det är för ett visst antal bitfel vid en given SNR-nivå.
I fig. 3.6 visas ögondiagrammet för den simulerade modulatorns utsignal, vil- ken stämmer bra överens med [17]. Även ögondiagram i fig. 3.13 som är uppritad av data från den implementerade hårdvarumodulatorn visar på bra överensstä- melse med referensinformation.
Fig. 3.4 visar spektraltätheten för den simulerade modulatorn. Spektraltät- heten bör vara så smal som möjligt så sändingen inte förstör för kringliggande frekvensband. Detta är en av SOQPSK-TG:s styrkor och spektraltätheten är smal jämfört med andra modulationer. I [20] visas spektraltäthetskurvor för SOQPSK-TG som kan jämföras med resultat i denna rapport.
Förmodligen är bitfelssannolikhetskarakteristiken, fig. 3.11, en av de vikti- gaste egenskaperna. Denna kurvan är med fördel skarpt lutande neråt då bit- felssannolikheten minskar snabbare. Dessvärre finns endast en simulerad bitfels- sannolikhetskurva tillgänglig från MATLAB-mottagaren eftersom det inte fanns möjlighet att skapa en för hårdvarumottagaren. Dessa kurvor kan jämföras med kurvor tillgängliga i [8] [11]. En tumregel är att utvärdera modulationsteknikens SNR-nivå vid bitfelssannolikheten Pb = 10−5.
Mjukvaran som använts i projektet har uteslutande varit MATLAB och Quartus. MATLAB har använts för att skapa simuleringsmodellen nämnd ti- digare, men även för att behandla stora datamängder som är inspelade från hårdvaruimplementationen. Datasekvenser som spelats in från hårdvaran spa- ras binärt i CSV-format och gör det svårt att hitta avvikelser eller få en överblick över fångad data. Detta gör MATLAB till ett utmärkt val att läsa in, manipulera och presentera datan och mycket kan effektiviseras m.h.a. skriptningsmöjlighe- terna.
Quartus från Altera är programvaran som använts för att skapa designerna till utvecklingskorten och även simulera dem. Simuleringsmiljön i Quartus är till skillnad från andra HDL-utvecklingsverktyg uppbyggd på att man skapar signalvågorna till blocken man simulerar. Många HDL-miljöer har endast möj- lighet att simulera block efter man skapat en ‘testbänk’ att simulera genom, vilket kan vara mycket tidsödande vid mindre simuleringar.
Quartus har även ett omfattande bibliotek med IP-block vilket förenklat