USB-kommunikation med programmerbar ultraljudssändare

Transkript

1 EXAMENSARBETE 2004:250 CIV USB-kommunikation med programmerbar ultraljudssändare Harald Stribén CIVILINGENJÖRSPROGRAMMET Luleå tekniska universitet Institutionen för systemteknik, Avdelningen för datorteknik 2004:250 CIV ISSN: ISRN: LTU - EX / SE

2 USB-Kommunikation med programmerbar ultraljudssändare Harald Stribén Luleå University of Technology Dept. of Computer Science and Electrical Engineering Luleå University of Technology September 10, 2004

3 ii

4 ABSTRACT In medical material science, injectable bone cements are being developed to fill and repair defective bones with minimal surgical procedure. The setting time determines the amount of time one have, working with the material and when it is possible to close the wound without complications. Therefore the accuracy of the measured setting time is important. A Method based on ultrasound is being developed for this purpose. A reliable method would be of direct help both to the surgeon and the people who develop these cements. This could lead to shorter operating time for the patients. One of the problems with the ultrasonic pulse-echo technique used today is that it requires expensive equipment, and that the equipment used is not flexible enough. In other words, there is a need for a more flexible instrument that costs less money. This report will show how you could implement one part of such a meter. The hardware used is a SDRAM memory module, a FPGA programmable logic device and a dedicated module for communication via USB. The work was mostly done in a hardware description language called VHDL. The task was analyzed and split into parts that could be solved and implemented separate and finally brought together to form the working meter. The digital part of the meter is implemented, but to be able to build a whole meter a new lab card or custom made PCB have to be used that could utilize more of the FPGA s IO pins. From this thesis one could draw the conclusion that the FPGA and Memory module used are well suited for the task, and that now there is a platform to build a meter on. iii

5 iv

6 SAMMANFATTNING Inom medicinsk materialteknik utvecklar man injicerbara ben-cement, att användas för att fylla och reparera defekter med minimala kirurgiska ingrepp. Härdningstiden bestämmer hur länge man kan arbeta med materialet, och när man kan sy ihop såret utan risk för medicinska komplikationer. Det är därför av stor vikt att man kan bestämma denna tid så exakt som möjligt. En metod baserad på ultraljud håller på att tas fram för detta ändamål. En tillförlitlig mätmetod skulle vara till omedelbar hjälp både för medicinsk personal och de som utvecklar materialen, vilket skulle kunna innebära kortare operationstider för patienterna. Ett av problemen med ultraljudseko-metoden idag är att den kräver dyr hårdvara, och att den hårdvara som finns idag inte heller är särskilt flexibel. Därför finns ett behov av att utveckla en billigare och mer flexibel mätutrustning. Detta arbete visar hur man kan bygga en del av denna mätutrustning. Den hårdvara som används är ett RAM-minne av typen SDRAM, en FPGA och en modul för kommunikation via USB. Arbetet bestod till huvuddelen av programmering av FPGA:n i det hårdvarubeskrivande språket VHDL. Problemet delades upp i delar efter de arbetsuppgifter som FPGA:n har, för att kunna lösa dem separat och sedan sammanfoga dem till en enhet. Den digitala delen av mätinstrumentet är implementerat, men för att kunna bygga en färdig mätare måste ett annat labbkort eller ett egenkostruerat kretskort användas som har möjlighet att använda fler av FPGA:ns datapinnar. Av detta arbete kan man dra slutsatsen att använd FPGA och Minnesmodul är väl valda för uppgiften och att det nu finns en plattform att bygga ett färdigt instrument på. v

7 vi

8 INNEHÅLL KAPITEL 1: INLEDNING 3 KAPITEL 2: TEORI OCH FÖRUTSÄTTNINGAR Härdningstid för bencement Ultraljudseko-metoden Problembestämning Analys KAPITEL 3: HÅRDVARA OCH DESIGN FPGA SDRAM USB till parallellt gränssnitt Prototypkort Designflöde Paketbaserad kommunikation Design KAPITEL 4: IMPLEMENTATION OCH RESULTAT Koppling Verifiering av hårdvara Kommunikation Minne Mätning KAPITEL 5: DISKUSSION OCH SLUTSATSER Mätinstrumentet Möjliga förbättringar Fortsatt arbete

9 viii

10 FÖRORD Denna rapport är skriven som examensarbete på civilingenjörsprogrammet datateknik med inriktning mot datorteknik på avdelningen för "Embedded Internet Systems" (EISLAB), Luleå Tekniska Universitet (LTU). Efter att ha pratat med Jonas Thor, doktorand på avdelningen EISLAB, om att göra ett examensarbete inom datorteknik, så lade han ut en förfrågan på avdelningen för systemteknik om det fanns något intressant projekt som sökte arbetskraft. Johan Carlson, universitetslektor på avdelningen för signalbehandling, kom med ett förslag om att göra en del av en mätutrustning. Jonas blev min handledare, Johan blev examinator och resten är historia. Harald Stribén Luleå, Augusti

11 2 INLEDNING

12 KAPITEL 1 Inledning Inom medicinsk materialteknik utvecklar man injicerbara ben-cement, att användas för att fylla och reparera defekter med minimala kirurgiska ingrepp. Ett cement karaktäriseras bland annat utifrån sina mekaniska egenskaper som hållfasthet, porösitet, densitet och härdningstid. Härdningstiden bestämmer hur länge man kan arbeta med materialet, och när man kan sy ihop såret utan risk för medicinska komplikationer. Det är därför av stor vikt att man kan bestämma denna tid så exakt som möjligt. Befintliga standardmetoder för att studera härdningstiden hos ett cement har visat sig ha dålig repeterbarhet och kräver stora säkerhetsmarginaler på grund av osäkerheter inbyggda i metoderna. En metod baserad på ultraljud håller på att tas fram och har visat lovande experimentella resultat. En tillförlitlig mätmetod skulle vara till omedelbar hjälp både för medicinsk personal och de som utvecklar materialen. Detta skulle också kunna innebära kortare operationstider för patienterna, eftersom en tillförlitlig mätmetod innebär att läkarna inte behöver lägga på samma säkerhetsmarginaler som idag. Ett av problemen med ultraljudseko-metoden idag är att den kräver dyr hårdvara, och att den hårdvara som finns inte heller är flexibel. Därför finns ett behov av att utveckla en billigare och mer flexibel mätutrustning. Denna mätutrustning skulle bestå i en svart låda som till exempel kan kopplas till en bärbar dator. Lådan innehåller allt som behövs för att excitera ultraljudselementet på ett kontrollerat sätt och har även kapacitet att lagra ekot som återspeglas till elementet. Från datorn som styr lådan ska man kunna programmera den med en skräddarsydd exciteringspuls, det ska gå att ställa ingångsförstärkningen och man ska kunna läsa av mottagna data. Allt detta via en standard USB (Universal Serial Bus) kabel. Den svarta lådan kan delas upp i två huvuddelar: En helt digital del som innehåller kommunikation via USB och hantering av Minne. Och en analog del som innehåller förstärkare, analog till digital och digital till analog omvandlare. Detta arbete syftar till att designa och implementera den digitala biten av mätutrustningen, så att den passar i en programmerbar logisk krets. Teori och förutsättningar innehåller information om använda teorier och vad arbetet har bestått i och hur det har delats upp. Hårdvara och design beskriver den hårdvara som används i projektet och designarbetet. Implementation och Resultat beskriver sedan arbetet och resultatet därav. Slutligen kommer Diskussion och slutsatser som diskuterar utkomsten av detta arbete, möjliga förbättringar och fortsättningar på arbetet. 3

13 4 TEORI OCH FÖRUTSÄTTNINGAR

14 KAPITEL 2 Teori och förutsättningar I detta kapitel förklaras teorier och metoder använda i detta arbetet. Först kommenteras existerande standardmetoder för att estimera härdningstiden hos bencement. Sedan beskrivs grunderna i den metod som detta arbete grundar sig på, nämligen ultraljudseko-metoden. Slutligen beskriver jag vad arbetet går ut på och hur det delades upp. 2.1 Härdningstid för bencement Cement som skall användas i medicinska sammanhang måste noggrant undersökas och karaktäriseras utifrån sina mekaniska egenskaper. En av de viktigaste egenskaperna är härdningstiden. Den avgör hur länge man kan arbeta med materialet, och när man kan sy ihop såret utan risk för medicinska komplikationer. Idag finns det två standardmetoder för att studera härdningsprocessen. Båda dessa metoder går ut på att utsätta cementytan för ett visst tryck och sedan studera ytan för att se hur den påverkats. Om man förenklar lite så anses cementen ha stelnat när man inte längre lämnar några märken på ytan. Dessa metoder[1] heter the Gillmore needles method och the Vicat needle. Med hjälp av ultraljudseko så kan man studera härdningsprocessen mer ingående samtidigt som man inte gör någon åverkan på själva cementet. 2.2 Ultraljudseko-metoden Denna princip finns beskriven i flera rapporter, till exempel "Monitoring the setting of injectable calcium-based bone cements using pulse-echo ultrasound" [2] och "Monitoring the setting of calcium-based bone cements using pulse-echo ultrasound" [3]. Principen bakom metoden är att mäta två storheter. Man mäter upp ljudhastigheten i cementprovet, och man mäter den akustiska impedansen vid gränsen mellan ett buffertmaterial med kända akustiska egenskaper, och cementprovet. Dessa två storheter används för att 5

15 6 TEORI OCH FÖRUTSÄTTNINGAR Figur 2.1: Labbutrustning för att mäta med ultraljudseko metoden Figur 2.2: Exempel på reflekterad puls

16 2.2. ULTRALJUDSEKO-METODEN 7 beräkna den momentana densiteten. När en ljudvåg kommer till en gräns mellan två material med olika akustiska egenskaper, så reflekteras en del av vågen tillbaka medan resten av vågen fortsätter in i det nya materialet. Hur mycket av vågens energi som reflekteras beror på skillnaden i specifik akustisk impedans. Den specifika akustiska impedansen, z, för ett material har enheten tryck/partikelhastighet (Pa s) och är användbar vid beräkningar av hur mycket av ljudvågens energi som fortsätter genom en gräns mellan två material in i det andra materialet, och hur mycket som reflekteras. För att genomföra mätningarna används labbuppställningen i figur 2.1. Ultraljudsgivaren används först för att skicka ut en kort ultraljudspuls. Sedan används samma givare som en mottagare för att lyssna på de återspeglade ekon som kommer tillbaka. Den elektriska pulsen som mottagits av givaren samplas sedan för att slutligen hamna i en dator. Figur 2.2 visar ett exempel av en mottagen signal från en mätning på ett cementprov. Första ekot x 1 (t) kommer från gränsen mellan Bufferten och provet och det andra ekot kommet från gränsen mellan provet och reflektorn. Förhållandet mellan amplituden hos det första ekot x 1 (t) och motsvarande eko från en kalibreringsmätning med vatten istället för cement i mätutrustningen ger den specifika akustiska impedansen för cementprovet. Tiden mellan de två ekona är tiden det tar för ljudet att gå igenom cementprovet två gånger, avståndet är känt vilket då ger ljudhastigheten i provet. Dessa två storheter kan användas för att ta fram densitet för cementprovet. Reflektionskoefficienten R p,c definieras som mängden reflekterad energi från gränsen mellan bufferten och cementprovet. R p,c = A c A W R p,w (2.1) A c är amplituden hos det första ekot x 1 (t) från gränsen mellan buffert och cementprov. R p,w är reflektionskoefficienten för gränsen mellan buffert och vatten, och A w är amplituden hos första ekot vid kalibreringsmätningen med vatten. Reflektionskoefficienten hos vatten ges av: R p,w = z w z p z w + z p (2.2) där z w och z p är kända specifika akustiska impedansen för vatten respektive bufferten. Amplituden hos ekona är beräknade genom att först transformera de samplade pulserna med diskret fouriertransform, sedan beräkna amplitudförhållandet A c /A w för alla frekvenser inom bandvidden för pulserna. Slutligen beräknas medelvärdet för att få ett medelvärde på dämpningen. När man känner reflektionskoefficienten kan den akustiska impedansen beräknas: z c = z p 1 + R p,c 1 R p,c (2.3) För att bestämma ljudhastigheten i cementprovet korskorreleras de två ekona x 1 (t) och x 2 (t). Maxvärdet hos korskorrelationen motsvarar tidsskillnaden t mellan pulserna. Eftersom sträckan som pulsen passerat är känd, d 2, är ljudhastigheten:

17 8 TEORI OCH FÖRUTSÄTTNINGAR Figur 2.3: Exempel på den specifika akustiska impedansen i ett prov, som funktion av tiden Figur 2.4: Exempel på ljudhastigheten i ett prov, som funktion av tiden

18 2.3. PROBLEMBESTÄMNING 9 Figur 2.5: Exempel på densitet i ett prov, som funktion av tiden c = 2 d 2 t (2.4) Från ljudhastigheten, c, och cementprovets specifika akustiska impedans, z c (Ekvation 2.3), kan densiteten, ρ beräknas: ρ = z c c (2.5) Denna metod ger inte bara härdningstid och densitet, den ger även en möjlighet att studera hela härdningsförloppet. Figur 2.3 visar ett exempel på den specifika akustiska impedansen i ett prov, som funktion av tiden. Figur 2.4 visar ett exempel på ljudhastigheten i ett prov, som funktion av tiden. Figur 2.5 visar ett exempel på densitet i ett prov, som funktion av tiden En stor fördel med metoden är att den är helt objektiv och därför gör det lätt för oberoende forskare att genomföra experimentet och sedan jämföra resultaten. 2.3 Problembestämning Detta arbete syftar till att ta fram en del av en mätutrustning. Hela mätutrustningen kan ses i figur 2.6. En mätning ska gå till på det viset att man från PC:n laddar ned en skräddarsydd exciteringskurva till RAM-minnet. RAM-minnet är uppdelat i en sändbank och en bank för

19 10 TEORI OCH FÖRUTSÄTTNINGAR I/O Sw DA Power Amp Filter Pre Amp AD Analog Digital RAM FPGA USB PC Figur 2.6: Systemskiss av mätutrustning mottagna mätdata. Sedan kan en mätning startas vilket innebär att den data som finns i sändbanken skickas genom digital till analog omvandlaren (DA), den analoga signalen passerar sedan genom en effektförstärkare (Power Amplifier), för att slutligen omvandlas till ultraljud i ultraljudsgivaren. När data är skickat slår utrustningen om till mottagning, och det ultraljud som kommer tillbaka till ultraljudsgivaren filtreras och förstärks innan det passerar genom en analog till digital omvandlare (AD), för att sedan lagras i mottagningsbanken i RAM-minnet. Nu kan man från PC:n läsa ut färdig mätdata. Kommunikationen med PC:n sker som nämnts tidigare genom USB. Den övre delen av figur 2.6 är den analoga delen, och den nedre delen är den digitala. Detta arbete visar hur man kan implementera den digitala delen i en FPGA. Funktionaliteten är beskriven i VHDL, ett hårdvarubeskrivande språk. I denna rapport så kommer jag dock bara att beskriva designen på en högre nivå i termer av block och gränssnitt. 2.4 Analys Hårdvarumässigt består den digitala delen av mätutrustningen av en FPGA, ett RAM-minne och en modul för kommunikation via USB. RAM-minnet och FPGA:n sitter redan på ett prototypkort. Sammankopplingen av de två korten, prototypkortet och USB-modulen togs fram innan fortsatt arbete med programmering av FPGA:n kunde göras. FPGA:n skall utföra flera uppgifter: Styra förstärkningsfaktorn för ingångsförstärkaren.

20 2.4. ANALYS 11 Ställa om mellan sändning och mottagning. Skriva och läsa RAM-minnet från PC. Styra överföring av data från RAM-minnet till DAC:en. Spara undan data från ADC:en i RAM-minnet. Block som uppenbart behövs är dels ett som pratar med USB-kontrollern och ett som sköter SDRAM-modulen. Sedan behövs Styrning av mätarens olika funktioner. Mer om vilka block och gränssnitt som skapats i kapitel 3.7.

21 12 HÅRDVARA OCH DESIGN

22 KAPITEL 3 Hårdvara och design Detta kapitel beskriver först den hårdvara och några av de principer som användes vid utförandet av detta arbete. Hårdvaran som använts i arbetet var en FPGA, en kommunikationskrets för USB och ett prototypkort med en FPGA och SDRAM på. Sedan beskrivs designflödet som används vid implementation av hårdvara med hjälp av VHDL. Den för projektet valda kommunikationsprincipen beskrivs. Sist i kapitlet redovisas den valda designen för projektet. 3.1 FPGA Det finns olika typer av programmerbar logik på marknaden (Programmable Logic Devices, PLD). En typ av PLD är en FPGA, vilket står för Field Programmable Gate Array. En FPGA består av ett mönster av konfigurerbara logikblock (Configurable Logic Blocks, CLB), omgivna av programmerbara I/O-block (IO Blocks, IOB), och sammankopplade med programmerbara kopplingar som kan ses i figur 3.1. Antalet CLB:er i en FPGA varierar mellan några få och flera tusen. Prestanda hos en FPGA beror i stor utsträckning på funktionen hos CLB:erna och möjligheten att med så lite delay som möjligt sammankoppla CLB:er och IOB:er. De flesta FPGA:er är SRAM baserade. En FPGA baserad på SRAM kan programmeras om obegränsat antal gånger, men den måste programmeras varje gång efter man slår på strömmen. FPGA:n som används i detta arbete heter SPARTAN-II XC2S50. Dess CLB-mönster är stort och har således 382 st CLB:er. Den har 176st användbara I/O-pinnar. Och kan, beroende på implementerad konstruktion, klockas upp till 200 MHz 3.2 SDRAM SDRAM står för Synchronous Dynamic Random Access Memory. SDRAM använder en klockpuls för synkronisering, medan standard DRAM är ett icke-synkront minne. SDRAM arbetar med höghastighets-åtkomst, så kallad burst mode, vilken använder sig av en intern adress-kolumngenerator. När den första adresskolumnen för åtkomst är bestämd, kan de 13

23 14 HÅRDVARA OCH DESIGN Figur 3.1: Generaliserad FPGA-struktur följande adresserna automatiskt tas fram av den interna kolumngeneratorn. Mode-registret tar emot den begärda informationen och styr i turordning minnet i enlighet med informationen. Ett SRAM är ett minne som hela tiden håller sitt data så länge strömmen är påslagen, men det tar stor yta på kretsens kiselyta. DRAM är en typ av minne som tar betydligt mindre yta än SRAM, men håller inte kvar sin data hur länge som helst. Därför behöver DRAM uppdateras eller refreshas. SDRAM är som nämnt ovan ett utökat DRAM, så det behöver också refreshas. Det SDRAM som används i detta arbete heter K4S641632F-TC75 från Samsung[4]. Det kan klockas upp till 133 MHz och är uppbyggt av fyra banker med vardera 1Mbit x 16 minnesceller. Antal på varandra följande läsning eller skrivningscykler initierade av ett enda kommando Burst length är 1, 2, 4, 8 eller Full page (det vill säga hela raden 16bitar). Refresh perioden, det vill säga tiden från en refresh till dess att minnet måste refreshas igen. 3.3 USB till parallellt gränssnitt USB to FIFO Parallel Interface Module, DLP-USB245M[5] är en färdig modul för att underlätta kommunikation via USB. Den har färdiga drivrutiner att installera i datorn som maskerar

24 3.3. USB TILL PARALLELLT GRÄNSSNITT 15 FIFO Read Cycle >80 RXF# RD# >50 >50 <30 >10 D[7..0] Valid data RXF# Låg när åtminstone en byte finns i receivebuffer. Dra RD# låg för att läsa första värdet i infifo:n, sätt den hög igen när data är läst. FIFO Write Cycle >80 TXE# >50 >50 WR D[7..0] <20 >10 Valid data När TXE# är hög så är utfifo:n full. För att skriva till utfifo:n sätts först WR hög. Sedan läggs datat ut på datapinnarna, WR sätts låg för att läsa av datat. Datapinnarna släpps. Figur 3.2: DLP-USB245M Hårdvaruinterface hårdvaran som en vanlig RS232 seriell port, men med mycket högre hastighet (så kallad baud rate inställning ignoreras). På hårdvarusidan har den ett gränssnitt för att läsa och skriva parallell (8 bitar) data åt gången som kan ses i figur 3.2.

25 16 HÅRDVARA OCH DESIGN VHDL kodeditering Funktions simulering ModelSim Begränsningar (Constraints) syntes Synplify översättning Mappning Place and route "Back annotation" Timing simulering Statisk timing analys Figur 3.3: Designflöde 3.4 Prototypkort Prototypkort XSA-50 Från XESS Corp.[6]. Kortet är bestyckat med en Spartan-II (XC2S50) FPGA från Xilinx[7]. FPGA:n är kombinerad med ett 8 Mbyte stort Synkront DRAM. Bitströmmen man vill programmera FPGA:n med kan sparas i ett Flash minne, så att FPGA:n blir konfigurerad så fort strömmen slås på. Kortet har även en parallellport genom vilken man kan ladda FPGA:n med hjälp av verktyg framtagna av XESS Corp. Kortet har även en programmerbar oscillator på 100 MHz, frekvensen kan ställas i jämna delar av 100 MHz till exempel 50, 25, 12.5, 6.25 MHz. För detta projekt krävs möjlighet att komma åt många av FPGA:ns pinnar från resterande hårdvara. Kortet har 84 anslutningar för att kunna kommunicera med ytterligare elektronik, men med olika restriktioner.

26 3.5. DESIGNFLÖDE Vänta Data esc Vänta esc Data 4 Figur 3.4: Tillståndsmaskin för avkodning av paketerade meddelanden 3.5 Designflöde Det syntesverktyg jag använt heter Synplify[8], och är även det program jag använt för att skriva och editera koden. För att simulera koden har ett program som heter Modelsim[9] använts. Slutligen har Xilinx[7] mjukvara använts för att kompilera nätlistor till bitmönster att programmera FPGA:n med. Här följer en genomgång av stegen från VHDL kod till färdig kretsbeskrivning i bitströmsform. Stegen kan även följas i figur 3.3. Först kommer funktionssimulering, som används för att kolla att VHDL beskrivningen är korrekt och beter sig på det vis man tänkt. I detta läge kan man dock inte testa tidsberoendet, det vill säga inte hitta fel som uppkommer av för stora delayer eller dylikt. Syntes kan definieras som att konstruera en mål-specifik nätlista från en beskrivning skriven i ett hårdvarubeskrivande språk till exempel VHDL. Synplify är ett program speciellt gjort för syntes och optimering för FPGA och avancerade PLD:er. Det finns flera steg i syntesen. Första steget är språksyntes; det hårdvarubeskrivande språket kompileras till kända byggstenar. Andra steget är optimering, där algoritmer används för att göra kretsen så liten och snabb som möjligt. Första optimeringen är oberoende av målteknologin och därför enkel, medan resten av optimeringen är gjord under sista steget. Sista steget är mappning till målteknologin. Målspecifika tekniker används, och en nätlista genereras i ett format som till exempel Xilinx place and route verktyg kan läsa. Xilinx mjukvara gör också den saker i flera steg. Första steget är översättning, där program-

27 18 HÅRDVARA OCH DESIGN met läser nätlistan från syntesprogramvaran och översätter den till ett för verktyget specifikt binärt format. Andra steget är Mappning, det vill säga att tilldela kretsens logiska byggstenar till specifika fysiska element, så som CLB:er och IOB:er. Tredje steget består av två delar nämligen place and route eller placering och sammankoppling. Placeringen består i att placera ut de block som under mappningen tilldelades uppgifter. Sammankopplingen är sedan just kopplingen mellan dessa logiska block. Efter dessa steg är implementationen klar och statisk tidsanalys kan göras. Man kan även utföra en så kallad Back annotation då den implementerade kretsen konverteras till en VHDL-nätlista och tidsdata är uttagna till en standard delay format (SDF) fil. Detta görs för att kunna göra tidssimuleringar av den färdiga implementationen, viket görs för att kolla att funktionen är den rätta och att det inte finns några tidsproblem i den färdiga designen. 3.6 Paketbaserad kommunikation För att skapa en fungerande kommunikation bör den ske i paketform, det vill säga ett paketformat definieras, vilket sedan går att följa för att avkoda de olika meddelanden som kan skickas över USB-porten. Enligt den definition av paketformat jag använt behövs ett escapetecken, en början respektive slut sekvens och ett id, alla delar är av bytestorlek. Till exempel: Paket innehållande ett kommando identifierat genom Id. [Esc][Begin][Id][Esc][End] Paket innehållande data identifierat genom Id. [Esc][Begin][Id][Data0][Data1]...[Datan][Esc][End] Id-byten talar om vad det är för paket som har överförts. Eftersom escapetecknet även måste användas i datat då det representerar ett värde, måste man behandla dem på ett särskilt sätt. Varje gång man vill skicka värdet som escape-tecknet representerar måste man sända två escape-tecken efter varandra, för att det inte ska feltolkas som en början- eller slutsekvens. I figur 3.4 beskrivs uppackning av ett paket konstruerat enligt ovan angivna format. Det kan dock påpekas att vid denna uppackning tas ingen hänsyn till idtecken, vilket resulterar i att man efter uppackning får en rad med bytes av vilka den första är idtecknet och eventuell fortsättning är data. Här kommer en beskrivning av villkor och resultat av tillståndsbyten i maskinen: 1. Maskinen står kvar i Vänta-läge så länge det inte kommer ett escapetecken. 2. Om ett escapetecken mottagits går maskinen till läget Vänta-esc. 3. I det fall att man i Vänta-esc tillståndet får det tecken som tillsammans med escapetecknet formar börjasekvensen går man vidare för att vänta på innehållet i paketet. 4. Så länge ny data innehållande vilket tecken som helst, för utom escapetecknet så fortsätter maskinen i Data-tillståndet och sparar undan de tecken som mottages. 5. I det fall ett escapetecken mottages så går maskinen till läget Data-esc för att kunna avgöra om det är en databit eller en styrsignal, till exempel början eller slut sekvens.

28 3.7. DESIGN 19 main 50MHz mem_usb_bridge USB245M usb_cntr rx/tx fifo gränssnitt registers config värden SDRAM gränssnitt xsasdramcntl SDRAM measure_cntr DATA IO gränssnitt AD/DA frekvens Figur 3.5: Block och gränssnitt i FPGA:n 6. Om det i en dataföljd kommer två på varandra följande escapetecken så representerar det värdet hos escapetecknet, och maskinen återgår till att vänta på data. Om man av någon anledning skulle få en startsekvens under Data-esc tillståndet, vilket man inte bör få om allt fungerar som det ska, så måste databufferten tömmas innan maskinen går till Data-tillståndet för att ta emot det nya paketet. 7. När slutsekvensen kommer så har man ett helt paket och kan gå vidare till att processa den data man fått eller gå tillbaka till Väntatillståndet, för att invänta nästa paket. 8. Om man i Vänta-esc inte erhåller ett tecken som tillsammans med escapetecknet bildar börjasekvensen så återgår man till Väntaläge för att invänta början på ett paket. 9. I det fall att ett escapetecken mottages i Vänta-esc tillståndet så står maskinen kvar i Vänta-esc då det kan vara början på en börjasekvens. 3.7 Design För att förklara funktionaliteten ska jag här beskriva vilka block jag valt att dela upp konstruktionen i. Hur blocken pratar med varandra dvs deras gränssnitt. Detta utan att gå ner på allt för djup nivå, se figur 3.5.

29 20 HÅRDVARA OCH DESIGN Block Inneslutande alla andra block har jag toppblocket, som jag kallat "main". För att prata med USB kontrollern har jag sedan "usb_cntr". Som SDRAM modul använder jag en något modifierad och buggfixad variant av en färdig SDRAM kontroller hämtad från XESS hemsida, de kallar den för "xsasdramcntl". Sedan har vi själva funktionaliteten hos mätaren, för att det inte ska bli för otymplig kod har jag valt att dela upp hanteringen av olika kommandon i tre block. Dessa block är mem_usb_bridge, register och measure_cntr vilkas funktion beskrivs nedan main Huvudblocket main representerar hur de övriga blocken ska kopplas samman och hur de ska kopplas till omvärlden. Detta block kan ses i figur 3.5, allt inom den grövre streckade linjen är main blocket. Denna figur beskriver mycket av den funktion main blocket har usb_cntr Denna enhet tar emot kommando och data paket skickade från PC:n och sänder även tillbaka svar till PC:n från de tre styrblocken. Innehåller mottagande och sändande först in först ut buffertar, så kallade FIFO buffertar. Har hand om kommunikationen med USB enheten, DLP-USB245M. DLP-kretsen innehåller även den två köer (FIFO) en för sändning och en för mottagning. Dessa fungerar som en buffert mot USB-porten så att man inte behöver synkronisera med datorn. DLP enheten kräver en specifik styrning och synkronisering som kunde ses i figur 3.2. Det är dock en klar fördel att inte behöva hantera USB-portens protokoll utan istället kunna läsa och skriva en byte åt gången. Detta block innehåller uppackning av paket på det sätt som fins beskrivet i kapitel mem_usb_bridge Styrblock nummer ett är dedikerat åt att låta PC:n skriva och läsa i SDRAM minnet. När detta block blir aktiverat för att läsa eller skriva så börjar det med att avkoda kommandot som skickats. Vid läsning så kommer först startadressen, på vilken position i minnet det första värdet ska läsas ifrån. Sedan kommer stopadressen, på vilken läsningen från minnet ska avslutas. Vid skrivning kommer först en startadress på vilken det första värdet ska skrivas, sedan kommer datat. Vid en läsning så läses alla värden från minnet som ligger mellan start och slutadressen och placeras i sändfifon hos usb_cntr, vid en skrivning så placeras alla data som finns i usb_cntr:s mottagningsbuffert från startadressen och framåt i minnet registers Styrblock nummer två innehåller register som kan hålla konfigurationsdata som skickas från PC:n, vilka används vid mätning. SDRAM minnet är, som tidigare nämnt, uppdelat i Mottagande, Rx, och sändande, Tx, del. Den sändande delen är där instrumentet tar den stimuli som skickas till ultraljudsgivaren vid excitering. De ekon som sen mottages samplas till den mottagande delen av minnet. Här följer en lista med de register som finns och vad deras konfigurationsvärde representerar.

30 3.7. DESIGN 21 RxBufferBegin Adressen för början på det mottagande minnet. RxBufferEnd Adressen för slutet på det mottagande minnet. TxBufferBegin Adressen för början på det sändande minnet. TxBufferEnd Adressen för slutet på det sändande minnet. RxGain Förstärkningsgraden hos den ingående förstärkaren. TriggerDelay Den tid instrumentet ska vänta från det att den sänt allt i sändbufferten tills dess att den ska börja sampla nya invärden measure_cntr Styrblock nummer tre är det som styr själva mätningen. När en mätning aktiveras så är det detta block som tar kommandot i FPGA:n och ser till att mätningen utförs enligt plan. Ultraljudsgivaren exciteras med signalen som finns i SDRAM, sedan ställs mätaren om till mottagning och ekot sparas i en annan del av SDRAM minnet. Även förstärkningen hos ingångsförstärkaren ställs in i enlighet med konfigurationen xsasdramcntl En SDRAM kontroller från labbkortstillverkaren har använts. Application Note av D. Vanden Bout, XSA Board SDRAM Controller [10] innehåller en fungerande kontroller och ett testprogram. Kontrollern finns för att underlätta läsning och skrivning mot SDRAM modulen, och för att underhålla den med refresch signaler inom rätt intervall. Mer om SDRAM modulen hittas i kapitel Gränssnitt Vi kan dela in gränssnitten i externa och interna gränssnitt. De externa gränssnitten är det som usbmodulen, DLP-USB245M, använder, det som SDRAM minnet använder och slutligen gränssnittet mot DA och AD omvandlare, Data IO. Dessa externa gränssnitt är det vi har att arbeta mot. De interna gränssnitten däremot är skapade för att separera funktionaliteten hos instrumentet på ett så logiskt och lättarbetat sätt som möjligt. De interna gränssnitten har jag döpt till rx/tx fifo och r/w SDRAM. Nedan följer en beskrivning av dessa gränssnitt.

31 22 HÅRDVARA OCH DESIGN 1 6 Vänta 2 3 Klar Kolla 5 4 Styrning av modulens funktion Figur 3.6: rx/tx fifo-gränssnitt, för styrblocken DLP-USB245M Ett externt gränssnitt som implementerats i usb_cntr blocket och som beskrivs närmare i kapitel rx/tx fifo När ett helt paket är mottaget så flaggar usb_cntr för att ett nytt kommando ligger och väntar. Då kollar alla styrblocken om det är ett kommando de ska ta hand om, annars går de och vilar igen. Från usb_cntr:ens sida väntar den bara på en klar signal från någon av styrenheterna, för att sedan åter vara beredd att motta fler paket. Usb_cntr kontrollerar vid klarsignal om sin sändfifo är tom annars sänds det som ligger i fifon innan den åter väntar på nästa anländande paket. För att svara mot detta gränssnitt har alla styrblock samma grund i sina tillståndsmaskiner. Denna grund kan ses i figur 3.6. Denna tillståndsmaskin fungerar på följande sätt (siffror i figuren): 1. Väntar på att få reda på att ett paket är mottaget 2. När ett nytt paket är mottaget så är första biten i rxfifon idbiten och alla styrblock kan se den. Alla går till kontrolltillståndet för att se om det är det som ska vakna. 3. Om Id:t inte känns vid av det aktuella blocket så går det åter och väntar på nästa paket.

32 3.7. DESIGN 23 clk rd haddr A1 A2 A3 earlyopbegun done hdout D(A1) D(A2) D(A3) Figur 3.7: SDRAM-kontroller läsoperation clk wr haddr A1 A2 A3 hdin D1 D2 D3 earlyopbegun Figur 3.8: SDRAM-kontroller skrivoperation 4. När ett paket har ett id som blocket känner igen så vaknar det upp och utför sin uppgift. 5. Efter att blocket utfört sin uppgift så går den till ett tillstånd för att signalera att uppgiften är slutförd, så att instrumentet kan fortsätta med nästa uppgift. 6. Efter att ha signalerat "uppgift slutförd" så återgår blocket till att vänta på nästa paket r/w SDRAM SDRAM kontrollern xsasdramcntl[10] har ett gränssnitt som lättast beskrivs med några kurvor. Figur 3.7 visar hur läsning av i det här fallet tre värden från minnet går till. Man börjar med att sätta haddr till den första adressen man vill läsa, och sätter rd till 1. earlyopbegun talar om ifall adressen har mottagits och man kan byta adress till nästa klockcykel. om inte early- OpBegun är hög så får man vänta tills den är aktiveras innan man går vidare och byter adress. Data finns sedan att hämta från hdout när done-signalen är hög. Figur 3.8 visar en skrivning av tre data till minnet går till. Adressen man vill skriva till läggs på haddr och datat man vill

33 24 HÅRDVARA OCH DESIGN Tecken Värde(Dec) Värde(Hex) [Esc] [Begin] 2 02 [End] 3 03 Tabell 1: ASCII-värden valda för paketkommunikation skriva läggs på hdin, sedan sätter man wr hög och byter till nya data med respektive adress om earlyopbegun är hög. Detta gränssnitt gör det möjligt att skriva eller läsa data nästan på varenda klockcykel, så länge minnet inte behöver göra refreschcykler SDRAM Det externa gränssnitt mellan minnesmodulen och FPGA:n som i detta arbete implementeras av ett färdigt block från tillverkaren av prototypkortet. Blocket kallas xsasdramcntl. Minnesmodulen beskrivs i kapitel DATA IO Detta interface är inte riktigt färdigdefinierat då den analoga sidan av instrumentet inte är färdigt. I specifikationen så anges en 12 bitars analog till digital omvandlare, som använder en klockfrekvens på 65 MHz. På grund av att minnet ska hinna med kommer instrumentet att använda en annan klockfrekvens än omvandlaren. Instrumentet måste klockas snabbare än omvandlaren för att hinna spara undan de data som kommer från den. En asynkron fifo används för att synkronisera mellan de två klockdomänerna. Om man i framtiden vill använda en 16 bitars omvandlare är det också möjligt då jag bara bortser från de extra bitar som finns tillgängliga. Gränssnittet har två 16 bitars asynkrona fifos, en för in och en för ut data så att både analog till digital och digital till analog omvandlaren existerar i 65 MHz-domänen. De två klockdomänerna kan ses i fig Kommunikation Kommunikationen mellan datorn och mätutrustningen görs i paketform, som beskrivet tidigare (kapitel 3.6). Detta paketsystem är uppbyggt på escapesekvenser. Med Värden enligt Tabell 1. Escapesekvenserna är: [Esc][Begin] - Börjasekvensen, som alla paket inleds med. [Esc][End] - Slutsekvensen, som avslutar alla paket. [Esc][Esc] - Om man i ett paket vill få med värdet av escapetecknet så måste man skicka det som två på varandra följande escapetecken. Olika kommandon har olika id, så här följer en lista på de kommandon som instrumentet svarar på, vilket id de har och vad de representerar. Id:t är skrivet både som decimaltal och hexadecimalt på formen Dec(xHex). Vad de olika registren representerar kan ses i kapitel

34 3.7. DESIGN 25 setrxbufferbegin Id: 20(x14). Kommandot skriver ett 32 bitars konfigurationsvärde till RxBuffertBegin registret. getrxbufferbegin Id: 21(x15). Kommandot läser ut ett 32 bitars konfigurationsvärde från RxBuffertBegin registret. setrxbufferend Id: 22(x16). Kommandot skriver ett 32 bitars konfigurationsvärde till RxBuffertEnd registret. getrxbufferend Id: 23(x17). Kommandot läser ut ett 32 bitars konfigurationsvärde från RxBuffertEnd registret. settxbufferbegin Id: 24(x18). Kommandot skriver ett 32 bitars konfigurationsvärde till TxBuffertBegin registret. gettxbufferbegin Id: 25(x19). Kommandot läser ut ett 32 bitars konfigurationsvärde från TxBuffertBegin registret. settxbufferend Id: 26(x1A). Kommandot skriver ett 32 bitars konfigurationsvärde till TxBuffertEnd registret. gettxbufferend Id: 27(x1B). Kommandot läser ut ett 32 bitars konfigurationsvärde från TxBuffertEnd registret. setrxgain Id: 30(x1E). Kommandot skriver ett 16 bitars konfigurationsvärde till RxGain registret. getrxgain Id: 31(x1F). Kommandot läser ut ett 16 bitars konfigurationsvärde från RxGain registret. settriggerdelay Id: 32(x20). Kommandot skriver ett 16 bitars konfigurationsvärde till TriggerDelay registret. gettriggerdelay Id: 33(x21). Kommandot läser ut ett 16 bitars konfigurationsvärde från TriggerDelay registret. start Id: 44(x2C). Kommandot startar en mätning, förutsatt att konfigurationsvärden är satta rätt så genomförs en mätning.

35 26 IMPLEMENTATION OCH RESULTAT writememory Id: 50(x32). Skriver data till minnet. Tar först ett 32 bitars värde som anger startadressen. sedan följer 16 bitars data, så många man vill skriva. readmemory Id: 51(x33). Läser data från minnet. Tar två 32 bitars värden, där det första är startadressen och det andra är stopadressen. Kommandot returnerar alla 16 bitars värden mellan de två adresserna.

36 KAPITEL 4 Implementation och resultat Kapitlet redogör för hur implementationen gått och de resultat som uppnåtts. Först det fysiska byggandet av labbsystemet, sedan verifiering av detsamma. Slutligen implementationen av de olika delarna av designen. 4.1 Koppling Sammankopplingen av de två korten, XSA-50-kortet och DLP-USB245M-kortet gjordes på ett prototypkort. Ett problem för kopplingen mellan de två är att hitta oanvända pinnar från FPGA:n, som även är uttagna till XSA-kortets prototypanslutningar. Vid en snabb titt, närmare bestämt när det beslutades att detta kort skulle användas för framtagning av utrustningen, så såg det ut att inte vara något problem, sådär en pinnar såg ut att vara nåbara. Det har dock visat sig att många av FPGA:ns pinnar används för kopplingar till de kretsar som redan finns på XSA-kortet, helt obundna är endast nio av pinnarna. Detta i kombination med att pinnarna från FPGA:n är utdragna till prototypanslutningarna på ett sådant sätt att de inte är i ordning, gör planeringen av kopplingarna komplicerad. För att kunna använda de resterande pinnarna måste man ta särskild hänsyn och även skriva in rutiner för att kunna använda vissa. 4.2 Verifiering av hårdvara För detta arbete så finns det två distinkta delar som måste fungera för att arbetet ska gå att genomföra, nämligen minnet och kommunikationen genom usb. Att testa om minnet fungerar eller inte gick att genomföra med exempelkod tillhandahållen av labbkortstillverkaren. Dock var denna kod dåligt dokumenterad så det krävdes laborerande innan det gick att avgöra att minnet var ok. Det var lite svårare att avgöra om kommunikationen via usb fungerar då det inte finns någon färdig kod för detta, och då man måste ha något sätt att avgöra om man lyckas överföra något. Ett annat problem var att de fanns olika drivrutiner till USB-modulen. En drivrutin som simulerar att den är en comport fick jag slutligen att fungera tillsammans med programmet som körs på PC:n för att kommunicera med modulen. 27

37 28 IMPLEMENTATION OCH RESULTAT En enkel kommunikationskod för att ta emot data från datorn skrevs och även en modul för att kunna visa tal på den på labbkortet inbyggda lysdiodsdisplayen. Fel uppstod till synes slumpmässigt och djupare undersökning krävdes. Kod för att kunna sända data till datorn skrevs och det var nu lättare att felsöka kommunikationen. Efter många försök visade det sig att två ledningar som valts inte var lämpliga eftersom de var beroende respektive användes till lysdiodsdisplayen. Manualen till labbkortet luslästes och två nya ledningar valdes. Vid dessa test hade en annan än den önskade klockfrekvensen använts och koden fungerade bara vid denna frekvens, men den kunde i alla fall påvisa att hårdvaran för USB-kommunikationen fungerade som den ska. 4.3 Kommunikation Komplexiteten i att designa ett kommunikationssystem är ganska stor när man ska göra det i hårdvara, så denna del krävde noga planering och många test testbänk För att kunna testa om kommunikationen fungerar genom simulering kräver det att man skriver en testbänk. I detta fall behövs en testbänk som simulerar USB-modulens funktionalitet utveckling och simulering Efter ovärderlig hjälp från min handledare, fungerar nu kommunikationen felfritt. Förbättringar är möjliga, mer om det nämns senare i raporten i kapitlet diskussion och slutsatser test på hårdvara Från början användes ett testprogram som tillverkaren av DLP-USB245M modulen tillhandahåller. Denna var dock något instabil och var inte så lämpad för uppgiften. För att kunna testa kommunikationen på ett mer systematiskt sätt så skrevs ett litet Java-program som kommunicerar med instrumentet via drivrutinen som maskerar usb:n som en comport. Javaprogrammet utökades ytterligare för att kunna användas som modul för Matlab. Denna modul har genomgått test, i form av slumptal som skrivits till minnet och sedan lästs tillbaka för att slutligen jämföras med den data som skrevs till minnet. Hela minnet skrevs och lästes upprepade gånger i överföringar av skiftande storlek, inga fel uppstod. 4.4 Minne Minnesmodulen SDRAM minnet krävde en del arbete trotts att jag här använde en färdig kontroller.

38 4.5. MÄTNING testbänk Från Samsung så fick jag tag i en verilog-modell av minnet som gick att simulera emot. Efter att ha justerat min testbänk att lägga in en viss fördröjning mellan minnet och FPGA:n så fungerade den utveckling och simulering Application Note av D. Vanden Bout, XSA Board SDRAM Controller [10] innehåller en fungerande kontroller och ett testprogram. Dock hade jag problem att simulera kontrollern, men efter att ha rättat några småfel i deras kod så fungerar den i simulatorn test på hårdvara Kontrollern fungerade redan utan korrigeringar i hårdvaran, men jag antar att det inte spelar någon roll om den får göra åtskilliga instruktioner i början för att en räknare "slår över". En räknare som ska vara 0 blir satt till räknarens maxvärde av misstag under initieringen, och så många instruktioner utförs. 4.5 Mätning Då det inte finns tillräckligt med pinnar på labbkortet för att fysiskt kunna koppla in riktiga AD- och DA-omvandlare så får det bli någon annans uppgift att ta ett annat labbkort som är mer lämpat för uppgiften och bygga ihop den färdiga mätaren. Dock tänker jag genom simulering visa att koden har stöd för de funktioner som då kommer att behövas testbänk Utökas med möjlighet att läsa indata från en fil. Enkla modeller för AD- och DA-omvandlarna har även skapats utveckling och simulering Styrning av mätförloppet. measure_cntr-blocket som styr hela mätningen börjar med att läsa från minnet de data som ligger på adresserna mellan txbufferbegin och txbufferend. Datat matas in i en asynkron fifo som används för att länka mellan de två klockdomänerna. När fifon är full eller när det är slut på data att skicka, vilket som händer först, så börjar instrumentet skicka data till ultraljudsgivaren. När fifon är tom så väntar instrumentet ett förutbestämt antal klockcykel, triggerdelay. Sedan aktiveras analog till digital omvandlaren och en mottagande asynkron fifo börjar fyllas, samtidigt som instrumentet skriver data till minnet så fort det finns data i fifon. Datat skrivs från adressen rxbufferbegin och framåt. En räknare håller reda på hur många mätvärden som läses in, det vill säga hur många klockcykler som passerar i omvandlarnas tidsdomän från det att AD-omvandlaren aktiveras. När önskat antal mätningar

39 30 DISKUSSION OCH SLUTSATSER gjorts, det vill säga rxbufferend-rxbufferbegin så avslutas mätningen och instrumentet återgår till viloläge.

40 KAPITEL 5 Diskussion och slutsatser Detta kapitel behandlar det slutliga resultatet och vad som skulle gå att göra bättre. Slutligen nämns även möjligheter till fortsatt arbete. 5.1 Mätinstrumentet Omfattningen av detta exjobb var att implementera den digitala delen av ett mätinstrument för mätning enligt ultraljudseko-metoden. Instrumentet ska kunna utföra följande. Styra en 12 bitars ADC, klockad i 65 MHz. Styra förstärkningsfaktor hos ingångsförstärkaren. Styra mätningsförloppet, med sändning fördröjning och mottagning. Konfigureras och ange aktuell konfiguration. Bli initierad med exciteringsdata, och läsa tillbaka exciteringsdata redan i minnet. läsa ut mottagen data, och skriva över den mottagna datan. Då endast den digitala delen av instrumentet är färdig finns ingen AD eller DA att testa mot, men dessa delar är testade med simulering. Övriga delar fungerar enligt ovan. För att kunna bygga en färdig mätare måste ett annat labbkort eller ett egenkostruerat kretskort användas som har möjlighet att använda fler av FPGA:ns datapinnar. Av detta arbete kan man dra slutsatsen att använd FPGA och Minnesmodul är väl valda för uppgiften och att det nu finns en plattform att bygga ett färdigt instrument på. 5.2 Möjliga förbättringar SDRAM minnet borde gå att använda som buffert för usbkommunikationen förutsatt att inte hela minnet används just vid det tillfället, som till exempel vid laddning av exciteringspuls till 31

41 32 DISKUSSION OCH SLUTSATSER instrumentet. Detta skulle göra att hela pulsen kunde skickas i ett stort paket utan att tumma på paketprotokollet. Som designen är nu finns det möjlighet att låsa instrumentet så att man måste starta om det. Detta skulle gå att komma runt men kräver omstruktureringar. 5.3 Fortsatt arbete Detta arbete blir lite haltande fram till dess att någon tar sig an att göra den analoga sidan av mätinstrumentet. Jag hoppas därför att någon tar sig an denna uppgift så snart som möjligt.

42 Referenser [1] J. Carlson, M. Nilsson, E. Fernández, and J. Planell, Monitoring the setting of injectable calcium-based bone cements using pulse-echo ultrasound, in IEEE Int. Ultrason. Symp., (Munich, Germany), pp , [2] M. Nilsson, J. Carlson, E. Fernández, and J. Planell, Monitoring the setting of calciumbased bone cements using pulse-echo ultrasound, Journal of Materials Sience, vol. 37, no. 13, pp , [3] J. Carlson, M. Nilsson, E. Fernández, and J. Planell, An ultrasonic pulse-echo technique for monitoring the setting of CaSO 4 -based bone cement, Biomaterals, vol. 24, no. 1, pp , [4] S. electronics, [5] D. D. Inc, [6] X. E. S. S. Corp., [7] X. Inc, [8] S. Inc, [9] M. T. Inc, [10] D. V. Bout, Xsa board sdram controller, application note, XESS Corp.,