Kombinerad DSP- och FPGA-lösning för en bildbehandlingsapplikation

.RPELQHUDG'63RFK)3*$O|VQLQJI|UHQ

ELOGEHKDQGOLQJVDSSOLNDWLRQ

Examensarbete utfört i elektroniksystem av

Marcus Mikaelsson

LiTH-ISY-EX-3231-2002

24 maj 2002

.RPELQHUDG'63RFK)3*$O|VQLQJI|UHQ

ELOGEHKDQGOLQJVDSSOLNDWLRQ

Examensarbete utfört i elektroniksystem vid Linköpings tekniska

högskola av

Marcus Mikaelsson

Reg nr: LiTH-ISY-EX-3231-2002

Handledare: Lars Asplund

Examinator: Kent Palmkvist

Avdelning, Institution Division, Department Institutionen för Systemteknik 581 83 LINKÖPING Datum Date 2002-04-24 Språk

Language Rapporttyp Report category ISBN X Svenska/Swedish

Engelska/English Licentiatavhandling X Examensarbete ISRN LITH-ISY-EX-3231-2002

C-uppsats

D-uppsats Serietitel och serienummer _{Title of series, numbering} ISSN

Övrig rapport

____

URL för elektronisk version

http://www.ep.liu.se/exjobb/isy/2002/3231/

Titel

Title Kombinerad DSP- och FPGA-lösning för en bildbehandlingsapplikation Combined DSP and FPGA solution for an imaging application

Författare

Author Marcus Mikaelsson

Sammanfattning

Abstract

This Master's Thesis describes the design of a new system where a digital signal processor has been added to an existing imaging system consisting of field programmable gate arrays. The new system will offer a higher degree of flexibility by considerably shortening the design time and make it possible to implement more complex algorithms than the existing ones.

The choice of system architecture and a test implementation are discussed. The test

implementation consists of a program for the digital signal processor and VHDL code for one of the field programmable gate arrays.

The code for the digital signal processor was designed for testing on an evaluation board from Texas Instruments. The evaluation board is connected to a computer, which runs a Windows program to visualize the result.

The choice of algorithm has not been made yet. In the test implementation a skewing algorithm is used as an example. Two implementations of the skewing algorithm has been optimized, one fix point version and one floating point version.

Nyckelord

Keyword

v Kombinerad DSP- och FPGA-lösning för en bildbehandlingsapplikation

S

AMMANFATTNING

Syftet med examensarbetet är att utgående från ett befintligt system för bildbehandling, som använder FPGAer, ta fram ett nytt system som utöver de befintliga FPGAerna även består av en digital signalprocessor. Bakgrunden är att ökad flexibilitet önskas för fram-tida implementeringar av algoritmer som ännu inte är helt fastställda.

Examensarbetet behandlar de arkitekturval som har gjorts för systemet samt en testim-plementering. Testimplementeringen består dels av ett program för DSPn och dels VHDL-kod för en av FPGAerna.

För att testa implementeringen så har programmet för DSPn anpassats så att de går att köra på ett utvecklingskort från Texas Instruments. Utvecklingskortet är anslutet till en dator som kör ett Windowsprogram som har utvecklats för att visualisera resultatet. Eftersom det inte finns någon algoritm som säkert ska användas så har en skevningsalgo-ritm implementerats. Den här skevningsalgoskevningsalgo-ritmen har optimerats för DSPn i en flyttal-sversion och en fixtalflyttal-sversion.

vii Kombinerad DSP- och FPGA-lösning för en bildbehandlingsapplikation

I

NNEHÅLLSFÖRTECKNING

KAPITEL

1.

I

NLEDNING

1

1.1 Projektbakgrund . . . 1

1.1.1 Beskrivning av det befintliga systemet . . . 1

1.1.2 Befintliga systemet på FPGA-nivå . . . 2

1.2 Begränsad flexibilitet i det befintliga systemet . . . 3

1.3 Problemställning . . . 3 1.4 Examensarbetets upplägg. . . 4 1.5 Rapportens upplägg . . . 5

KAPITEL

2.

DSP-

INTRODUKTION

7

2.1 Funktionsbeskrivning. . . 7 2.1.1 Processorkärnan (CPU) . . . 7 2.1.2 Minnesarkitektur . . . 8 2.1.3 EMIF . . . 9 2.1.4 HPI . . . 9 2.1.5 McBSP . . . 9 2.1.6 Avbrottsgenerering . . . 10 2.1.7 EDMA . . . 10 2.2 Utvecklingsmiljö . . . 11

KAPITEL

3.

FPGA-

INTRODUKTION

13

3.1 Funktionsbeskrivning. . . 13

3.1.1 Configurable Logic Block . . . 13

3.1.2 Input/Output Block . . . 14

3.1.4 Delay-Locked Loop . . . 15

3.2 Utvecklingsmiljö . . . 15

KAPITEL

4.

I

MPLEMENTERING

17

4.1 Krav på systemet . . . 17

4.2 Att starta exekvering av program i DSPn . . . 17

4.3 Val av systemarkitektur. . . 18

4.4 Ytterligare idéer. . . 19

4.5 Val av minnesstandard på EMIF . . . 19

4.5.1 Asynkrona minnen . . . 20

4.5.2 SBSRAM . . . 21

4.5.3 SDRAM . . . 22

4.5.4 Slutsats . . . 22

4.6 Minnesrymd och kommadon. . . 23

KAPITEL

5.

DSP-

IMPLEMENTERINGEN

25

5.1 Uppdelning av internminnet . . . 25

5.2 Skevningsalgoritmen . . . 26

5.3 Tillståndsgraf för buffring och beräkning . . . 27

5.4 Uppdelning av algoritmen i block . . . 30

5.5 Dataflyttning . . . 31

5.6 EDMA-programmering . . . 33

5.7 Inget operativsystem . . . 34

Innehållsförteckning

Kombinerad DSP- och FPGA-lösning för en bildbehandlingsapplikation ix

KAPITEL

6.

FPGA-

IMPLEMENTERINGEN

37

6.1 Blocknivå . . . 37 6.1.1 Datablock . . . 38 6.1.2 Adressblock . . . 38 6.1.3 RAM-block . . . 38 6.1.4 Kommandoblock . . . 38 6.1.5 Kommandokontroller . . . 38 6.1.6 Dataflyttaren . . . 39 6.2 Modifieringar . . . 39

6.3 Simulering och verifiering . . . 39

6.4 Prestanda . . . 40

KAPITEL

7.

O

PTIMERINGAR

41

7.1 Mjukvaru-pipelining . . . 41 7.2 Loop unrolling . . . 41 7.3 Förutsättningar . . . 41 7.4 Flyttalsversioner. . . 42 7.4.1 Flyttalsversion 1 . . . 42 7.4.2 Flyttalsversion 2 . . . 43 7.4.3 Flyttalsversion 3 . . . 44 7.4.4 Flyttalsversion 4 . . . 44 7.4.5 Flyttalsversion 5 . . . 45 7.5 Fixtalsversioner . . . 45 7.5.1 Fixtalsversion 1 . . . 45 7.5.2 Fixtalsversion 2 . . . 46 7.5.3 Fixtalsversion 3 . . . 46 7.6 Resultat . . . 48

KAPITEL

8.

G

RAFISKA GRÄNSSNITT

49

8.1 Gränssnitt för test av kommunikation . . . 49

8.2 Gränssnitt för hela systemet . . . 50

KAPITEL

9.

R

ESULTAT

51

R

EFERENSLISTA

53

BILAGA

A.

F

ÖRKORTNINGSLISTA

55

BILAGA

B.

O

PTIMERINGSRESULTAT

57

B.1 Flyttalsversion 1 . . . 57 B.2 Flyttalsversion 2 . . . 58 B.3 Flyttalsversion 3 . . . 58 B.4 Flyttalsversion 4 . . . 59 B.5 Flyttalsversion 5 . . . 60 B.6 Fixtalsversion 1 . . . 60 B.7 Fixtalsversion 2 . . . 61 B.8 Fixtalsversion 3 fall 1 . . . 61 B.9 Fixtalsversion 3 Fall 2 . . . 62

xi Kombinerad DSP- och FPGA-lösning för en bildbehandlingsapplikation

F

IGURFÖRTECKNING

Figur 1.1: Befintliga systemet på kortnivå ...2

Figur 1.2: Befintliga systemet på FPGA-nivå. ...3

Figur 2.1: DSPns arkitektur...7

Figur 2.2: Parameterstruktur för EDMA ...10

Figur 2.3: Exempel på dataflyttning med EDMA ...11

Figur 3.1: Översikt av FPGA-arkitektur ...13

Figur 3.2: Blockbeskrivning av en slice...14

Figur 3.3: Delay-Locked Loop...15

Figur 4.1: Systemförslag ...18

Figur 4.2: Asynkron läsning...20

Figur 4.3: Asynkron skrivning ...20

Figur 4.4: SBSRAM-läsning ...22

Figur 4.5: SBSRAM-skrivning ...22

Figur 4.6: Kommandostruktur för att styra FPGA-buffertarna ....23

Figur 4.7: Minnesrymd i FPGA ...24

Figur 5.1: Dataflöde och buffertar i systemet ...25

Figur 5.2: Obehandlad och skevad bild...26

Figur 5.3: Visualisering av två-punkters faltning...27

Figur 5.4: Obehandlad och önskad bild samt delningsfaktorerna 27 Figur 5.5: Blockstrolek och iterering av blocken i bilden...28

Figur 5.6: Tillståndsgraf för buffring ...28

Figur 5.7: Förklaring av symbolerna i tillståndsgrafen ...29

Figur 5.8: Tillståndsgrafen applicerad på 2x4 data ...30

Figur 5.9: Beräkningsordning för datablock ...31

Figur 5.10: Dataflöde mellan DSPn och FPGAerna ...32

Figur 5.11: Exempel på multipel tilldelning ...33

Figur 5.12: Kedjningen av EDMA-kanalerna ...34

Figur 5.13: Förklaring av symbolerna som finns i figur 5.11 ...34

Figur 6.1: FPGA-implementering på blocknivå...37

Figur 6.2: Flödesschema för registerkontrollern ...39

Figur 7.1: Mjukvaru-pipelining...41

Figur 7.2: Kodstruktur för skevningsalgoritmen...42

Figur 7.3: Variabler och kod för flyttalsversion 1...42

Figur 7.4: Kompilatorns schemaläggning av flyttalsversion 1 ....43

Figur 7.5: Ändring av variabeltyper för flyttalsversion 2 ...43

Figur 7.6: Variabler och kod för flyttalversion 3 ...44

Figur 7.7: Variabler och kod för flyttalsversion 4...44

Figur 7.8: Kod för flyttalsversion 5...45

Figur 7.9: Variabler för fixtalsversionerna...45

Figur 7.10: Kod för fixtalsversion 1...45

Figur 7.12: Variabler för fixtalsversion 3 ... 46

Figur 7.13: Två fall som kan inträffa vid behandling av data ... 46

Figur 7.14: Kod för fixtalsversion 3 fall 1 ... 47

Figur 7.15: Kod för fixtalsversion 3 fall 2 ... 47

Figur 7.16: Alternativ kod för fixtalsversion 3 fall 2... 48

Figur 8.1: Testprogram för kommunikation med DSPn ... 49

1 Kombinerad DSP- och FPGA-lösning för en bildbehandlingsapplikation

K

APITEL

1

1

I

NLEDNING

Det här kapitlet ger bakgrunden och problemställningen för exa-mensarbetet som har utförts vid Enea Epact AB i Linköping under höstterminen 2001.

1.1 Projektbakgrund

Enea Epact har utvecklat en bildbehandlingsapplikation åt en kund. Detta examensarbete behandlar en tänkbar vidarutveckling av en del av det här systemet. Vilket företag som är kund och vad hela systemet gör är i nuläget hemligt.

1.1.1 Beskrivning av det befintliga systemet

I rapporten så avses med system bara den del av hela systemet som jag har tittat på. Sys-temet får in data via 28 seriella kanaler. Läsning av resultatet och kontrollflödet mellan delsystem och värddator sker via en buss. Den totala bandbredden för de seriella kana-lerna är 2 Gbps.

Systemet har en realtidsdel och en efterbehandlingsdel. Realtidsdelen parallelliserar och skriver data till minnet efter en databehandling. När realtidsdelen är avklarad utförs efter-behandlingsdelen på det som nu är bilddata.

Systemet består främst av FPGAer (Field Programmable Gate Array) och minneskapslar. De FPGAer som används i systemet presenteras i ett eget kapitel. På nästa sida finns en förenklad figur av hur systemet ser ut på kortnivå.

För kommunikation med en värddator använder systemet en VME-buss (Versa Module Eurocard). VME-standarden började utvecklas 1980, men har genomgått många revi-sioner sedan dess. VME-bussens signaler är asynkrona och i systemet används 32 bitar för data. Standarden stödjer även 8, 16 och 64 bitar. Mer information om VME, se [32]. På kortet finns det tre FPGAer som benämns FPGA1, FPGA2 och VME-FPGA. Varje FPGA har 2 stycken 64 bitar breda minnesbussar med 4 stycken 256 Mbit minneskapslar per buss. Totalt finns det alltså 16 stycken minneskapslar på kortet vilket ger 512 Mbyte. Den stora mängden minne finns för att ge flexibilitet samt för att kunna spara undan obearbetad bilddata vid felsökning och justeringen av bildbehandlingsparametrar.

VME-FPGAn konfigureras från ett PROM vid start. När VME-FPGAn är konfigurerad så kan resten av systemet konfigureras via VME-bussen. VME-FPGAn är master på lokalbussen som har tidsmultiplexad data och adress. FPGA1 och FPGA2 har en egen buss som används för att kunna dela bilddata mellan FPGAerna.

Figur 1.1: Befintliga systemet på kortnivå

1.1.2 Befintliga systemet på FPGA-nivå

VME-FPGAn består i stora drag av en brygga mellan VME-bussen och lokalbussen. För-utom bryggan så finns det bland annat konfigureringsdelen för de andra FPGAerna. FPGA1 och FPGA2 har samma konfigureringsfil. Det som avgör vilken FPGA som blir 1 och vilken som blir 2 är en insignal. På kretskortet så är den här signalen ansluten till jord på den ena FPGAn och till 3,3 volt på den andra FPGAn.

I figuren på nästa sida finns de största blocken i FPGA1 och FPGA2 uppräknade. Intern-bussen som ansluter de flesta blocken är 128 bitar bred. Lokalbusskontrollern bestämmer vilket block som för tillfället är master på internbussen. All styrning sker via lokalbussen och olika block startas med skrivningar i register som finns i FPGAns adressrymd. FPGAn och den seriella länken klockas inte med samma klocka. Därför används två-portsminnen som klockas med systemklockan på läsporten och med samma klocka som den seriella länken på skrivporten. Parallelliseringen sker i tvåportsminnena genom att använda en en bit bred skrivport och en 16 bitars bred läsport.

Realtidsbehandlingen matas med 12 bitar bred data som behandlas och sedan skrivs till minnet via SDRAM-kontrollern.

/2.$/%866

)3*$%866













)3*$

90(

)3*$

)3*$

6'

5$

0

6'

5$

0

6'

5$

0

6'

5$

0

90(%866

6(5,(//'$7$

6(5,(//'$7$

Inledning

Kombinerad DSP- och FPGA-lösning för en bildbehandlingsapplikation 3

Figur 1.2: Befintliga systemet på FPGA-nivå.

1.2 Begränsad flexibilitet i det befintliga system

Det befintliga systemet är helt baserat på FPGAer och utvecklat med hjälp av VHDL, ett hårdvarubeskrivande språk.

Vilka efterbehandlingsalgoritmer som ska användas är inte helt fastställt. Kunden önskar därför att de själva ska kunna utföra utvärdering och implementering av efterbehand-lingsalgoritmerna. De vill ha större flexibilitet i systemet för utvärdering och senare även för uppgraderingar.

Kunden som utvecklar mjukvaran till systemet är därför intresserade av en vidareutveck-ling där en DSP (digital signalprocessor) används för efterbehandvidareutveck-lingsalgoritmerna. En DSP ger kortare utvecklingstid och framför allt så kan de programmeras med C/C++, en utvecklingsmiljö som kunden behärskar.

1.3 Problemställning

Med utgångspunkt från det befintliga systemet ska en ny systemarkitektur som innefattar en DSP tas fram. För både DSPn och FPGAerna ska grundläggande implementeringar göras som kan användas som utgångspunkt för eventuella framtida versioner av systemet.







5HDOWLGV

EHKDQGOLQJ

7YnSRUWV

PLQQH

(IWHU

EHKDQGOLQJ

_NRQWUROOHU

6'5$0

/RNDOEXVV

NRQWUROOHU

'HOQLQJ

DYGDWD

/RNDOEXVV

)3*$EXVV

,QWHUQEXVV

6HULHOOGDWD

Förutsättningarna är att efterbehandlingsdelen ska utföras i DSPn istället för i FPGAerna, att försöka behålla samma kapslar på FPGAerna och att DSPn ska gå att programmera och gärna felsöka via systemet.

Implementeringen för FPGA1 och FPGA2 ska vara av sådan art att den lätt kan användas i systemet genom att byta efterbehandlingsdelen mot ett nytt block.

Implementeringen i DSPn ska vara någorlunda generell så att det går att byta algoritm utan allt för mycket modifieringar. Den algoritm som ska implementeras är en tvåpunk-ters faltning som skevar bilden. Examensarbetet inriktar sig enbart på implementeringen och inte på val av algoritm.

Eftersom det finns en utvecklingsmiljö för Texas Instruments TMS320C6000-serie och ett utvecklingskort med en TMS320C6711 DSP, så ska systemet modifieras med utgångspunkten att den processorn ska användas.

Texas Instruments är den största DSP-tillvekaren och ligger i framkanten när det gäller utvecklingen av DSPer. Om beräkningskraften inte skulle räcka till finns det kraftfullare DSPer som TMS320C6400 att tillgå.

1.4 Examensarbetets upplägg

När jag började med examensarbetet hade jag inga tidigare erfarenheter av att använda DSPer. Därför så ägnade jag den första tiden åt att lära mig mer om DSPer i allmänhet och om utvecklingsmiljön med tillhörande utvecklingskort som finns tillgänglig på Enea Epact.

Utvecklingskortet ansluts till en dator och det finns två sätt att kommunicera med DSP från egna program. För att prova de två sätten skrevs några testprogram. Program skrevs även för att komma fram till en enkel implementering av algoritmen, för att användas som grund för DSP-versionen och även som referens för andra implementeringar av algoritmen.

Efter att ha studerat de kommunikationsmöjligheter som finns på DSPn och det befint-liga systemets arkitektur så togs olika alternativ till ny systemarkitektur fram. Förslagen rangordnades med avseende på för- och nackdelar.

När valet av systemarkitektur var gjort så påbörjades den övergripande implemen-teringen. Vilken minnesstandard ska simuleras av FPGAn? Behövs det buffertar? Hur ska buffertarna kontrolleras?

Sedan gjordes en implementering av DSP-delen på utvecklingskortet. För att testa imple-menteringen skapades ett program som laddar ned bilddata och program till DSPn. Efter nedladdningen startas programmet och resultatet kan läsas tillbaka för visualisering på datorn.

Slutligen så implementerades den delen som ska sitta i FPGAn. Implementeringen testades genom simulering på datorn med en testbänk.

Inledning

Kombinerad DSP- och FPGA-lösning för en bildbehandlingsapplikation 5

1.5 Rapportens upplägg

När jag har valt den tekniska nivån på rapporten så har jag förutsatt att läsaren har mot-svarande förkunskaper som jag hade innan jag började med examensarbetet. Framför allt så bör läsaren vara bekant med vad programmerbar logik är, och stegen från idé till programmerad krets, då detta till stora delar är helt utelämnat i rapporten.

Jag har försökt få helheten att framgå i rapporten i stället för att beskriva enskilda detal-jer.

I kapitel 2 och 3 introduceras den DSP-familj och FPGA-familj som har använts. Kapitel 4 behandlar implementeringen på systemnivå medans kapitel 5 och 6 tar upp implemen-teringen i DSPn och i FPGAn.

Optimering av efterbehandlingsalgoritmen tas upp i kapitel 7. Kapitel 8 visar de program som har skrivits för test, och för att visualisera efterbehandlingsresultatet från DSPn. Slutligen så sammafattas resultaten i kapitel 9.

7 Kombinerad DSP- och FPGA-lösning för en bildbehandlingsapplikation

K

APITEL

2

2

DSP-

INTRODUKTION

I det här kapitlet introduceras den DSP som har använts. DSPn kommer från Texas Instruments TMS320C6000 serie och har beteckningen TMS320C6711.

2.1 Funktionsbeskrivning

Figuren nedan visar funktionsblocken och själva processorkärnan i DSPn. Figuren är en förenklad form av motsvarande figur i [7]. För mer information än den som finns i det här kapitlet så rekommenderas “Peripherals Reference Guide” [9] som behandlar minnesarkitekturen och allt annat som inte är processorkärnan.

En alternativ källa för att snabbt få en uppfattning om processorn är två jämförelser [30] och [31] som Analog Devices har gjort mellan två av sina egna DSPer (21160 och 21161) mot TMS320C6000 serien.

Figur 2.1: DSPns arkitektur

2.1.1 Processorkärnan (CPU)

CPUn har två delar, A och B. Varje del har 16 stycken 32 bitars register och fyra olika funktionsenheter. Funktionsenheterna kan använda alla register inom sin del, men har begränsad åtkomst till registerna i den andra delen.

/ 60' '06 /

$5HJLVWHU)LOH %5HJLVWHU)LOH

'DWD3DWK$

'DWD3DWK%

,QVWUXFWLRQ'HFRGH

,QVWUXFWLRQ'LVSDWFK

,QVWUXFWLRQ)HWFK

,QWHUUXSW &RQWURO ,Q&LUFXLW (PXODWLRQ 7HVW &RQWURO 5HJLVWHUV &RQWURO /RJLF ([WHUQDO 0HPRU\ ,QWHUIDFH (0,) 7LPHU  0XOWLFKDQQHO %XIIHUHG 6HULDO3RUW  0F%63 +RVW3RUW ,QWHUIDFH +3, ,QWHUUXSW 6HOHFWRU

/HYHO3URJUDP&DFKH.E\WHV

/HYHO'DWD&DFKH.E\WHV

/H

YH

O

0

HP

RU

\



.E

\W

HV

(Q

KD

QF

HG

'

0

$

&

RQ

WUR

OOH

U

& &38'63&RUH

7 0 3// [[ 3RZHU'RZQ/RJLF &RQILJXUDWLRQ%RRW

Totalt finns det alltså 8 funktionsenheter och instruktionerna till dessa grupperas i instruktionspaket. Ett instruktionspaket har variabel längd beroende på hur många funk-tionsenheter som ska användas under en viss klockcykel. Även om instruktionspaketen är av olika längd så hämtar CPUn alltid instruktionsdata från programcachen med 256 bitar i taget.

I tabell 2.1 visas vilka operationer som går att utföra i de olika funktionsenheterna för fixtal respektive flyttal. SP, DP och INT står för enkel precision, dubbel precision samt heltal i tabellen som är en förenklad version av tabell 2-2 i [8]. DSPn som har använts kan hantera flyttal och fixtal och kan utföra operationer från båda kolumnerna.

TMS320C64x har endast fixtal, men kan utföra ytterligare operationer på fixtal. Ett exempel är ADD4 som tar två register som indata och utför en addition på varje byte i ett ord. Dessa finns inte med i tabellen.

Tabell 2.1: Funktionsenheternas operationer

2.1.2 Minnesarkitektur

Det finns två stycken nivå ett cacheminnen, ett för program och ett för data. Båda är 4 Kbyte stora, men de har olika uppbyggnad och databredd mot CPUn och internminnet. Programcachen har 256 bitars bredd mot internminnet jämfört med datacachen som har 64 bitar.

Internminnet består av 4 banker som är 64 bitar breda. Bankerna ger tillsammans 64 Kbyte minne. Internminnet kan antingen användas som ett nivå två cacheminne, eller som ett vanligt minne. Det går att välja hur stor del som ska utgöra cacheminne, från inget till allt i steg om 16 Kbyte.

Functional Unit Fixed-Point Operations Floating-Point Operations .L1 and .L2 32/40-bit arithmetic and compare operations.

32-bit logical operations.

Leftmost 1 or 0 counting for 32 bits. Normalization Count for 32 and 40 bits.

Arithmetic operations. DP --> S P, INT --> DP , INT --> SP conversion operations.

.S1 and .S2 32-bit arithmetic operations.

32/40-bit shifts and 32-bit bit-field operations. 32-bit logical operations.

Branches.

Constant generation.

Register transfers to/from control register file (.S2 only).

Compare.

Reciprocal and reciprocal square-root operations. Absolute value operations. SP--> DP conversion operations.

.M1 and .M2 16x16 multiply operations. 32x32-bit fixed-point multiply operations. Floating-point multiply operations.

.D1 and .D2 32-bit add, subtract, linear and circular address calculation.

Loads and stores with 5-bit constant offset. Loads and stores with 15-bit constant offset (.D2 only).

Load doubleword with 5-bit constant offset.

DSP-introduktion

Kombinerad DSP- och FPGA-lösning för en bildbehandlingsapplikation 9 2.1.3 EMIF

EMIF (External Memory Interface) är minnesbussen som kan köras i 32, 16 eller 8 bitars bredd. EMIF stödjer tre olika minnesstandarder: SDRAM (Synchronous Dynamic RAM), SBSRAM (Synchronous Burst Static RAM) samt asynkrona minnen som SRAM, ROM och flashminnen.

EMIF kan bland annat konfigureras med avseende på refresh-perioden för SDRAM och olika tider vid läsning av asynkrona minnen.

DSPn kan dela minnesgränssnittet med externa enheter genom att använda signalerna HOLD, HOLDA och BUSREQ. HOLD används av den externa enheten för att begära tillgång till minnesbussen. När DSPn har slutat driva bussen så aktiveras HOLDA. BUSREQ sätts av DSPn när den vill ha tillgång till, eller använder minnesbussen. BUSREQ är oberoende av HOLD och HOLDA och den externa enheten måste inte lämna tillbaka minnesbussen om den inte vill.

DSPn använder en extern klocka för att generera klockan till minnesbussen. Den maxi-mala frekvensen för minnesbussen är 100 Mhz. Maximal överförningshastighet blir då 3,2 Gbps för EMIF om SDRAM eller SBSRAM används och cykler för refresh, radbyte och byte mellan läsning och skrivning inte räknas. För asynkrona minnen så används flera klockcykler för en åtkomst på minnesbussen. En del av DSPerna i samma familj använder systemklockan istället för att skapa klockan till minneskretsarna.

2.1.4 HPI

HPI (Host Port Interface) är en 16 bitar bred expansionsbuss som gör det möjligt att läsa och skriva i DSPns adressrymd. Alla läsningar och skrivningar görs med 32 bitar genom att dela in bitarna i en hög och en låg del. HPI kan användas för att koppla samman två stycken DSPer eller en DSP och något annat.

Överförningshastigheten för HPI varierar beroende på var i minnesrymden som en åtkomst görs, om det är en skrivning eller en läsning samt om åtkomsten görs med auto-matisk adressökning. I referenslistan finns en applikationsrapport, [20], som redovisar prestandasiffror för HPI hos C6201/6701 som också har 16 bitar bred HPI. Om auto-matisk adressökning används kan läsningar ske med ungefär 200 Mbps och skrivningar med 300 Mbps.

Det finns några skillnader som att C621x/671x har 8 ord djupa läs- och skrivbuffertar och att den kan klockas i 150 Mhz jämfört med C6201/6701 som klarar 200 Mhz, men värdena ger en uppfattning om storleksordningen på överförningshastigheten.

2.1.5 McBSP

DSPn har två stycken McBSP (Multichannel Buffered Serial Port) som enligt databladen klarar maximalt 33 Mbps vardera. Serieportarna klarar av flera olika seriella kommuni-kationsstandarder och kan konfigureras med en mängd register. Initialiseringen av serie-portarna beskrivs i [22].

2.1.6 Avbrottsgenerering

Det finns fyra externa ingångar för avbrott som är konfigurerbara EXT_INT[4..7] och NMI (Nonmaskable Interrupt) som endast kan aktiveras med en stigande flank på insignalen. Ingångarna för avbrottsgenerering kan också användas för att aktivera över-förningar med EDMA, se nästa avsnitt.

In- och utgångarna till timer 0 och 1 kan användas som 2 generella ingångar och 2 generella utgångar. Dessa kan till exempel användas för att generera avbrott hos andra enheter, eller användas som godtyckliga kontrollsignaler.

2.1.7 EDMA

DMA är vanligtvis konceptet att flytta data utan att belasta processorn. Här står E för

enhanced, och EDMA kan mer än att bara kopiera ett block till ett annat.

EDMA består av en minnesrymd på 2 Kbyte och en enhet som flyttar data. I minnesrym-den som kallas PARAM får det plats 85 stycken parameterstrukturer med inställningar hur data ska flyttas. Det finns 16 kanaler som motsvarar de 16 första platserna. Dessa kan startas genom olika händelser som genererar avbrott, skrivning till register eller seriepor-tar som har tagit emot data eller ska skicka data.

De platser i PARAM som inte används som kanaler kan inte startas direkt, men de kan användas för att länka till, från de 16 första platserna. När en dataflyttning som beskrivs av en parameterstruktur är färdig kan det ske tre saker.

1. Det genereras ett avbrott.

2. Ett register sätts som heter TCINT (Transfer Complete Interrupt). Det här regist-ret kan användas för att läsa av vilken dataflyttning som genererade ett avbrott. Det kan även användas för att starta en ny dataflyttning. Vilken bit som ska sättas i TCINT ställs in i options-fältet, se figur 2.2.

3. Länkningsbiten är satt i options-fältet vilket innebär att parameterstrukturen som blev färdig skrivs över med den parameterstruktur som väljs med länkadressen.

Figur 2.2: Parameterstruktur för EDMA

I figuren ovan visas de fält som finns i parameterstrukturen. Options innehåller inställ-ningar om hur data ska flyttas och vad som ska hända när den är färdig.

2SWLRQV

6RXUFHDGGUHVV

$UUD\)UDPHFRXQW

(OHPHQWFRXQW

'HVWLQDWLRQDGGUHVV

$UUD\)UDPHLQGH[

(OHPHQWLQGH[

&RXQWUHORDG

/LQNDGGUHVV





DSP-introduktion

Kombinerad DSP- och FPGA-lösning för en bildbehandlingsapplikation 11

I figur 2.3 visas ett exempel på en dataflyttning med EDMA. Mer information om olika möjliga flyttningar finns i [24] och mer information om EDMA allmänt i [9] och [25].

Figur 2.3: Exempel på dataflyttning med EDMA

2.2 Utvecklingsmiljö

För utvecklingen av DSP-koden så har Texas Instruments Imaging Developer's Kit använts som innehåller dels en utvecklingsmiljö och dels ett utvecklingskort för att köra programmen på.

Utvecklingskortet består av en TMS320C6711 DSP med 16 Mbyte SDRAM. Kortet ansluts till parallellporten på en dator och används för att ladda ned programkoden och för avlusning. Bildbehandlingsdelen består av ett dotterkort som har två videokretsar, en FPGA och ett videominne. Till det här kortet kan en videosignal och en VGA-skärm anslutas. För att styra dotterkortet finns det ett kodbibliotek som förklaras i [14], [15] och [16].

Mjukvaran är Code Composer Studio 'C6000 version 1.23 (CCS) från Texas Instruments. CCS är en integrerad utvecklingsmiljö som förutom själva programmeringsdelen inne-håller en simulator och en debugger för att felsöka program när de körs på utvecklings-kortet. Simulatorn gör det möjligt att köra programmen i mjukvara utan att ha någon DSP.

Själva koden kan skrivas med en kombination av följande tre saker:

1. C/C++

2. Sekventiell assembler

3. Parallell assembler

Anledningen till att det finns två olika assembler är att skillnaden mellan C/C++ och den parallella assemblern är större än vad den vanligtvis är mellan C/C++ och assembler. Inte nog med att det finns 8 olika enheter som kan göra var sin sak varje klockcykel, de tar

















































$UUD\LQGH[

$UUD\LQGH[

6RXUFHDGGUHVV

'HVWLQDWLRQDGGUHVV

även olika många cykler innan resultatet finns tillgängligt. Den sekventiella assemblern gör det möjligt att optimera sin C/C++ kod men fortfarande låta kompilatorn ta hand om allokeringen av beräkningsenheter och register.

För den som använder utvecklingsmiljön finns det två olika sätt att flytta data mellan DSPn och datorn. Det första är RTDX (Real-Time Data Exchange) som använder sig av COM-klienter (Component Object Model) på datorn. Det andra alternativet är att använda en DLL (Dynamic Link Library) som innehåller funktioner som kan anropas från egna program.

För att använda RTDX så krävs att programmet i DSPn är förberett för RTDX till skill-nad från DLL-versionen som använder HPI och kan skriva och läsa i DSPns minnesrymd utan att programmet i DSPn vet om det.

Både RTDX och DLL-versionen har testats och DLL-versionen känns lättare använda eftersom den inte behöver någon kod i DSPn.

Mer information om utvecklingsmiljön finns i [1], [2] och [6]. För mer information om RTDX se [3] och för DLL-versionen [1]. Information om DLLer i allmänhet finns i [32].

13 Kombinerad DSP- och FPGA-lösning för en bildbehandlingsapplikation

K

APITEL

3

3

FPGA-

INTRODUKTION

Systemet som finns är byggt kring FPGAer (Field Programmable Gate Array). Syftet med det här kapitlet är att ge en snabbintro-duktion av de FPGAer som används.

FPGAerna (Field Programmable Gate Array) som finns i det befintliga systemet kommer från Xilinx och är av typen Virtex-E. Xilinxs FPGAer är RAM-baserade och måste pro-grammeras efter spänningstillslag.

3.1 Funktionsbeskrivning

Figuren nedan illustrerar arkitekturen i Virtex-E. Alla delarna kopplas samman genom en programmerbar sammankopplingsmatris som delvis utgörs av VersaRing. Blockens funktion förklaras i följande avsnitt

.

Figur 3.1: Översikt av FPGA-arkitektur

3.1.1 Configurable Logic Block

CLB (Configurable Logic Block) utgör elementen för att skapa logik. En CLB består av två stycken block som kallas för slice. På nästa sida visas hur en slice är uppbyggd.

%6

5$

0

V

%6

5$

0

V

%6

5$

0

V

%6

5$

0

V

&/

%V

&/

%V

&/

%V

&/

%V

9HUVD5LQJ

'//'//

'// '//

'//

'//

'//

'//

,2%

V

,2%

V

Varje slice består av två stycken delar som vardera innehåller en funktionsgenerator med fyra ingångar, logik för att generera carrysignal och ett minneselement. Dessutom finns det en del extra logik för att kunna använda de två funktionsgeneratorerna tillsammans och därmed klara av funktioner med fem eller sex insignaler.

Figur 3.2: Blockbeskrivning av en slice

Funktionsgeneratorerna är implementerade som LUTar (Look-Up Table). Förutom att fungera som funktionsgenerator kan varje LUT användas som 16x1-bit synkront RAM. Två LUTar kan användas som 16x2-bit eller 32x1-bit synkront RAM, alternativt 16x1 synkront tvåports RAM. En LUT kan även användas för att skapa ett 16-bitars skift-register.

Minneselementen kan antingen användas som en D-vippa eller som en latch. Carry-logiken används för att få hög hastighet på aritmetiska funktioner.

3.1.2 Input/Output Block

Varje IOB (Input/Output Block) har hand om en IO-pinne på kapseln. I IOB finns förutom buffertar för att driva in- och utsignaler, minneselement som kan användas som D-vippa eller latch. Det finns ett minneselement på utgången, ett på ingången och ett för output enable på utgången.

Alla IOB är grupperade i åtta banker. Bankerna kan ha olika matningsspänning och refe-rensspänning, men inom en bank får endast en matningsspänning och en referens-spänning användas. Matningsreferens-spänning och referensreferens-spänning väljs efter vilken/vilka IO-standarder som varje bank ska stödja.

/87

/87

&DUU\

&RQWURO

&DUU\

&RQWURO

'

'

4

4

63

63

&(

&(

5&

5&

*

)

*

)

*

)

*

)

%<

%;

&,1

&287

<%

<

<4

;%

;

;4

FPGA-introduktion

Kombinerad DSP- och FPGA-lösning för en bildbehandlingsapplikation 15 3.1.3 Block SelectRAM

Block SelectRAM är minnesblock som är 4096 bitar vardera. Blocken är synkrona och har två portar som båda klarar läsning och skrivning. Portarnas databredd kan väljas obe-roende av varandra som 1, 2, 4, 8 eller 16 bitar. Flera block kan kombineras för att skapa större minnen. Antalet minnesblock per FPGA sträcker sig från 16 stycken i XCV50E till 208 stycken i XCV3200E. Mer information finns i [28] och [33].

3.1.4 Delay-Locked Loop

För att minimera klockskevning och fördröjningar i klocknäten så finns det upp till åtta DLLer (Delay-Locked Loop) i FPGAn.

Figur 3.3: Delay-Locked Loop

Figuren ovan visar hur en enkel DLL fungerar. Det man vill åstadkomma är att eliminera fördröjningen från CLKIN till klocknätet. Lösningen är att fördröja CLKIN nästan en hel period så att CLKIN och CLKFB har sina flanker samtidigt, detta förklaras i [35]. DLLer kan även användas för att få ut olika faser från klocksignalen och för att höja eller dela ned klockans frekvens med olika faktorer.

3.2 Utvecklingsmiljö

FPGAerna har programmerats med VHDL. För att använda blockminnen så har Xilinx Core Generator använts som skapar nätlistor över blockminnena, se [29].

För simulering av VHDL-koden har Modelsim PE från Model Technology använts. För att skapa nätlistor från koden har Leonardo Spectrum från Exemplar använts. Slutligen så har Xilinx Alliance använts för att skapa konfigureringsdata från nätlistorna.

&/.,1

&/.87

&/.)%

9DULDEHO

I|UGU|MQLQJ

.RQWUROO

.ORFNQlW

17 Kombinerad DSP- och FPGA-lösning för en bildbehandlingsapplikation

K

APITEL

4

4

I

MPLEMENTERING

Antag att det finns två FPGAer, en DSP-processor och ett antal minneskretsar. Hur bör komponenterna anslutas till varandra för att skapa ett bra system? Det är frågan som det här kapitlet ger några svar på.

4.1 Krav på systemet

I nedanstående lista finns de viktigaste kraven på systemet när det gäller funktionalitet. • Enkelt att byta programkoden som körs i DSPn

• Felsöka programkod när den körs på DSPn i systemet • Utbyta information mellan DSP och VME-FPGA • DSPn ska kunna läsa och skriva i FPGAernas minnen

4.2 Att starta exekvering av program i DSPn

I kapitlet som introducerade DSPn så finns de viktigaste sakerna som rör kommunikation mellan DSPn och omvärlden. En sak som inte förklarades är hur man får ett program att köra i DSPn, vilket görs här.

För TMS320C621x/671x finns det två alternativa sätt att starta program i DSPn efter reset. Första alternativet är att ha ett flashminne som innehåller programkoden på min-nesbussen. Det andra alternativet är att ladda programkoden via HPI och att sedan gene-rera ett avbrott, via HPI, som startar programmet.

Ett flashminne som sitter på minnesbussen kan programmeras i systemet genom att ladda ned ett program i DSPn (HPI), som programmerar flashminnet med data som skickas till DSPn med HPI eller en serieport. Ett exempel är utvecklingskortet som har ett flash-minne och kan programmeras från värddatorn via HPI. Ett alternativt sätt att program-mera flashminnet är till exempel att styra de högst adressbitarna externt och därmed välja ett av flera program i flashminnet, varav ett programmeringsprogram. Problemet med det sista alternativet är att få in programmet från början.

I det här fallet så ska FPGAerna på kortet konfigureras från PROM eller via VME-bussen. Eftersom resten av systemet ändå måste konfigureras vid start finns inget behov av att DSPn laddar in ett program och startar direkt vid uppstart.

Med HPI är det möjligt att läsa och skriva i DSPns minnesrymd vilket gör det möjligt att utbyta data mellan DSPn och VME-FPGAn. Datautbytet kan användas både för styrning av DSPn och för kontroll. Slutsatsen blir att i den här tillämpningen är HPI mest fördel-aktigt för att ladda program.

4.3 Val av systemarkitektur

Förutom de krav på funktionalitet som presenterades i början av kapitlet tillkommer en del praktiska krav som hur många in- och utgångar som krävs på FPGAerna, krav på sig-nalintegritet och hög bandbredd.

FPGAer med fler in- och utgångar gör dem inte direkt dyrare, utan kostnaden ökar indi-rekt då kraven på mönsterkortet ökar. Fler I/O innebär mindre bendelning och fler rader med bollar i BGAerna vilket kan kräva mikrovior för att få ut alla signaler.

För att få bra signalintegritet bör signalerna förgrenas så lite som möjligt och termineras korrekt. Signaler som förgrenas mycket är svårare att terminera på ett bra sätt och svårare att dra på kretskortet.

Den maximala hastigheten på VME-bussen är 20 Mbyte/s vilket är mindre än HPI och liten jämfört med den befintliga lokalbussen och minnesgränssnittet på DSPn. VME-bussens begränsning till 20 Mbyte/s kommer från värddatorns VME-kontroller som är master.

Med detta som utgångspunkt så presenteras här fyra olika lösningar. Tanken bakom de bussar som sitter ihop är att de delar på de fysiska signalerna, men använder olika proto-koll och har separata signaler som anger vilket funktionsmod som gäller

Figur 4.1: Systemförslag                         )3*$ )3*$ )3*$ )3*$ 90( )3*$ 90( )3*$ )3*$90( 90( )3*$ )3*$ )3*$ )3*$ )3*$ 6' 5$ 0 6' 5$ 0 6' 5$ 0 6' 5$ 0 6' 5$ 0 6' 5$ 0 6' 5$ 0 6' 5$ 0 6' 5$ 0 6' 5$ 0 6' 5$ 0 6' 5$ 0 6' 5$ 0 6' 5$ 0 6' 5$ 0 6' 5$ 0 90(%866 90(%866 90(%866 90(%866 6(5,(//'$7$ 6(5,(//'$7$ 6(5,(//'$7$ 6(5,(//'$7$ 6(5,(//'$7$ 6(5,(//'$7$ 6(5,(//'$7$ 6(5,(//'$7$ '63 '63 '63 '63 (0,) (0,) (0,) (0,) +3, +3, +3, +3,

$

%

&

'

/2.$/%866 /2.$/%866 /2.$/%866 /2.$/%866 /2.$/%866 /2.$/%866 /% /% /%+3, /%+3, +3, +3, /2.$/%866 /2.$/%866 0,11(6%866 0,11(6%866 0,11(6%866 0,11(6%866 0,11(6%866 0,11(6%866 0,11(6%866 0,11(6%866

Implementering

Kombinerad DSP- och FPGA-lösning för en bildbehandlingsapplikation 19

I tabellen nedan så presenterars en kvalitativ bedömning av de olika alternativen. En slut-sats är att det är svårt att få ihop bra signalintegritet med få IO, vilket var väntat.

Tabell 4.1: Systemlösningarnas för- och nackdelar

Av EMIF, lokalbussen och HPI är EMIF den buss som kommer att arbeta med den högsta frekvensen. Om man bortser från att spara IO så bör EMIF därför endast användas som minnesgränssnitt mot FPGAerna och inget annat. Det här utesluter A och B.

När det gäller C och D är det HPI som skiljer. I alternativ C är HPI sammankopplad med lokalbussen till skillnad från D där HPI har en egen anslutning till VME-FPGAn. I C är kontrollflödet skiljt från dataflödet, och i D är även de båda kontrollflödena skilda från varandra. En fördel med D är att lokalbussen förblir orörd från det befintliga systemet. Skillnaden mellan C och D är till största delen estetisk - vad som ser snyggt ut. De är inte möjligt att använda de båda kontrollflödena samtidigt eftersom de ska dela på VME-bussen i slutänden.

Även mellan A och B är det HPI som utgör skillnaden. En anledning till att EMIF inte ska blandas ihop med annat är, förutom försämrad signalintegritet, att en åtkomst via HPI kan resultera i en åtkomst på minnesbussen. Det går alltså inte att använda HPI för åtkomst av FPGAernas buffertar om alternativ B väljs.

Sammanfattningsvis så är det antalet IO som avgör. Kan man välja en krets med tillräck-ligt många IO och kan dra ledningarna på kretskortet så är D vinnaren. Om man måste ha färre IO så rekommenderas ordningen C, A, B.

4.4 Ytterligare idéer

En del idéer som inte kom så långt att de fick sina egna bilder är:

• att ha ett minne på minnesbussen som kan användas för att spara temporär data eller programkod om den inte får plats i det som blir kvar av internminnet. • att använda HPI för att koppla ihop FPGAerna och DSPn och låta extra minnen

sitta på EMIF.

4.5 Val av minnesstandard på EMIF

Det är bestämt att DSPn och FPGAerna ska kopplas samman med EMIF. Frågan är hur det ska göras, vilken minnestyp ska simuleras av FPGAn? De som finns att välja bland är asynkrona minnen, SDRAM och SBSRAM.

$ % & ' ,290()3*$     ,2)3*$     6LJQDOLQWHJULWHW     6HSDUDW NRQWUROO GDWD    

4.5.1 Asynkrona minnen

I figur 4.2 och 4.3 visas exempel på en läscykel och en skrivcykel för asynkrona minnen. Det går att variera antalet klockcykler som ska användas för setup, strobe och hold. I exemplet är setup och hold en klockcykel och strobe två klockcykler. Det går också att använda handskakning i form av ARDY om så önskas. Om handskakning inte används så utgår "Not Ready" i figurerna. Signalerna i figurerna 4.2 till 4.5 finns förklarade i tabell 4.1 på nästa sida.

Figur 4.2: Asynkron läsning

Figur 4.3: Asynkron skrivning

(&/.287

&([

%(>@

($>@

('>@

$2(

$5(

$:(

$5'<

($

%(

6HWXS

6WUREH

1RW5HDG\

+ROG

(&/.287

&([

%(>@

($>@

('>@

$2(

$5(

$:(

$5'<

($

%(

6HWXS

6WUREH

1RW5HDG\

+ROG

:ULWH'DWD

Implementering

Kombinerad DSP- och FPGA-lösning för en bildbehandlingsapplikation 21

Den största fördelen med asynkrona minnen är handskakningsmöjligheterna som resul-terar i att det inte behövs någon buffert för att klara läsningar samt att det är möjligt att göra slumpvis åtkomst.

Nackdelen är överförningshastigheten. Det går åt klockcykler för setup och strobe samt för att vänta på ARDY. En annan nackdel är att övriga systemet är synkront och att det måste klockas med minnesklockan i alla fall.

Tabell 4.1: Minnesgränssnittets signaler

Av signalerna i tabell 4.1 är BE i störst behov av en förklaring. BE som står för byte

ena-ble gör det möjligt att välja vilka bytes i ett ord som ska skrivas till minnet vid en

skriv-ning.

4.5.2 SBSRAM

I figurerna 4.4 och 4.5 visas vågformerna för läsning och skrivning till SBSRAM. Obser-vera att det här är vad DSPn gör. Om man tittar i databladet för ett SBSRAM så måste till exempel CEx endast vara definierad de klockcykler som SSADS är låg. I läsningsexem-plet så är CEx låg fram till nästa gång SSADS är låg, vilket gör det lätt att implementera i en FPGA jämfört med om CEx endast hade varit definierad då SSADS är låg.

SBSRAM är som namnet antyder synkrona statiska minnen som har en intern adressräk-nare för de två lägsta bitarna i adressen. När en läsning av fyra ord på rad görs så anges endast adressen till det första ordet. Vid läsning så finns det en fördröjning för läst data på två klockcykler.

Fördelarna med SBSRAM är att det har hög överförningshastighet och att det är syn-kront samtidigt som det är enkelt. Nackdelen är att det behövs en läsbuffert vid en imple-mentering i en FPGA för att klara tidskraven på en läsning. Läsbufferten behövs eftersom FPGAn i sin tur inte hinner läsa data från sina SDRAM med tillräckligt låg för-dröjning.

ECLKOUT clock CEx chip enable

BE byte enable EA address ED data

AOE output enable ARE read enable AWE write enable ARDY ready

SSADS adress strobe SSOE output enable SSWE write enable

Figur 4.4: SBSRAM-läsning

Figur 4.5: SBSRAM-skrivning

4.5.3 SDRAM

SDRAM har ungefär samma överförningshastighet som SBSRAM. Det är dock inte lika enkelt att använda då det är dynamiskt och ett SDRAM måste klara av kommandon från kontrollern. Exempel på kommandon är inställning av hur många klockcykler det tar vid läsning, hur många ord som ska läsas på en rad med mera.

4.5.4 Slutsats

SDRAM och SBSRAM har önskad överförningshastighet och är synkrona vilket är att föredra mot ett asynkront gränssnitt, även om det innebär att en buffert måste användas. SBSRAM-gränssnittet är enklare att implementera i en FPGA, och är det som rekom-menderas för systemet.

(&/.287

&([

%(>@

($>@

('>@

66$'6

662(

66:(

($

%( %( %( %(

4

4

4

4

(&/.287

&([

%(>@

($>@

('>@

66$'6

662(

66:(

($

%( %( %( %(

4

4

4

4

Implementering

Kombinerad DSP- och FPGA-lösning för en bildbehandlingsapplikation 23

4.6 Minnesrymd och kommadon

Valet av SBSRAM till minnesstandard gör att det krävs någon form av buffert i FPGAerna som styrs med kommandon som skrivs till FPGAn. I FPGAerna finns det ungefär 10 Kbyte minne som inte används av den befintliga konstruktionen. Därför väljs 8 Kbyte att användas till databuffert och 1 Kbyte till kommandominne.

Hur ska bufferten fungera för maximal flexibilitet? Från början var tanken att det räcker med två databuffertar på vardera 4 Kbyte och det är så koden i DSPn fungerar. Men den kommandostruktur som har definierats klarar av godtyckliga datastorlekar så länge de får plats i 8 Kbyte.

Figur 4.6: Kommandostruktur för att styra FPGA-buffertarna

Kommandostrukturen visas i figuren ovan. För framtida utbyggnad och enkel adressering så är den 128 bitar stor även om bara 5/8 används för närvarande. Startadressen för SDRAMet anges i byte med 29 bitar. Eftersom SDRAMet har en 16 byte bred minnes-buss är endast adresser som är multiplar av 16 byte definierade för SDRAMet.

Även startadressen i bufferten anges i byte med 13 bitar och måste vara en multipel av 16 byte. Anledningen till att adresserna anges i byte är att alla adresser anges i byte för att få enhetligt användargränssnitt. R/W anger om det är en läsning eller en skrivning, 1 för läsning och 0 för skrivning. För att starta ett kommando så skrivs 1 till startbiten. När kommandot börjar utföras så nollställs startbiten av FPGAn och när kommandot är färdigt sätts Rdy-biten.

Ett kommando resulterar i en läsning/skrivning av SDRAMet av ett antal block som i sin tur består av ett antal element. Ett element är 16 byte. I ett block ligger alla element på rad i SDRAMet och efter sista elementet i blocket så ökas adressen till SDRAMet med adressökningen för att komma till nästa block. Adressökningen anges i byte med 16 bitar och måste även den vara en multipel av 16 byte.

Även om data läses med block och element från SDRAMet så sparas all data linjärt i buf-ferten. Anledningen till detta är att om man vill flytta om data ytterligare så kan det göras med DMAn i DSPn vid läsning från bufferten. Dessutom så finns det inte något behov av att spara data på något annat sätt än linjärt i bufferten i den applikation som har under-sökts.

$QWDOEORFN



$QWDOHOHPHQW

SHUEORFN

$GUHVV|NQLQJSHUEORFN

6WDUWDGUHVVLEXIIHUW

6WDUWDGUHVVL6'5$0

5

:

6WDU

W

5G\

 

0x0

0x4

0x8

0xC

Om minnesrymden är det inte så mycket att säga. Den visas i figuren nedan och adres-serna till vänster är i byte och adresadres-serna till höger är i 32 bitars ord, dvs de fysiska sig-naler som går mellan DSPn och FPGAerna.

Figur 4.7: Minnesrymd i FPGA

Det finns 64 kommandoplatser eftersom det är vad som får plats i 1 Kbyte. Alla dessa behöver dock inte genomsökas i implementeringen om de inte används av DSPn.

0x0000

0x1000

0x2000

0x2010

0x2020

0x2030

0x23F0

0x400

0x000

0x800

0x804

0x808

0x80C

0x8FC

.RPPDQGR

.RPPDQGR

.RPPDQGR

.RPPDQGR

.RPPDQGR

'DWDEXIIHUW$E\WHV

'DWDEXIIHUW%E\WHV

25 Kombinerad DSP- och FPGA-lösning för en bildbehandlingsapplikation

K

APITEL

5

5

DSP-

IMPLEMENTERINGEN

Det här kapitlet behandlar den del av systemet som utförs i DSPn. Bland annat så presenteras hur internminnet utnyttjas, hur data buffras, hur algoritmen har delats upp och hur EDMAn har programmerats.

5.1 Uppdelning av internminnet

I det föregående kapitlet beslutades att SBSRAM-minnesgränssnitt ska användas mellan FPGAerna och DSPn. Det här resulterade i att det behövs buffertar i FPGAerna. Nu har turen kommit till DSPn, då det är dags att bestämma vilka buffertar som behövs där. DSPn har 64 Kbyte internminne som kan användas som minne, cache eller en kombi-nation i steg om 16 Kbyte, se [9]. I den här tillämpningen används hela internminnet som minne. Dels för att det inte finns någon annan möjlighet att spara programmet än i intern-minnet, dels för att data buffras i FPGAerna och dels för att FPGAernas minnen inte kan adresseras linjärt av DSPn.

Figur 5.1: Dataflöde och buffertar i systemet

6'5$0

)3

*

$



%XIIHUW$ %XIIHUW%

6'5$0

)3

*

$



%XIIHUW$ %XIIHUW%

$

%

&

'

(

$

%

&

'

(

'63

%XIIHUWDUI|U)3*$

%XIIHUWDUI|U)3*$

Figur 5.1 på föregående sida visar dataflödet för implementeringen, buffertarna som finns i FPGAerna samt de buffertar som nu införs i DSPn. För FPGAerna så valdes buffertstorleken utifrån tillgängligt minne samt databredd mot DSPn och internbussen, vilket resulterade i en 8 Kbyte stor buffert. Här har bufferten delats i två stycken lika stora delar A och B, där A används för att läsa data från SDRAMet och B för att skriva till SDRAMet.

För att maximera utnyttjandet av FPGAerna så dubbelbuffras varje FPGA med fem buffertar per FPGA i DSPn. För varje FPGA används två buffertar för att läsa in data och tre buffertar för att skriva resultatet i. Att det krävs tre buffertar för resultatet beror på den skevningsalgoritm som har använts som exempel på bildbehandlingsalgoritm i den här implementeringen. Den skevade bilden tar mer plats i minnet.

De fem buffertarna i DSPn benämns A till E, vilket framgår av figur 5.1. Buffert A och B används för att läsa in data från FPGAns buffert A. Data läses in till en av A och B sam-tidigt som data i den andra bufferten beräknas och sparas i motsvarande buffert C till E. Buffertarna C till E används för att spara resultatet av algoritmen temporärt innan det kan skrivas till FPGAns buffert B.

Genom att använda två inbuffertar per FPGA i DSPn och att växla mellan FPGAerna kan varje FPGA balanseras för maximal utnyttjandegrad samtidigt som DSPns minnesgräns-snitt utnyttjas maximalt. Detta beror på att kommunikationen mellan DSP och FPGA är snabbare än kommunikationen mellan FPGA och SDRAM, där den begränsande faktorn är SDRAM-kontrollern i FPGAn.

Eftersom storleken på buffert A och B i FPGAerna är 4 Kbyte stora så väljs buffertarna i DSPn lika stora. Därmed används totalt 40 Kbyte för att buffra data i DSPn och resterande 24 Kbyte kan användas för stack, variabler och programkod.

5.2 Skevningsalgoritmen

I figuren nedan visas vad skevningsalgoritmen ska göra. Det som ska vara reglerbart är offset och vinkeln i den skevade bilden.

Figur 5.2: Obehandlad och skevad bild

RIIVH

W

_YLQNHO

DSP-implementeringen

Kombinerad DSP- och FPGA-lösning för en bildbehandlingsapplikation 27

Genom att förutsätta att vinkeln är mellan 0 och 90 grader samt att offset är positiv så förenklas implementeringen. Implementeringen som har gjorts förutsätter dessutom att den skevade bilden får plats och inte klipps av i nederkanten.

För att få till skevningen används en två-punkters faltning på varje pixelkolumn. Varje pixel i den obehandlade bilden delas i två delar. Varje pixel i den skevade bilden skapas genom att addera de två delarna som ligger närmast. I figuren nedan visas hur det här går till.

Figur 5.3: Visualisering av två-punkters faltning

I figuren nedan illustreras hur skevningen har implementerats. Längst till vänster visas den obehandlade bilden, i mitten det som egentligen önskas, och till höger visas delningsfaktorerna. Delningen av pixlarna görs linjärt mot den höjd de täcker i den önskade bilden. Av figuren framgår det även att delningsfaktorerna är olika för de olika kolumnerna.

Figur 5.4: Obehandlad och önskad bild samt delningsfaktorerna

5.3 Tillståndsgraf för buffring och beräkning

Skevningsalgoritmen behöver en uppsättning parametrar för varje kolumn med pixlar. Genom att iterera bilden kolumnvis i stället för radvis räcker det att dessa parametrar endast beräknas en gång per kolumn och skevning. En radvis iteration av bilden kräver antingen att parametrarna för varje kolumn sparas i internminnet eller att de beräknas på nytt varje gång. Att spara parametrarna tar plats och att flytta parametrarna mellan minne och register tar tid.

Eftersom data buffras i FPGAerna bör bilden delas in i block som är lika stora som en buffert. FPGAerna har 16 byte breda bussar mot SDRAMen och för att utnyttja detta så bör blocken vara minst lika breda, vilket motsvarar 8 pixlar då varje pixel är 2 byte. För att utnyttja bredden på minnesbussen, men samtidigt ha så få parametrar som möjligt internminnet så väljs att bilden ska delas in i block som är 8 pixlar breda och 256 pixlar höga.

För att minimera beräkningar av parametrar och användandet av temporära variabler så itereras bilden kolumn för kolumn i blockstorlek med början i över vänstra hörnet, se figur 5.5.

Figur 5.5: Blockstorlek och iterering av blocken i bilden

I tillståndsgrafen nedan visas tillståndet hos DSP-buffertarna för en FPGA. Horisontella pilar är flyttning av data mellan FPGA och DSP. Lodräta pilar från inbuffert till utbuffert representerar beräkningar och pilar mellan utbuffertar representerar flyttning av data. R står för rensa (data i blocket nollställs) och B för beställning av data. Med beställning av data avses att skicka kommandot för inläsning av data från SDRAM till FPGA-buffert A. Symbolerna finns förklarade i figur 5.7.

Figur 5.6: Tillståndsgraf för buffring







6

6

6

6

6

6

6

6

6

6

% % % % % 5 5 5 5 5 %HUlNQDWVLVWDHOHPHQWHW LNROXPQHQ" _1(- 1lVWVLVWDEHUlNQLQJHQ" 1(--$ -$

DSP-implementeringen

Kombinerad DSP- och FPGA-lösning för en bildbehandlingsapplikation 29

Figur 5.7: Förklaring av symbolerna i tillståndsgrafen

Varje tillstånd utförs först på FPGA1 och sedan på FPGA2 för att ge FPGAerna så mycket tid som möjligt för att läsa och skriva. Mer om detta längre fram.

I tillståndsgrafen förutsätts att skevningen ska ske såsom visas i figur 5.2 med en positiv vinkel. Om skevningen ska ske uppåt måste buffertarna C till E användas i omvänd ord-ning, och blocken itereras med början längst ned för att sedan gå uppåt.

Tillstånden S0 till S2 utgör en infasning, samt S7 till S9 en utfasning. Tillstånden S3 till S6 utgör själva kärnan och itereras tills det är dags för utfasningen.

S3 beräknar data från buffert B till buffert D. Om det var det sista elementet i kolumnen som beräknades så ska en extra skrivning ske till FPGA-bufferten av det som finns i buf-fert E, vilket utförs i tillstånd S6. Om det inte var det sista elementet i kolumnen som beräknades så ska det som finns i buffert E flyttas upp till buffert C vilket utförs i till-stånd S4.

S5 beräknar data från buffert A till buffert C. Om det är näst sista beräkningen så ska ingen ny data beställas till FPGAn och nästa tillstånd ska vara S7 istället för S3.

1DPQ

% 5

,1.E\WH

,1.E\WH

87.E\WH

87.E\WH

87.E\WH

$

%

&

'

(

/lVIUnQ)3*$

6NULYWLOO)3*$

%HVWlOOWLOO)3*$

5HQVDEXIIHUW

%HUlNQDRFKVSDUDLEXIIHUW

)O\WWDWLOOEXIIHUW

Nedan visas ett exempel som har 2x4 indata och 2x5 utdata. De vita fälten är block som motsvara minnesplatser för indata i SDRAMen och de grå fälten är block som motsvarar minnesplatser för resultatet. I tillståndet S4 finns sker all aktivitet i DSPns buffertar som inte finns med i den här förklaringen.

Figur 5.8: Tillståndsgrafen applicerad på 2x4 data

5.4 Uppdelning av algoritmen i block

Hittills har det bestämts att data ska behandlas i block som är 8 pixlar breda och 256 pix-lar höga. På tur står att bestämma hur blocken ska beräknas. Två saker som har tagits hänsyn till när beräkningsordningen har bestämts är storleken på nivå ett cacheminnet i DSPn och hur snabba olika implementeringar av algoritmen är.

I optimeringskapitlet presenteras lite olika implementeringar och resultaten. Det visade sig att en fixtalsimplementering som behandlar två pixlar i bredd är den snabbaste med 1 eller 1,25 klockcykler per pixel beroende på data. Alltså bör data behandlas två i bredd.

%

%

%

%

/

/

/

/

6

6

6

6

6

/

6

6

6

6

%

%

%

%

/

/

/

6

6

6

6

6

6

6

6

6

6

6

6

6

6

6

6

%HVWlOO

/lV

6NULY

%HUlNQD

6

/

%

'DWDLQ

'DWDXW

DSP-implementeringen

Kombinerad DSP- och FPGA-lösning för en bildbehandlingsapplikation 31

Figur 5.9: Beräkningsordning för datablock

Cacheminnet för data är 4 Kbyte och vid miss av data så läses nästa 32 byte in i cacheminnet. Det betyder att första kolumnens läsning av minnet kommer resultera i att hela blocket läses in. Eftersom det behövs en del variabler för att iterera samt för att vara på den säkra sidan så har varje block delats i två. Först beräknas den övre delen av blocket och sedan den undre delen. Allt detta visas i figur 5.9.

Indelningen förhindrar att data som ska skrivas till FPGAn från till exempel buffert D inte skrivs över av beräkning från buffert A till buffert C innan den är i säkerhet i FPGAn. Mer om detta i nästa avsnitt.

5.5 Dataflyttning

Det är FPGAernas SDRAM-kontroller som begränsar bandbredden mellan DSPn och FPGAernas minnen. Om algoritmen först körs på hela bilden i FPGA1 och sedan hela bilden i FPGA2 kommer DSPns minnesbuss att vara outnyttjad stora delar av tiden. Detta förutsätter att DSPn kan mata minnesbussen med data, vilket är sannolikt i det här fallet.

Om ett block från vardera FPGA beräknas per iteration så kan utnyttjandegraden hos DSPns minnesbuss ökas betydligt. I figur 5.10 på nästa sida visas hur detta görs. Buffert A och B är de som finns i FPGAerna. Buffert A används för att läsa från FPGAns minne och buffert B för att skriva till FPGAns minne.









Figur 5.10: Dataflöde mellan DSPn och FPGAerna

Samtidigt som DSPn börjar beräkna datablocket för FPGA1 så skrivs föregående data till buffert B. När data har skrivits till FPGA1 så skrivs data till buffert B i FPGA2. Fortfa-rande så beräknar DSPn datablocket för FPGA1. När skrivningen är färdig så läses data från FPGA1 och sedan FPGA2. Någon gång efter att skrivningen till FPGA1 är färdig börjar DSPn beräkna blocket för FPGA2.

Eftersom övre halvan av ett datablock beräknas först så tar det minst 8x128x1 = 1024 klockcykler innan den nedre halvan kan skriva över data i den övre halvan av nästa buf-fert. Att skriva den övre halvan av bufferten till FPGAns buffert tar 512 klockcykler på minnesklockan vilket motsvarar 512x1,5 = 768 klockcykler hos CPUn. Hela bufferten kommer att ha skrivits till FPGAn innan datablocket börjar beräknas för FPGA2 och där-för kan samma resonemang används där-för att se att ingen buffert kommer att skrivas över innan den har skrivits till sin FPGA.

Ett resultat av det här är att det inte behövs någon synkronisering mellan beräkningsdelen och dataflyttningen mellan DSP och FPGA under pågående beräkning. Dock så måste den synkroniseras när båda datablocken är beräknade, eftersom det tar längre tid att

6NULYWLOOEXIIHUW%

6NULYWLOOEXIIHUW%

/lVIUnQEXIIHUW$

/lVIUnQEXIIHUW$

%HVWlOOVNULYQLQJ

%HVWlOOVNULYQLQJ

%HVWlOOOlVQLQJ

%HVWlOOOlVQLQJ

)3*$

)3*$

DSP-implementeringen

Kombinerad DSP- och FPGA-lösning för en bildbehandlingsapplikation 33

5.6 EDMA-programmering

Så långt har det varit en teoretisk diskussion om hur data ska flyttas och att den ska ske samtidigt som DSPn beräknar nya datablock. I tillståndgrafen som presenterades tidigare så fanns det en del olika dataflyttningar som nu ska implementeras.

För varje tillstånd i tillståndsgrafen ska flera dataflyttningar utföras. Frågan är hur data-flyttningarna i ett tillstånd ska fås att utföras efter varandra. Som vanligt så finns det olika sätt att lösa uppgiften. De två sätten är att använda avbrott eller att kedja flera para-meterstrukturer.

Om man använder avbrott ställer det en del krav på vilka optimeringar som tillåts i koden. Till exempel måste en for-loop ha mer än ett visst antal instruktioner för att det ska vara möjligt att använda avbrott.

Om avbrott inte används kan registerna schemaläggas hårdare av kompilatorn genom att använda multipel tilldelning i stället för enkel tilldelning. Enkel tilldelning innebär att när en instruktion, som tar flera klockcykler att utföra, utförs så skrivs inget nytt värde till det registret förrän instruktionens resultat verkligen har skrivits till registret, vilket möjliggör användandet av avbrott.

Multipel tilldelning innebär att ett register har tilldelats ett värde som kommer att använ-das under tiden som en instruktion som utförs kommer att skriva i registret när den är fär-dig någon klockcykel senare. Under dessa förutsättningar är det inte möjligt att använda avbrott. Exemplet nedan kommer från avsnitt 7.2 i [23] och visar multipel tilldelning.

Figur 5.11: Exempel på multipel tilldelning

Det andra alternativet att kedja flera parameterstrukturer går till så att först länkas en parameterstruktur in, dvs innehållet i den aktuella kanalen ersätts med det som finns på länkadressen, och sedan startas den genom att välja den kanalen i TCINT i options-fältet. Det är bara kanalerna 8 till och med 11 som kan startas med TCINT.

Eftersom det inte behövs någon synkronisering mellan de olika delarna så väljs att kedja parameterstrukturerna. I figur 5.12 visas hur parameterstrukturerna är strukturerade. Innan dataflyttningen startas så väljs vilken kanal som ska startas efter skrivningen i

Write4, 0 om endast en skrivning ska ske, 9 för skrivning med läsning, 10 för skrivning

med beställning av data eller 11 för skrivning med läsning och beställning av data. Om en skrivning inte önskas göras startas kanal 9 för läsning eller kanal 10 för beställ-ning av data eller kanal 11 för både och. Alla dataflyttbeställ-ningar avslutas med TCINT 0 som används för att synkronisera beräkningsdelen och dataflyttningen. Här väljs åter att inte använda avbrott utan att läsa av TCINT registret direkt eftersom programmet ändå inte har något annat att göra.

SUB .S1A4,A5,A1 ;writes to A1 in single cycle

*A0,A1 A1,A2,A3 A1,A4,A5 .D1 .L1 .M1 LDW NOP ADD NOP MPY 1 2 3 4 5-6 7

;writes to A1 after 4 delay slots ;uses old A1 (result of SUB) ;uses new A1 (result of LDW)