SMD106 Projektrapport Implementation av Texas Instruments TMS320C10 DSP-kärna i Virtex XCV100 FPGA

Transkript

1 SMD106 Projektrapport Implementation av Texas Instruments TMS320C10 DSP-kärna i Virtex XCV100 FPGA Lars Persson larper-8@sm.luth.se Lars Olsson larolo-7@sm.luth.se Luleå Tekniska Universitet 23 maj 2002

2

3 Sammanfattning Vi har i projektkursen SMD106 implementerat en Texas Instruments TMS320C10 kompatibel DSP-kärna. Arkitekturen har modierats till en pipeline med tre steg. Två moduler för avbrottshantering och synkron seriell kommunikation har lagts till. Implementationen har syntetiserats med Synplify Pro 7.0 och utnyttjar ca två tredjedelar av en Xilinx XCV100 FPGA. En klockfrekvens på strax över 20 MHz kan uppnås med 15 ns extern SRAM. Vi har testkört på XESS prototypkort och konstaterat att kärnan och modulerna fungerar i hårdvara.

4

5 Innehåll 1 Inledning 1 2 Arkitektur Översikt Vår tolkning av arkitekturen Avvikelser från ISA Implementation Klockgenerering Resetenheten Stacken Programminnet Övrig logik i Fetchsteget Programräknare Pipelineregistret Hoppenhet Dekoderenhet ALU operandskiftare och sign-extension Multiplikator ALU Ackumulatorskiftaren Dataminne Övrig logik i Executesteget Ackumulatorn Statusregistret Hjälpregistren Moduler Avbrottshanterare Serieport Veriering 12 6 Resultat 12 7 Diskussion 13 8 Referenser 14

6

7 1 Inledning Vi valde som projektuppgift i kursen SMD106 att implementera en DSP-kärna i en FPGA. Efter utvärdering av bentliga arkitekturer och tillgängliga resurser valde vi att utgå från Texas Instruments TMS320C10. Den har instruktionsord på 16 bitar, vilket passar utvecklingskortet, samt lagom instruktionsuppsättning. Vårt mål var att implementera en processorkärna med i stort sett kompatibel instruktionsuppsättning och uppnå en klockfrekvens på 20 MHz. För att kunna testa kärnan i praktiken behövde vi också implementera en synkron serieport för att kunna kommunicera med en stereocodec på utvecklingskortet. 2 Arkitektur 2.1 Översikt Texas Instruments TMS320C10 har en heltalsenhet innehållande en 32-bitar ALU och en separat 16x16-bitar multiplikator. Resultatet från heltalsenheten mellanlagras i en 32-bitar ackumulator. För mer permanent lagring nns ett dataminne på upp till bitar ord integrerat på chipet. Minnet kan adresseras indirekt genom två 16-bitar hjälpregister. Arkitekturen använder Harvardmodellen och har ett separat programminne på bitar ord. Det nns en hårdvarubaserad stack som normalt har fyra nivåer. För att kommunicera med yttre enheter nns det en 16-bitar databuss. Arkitekturen har 60 instruktioner och ertalet utförs på en klockcykel. 2.2 Vår tolkning av arkitekturen Enligt blockschemat i databladet [1] har TMS320C10 endast en gemensam databuss internt som delas mellan program och dataminne samt också periferienheter. För att lösa problemet med delningen av bussen arbetar arkitekturen på vissa ställen med en klockfrekvens som är fyra gånger lägre än ingångsklockan och instruktionscykeln beräknas från denna klockperiod istället. På så vis hinner man med att lägga ut adress, klocka in en ny instruktion och eventuellt göra en dataminnes/periferienhetsåtkomst under samma instruktionscykel. Eftersom TMS320C10 är en gammal arkitektur, faktiskt en av de allra första implementationer av en DSP, så har den många begränsningar på grund av dåtidens teknik. I vår implementation har vi först och främst varit intresserade av att uppnå kompatibilitet med dess ISA så att vi kan utnyttja bentliga programmeringsverktyg och algoritmer. Vi har därför frångått Texas Instruments design på ett antal punkter för att förbättra prestandan och för att förenkla implementationen. Enligt en pressrelease [2] inkluderar TMS320C10 en pipeline, men från databladet [1] framgår det inte hur den är implementerad. I vår design nns det en pipeline med tre steg: Fetch, Decode och Execute, som kan ses i blockschemat i gur 1. Texas implementation har en genomströmningshastighet på 5 MIPS i 20 MHz. Vår arkitektur behöver 6 klockcykler för att utföra en instruktion, men pipelinen ökar genomströmningshastigheten 3 gånger så vi uppnår 10 MIPS i 20 MHz. 1

8 Figur 1: Blockschema för vår design 2

9 2.3 Avvikelser från ISA Vår implementation av instruktionuppsättningen kan sägas vara 99% kompatibel med specikationen. Första avvikelsen är i SAR-instruktionen. Den sparar ett hjälpregister till dataminnet. Om SAR exekveras med indirekt adressering och postincrement/postdecrement för att spara samma register som utför adresseringen kommer det ändrade värdet att sparas till minnet enligt en notering i Texas specikation. I vår implementation kommer värdet som fanns i registret då instruktionen startades att skrivas till minnet. Instruktionerna IN och OUT behövde i Texas implementation två klockcykler för exekveringen p.g.a. en resurskonikt med fetch-enheten. Vi valde att göra en separat buss för periferimoduler och kan därför köra instruktionerna utan att stanna pipelinen. Den begränsning som fanns i Texas implementering av SUBC-instruktionen gällande användning av ackumulatorn efterföljande instruktionscykel nns inte i vår implementation. 3 Implementation 3.1 Klockgenerering Virtex innehåller fyra stycken Delay-Locked Loops varav vi använder en för att generera en klocksignal som ligger i fas med ingångsklockan men har dubbelt så lång period. Denna långsammare klocka kommer att användas för att driva pipelineregistren och på så sätt bestäms instruktionscykeln från denna. 3.2 Resetenheten Resetenheten används för att generera en resetsignal som har en stigande ank som ligger i fas med den långsamma klockan (och därmed också den snabba). Den består av ett skiftregister på 2 bitar med asynkron reset. En konstant '1' klockas in i registret vilket innebär att reset går hög 2 klockcykler efter att resetingången gått hög enligt diagrammet i gur 2. Figur 2: Tidsdiagram för resetenheten. 3

10 3.3 Stacken Stacken i TMS320C10 arkitekturen är hårdvarubaserad och vanligtvis på fyra nivåer. I vår design har vi utökat den till åtta nivåer så minnesfunktionaliteten kommer att ta upp 8 12 = 96 bitar, vilka implementeras med hjälp LUTar som fungerar som 16 x 1-bitar dubbelportat synkront RAM. Totalt kommer det alltså att gå åt 6 slice:ar exklusive de som krävs för att implementera den övriga logiken. Stacken drivs med den snabba klockan och klockas på stigande ank. Läsning/skrivning behöver utföras vid era tillfällen. En skrivning sparar alltid något av följande värden som väljs av en mux framför ingången: De 12 lägsta bitarna från ackumulatorn. PC. PC+1. Skrivning ska utföras när något av följande inträar: CALL instruktion ska spara returadress (PC+1). CALA instruktion ska spara returadress (PC). TBLR eller TBLW ska temporärt spara PC. PUSH instruktion ska utföras. Ett avbrott har inträat och returadress ska sparas (PC). Läsning sker alltid till PC registret via dess ingångsmux eller till ALUn via dess ingångsmux och ska utföras vid följande: RET ska läsa tillbaka returadress till PC. TBLR eller TBLW ska återställa PC som temporärt har sparats. POP-instruktion ska utföras. 3.4 Programminnet Programminnet för DSP:n är placerat i en av de två externa 16-bitars SRAM-banker som nns tillgängliga på XSV-kortet. Både läsning och skrivning till minnet drivs på fallande ank från den snabba klockan enligt gur 3 och 4. 4

11 Figur 3: Tidsdiagram för läsning av programminnet. Figur 4: Tidsdiagram för skrivning av programminnet. Utgången från minnet är kopplad dels till ett register som burar instruktionen, dels till en mux på dataminnets ingång för att kunna hantera TBLR instruktionen som yttar data mellan program och dataminnena. Till sist är den också kopplad till en mux framför PC registret så att det är möjligt att hoppa till en adress som läses från programminnet. Det är också möjligt att skriva till programminnet via TBLW -instruktionen så kärnan kan driva den externa databussen från dataminnet. 3.5 Övrig logik i Fetchsteget Programräknare PC-registret innehåller aktuell programminnesadress och uppdateras via en mux som styrs av följande villkor: Vid normal exekvering, öka PC med 1. Om ett avbrott har inträat, ladda avbrottsadress. 5

12 Om exekveringen måste stanna, behåll nuvarande PC. Om RET nns i Decodesteget eller TBLR/TBLW nns i Executesteget, återställ PC från stacken. Om CALA/TBLR/TBLW nns i Decodesteget, ladda PC från ackumulatorn. Om en annan hoppinstruktion än CALA och RET nns i Decodesteget och eventuellt villkor är uppfyllt, ladda PC från programminnet. Muxen innan PC-registret väljer mellan följande signaler: Behålla gamla värdet på PC. PC+1. Värde från stacken. 12 lägsta bitarna från programminnet. 12 lägsta bitarna från ackumulatorn. Avbrottsadress (0x0002) Pipelineregistret Från Fetchsteget nns ett pipelineregister, klockat med den långsamma klockan, som antingen lagrar den aktuella instruktionen eller en NOP-instruktion i de fall då exekveringen tillfälligt måste avstannas. En mux framför registret som styrs från Decodesteget ser till att rätt data klockas in. 3.6 Hoppenhet Denna enhet avgör huruvida ett villkor associerat med en hoppinstruktion är uppfyllt. För att kunna utföra detta behöver den veta hur ackumulatorn, hjälpregister och statusregistret ser ut. För hjälp med detta nns det forwardingenheter som avgör om den instruktion som ligger i Executesteget modierar någon av dessa och isåfall skickar den de nya värdena istället för de som ligger i registren. 3.7 Dekoderenhet Denna enhet tittar på instruktionen som ligger i pipelineregistret och sätter diverse kontrollsignaler till Executesteget som lagras i pipelineregister. Om instruktionen i fråga behöver bromsa exekveringen (på grund av resurskonikt i pipelinestegen) sätts pipelinemuxen i Fetchsteget så att en NOP-instruktion klockas in istället för den riktiga instruktionen. Programräknaren sätts att behålla det gamla värdet så att instruktionen kan utföras när resurskonikten har försvunnit. 6

13 3.8 ALU operandskiftare och sign-extension Vissa instruktioner skiftar ena ALU-operanden till vänster ett antal steg vilket utförs av denna enhet. Dessutom konverterar några instruktioner en operand som är representerad med 16-bitar två-komplement till 32-bitar två-komplement vilket också utförs här. Operanden kan antingen komma från minnet eller från ett 8-bitars immediatefält som utökas till 16 bitar. En mux som styrs av en kontrollsignal från Decodesteget avgör vilken som blir insignal. Utsignalen från skiftaren går till ett register Multiplikator Denna multiplikator måste kunna utföra en 16x16 multiplikation på enbart en klockcykel. Multiplikatorn tar en av faktorerna från T-registret och den andra från antingen ett 13-bitars immediatefält i instruktionen eller från minnet. Valet avgörs av en mux som ställs in beroende på om instruktionen är MPY eller MPYK. Produkten sparas i P-registret ALU ALUn behandlar endast ett fåtal operationer; addition, subtraktion och absolutbelopp samt de logiska operatorerna AND, OR, XOR. Det nns också två operationer som enbart använder ALUn för att ladda ett värde till ackumulatorn, nämligen LOAD, som låter en operand omodierat passera, och ZERO som matar ut 32 bitar med värdet 0. Eftersom addition och subtraktion kan utföras av samma hårdvara när man använder två-komplement, så tas två-komplementet av operand B och matas till samma adderare som vid addition så att man sparar resurser. En overowagga beräknas för varje operation, men den har bara mening vid addition och subtraktion i två-komplementsform. Ingen carry beräknas. ALUn måste också klara saturate vid vissa operationer. Detta är implementerat genom att man har en mux som bestämmer om man ska mata ut resultatet från adderaren eller max om man har positiv overow; min om man har negativ. Det nns ingen divisionsinstruktion i arkitekturen men division kan ändå genomföras med hjälp av en lite ovanlig ALU-operation som kallas för villkorlig subtraktion. Detta innebär att man från ackumulatorn subtraherar en operand som skiftats 16 bitar till vänster. Om resultatet är negativt ignoreras operationen och man matar ut ackumulatorns värde 2. Annars sparas resultatet Om man placerar det tal man vill dividera i ackumulatorn och man matar in talet som det ska divideras med som operand och utför denna operation 16 gånger så har man faktiskt genomfört en 16 bitars division där kvoten nns i de 16 lägsta bitarna i ackumulatorn och eventuell rest i de 16 högsta. Operand B kommer alltid från ackumulatorn och man väljer operand A genom en mux som har följande insignaler: Från registret som lagrar resultatet från skiftenheten. 1 Registrets funktion behandlas i avsnittet Diskussion. 7

14 Från stacken. Från P registret. Från minnet vänsterskiftat 16 bitar, används av bland annat instruktionerna SUBC, ADDH och SUBH Ackumulatorskiftaren Ackumulatorskiftaren är på 20 bitar och används för att spara de mest signikanta bitarna i ackumulatorn till dataminnet. Enligt denitionen på instruktionen kan den endast skifta 0, 1 eller 4 steg till vänster Dataminne I Texas Instruments implementation av TMS320C10 är dataminnet begränsat till 144 ord, antagligen beroende på att det var dyrt med integrerat minne vid tidpunkten då arkitekturen konstruerades. I Virtexkretsens Block SelectRAM är blockstorleken 4096 bitar så det var enkelt att utöka storleken till 256 ord utan att behöva göra några ytterligare designförändringar. Dataminnet är implementerat som dubbelportat Block SelectRAM i Virtex kretsen. Anledningen till att det behövs två portar är att man ibland måste kunna läsa och skriva till två olika adresser under samma klockcykel från den snabba klockan. Det är instruktionerna DMOV och LTD som behöver denna funktionalitet då de kopierar ett ord från en minnesadress till nästa minnesadress. Dataingången på port B är alltså alltid kopplad till datautgången på port A och adressen på port B är samma som på port A+1. För all annan aktivitet används enbart port A. Adressen till minnet kan antingen komma från ett hjälpregister eller från immeditatefältet i instruktionen. En mux som styrs av en kontrollsignal från Decodesteget bestämmer vilken. Eftersom immediatefältet bara är på 7 bitar och det behövs 8 bitar för att adressera 256 minnesadresser tas en extra bit från DP-registret vid immediate adressering. Vid skrivning till minnet kan data komma från ett ertal källor, bestämda av en mux på dataingången: De 16 lägsta bitarna från ackumulatorn. Resultatet från ackumulatorskiftaren. Aktuellt hjälpregister. Statusregistret. Periferibussen. Programminnet. Dataminnet är klockat på fallande ank och skrivning fungerar precis som för programminnet (Se gur 4). Läsning sker alltid på fallande ank. 8

15 3.13 Övrig logik i Executesteget Ackumulatorn Ackumulatorn är egentligen bara ett 32 bitars register, klockat med den långsammare klockan, som innehåller resultatet efter en ALU operation. Eftersom vissa konditionella hoppinstruktioner måste veta hur ackumulatorn ser ut för att kunna evaluera villkoren är den kopplad till en forwardingenhet som skickar det nya värdet istället för det som är lagrat i ackumulatorn om instruktionen i Executesteget skriver till ackumulatorn Statusregistret Statusregistret är klockat med den långsammare klockan och innehåller aggor för overow (V), overowläge (OVM), avbrottsmask (INTM), hjälpregisterpekare (ARP) och dataminnespekare (DP). Precis som med ackumulatorn är en del bitar i statusregistret kopplade till en forwardingenhet. Statusregistret kan sparas och laddas från minnet och har då formatet som visas i tabell V OVM INTM reserverade ARP reserverade DP Tabell 1: Bitformat för statusregister vid läsning/skrivning Hjälpregistren Det nns två hjälpregister som kallas för AR0 och AR1. En pekare kallad ARP håller reda på aktuellt register. Registren kan automatiskt ökas eller minskas med ett efter att en indirekt minnesåtkomst har skett. En mux bestämmer huruvida det nya värdet till aktuellt register ska vara det gamla värdet, det gamla värdet+1, det gamla värdet 1 eller om det ska tas från minnet eller från immediatefältet. De två sista alternativen bestäms av ytterligare en mux. Hoppenheten behöver veta om hjälpregistren är 0 så en zeroagga är kopplad till forwardingenheten. 4 Moduler 4.1 Avbrottshanterare För att eektivt kunna behandla asynkrona I/O anrop brukar de esta processorer innehålla en avbrottsenhet. TMS320C10 innehåller i orginalutförande endast en rudimentär sådan som bara tillåter ett externt avbrott att ske. För vår applikation behövde vi kunna ta emot två avbrottsförfrågningar från serieporten; en för sändning och en för mottagning av data. Vi utökade därför designen med en modul som hanterar de två extra avbrotten genom att placera den på periferienhetsbussen så att instruktionerna IN och OUT kan användas for att kommunicera med den. Avbrottsenheten använder adresserna enligt tabell 2. INTF läses när ett avbrott har inträat och man vill veta källan. INTE fungerar som en mask och 9

16 används för att slå av/på avbrott från en viss källa. För att indikera att man har behandlat ett avbrott skriver man till INTC. Alla adresser använder den bitplaceringen som visas i tabell 3. Adress Namn Riktning Funktion 000 INTF R Inträade avbrott. 001 INTE RW Påslagna avbrott. 010 INTC W Rensning av inträade avbrott. Tabell 2: Adresser till avbrottshanteraren reserverade sändning mottagning Tabell 3: Placering av bitar i avbrottsregistren. Avbrottshanteringen fungerar enligt samma princip som den ursprungliga modellen förutom att man också måste utföra dessa steg i avbrottshanteraringsrutinen: 1. Läsa ut vilket avbrott som inträat från INTF. 2. Skriva aktuell bit till INTC för att indikera att man har tagit hand om avbrottet. Dessa steg bör utföras så tidigt som möjligt i avbrottshanteringen så att ytterligare avbrott registreras. De större kretsarna i C10-familjen använder en liknande modell för avbrottshanteringen. Från blockschemat i gur 5 observeras ingången 'BlockInterrupt'. Denna signal används for att fördröja ett avbrott så att inte en multicykelinstruktion avbryts mitt i. Det nns också ett specialfall, nämligen multiplikationsinstruktionerna MPY och MPYK, där efterföljande instruktion ska utföras innan avbrott så att man hinner spara P registret efter multiplikation. 10

17 Figur 5: Blockschema för avbrottshanteraren. 4.2 Serieport En synkron serieport nns i de esta DSP:ar och är ett viktigt gränssnitt för anslutning till AD/DA-omvandlare och tidsmultiplexade PCM-bussar. Normalt är de exibla och kan kongureras för ett antal olika dataformat och klockningsmodeller. Vi har valt att implementera en serieportmodul som endast fungerar med dataformatet som codeckretsen AK4520A på XESS-kortet använder. Gränssnittet mot kretsen består av 3 klocksignaler och 2 datasignaler enligt tabell 4. MCLK Codec master clock SCLK Serial clock LRCK Left/right clock SDI Serial data in SDO Serial data out Tabell 4: Signaler synkron serieport. MCLK klockar logiken i codeckretsen och bestämmer samplingsfrekvensen enligt sambandet f s = MCLK/256. SLCK är klocksignal för serieporten. Data skiftas ut på SCLKs fallande ank och läses in på stigande ank. LRCK bestämmer om det är data för höger eller vänster stereokanal som överförs. Vi har endast implementerat en kanal. Samtliga klockor genereras av serieportmodulen. Klockgeneratorn består av ett antal räknare med carryutgångarna kopplade till T-vippor. De seriella in- och utgångarna är kopplade till var sitt 32-bitar skiftregister vilket är det normala sättet att implementera en serieport. Codecens AD/DA-omvandlare har 20 bitar precision, men för att passa med 16-bitarsminnet i DSP:n är endast de 11

18 16 mest signikanta bitarna tillgängliga för kärnan. Orsaken till att skiftregisterna då är på 32 bitar är att dataformatet på seriebussen är 32 bitar per sample. Modulens gränssnitt mot kärnan består av två 16-bitar register med tillhörande avbrottsignaler. En avbrottsignal signaleras när data nns att hämta i mottagningsregistret (RxInt) och den andra när sändregistret kan fyllas på (TxInt). 5 Veriering Veriering av design och VHDL-kod har skett i era steg för att hitta fel så tidigt som möjligt och därmed underlätta felsökning och felrättning. I början av projektet tog vi fram en tabell över hur alla kontrollsignaler ska sättas för samtliga instruktioner. Tabellen inspekterades sedan av oss båda och vi kunde åtgärda ett tiotal fel redan då. Eftersom mikroarkitekturen inte fanns beskriven så var det också en viktig del av designen. Vi mappade varje instruktion till de olika enheterna i blockschemat för att vara försäkra oss om att designen var någorlunda komplett. Det är viktigt så att man inte sent i projektet upptäcker att en instruktion är omöjlig att implementera utan omfattande ändringar i mikroarkitekturen. Under utvecklingen av VHDL-kod simulerades de esta mindre komponenter separat med en grundläggande testbänk. När pipelinestegen hade byggts upp fungerade denna metod inte eftersom antalet kontrollsignaler blev för stort. Veriering av hela konstruktionen utförde vi med assemblerprogram som testkördes i simulatorn. Först verierades ett mindre antal instruktioner genom visuell inspektion av vågformerna i simulatorn. När man har etablerat att dessa fungerar går det sedan att skriva självkontrollerande kod för större delen av instruktionuppsättningen. Testprogrammet avslöjade ca 20 fel. Slutligen var det då dags för elddopet. Testkörning på prototypkortet. Fungerar det inte så är kortet en svart låda med mycket begränsade möjligheter till felsökning. Vi utvecklade ett testprogram som lägger ut en sinuston på serieporten och laddade in det i SRAM:et. Resultatet var positivt och vi kunde höra tonen i de ansluta hörlurarna. Själva processen att ladda in programkoden i simulatorn kräver era steg med olika konverteringsprogram innan formatet passar IO-funktionerna i VHDL. Först används Alfred Arnolds Macro Assembler AS för att kompilera koden. Objektlen överförs sedan till Intel 16-bitars hexformat med assemblerns konverteringsprogram och därifrån till binärt format med programmet objcopy. Slutligen sköter ett perlscript konvertering från binärt format till hexadecimalt format med ett 16-bitar ord per rad som passar VHDL. Ytterligare ett steg krävs för att ladda in programkod i SRAM på prototypkortet, nämligen konvertering av byteordningen i instruktionsorden. 6 Resultat Då kärnan är i det närmaste 100% kompatibel med Texas ISA och går att köra i önskad klockfrekvens så anser vi att målet med projektet har uppnåtts. Syntes av designen har utförts i Synplify Pro 7.0. Med serieport och avbrottshanterare utnyttjas 62% av de så kallade Logic Cells (LC) i en Virtex XCV100 FPGA samt 12

19 ett blockram. Särskilt utrymmeskrävande är multiplikatorn som bara den fyller ca 10% av FPGA:n och ALU-enheten med 25%. Vi har inte något att jämföra med, men ALU-enheten bör vara mer utrymmeskrävande än i en vanlig RISC-processor eftersom den ska hantera saturation och ett antal specialiserade instruktioner. Vår målfrekvens på 20 MHz var inte svår att nå, men gränsen ligger inte långt från det. Eftersom designen har en pipeline krävs forwarding av resultatet från ALU:n till de övriga pipelinestegen vilket ger en lång kritisk väg. Även hastigheten på det externa minnet sätter en gräns för klockfrekvensen. På en halv klockcykel måste resultatet från en läsning ha stabiliserats och propagerat in i FPGA:n. XESS-kortet har 15 ns SRAM vilket medför minst ca 20 ns för en halv klockcykel. 7 Diskussion Om specikationen för Virtexkretsens DLL granskas ser man att den minsta klockfrekvensen på ingången är satt till 25 MHz. Tillsammans med timingen för det externa SRAM:et som kräver klockfrekvens på mindre än 25 MHz så är vår arkitektur precis på gränsen till att inte kunna implementeras i en Virtex FPGA. Det visar sig dock att klockningen fungerar en bit under den ociella gränsen, men att köra en komponent utanför specicerade området är förstås inte bra då det inte nns någon garanti att den fungerar. För att erhålla en design med garanterad funktions krävs snabbt SRAM som tillåter klockning i 25 MHz eftersom resten av logiken kan köras i över 25 MHz. Virtexkretsen vi använder är dessutom den långsammaste i Virtexfamiljen. Med den inbyggda multiplikatorn i Virtex2 bör man kunna uppnå betydligt högre klockfrekvens. Ett av de större problemen vi ställdes inför var komplexiteten som uppstod när båda ankerna i två olika klockor utnyttjades. Synplifys constrainteditor klarade inte av den viktigaste kritiska vägen vi hade i designen. Det var en lång kedja av logik som började på utdataporten i ett BlockRAM. RAMet klockas med negativ ank av den snabba klockan. Vi vet dessutom att utdatat från minnet bara ändras varannan klockcykel i det fall vi läser från minnet. Slutet av kedjan är register klockade med positiv ank av den långsamma klockan. Sammanlagt nns det 1.5 klockcykel av den snabba klockan tillgodo, men Synplify ser bara 0.5 klockcykel eftersom verktyget inte vet att minnesutgången behåller sitt värde. En multicycle path constraint passar inte eftersom den bara kan ha ett heltal antal klockcykler och dessutom antar verktyget att det är samma klocka på båda registren. Till slut löste vi problemet genom att sätta in ett extra register mellan skiftenheten och ALUn. Om ni önskar använda koden i något annat sammanhang så notera också följande. Vi har instansierat ett antal Virtex-specika komponenter. Simuleringsmodellen nns tyvärr inte i samma bibliotek som Synplify använder vid syntes. Därför nns två direktiv för biblioteken i vissa ler, varav det ena som berör Virtexbiblioteket ska kommenteras bort vid simulering. 13

20 8 Referenser [1] Texas Instruments (1991). TMS320C1x User's Guide. URL: ( ). [2] Texas Instruments (1983). TMS320 Press Release. URL: ( ). 14