EXAMENSARBETE
2004:250 CIV
Harald Stribén
USB-kommunikation med
programmerbar ultraljudssändare
CIVILINGENJÖRSPROGRAMMET
Luleå tekniska universitet
Institutionen för systemteknik, Avdelningen för datorteknik
2004:250 CIV • ISSN: 1402 - 1617 • ISRN: LTU - EX - - 04/250 - - SE
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
ii
A BSTRACT
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.
iv
S AMMANFATTNING
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 komp- likationer. 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å.
vi
I NNEHÅLL
KAPITEL1: INLEDNING 3
KAPITEL2: TEORI OCH FÖRUTSÄTTNINGAR 5
2.1 Härdningstid för bencement . . . 5
2.2 Ultraljudseko-metoden . . . 5
2.3 Problembestämning . . . 9
2.4 Analys . . . 10
KAPITEL3: HÅRDVARA OCH DESIGN 13 3.1 FPGA . . . 13
3.2 SDRAM . . . 13
3.3 USB till parallellt gränssnitt . . . 14
3.4 Prototypkort . . . 16
3.5 Designflöde . . . 17
3.6 Paketbaserad kommunikation . . . 18
3.7 Design . . . 19
KAPITEL4: IMPLEMENTATION OCH RESULTAT 27 4.1 Koppling . . . 27
4.2 Verifiering av hårdvara . . . 27
4.3 Kommunikation . . . 28
4.4 Minne . . . 28
4.5 Mätning . . . 29
KAPITEL5: DISKUSSION OCH SLUTSATSER 31 5.1 Mätinstrumentet . . . 31
5.2 Möjliga förbättringar . . . 31
5.3 Fortsatt arbete . . . 32
viii
F ÖRORD
Denna rapport är skriven som examensarbete på civilingenjörsprogrammet datateknik med in- riktning 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 exa- mensarbete 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 2004.
2 INLEDNING
K APITEL 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 an- nat 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 billi- gare 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äd- darsydd 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 kom- munikation 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 im- plementera 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.
4 TEORI OCH FÖRUTSÄTTNINGAR
K APITEL 2 Teori och förutsättningar
I detta kapitel förklaras teorier och metoder använda i detta arbetet. Först kommenteras exis- terande standardmetoder för att estimera härdningstiden hos bencement. Sedan beskrivs grun- derna 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 karak- täriseras utifrån sina mekaniska egenskaper. En av de viktigaste egenskaperna är härdningsti- den. 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 in- jectable 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 ce- mentprovet, och man mäter den akustiska impedansen vid gränsen mellan ett buffertmate- rial med kända akustiska egenskaper, och cementprovet. Dessa två storheter används för att
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
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å skill- naden 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 x1(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 x1(t) och motsvarande eko från en kalibreringsmätning med vatten istället för cement i mätutrust- ningen 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 cement- provet.
Reflektionskoefficienten Rp,c definieras som mängden reflekterad energi från gränsen mel- lan bufferten och cementprovet.
Rp,c = Ac
AWRp,w (2.1)
Ac är amplituden hos det första ekot x1(t) från gränsen mellan buffert och cementprov.
Rp,w är reflektionskoefficienten för gränsen mellan buffert och vatten, och Aw är amplituden hos första ekot vid kalibreringsmätningen med vatten. Reflektionskoefficienten hos vatten ges av:
Rp,w = zw− zp
zw+ zp (2.2)
där zw och zp ä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 Ac/Aw 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:
zc = zp1 + Rp,c
1 − Rp,c (2.3)
För att bestämma ljudhastigheten i cementprovet korskorreleras de två ekona x1(t) och x2(t). Maxvärdet hos korskorrelationen motsvarar tidsskillnaden ∆t mellan pulserna. Efter- som sträckan som pulsen passerat är känd, d2, är ljudhastigheten:
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
2.3. PROBLEMBESTÄMNING 9
Figur 2.5: Exempel på densitet i ett prov, som funktion av tiden
c = 2d2
∆t (2.4)
Från ljudhastigheten, c, och cementprovets specifika akustiska impedans, zc(Ekvation 2.3), kan densiteten, ρ beräknas:
ρ = zc
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
10 TEORI OCH FÖRUTSÄTTNINGAR
Power Amp Pre Amp
FPGA
PC USB
RAM
Filter
DA AD
I/O Sw
Digital Analog
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änd- banken 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. Funktion- aliteten ä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 pro- totypkort. 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.
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.
12 HÅRDVARA OCH DESIGN
K APITEL 3 Hårdvara och design
Detta kapitel beskriver först den hårdvara och några av de principer som användes vid utföran- det 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 16 × 24 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
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 min- nesceller. Antal på varandra följande läsning eller skrivningscykler initierade av ett enda kom- mando “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 under- lätta kommunikation via USB. Den har färdiga drivrutiner att installera i datorn som maskerar
3.3. USBTILL PARALLELLT GRÄNSSNITT 15
RXF# Låg när åtminstone en byte finns i receivebuffer.
5..25 >80
>50 >50
<30 >10
D[7..0]
RD#
RXF#
Valid data
D[7..0]
TXE#
Valid data WR
FIFO Read Cycle
igen när data är läst.
FIFO Write Cycle 5..25 >80
>50 >50
<20 >10
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.
Dra RD# låg för att läsa första värdet i inFIFO:n, sätt den hög
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.
16 HÅRDVARA OCH DESIGN
VHDL kodeditering
Funktions−simulering ModelSim
syntes Synplify Begränsningar
(Constraints)
Statisk timing−
"Back annotation" Timing−simulering Mappning
översättning
analys Place and route
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. Bit- strö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 program- merbar 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.
3.5. DESIGNFLÖDE 17
9
Data−esc Vänta−esc
Data Vänta
1
2
3
4 5
6 7
8
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] an- vä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öms- form. 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-
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 plac- era 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 implementer- ade 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 implementatio- nen, 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 paketfor- mat 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 iVänta-lägeså länge det inte kommer ett escapetecken.
2. Om ett escapetecken mottagits går maskinen till lägetVänta-esc.
3. I det fall att man i Vänta-esc tillståndet får det tecken som tillsammans med es- capetecknet 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ät- ter maskinen iData-tillståndet och sparar undan de tecken som mottages.
5. I det fall ett escapetecken mottages så går maskinen till lägetData-escför att kunna avgöra om det är en databit eller en styrsignal, till exempel början eller slut sekvens.
3.7. DESIGN 19
DATA IO gränssnitt usb_cntr
rx/tx fifo gränssnitt
mem_usb_bridge
registers
config värden
measure_cntr
SDRAM gränssnitt
xsasdramcntl
USB245M SDRAM
main 50MHz
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-esctillståndet, vilket man inte bör få om allt fungerar som det ska, så måste databufferten tömmas innan maskinen går tillData-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 tillVä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 tillVäntalägeför att invänta början på ett paket.
9. I det fall att ett escapetecken mottages iVänta-esctillståndet så står maskinen kvar i Vänta-escdå 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 konstruk- tionen 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.
20 HÅRDVARA OCH DESIGN
3.7.1 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 mod- ifierad 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.
3.7.1.1 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.
3.7.1.2 usb_cntr
Denna enhet tar emot kommando och data paket skickade från PC:n och sänder även till- baka 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 synkronis- era 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 3.6.
3.7.1.3 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 avs- lutas. 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.
3.7.1.4 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 Mot- tagande, 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 kon- figurationsvärde representerar.
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.
3.7.1.5 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. Ultraljudsgi- varen 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.
3.7.1.6 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 test- program. 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 3.2.
3.7.2 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.
22 HÅRDVARA OCH DESIGN
modulens funktion 1
2
3
5 4
6 Vänta
Kolla Klar
Styrning av
Figur 3.6: rx/tx fifo-gränssnitt, för styrblocken
3.7.2.1 DLP-USB245M
Ett externt gränssnitt som implementerats i usb_cntr blocket och som beskrivs närmare i kapitel 3.3.
3.7.2.2 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.
3.7. DESIGN 23
clk
A1 A2 A3
D(A3) D(A2)
D(A1)
rd
0 1 2 3 4 5 6 7 8
done hDOut earlyOpBegun hAddr
Figur 3.7: SDRAM-kontroller läsoperation
clk
hAddr
0 1 2 3 4 5
hDIn D1 D2 D3
A1 A2 A3
earlyOpBegun hAddr wr
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.
3.7.2.3 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
24 HÅRDVARA OCH DESIGN
Tecken Värde(Dec) Värde(Hex)
[Esc] 16 10
[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.
3.7.2.4 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. Minnes- modulen beskrivs i kapitel 3.2.
3.7.2.5 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 an- vä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 3.5.
3.7.3 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 3.7.1.4.
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 reg- istret.
• 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 reg- istret.
• 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.
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 star- tadressen och det andra är stopadressen. Kommandot returnerar alla 16 bitars värden mellan de två adresserna.
K APITEL 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 50-60 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.
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.
4.3.1 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.
4.3.2 utveckling och simulering
Efter ovärderlig hjälp från min handledare, fungerar nu kommunikationen felfritt. Förbät- tringar är möjliga, mer om det nämns senare i raporten i kapitlet diskussion och slutsatser.
4.3.3 test på hårdvara
Från början användes ett testprogram som tillverkaren av DLP-USB245M modulen tillhan- dahå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 kom- municerar 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.
4.5. MÄTNING 29
4.4.1 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.
4.4.2 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.
4.4.3 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.
4.5.1 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.
4.5.2 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
30 DISKUSSION OCH SLUTSATSER
gjorts, det vill säga rxBufferEnd-rxBufferBegin så avslutas mätningen och instrumentet återgår till viloläge.
K APITEL 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 kret- skort 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
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.
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. 1261–1264, 2002.
[2] M. Nilsson, J. Carlson, E. Fernández, and J. Planell, “Monitoring the setting of calcium- based bone cements using pulse-echo ultrasound,” Journal of Materials Sience, vol. 37, no. 13, pp. 1135–1141, 2002.
[3] J. Carlson, M. Nilsson, E. Fernández, and J. Planell, “An ultrasonic pulse-echo technique for monitoring the setting of CaSO4-based bone cement,” Biomaterals, vol. 24, no. 1, pp. 71–77, 2003.
[4] S. electronics, “http:/www.samsung.com,” 2004.
[5] D. D. Inc, “http:/www.dlpdesign.com,” 2004.
[6] X. E. S. S. Corp., “http:/www.xess.com,” 2004.
[7] X. Inc, “http:/www.xilinx.com,” 2004.
[8] S. Inc, “http:/www.synplicity.com,” 2004.
[9] M. T. Inc, “http:/www.model.com,” 2004.
[10] D. V. Bout, “Xsa board sdram controller,” application note, XESS Corp., 2004.
