Design av en feltolerant RISCprocessor

Design av en feltolerant RISCprocessor ANDREAS SÖDERBERG TOMAS HOLMGREN Examensarbete Civilingenjörsprogrammet för Elektroteknik CHALMERS TEKNISKA HÖGSKOLA Institutionen för datorteknik Göteborg 2003

Abstract The purpose of this master thesis work was to design a single-channel microprocessor for use in applications with high safety requirements. In order to fulfill the application requirements, the processor was designed to be fail silent. The microprocessor was designed using VHDL and was implemented in a pre-made FPGA target system called FPGA-labkortsystem, which was provided by Chalmers University of Technology. To demonstrate the microprocessor's functionality, a simple two-hand manoeuvre control was built, which controls a 230V power connection. To program the microprocessor, an assembler was developed in the programming language ADA. The assembler translates assembly language for the microprocessor into machine code, which is automatically inserted either into a VHDL ROM block used for simulation or into a script-file which is compatible with the programming environment for the FPGA target system. The result of the thesis work is a microprocessor which complies with the fail silence requirements according to a failure mode and effects analysis (FMEA) performed. In order to verify that the actual implementation of the microprocessor complies with the requirements, a complete assessment including fault injection should also be performed. However, such an assessment was not within the time limits set for the thesis work. Innehållet i detta häfte är skyddat enligt Lagen om upphovsrätt, 1960:729, och får inte reproduceras eller spridas i någon form utan medgivande av författaren. Förbudet gäller hela verket såväl som delar av verket och inkluderar lagring i elektroniska och magnetiska media, visning på bildskärm samt bandupptagning. Andreas Söderberg och Tomas Holmgren, Göteborg 2003. 2

Innehållsförteckning Abstract...2 Innehållsförteckning...3 Förord...5 Sammanfattning...6 Inledning...7 1 RISC-arkitektur - introduktion...9 1.1 Arkitektur för feltolerant processor...9 1.2 CPU - Instruktionspipeline...10 2 Instruktioner...11 2.1 Instruktionsuppsättning...11 2.2 Programmering av processorn...12 3 Målsättning...14 4 Prestandaökande metoder...15 4.1 Separat hoppberäkning/verifiering...15 4.2 Forwarding...15 4.3 ALU...16 5 Metoder för feldetektering...16 5.1 Bergerkod...16 5.2 CRC-checksumma...16 5.3 Assemblatorn...17 5.4 Övervakning av multiplexrar...17 5.5 Dubblerade funktioner...17 6 Användning av metoder för feldetektering...18 6.1 Instruktion...18 6.2 Villkorliga/ovillkorliga hopp...18 6.2.1 Villkorligt hopp...18 6.2.2 Ovillkorligt hopp...18 6.2.3 TRAP genererade hopp...18 6.3 Aritmetiska operationer...18 6.4 Läsning/skrivning till dataminnet och IO portar...19 6.4.1 Läsning/skrivning till dataminne...19 6.4.2 Läsning av IO portar...19 6.4.3 Skrivning till IO portar...19 6.5 Instruktionshämtning...19 7 Åtgärder vid detekterat fel...19 8 Implementation...19 8.1 KRETS 1...20 8.1.1 IF-steget...20 8.1.2 ID-steget...23 8.1.3 EX-steget...28 8.1.4 BC-steget...30 8.1.5 WB-steget...31 8.1.6 IO-portar...32 8.1.7 IO-port A...33 8.1.8 IO-port B...34 8.1.9 IO-komparator...34 8.1.10 FELHANTERAREN...35 8.2 KRETS 2...37 8.2.1 BP-blocket...37 8.2.2 IO-port C...39 8.2.3 Pulsdetektorn...39 9 Feleffektsanalys...40 10 Resultat...43 11 Slutsats...43 12 Diskussion och vidare arbete...44 3

13 Referenser...45 Bilaga 1 Instruktioner...46 Bilaga 2 IF-steget...49 Bilaga 3 ID-steget...50 Bilaga 4 EX-steget...51 Bilaga 5 BC-steget...52 Bilaga 6 WB-steget...53 Bilaga 7 Felhanteraren...54 Bilaga 8 Skifter...55 Bilaga 9 BP-blocket...56 Bilaga 10 Assemblatorn ASRC...57 Bilaga 11 Applikation...58 Bilaga 12 Assemblerkod för styrprogrammet....60 Bilaga 13 VHDL-kod för Krets 1...62 Bilaga 14 VHDL-kod för Krets 2...121 4

Förord Denna rapport är resultatet av ett examensarbete genomfört vid SP Sveriges Provningsoch Forskningsinstitut, enheten för elektronik, sektionen för programvara (ELp) sommaren och hösten år 2002. Studenterna Andreas Söderberg och Tomas Holmgren avslutade med detta examensarbete sin civilingenjörsutbildning vid Chalmers tekniska högskola med inriktning mot elektronikkonstruktion. Examensarbetet är ett konstruktionsprojekt vilket syftar till att designa ett avancerat digitalt system som anknyter till de kurser som studenterna läst under sin utbildning. Handledaren för examensarbetet vid SP heter Johan Hedberg och examinatorn vid Chalmers Tekniska Högskola heter Peter Folkesson. Vi vill tacka vår handledare Johan Hedberg för de givande diskussioner samt stöd som givits oss under examensarbetets gång. Vi vill även tacka Peter Folkesson vid Chalmers Tekniska Högskola (inst. för datorteknik) för förbättrande idéer samt att vi har fått låna utrustning vilken möjliggjorde implementation av systemet och därmed färdigställandet av examensarbetet. Andreas Söderberg Tomas Holmgren 5

Sammanfattning Syftet med detta examensarbetet var att konstruera en enkanalig mikroprocessor avsedd för användning i säkerhetskritiska applikationer med krav på felsäkerhet. Eftersom processorn är enkanalig ställs endast krav på feltystnad i händelse av fel. Processorn konstruerades i VHDL och implementerades i ett färdigt målsystem FPGA labkortsystem som utlånades av Chalmers Tekniska Högskola. För att visa processorns funktionalitet konstruerades även en enkel applikation i form av ett tvåhandsmanöverdon som kunde styra en 230V anslutning. För att möjliggöra programmering av processorn utvecklades även en assemblator, i programmeringsspråket ADA. Assemblatorn översätter assemblerkod till antingen en script -fil anpassad för nerladdning av applikationsprogrammet i labsystemet eller ett VHDL-block för simulering. Resultatet av examensarbetet blev en processor som uppfyller kraven på feltolerans enligt en feleffektsanalys som genomförts. För att visa att processorimplementationen verkligen uppfyller feltoleranskraven krävs en mera grundläggande utvärdering, t ex med hjälp av felinjicering, som inte ryms inom examensarbetets omfattning. 6

Inledning Vid konstruktion av säkerhetskritiska programmerbara elektroniska system är en viktig del av konstruktionsarbetet att ta hänsyn till de potentiella felorsaker som systemet kommer att utsättas för då det sätts i drift. För att hantera dessa potentiella felorsaker ingår det i konstruktionen att systemet har möjlighet att övervaka sin egen funktion samt att systemet kan vidta övergripande åtgärder om systemets funktion avviker från sin specifikation. En mycket användbar metodik för implementation av övervakande funktioner är redundanta funktioner. En redundant funktion är en extra funktion vilken fyller samma syfte som den funktion som den ska övervaka. Redundans kan införas på olika systemnivåer och i olika omfattning beroende på de felorsaker som är förenade med systemet. För att ytterligare konkretisera begreppet redundans ges nedan exempel på de övergripande tillvägagångssätten (principerna) för att skapa redundans: Hårdvarumässig redundans: En elektronisk funktion (t ex processor) mångfaldigas och de olika resultaten från funktionerna jämförs för att upptäcka avvikelser. De olika funktionerna behöver inte nödvändigtvis vara implementerade på samma sätt. Mjukvarumässig redundans: Samma programvara mångfaldigas och exekveras samtidigt. Detta är ett vanligt förfarande vid hårdvarumässigt redundanta mikroprocessorsystem. Resultaten från de olika programvarorna jämförs för att upptäcka avvikelser. Programvarorna i ett sådant system brukar ha samma funktion men vara programmerade på olika sätt, annars är risken stor att ett fel i en programvara samtidigt uppträder i de övriga. Detta kallas för N-version program eller diversifierade program. Informationsmässig redundans: Samma meddelande skickas flera gånger från en sändare till en mottagare. Ett av meddelandena kan t ex skickas i form av en checksumma. Meddelandena jämförs sedan för att upptäcka avvikelser. Denna typ av redundans innefattar även informationslagring i register och minnen genom mångfaldning. Tidsmässig redundans: Hårdvara eller mjukvara mångfaldigas och utför samma operation vid olika tidpunkter. Exempel på denna typ av redundans är att lagra två (eller flera) uppsättningar av samma programvara i ett minne. Efter att första programmet är exekverat lagras resultatet och nästa program exekveras. Därefter jämförs resultaten från de båda programmen för att upptäcka avvikelser. I vissa säkerhetskritiska applikationer krävs det att styrsystemet förmår att kontrollera applikationen även i händelse av fel. För att uppfylla detta krävs minst en dubblering av den elektronik som ansvarar för de säkerhetskritiska funktionerna i styrsystemet. Beträffande maskinstyrningar finns det dock ett antal säkerhetskritiska applikationer vars styrsystem måste ha egenskapen att upptäcka fel och i så fall endast kunna försätta applikationen i ett speciellt säkerhetstillstånd. Det är idag praxis att använda sig av dubblerade system till styrsystem även till sådana applikationer. Detta innebär att styrsystemen blir överdimensionerade och dyra. Detta examensarbete syftar till att specificera och designa en enkanalig och feltolerant processorarkitektur som kan ersätta ett två-kanaligt processorbaserat system med avseende på feltolerans. Orsaker till att fel kan uppstå i en processor är såväl miljöberoende (t ex strålning och elektromagnetiska/ledningsbundna störningar/transienter) som materialberoende fel orsakade av ålder eller förslitning eller feldimensionering. Målsättningen med denna 7

processor är att den ska kunna upptäcka samtliga typer av enkelfel såväl transienta som permanenta. Designen grundar sig på att utnyttja pipelining för att primärt öka feltoleransen istället för prestanda samt att nyttja informationsredundans via kompilatorn. För att minimera hårdvarukostnaden nyttjas dessutom tidsredundant exekvering istället för hårdvaruredundans. 8

1 RISC-arkitektur - introduktion I detta avsnitt ges en mycket kortfattad introduktion till RISC-arkitekturen. En processor baserad på en RISC-arkitektur (Reduced Instruction Set Computer) är en pipelinad dator med följande egenskaper: -Den exekverar en instruktion per cykel -Har många register -Har kraftigt reducerad instruktionsuppsättning Att en processor är pipelinad innebär att dess olika funktioner är indelade i olika block med register emellan. Det vill säga att varje instruktion tar lika många klockcykler på sig att exekveras som det finns pipelinesteg. Eftersom varje pipesteg kan innehålla en unik instruktion kan processorn exekvera en instruktion per klockcykel. Arkitekturen i figur 1 har delat data- och instruktionsminne. Dataminnet accessas från WB-steget och instruktionsminnet accessas från IF-steget. Figur 1: Exempel på RISC-pipeline Exempel på instruktionsformat: [OP][DEST][SRC1][SRC2] OP = operationskod samt adresseringsmod DEST = Målregister i vilket resultatet av operationen ska lagras SRC1 = Första datafältet (vanligen en adress till registerbanken) SRC2 = Andra datafältet (adress till registerbanken eller ett tal) IF (Instruction Fetch) Steget läser instruktionen från instruktionsminnet ID (Instruction Decode) Steget avkodar instruktionen till styrsignaler och datafält I detta steg ligger registerbanken. EX (Execute) Steget exekverar operationen med datafälten från ID-steget WB (Write Back) Steget skriver resultatet från EX-steget till registerbanken, dataminnet eller IO-portarna beroende på vilken operation som exekverats. För mer information om RISC-arkitekturen se [RISC]. 1.1 Arkitektur för feltolerant processor Processorarkitekturen som konstruerades under examensarbetet är baserad på RISCarkitekturen i kapitel 1men utökad för feltolerans. Processorn är uppdelad i två separata kretsar för att begränsa felspridningsområdet och för att minska sannolikheten för sk. common-mode failures. Med separerade kretsar menas här två fristående chip med två oberoende klockor. Processorn har en ordlängd på 24 bitar. 9

* * * * * Figur 2 ger en översiktlig bild av processorns implementation i de båda kretsarna. De i figuren ingående blocken kommer noggrant att beskrivas längre fram i rapporten. I KRETS 1 finns själva CPU:n (se avsnitt 1.2), två stycken IO-portar (IOa, IOb) om vardera 12 IO-pinnar, en pulsräknare (PC) samt ett felhanteringsblock (FH). I KRETS 2 finns en kopia av felhanteraren från KRETS 1 (FH), ett block för bergerkodshantering (BP), en kopia av pulsräknaren från KRETS 1, samt en IO-port (IOc) vilken en av IO-portarna från KRETS 1 måste passera. %#! " # $& $# Figur 2: Processorn På grund av att båda kretsarna kan styra varsin IO-port med sina respektive felhanterare kan de båda kretsarna oberoende av varandra försätta minst en av IO-portarna i säkerhetsläge för att indikera närvaro av fel, dvs. processorn är feltyst. IO-portarna är gjorda så att även applikationen som processorn ska styra måste vara feltolerant och kunna upptäcka ej tillåtna utsignalskombinationer på de båda IO-portarna. 1.2 CPU - Instruktionspipeline CPU:n är uppbyggd med den i avsnitt 1 nämnda RISC-arkitekturen som underlag. Det som främst skiljer denna instruktionspipelinen med RISC-pipelinen är att steget BC har tillkommit. En närmare beskrivning av samtliga block ges längre fram i denna rapport. ')( ')+,-.0/ 12. Figur 3: CPU:ns instruktionspipeline Registerbanken som finns i ID-steget innehåller 32 st. register. 10

2 Instruktioner En instruktion till den feltoleranta processorn är uppbyggd på följande sätt: [OP] [DEST] [SRC1] [SRC2] Instruktionen avkodas i sina adresseringsmoder till följande fall REGISTER SRC1 och SRC2 innehåller adresser till registerbanken, DEST innehåller adressen till registerbanken i vilken resultatet av operationen ska lagras. IMMEDIATE SRC1 innehåller en adress till registerbanken och SRC2 är värdet från immediatefältet som (i processorn) utökas till 24 bitar beroende på signbiten (bit 12). DEST innehåller adressen till registerbanken i vilken resultatet av operationen ska lagras. EXTENDED IMMEDIATE SRC1 innehåller en adress till registerbanken och SRC2 är värdet från immediatefältet som flyttas till de tolv mest signifikanta bitarna, övriga bitar sätts till noll. DEST innehåller adressen till registerbanken i vilken resultatet av operationen ska lagras. 2.1 Instruktionsuppsättning En instruktion innehåller 59 bitar och är utformad enligt följande: [AM][OP1][OP2][PCS1][PCS2][DEST][SRC1][SRC2][IMB][INB][TAGS] AM: Adresseringsmod 2 bitar OP1: Aktuell op-kod 5 OP2: Nästa op-kod 5 PCS1: Nästa instruktionsadress 4 PCS2: Förväntad instruktionsadress vid hopp 4 DEST: Adress till destinationsregistret 5 SRC1: Adress till register 5 SRC2: Data eller adr. till reg 12 IMB: Bergerkod för immediate-fält 5 INB: Bergerkod för hela instruktionen 6 TAGS: Kanalidentitet för multiplexrar 6 Samtliga av dessa förkortningar och begrepp kommer att förtydligas senare i rapport. Processorn har följande instruktionsuppsättning. I tabell (-) = Illegal instr. OP-KOD REG IMM XIMM 00000 ADD (NOP) ADDI ADDX 00001 SUB SUBI SUBX 00010 AND CMPI CMPX 00011 ORA ORAI ORAX 00100 XOR ANDI ANDX 00101 CMP XORI XORX 00110 ADV ADVI ADVX 00111 SUV SUVI SUVX 01000 LLS LLSI LLSX 01001 LRS LRSI LRSX 11

01010 ALS ALSI ALSX 01011 ARS ARSI ARSX 01100 - BEQ - 01101 - BNE - 01110 - RFT - 01111 - TRP - 10000 - RIO - 10001 LDW LDWI LWX 10010 - PUT - 10011 - SDW SWX 10100 - - - 10101 - - - 10110 - PRT - 10111 SFE - - 11111 - RST - Tabell 2: Instruktionsuppsättning 2.2 Programmering av processorn Nedanstående tabell visar hur många cykler de olika instruktionerna kräver för att exekveras (dvs. hur många instruktioner av typen NOP som måste finnas i programmet efter instruktionen, undantaget branch-instruktioner) : Operation Antal cykler/op Aritmetiska operationer 1 Branch, TRP, RFT 2 RIO, LDW 5 Övriga 1 Tabell 1: Antal klockcykler per instruktion Då processorn ska programmeras måste ett visst tillvägagångssätt följas. Ett program ska vara uppbyggt på följande sätt (se bilaga 1 för en beskrivning av samtliga instruktioner): Adress Operation Kommentar 0 BEQ R0 R0 START RESET Jump to START 1 NOP TRAP handler 2 TST - - - - n RFT Return From Trap n+1 NOP n+2 TST START n+m - Program Vid reset sätts alltid programräknaren (PC) till adress 0. Där måste ett ovillkorligt hopp tas som hoppar till adress n+2 (START). Detta på grund av att processorn inte har en korrekt återhoppsadress lagrad för instruktionen RFT efter en reset. Vid användning av hoppinstruktioner: Varje, till hoppinstruktionen, efterföljande instruktion kan ha godtycklig OP-kod men instruktionen efter den ska ha samma OP-kod som den instruktion som exekveras först om hoppet tas. Se program ovan där BEQ efterföljs av instruktionen NOP och därefter 12

TST vilken också återfinns på måladressen (START). Om detta inte efterföljs kommer processorn att försättas i feltyst läge. Hoppvektorn refereras relativt den närmst efter hoppinstruktionen följande instruktion. Det vill säga att om hoppvektorn = 0 sätts programpekaren (PC) på instruktionen som följer hoppinstruktionen. I programmet ovan ska START bytas mot n+1 vilket ger att hoppet går till n+2. Se även nedanstående exempel: m BEQ R0 R0 1 m+1 NOP Programpekaren sätts alltid till adress (m+1)-1 = m, det vill säga att programmet är en oändlig loop. Utöver ovanstående programtekniska krav ska programmen till processorn utformas för feltolerans på samma sätt som om processorn inte var feltolerant. Nedanstående principer är exempel på några tillvägagångssätt som bör vara inkluderade i programvaran. Structured programming: Mjukvaran ska vara utformad på ett sådant sätt att den är enkel att analysera. Se även [IEC 61508-7, clause B6] Software diversity: En specifikation för ett applikationsprogram är utformat i N olika varianter. Samma insignaler ges till de N programmen varefter de N uppsättningarna av utsignalerna jämförs. Se även [IEC 61508-7, clause B17] (Detta kan i vissa fall göras på vissa delar av en programvara, t ex säkerhetskritiska funktioner) Well defined output control: Rimlighets plausability kontroller ska göras före och efter förändring av värdet på utgångar. Utgångarna ska styras från en väl definierad del av mjukvaran. Se även [IEC 61508-7, clause B15] Plausability check of input variables: Inparametrar till funktioner/procedurer bör rimlighetskontrolleras innan de används. Se även [IEC 61508-7, clause B15] Selftest using software: Speciell mjukvara kontrollerar att processorns funktioner fungerar vid start och reset. Se även [IEC 61508-7, clause C.3.1 och C.3.2] Software monitoring: Programsekvensen är övervakad av programvara (som en programvaru-watch dog). Se även [IEC 61508-7, clause C.9.3 och C.9.4] Instruction set test: Alla instruktioner i instruktionsuppsättningen bör testas av programvaran innan de används. Invariable memory: Programvara som genomför minnestester vid start och/eller i drift på instruktionsminnet. Se även [IEC 61508-7, clause C.4] Variable memory: Programvara som genomför minnestester vid start och/eller i drift på dataminnet och registerbanken. Se även [IEC 61508-7, clause C.5] Den instruktion som finns för att testa processorns förmåga att upptäcka fel (TST) ska användas med tillräckligt täta tidsintervall. Den som utformar applikationsprogrammet till den feltoleranta processorn bör ändvända sig av ovanstående metoder, samt lägga till de metoder som är relevanta för applikationen (och dess krav på feltolerans) som processorn ska styra. 13

Mer information om hur ett säkerhetskritiskt program ska utformas finns att läsa bla i rapporten [SP REPORT 1997:12] och i standarden [IEC 61508] (se referenslista). 3 Målsättning Målsättningen med konstruktionen av den felsäkra varianten av processorn är att processorn omedelbart ska upptäcka alla enkelfel som påverkar dess funktionalitet. Ett latent fel ska inte orsaka förlust av processorns feltolerans i kombination med ytterligare ett enkelfel. Övergripande åtgärd om fel detekteras: Om fel upptäcks görs ett försök till återhämtning, dvs. operationen repeteras en gång. Om felet kvarstår sätts processorn i feltyst läge. Processorn är utrustad med dubblerade IO-portar. Feltyst läge innebär att dessa låses till ett bestämt värde (alla utgångar sätts låga). Processorn ska dessutom vara robust i drift. För att uppnå ovanstående målsättning har följande övergripande principer använts vid konstruktionen av processorn: Processorns funktionalitet är uppdelad i två separata kretsar (chip). Alla felupptäckande mekanismer ska vara implementerade på minst två ställen i processorn (tids- eller hårdvarumässig redundans) Assemblatorn är utformad så att den kan prediktera dataflödet genom processorn samt infoga informationsmässig redundans i instruktionen. Samtliga fel indikeras på en speciell buss som genomlöper hela pipelinen. Feldetekteringsmekanismerna korrigerar respektive bit i bussen vilken initieras som om alla fel har upptäckts för varje exekverad instruktion. Möjlighet att prova samtliga felupptäckande mekanismer med en speciell instruktion vilken stimulerar dessa mekanismer att generera felsignaler. Felhanterarna ska vara utformade så att de för denna instruktion endast accepterar ett resultat på felbussen som innehåller samtliga fel. Kontroll av att samtliga piperegister uppdaterar sina värden vid exekvering. Kontrollera data som lagrats i registerbanken och instruktionsminne hårdvarumässigt med hjälp av checksummor (bergerkoder). Data lagras i dataminnet tillsammans med sin checksumma. I registerbanken lagras även skrivadressen för att hårdvarumässigt kontrollera att data lästs/skrivits från rätt adress. Kontroll av data skrivs/läses från korrekt adress i dataminnet görs i mjukvara. IO-portarna ska vara utformade så att de är dubblerade. På så sätt kan applikationen som processorn är ansluten till konstrueras så att den jämför utsignalerna, och försätts i feltyst läge om dessa inte överensstämmer. Insignalerna från de båda IO-portarna ska jämföras innan de skrivs till registerbanken. Med enkelfel menas i denna rapport: Stokastiskt fel, som kan uppstå i hårdvara såväl som i mjukvara. I denna kategori av fel inräknas också spridningsfel med gemensam orsak (Common Cause Failures, CCF) men däremot inte multippelfel av typen; flera identiska enkelfel som inträffar i olika redundanta kanaler vid samma tidpunkt (Common Mode Failures, CMF). Inte heller ingår multippelfel av typen; flera olika enkelfel som inträffar vid samma tidpunkt (Different Mode Failures, DFM). 14

Följande fel upptäcks av processorn Permanenta enkelfel Analyseras med en integrerad testsekvens i programvaran. Åtgärd om fel upptäcks: Möjlighet att använda speciell instruktion för att försätta processorn i feltyst läge. Transienta enkelfel Störningar i hårdvaran/fel i programvara analyseras med funktioner implementerade i hårdvaran. Åtgärd om fel upptäcks: Operationen repeteras en gång, om felet kvarstår sätts systemet i feltyst läge. Om ett fel upptäcks registreras detta på en speciell databuss (failurebus) som är ansluten till felhanteraren (FH). Felhanteraren vidtar sedan åtgärd beroende på vilken typ av fel som anges på failurebus. 4 Prestandaökande metoder För att processorn inte ska förlora allt för mycket prestanda beroende på de feltoleranta egenskaperna har vissa konstruktionsmässiga åtgärder vidtagits. 4.1 Separat hoppberäkning/verifiering Det naturliga tillvägagångssättet att beräkna den nya adressen vid hopp (även verifiera villkoret för hopp) är att använda sig av ALU:n (Arithmeic Logic Unit) som finns i EXsteget (se figur 1). Detta sparar hårdvara eftersom ytterligare en komparator samt adderare annars måste finnas med i konstruktionen. Problemet med detta tillvägagångssätt är att detta tar 3 klockcykler att genomföra, och de instruktioner som läses in i pipelinen under två av klockcyklerna måste förkastas om hoppet genomförs. Förkastade instruktioner innebär i sin tur att det blir tomma luckor ( stall s ) i pipelinen som inte uträttar något arbete. I den feltoleranta processorarkitekturen har denna beräkning lagts i ID-steget (se bilaga 3, BRANCH LOGIC) för att spara en klockcykel vid hopp och därmed minska antalet stall s till en. 4.2 Forwarding Då en instruktion måste ha data från en tidigare exekverad instruktion som fortfarande ligger kvar i pipelinen uppstår problem med stall s. Betrakta följande exempel: ADD R1 R2 R3 SUB R4 R1 R5 Då instruktionen SUB ska läsa registerbanken har inte den tidigare instruktionen ADD exekverats färdigt genom pipelinen och har därför inte hunnit skriva resultatet i R1 (Detta kallas för RAW- (Read After Write) fel). Därför måste SUB vänta tills ADD gått igenom pipelinen, vilket innebär stall s. De flesta instruktionerna har en destinationsadress till registerbanken som följer instruktionen genom pipelinen. Genom att jämföra läsadresserna för SRC1 och SRC2 med destinationsadresserna för samtliga instruktioner längre fram i pipelinen går det att upptäcka om liknande problem har uppstått som i ovanstående exempel. Med forwarding menas att i så fall läsa tillbaka resultatet från den instruktionen direkt ifrån pipelinen och därmed inte behöva vänta på att resultatet ska skrivas i registerbanken (se bilaga 3). Detta fungerar inte för alla instruktioner, t ex läsning från IO-portar och dataminne. 15

4.3 ALU Adderaren i en ALU används ofta under exekvering av instruktioner. Om adderaren är långsam kan det påverka processorns totala prestanda märkbart. I den feltoleranta processorn har därför adderaren utformats enligt principen carry look ahead (se bilaga 4). I en vanlig adderare är inte beräkningen klar förrän carry-biten ripplat genom alla heladdrare som den är uppbyggd av. Med carry-look ahead minskas tiden för carryripplet. 5 Metoder för feldetektering 5.1 Bergerkod En bergerkod är en slags checksumma som beräknas genom att räkna antal ettor eller nollor i ett binärt tal. Syftet med bergerkoder är att om två tal finns tillgängliga med tillhörande bergerkoder är det möjligt att förutsäga bergerkoden för resultatet av en aritmetisk operation utan att utföra den aritmetiska operationen (se avsnitt 8.2.1, BPblocket). Det vill säga att det är möjligt att övervaka ALU:n i processorn med begerkoder. I processorn lagras alla tal tillsammans med sina bergerkoder (förutom vid TRAP). Eftersom bergerkoden också fungerar som en checksumma används bergerkoder för att kontrollera att de data som är lagrat i minne (registerbank, instruktionsminne och dataminne) fortfarande har samma bergerkod när det läses. Vid läsning av IO-portar skapas en bergerkod av resultatet som sedan skrivs tillbaka tillsammans med resultatet. Bergerkoder kan upptäcka enkelfel samt multipelfel i datamängder om multipelfelen är riktade åt samma håll det vill säga att alla bitar i multipelfelet fallerar till samma tal 1 eller 0. Exempel: Korrekt data Inkorrekt data Detekterat Feltyp 0010 0011 Ja Enkelfel 0110 1100 Nej Oriktat multipelfel 0001 0111 Ja Likriktat multipelfel 5.2 CRC-checksumma CRC (Cyclic Redundancy Check) är en sorts checksumma beräkning med mycket hög feltäckningsgrad. CRC checksumman beräknas med en binär division mellan data och ett tal (sk. polynom). Den rest som blir över efter divisionen är CRC-checksumman (se avsnitt 8.1.1). Divisionen som genomförs kallas även för modulo-2 division vilket innebär följande: Vid en vanlig heltalsdivision används högsta möjliga faktor vilken multipliceras med divisorn varefter produkten subtraheras bort från talet som ska divideras. Kvar blir en rest. Vid binär modulo-2 division ersätts subtraktionen med en XOR-operation mellan divisorn och resten. Genom att skifta datat lika många bitar åt vänster som polynomets längd-1fås alltid en sista rest (CRC) med samma bitlängd efter datat. Vid skift åt vänster fås lika många nollor till höger om datat som den förväntade CRC:ns längd. Om istället nollorna ersätts av en tidigare genererad CRC och divisionen genomförs kommer alltid resten bli noll om datat är samma som då CRC:n genererades. 16

På grund av att CRC-algoritmen utgörs av skiftningar och XOR-operationer är den lämplig att implementera i hårdvara. I processorn används CRC checksummor för att beräkna signaturer av programräknaren. Varje instruktion innehåller två programräknarsignaturer, en för nästa instruktion och en för möjlig nästa instruktion om hopp tages. 5.3 Assemblatorn Assemblatorn förutsäger två stycken programräknarsignaturer, en för nästa instruktion (PCS1) och en för nästa instruktion om hopp tagits (PCS2). Assemblatorn lägger även in nästa operationskod (NOP) i instruktionen. Bergerkoden till immediate-fältet beräknas av assemblatorn som även tar hänsyn till om immediate-fältet ska utökas med teckenbiten. Beroende på vilken instruktion som behandlas av assemblatorn, kan assemblatorn förutsäga vissa datavägar genom processorn. Assemblatorn anger datavägen i instruktionen med en TAG (se avsnitt 5.4) som sedan används för att verifiera att multiplexarna ställt sig rätt. Slutligen beräknas en bergerkod till hela instruktionen för att säkerställa att instruktionen lästs rätt från instruktionsminnet. 5.4 Övervakning av multiplexrar Vissa multiplexrar övervakas på så sätt att TAGs (se avsnitt 8.1.2) läggs till respektive dataingång. Denna TAG är unik för varje dataingång till multiplexern vilket medför att det går att se på utgången hur multiplexern adresserats. Assemblatorn förutsäger hur multiplexern ska adresseras beroende på vilken instruktion som exekveras och lägger till denna information till instruktionskoden. En komparator jämför sedan den TAG som ges på multiplexerns utgång med informationen från assemblatorn. Om multiplexern adresserats felaktigt kan detta upptäckas. Det går inte att förutsäga datavägen genom forwarding-blocket med assemblatorn. Varje TAG på dataväg till forwarding-blocket läggs till i respektive pipelinesteg. Identiteterna kontolleras sedan genom att dubblera komperatorena som jämför adresserna som avgör om datat ska forwardas. En uppsättning komperatorer styr multiplexrarna och dubbletterna förutsäger vilken identitet som ska ha forwardats. 5.5 Dubblerade funktioner Felhanteraren, en pulsräknarkrets samt IO-portarna är dubblerade och har en uppsättning i varje krets. Detta för att kretsarna ska kunna övervaka varandra och ha möjlighet att sätta åtminstone en av IO-portarna i feltyst läge. Felhanterarna kontrollerar inte varandras funktion. Istället antas att sannolikheten för att ett latent fel i en av felhanterarna ska åtföljas av ett fel i den andra felhanteraren vara mycket låg eftersom de är lokaliserade i olika kretsar. Funktionen hos IO-portarna kan kontrolleras av mjukvara och funktionen hos pulsräknarna (ska) kontrolleras av en extern watch-dog krets. 17

6 Användning av metoder för feldetektering 6.1 Instruktion Varje instruktion innehåller en bergerkod för att kontrollera att instruktionen lagrats/hämtats korrekt från instruktionsminnet. Varje instruktion innehåller bla information om -Aktuell op-kod -Efterföljande op-kod -Efterföljande CRC signatur av PC -Möjlig efterföljande CRC signatur av PC vid taget hopp -Bergerkod för immediate-fält -Multiplexeridentitet (TAG) för kontroll av dataflöde -Bergerkod för hela instruktionen I nedanstående avsnitt (6.2 6.5) beskrivs översiktligt hur denna information används tillsammans med de övriga metoderna för feldetektering. 6.2 Villkorliga/ovillkorliga hopp Redundans införs genom att en PC-signatur beräknas dels av assemblatorn och dels av processorn. Assemblatorn lagrar i varje instruktionskod den förväntade op-koden och tillhörande PC-signatur för nästa instruktionsadress samt PC-signatur för nästa instruktionsadress vid taget hopp. 6.2.1 Villkorligt hopp Bergerkod används för att verifiera att komparatorn i branchmodulen fungerar korrekt. Hoppadressen kontrolleras med hjälp av den förväntade PC-signaturen som kompilatorn beräknat. 6.2.2 Ovillkorligt hopp Ovillkorliga hopp verifieras endast genom kontroll av hoppets måladress (PCS). 6.2.3 TRAP genererade hopp Kompilatorn placerar TRAP-rutinen vid en känd startadress i instruktionsminnet. Mjukvarugenererad TRAP Aktuell PC lagras i register R31 (låses för skrivning) samt PC:ns signatur (PCS) i en buffert i IF-steget, TRAP-rutinens startadress flyttas till PC. Vid återhopp kan sedan innehållet i bufferten kontrolleras. Hårdvarugenererad TRAP Den instruktion som ligger först i pipen byts ut mot en mjukvarutrap och behandlas sedan på samma sätt som mjukvarugenererad TRAP. 6.3 Aritmetiska operationer All data i registerbanken och dataminnet lagras tillsammans med tillhörande bergerkod. Vid en aritmetisk operation används bergerkoderna till operanderna för att förutsäga vad resultatet av operationen kommer att få för bergerkod. Den beräknade bergerkoden 18

jämförs sedan med en bergerkod som är genererad av resultatet. Bergerkoderna används även för att kontrollera komparatorn i branch-hanteraren i ID-steget. 6.4 Läsning/skrivning till dataminnet och IO portar Figur 1.2 beskriver hur IO-portarna och dataminnet är anslutna till processorn. 6.4.1 Läsning/skrivning till dataminne All data som lagras i dataminnet/registerbanken skyddas av bergerkoder vilket gör att fel i datat upptäcks när det ska användas. Adresseringsfel i dataminnet upptäcks av minnestester implementerade i mjukvaran. 6.4.2 Läsning av IO portar Processorn har två stycken identiska IO-portar samt en transparent IO-port. IO-portarna har vardera 12 IO-signaler. Alla IO-signaler i IO-portarna kan konfigureras som ingång eller utgång. Om en IO-signal är konfigurerad som en ingång kan man även ange en prioritet på den. När ingångarna läses sammanfogas ingångarna från två IO-portar. Sammanfogningen sker på två sätt, antingen ska signalerna vara inverterade eller lika beroende på vilken prioritet som angivits. Resultatet av läsningen lagras i de 12 minst signifikanta bitarna och i de 12 mest signifikanta bitarna lagras statusbitar som anger om signalparen överensstämmer med den angivna prioriteten. 6.4.3 Skrivning till IO portar Vid skrivning till IO-portarna skrivs samma värde till de IO-signaler som är definierade som utgångar. Felsäkerheten från processorns sida ligger i att de tre IO-portarna var för sig kan tvingas till ett feltyst läge om ett fel i processorn upptäcks. 6.5 Instruktionshämtning För att en instruktion ska få hämtas från instruktionsminnet måste dess adress (PC) överensstämma med den som lagrats från föregående instruktion (PC signatur). Undantag görs i händelse av TRAP instruktion. 7 Åtgärder vid detekterat fel Om fel upptäcks görs ett försök till återhämtning, dvs. operationen repeteras en gång. Om felet kvarstår sätts processorn i feltyst läge. Feltyst läge innebär att alla utgångar på IOportarna sätts låga av felhanterarna. 8 Implementation Processorn är implementerad med hjälp av VHDL. Nedan följer den tekniska och funktionella beskrivningen av processorns olika block, samt dess mellanliggande signaler och bussar. Beskrivningen utgörs av blockdiagram för de olika stegen, dessa blockdiagram stämmer inte nödvändigtvis överens med den RTL-fil som syntesverktyget skapar vid syntes utan syftar bara till att ge en enkel och övergripande inblick i systemets olika funktioner och dess implementation. Beteckningar i blockdiagrammen: Då antal signaler i en buss måste förtydligas görs detta med följande beteckning i blockdiagrammen: bn:m där n högsta bitnummret i bussen och m lägsta. Ex. b4:0 är en 5-bitars buss med mest signifikanta biten 4. 19

Om inget anges har bussen samma bredd som den hade senast den betecknades (speciellt vid förgreningar). Varje beskrivning nedan inleds med en översiktlig beskrivning av blockets funktion följt av en beskrivning av vilka metoder för feldetektering som blocket använder. Efter detta kommer en lite fördjupad teknisk beskrivning av blockets implemention som läses tillsammans med respektive blockdiagramm i någon av bilagorna 2 9. Den tekniska beskrivningen syftar till att ge förståelse av VHDL-koden i bilaga 13 och 14. Vissa delar av processorn beskrivs i den tekniska beskrivningen men är inte utritade i blockdiagrammen. Detta för att block-diagrammen främst syftar till att illustrera dataflödet genom processorn och därför inte vara allt för detaljerade. Dessa delar är istället beskrivna i texten. Processorns uppbyggnad av VHDL-komponenter beskrivs av VHDL-koderna KRETS1 och KRET2 (bilaga 13 respektive 14). Själva CPU:ns uppbyggnad ges av VHDL-koden CPU (bilaga 13). Varje ingående VHDL-block är refererat från den tekniska beskrivningen nedan. 8.1 KRETS 1 8.1.1 IF-steget FUNKTION I detta steg hämtas instruktionen från minnet. Steget infogar även avbrottsinstruktionen TRAP vid externt avbrott. Ett avbrott innebär att en speciell TRAP-hanterare exekveras. Denna TRAP-hanterare har en fördefinierad startadress i instruktionsminnet. Programmet återgår till den programadress där avbrottet detekterats då instruktionen RFT (Return From Trap) exekveras. För varje instruktion som hämtas lagras programräknaren (PC), nästkommande instruktion (NOP) samt en signatur (PCS1) för nästkommande PC för normal exekvering och vid taget hopp (PCS2) i varsin stack. Stackarna används för att senare kunna köra om en instruktion om ett fel upptäcks i processorn samt för att kunna infoga en TRAPinstruktion i instruktionskedjan. Även NOP, PCS1 och PCS2 i den hämtade instruktionen lagras i respektive register. FELDETEKTERING När instruktionen hämtas beräknas en CRC-checksuma för den aktuella adressen (PC), denna checksumma jämförs sedan med den som lagrats från föregående instruktion PCS1 (eller PCS2 om hopp taget). PCS1 och PCS2 genereras av assemblatorn. Undantag görs i händelse av TRAP. Vid händelse av att den hämtade instruktionen är RFT jämförs PCS2 med ett särskilt register som skrevs vid en tidigare TRAP-instruktion. Detta register innehåller signaturen för återhoppsadressen från TRAP-hanteraren. Den hämtade operationskoden (OP) jämförs med den som lagrades i föregående instruktion (NOP). En berger-räknare går igenom hela instruktionen varefter resultatet jämförs med den av assemblatorn beräknade bergerkoden INB. Om INB inte överensstämmer med den framräknade bergerkoden för instruktionen sätts felsignalen im_failure hög. Om villkoren för programräknarsignaturen (PCS) eller för nästkommande instruktion (NOP) sätts felsignalen instr_failure hög. 20

TEKNISK BESKRIVNING Se bilaga 2 LÄSNING AV INSTRUKTION Multiplexern M0 styrs av signalen branch_taken och väljer om PC-registret ska laddas med NEXT_PC som kommer från ID-steget eller datat som finns lagrat i vippan D0. D0 innehåller adressen till den närmast efterföljande instruktionen i instruktionsminnet, denna adress är framräknad av adderaren A0. Multiplexern M1 styrs av signalen RETRY och väljer om PC:n ska hämtas ifrån stacken PC_STACK vid omkörning av instruktioner. Det från instruktionsminnet upplästa datat kommer på bussen ROM_DATA vilken är ansluten till en bergerkodsgenerator samt till multiplexern M2. Den framräknade bergerkoden jämförs i komparatorn C0 med INB som återfinns på bussen ROM_DATA. Om dessa inte är lika sätts felsignalen instr_failure hög. PC:n (XPC) är ansluten till 5 CRC-generatorer som genererar en 4 bitars CRC-kod för PC:n. Resultatet av CRC-beräkningen jämförs sedan i komparatorn C3 med PCS1 (genom D8). Om dessa inte är lika sätts signalen im_failure hög. Polynomet som används för CRC-genereringen är: 27 (b11011). Polynomet är inte valt av någon speciell orsak och användning avrekommenderas. Istället bör ett primtal användas som polynom, detta för att CRC-genereringen ska upptäcka fler fel. Varje instruktion (OP) jämförs med föregående instruktion (NOP, vippa D7) i komparatorn C2 (genom M3). Om OP inte överensstämmer med NOP kommer signalen instr_failure att sättas hög. De av assemlatorn förutsagda multiplexeridentiteterna (TAG:s) ges på bussarna wb_tag (2 bitar bred) och imm_ximm_tag (4 bitar bred). VID HOPP En hoppinstruktion kräver två klockcykler för att exekveras. I första klockcykeln ska hoppinstruktionen hämtas från IM i IF-steget och i den andra klockcykeln ska villkoret för hoppet verifieras i ID-steget. Om hoppet tas (det vill säga att villkoret för hoppet uppfylls) sätts signalen branch_taken från ID-steget samtidigt som hoppets nya instruktionsadress beräknas och ges tillbaka på bussen NEXT_PC. Den instruktion som hämtas till IF-steget under den andra klockcykeln (så kallad delay-slot ) kan väljas godtyckligt. Signalen branch_taken ställer om multiplexern M0 (och M4) så att nästa instruktion läses från den framräknade hoppadressen. M4 ställer om sig så att XPC:s CRCchecksumma istället jämförs med PCS2, precis som ovan sätts signalen im_failure hög om dessa inte är lika. Instruktionen efter delay-slot :en ska ha samma OP som den instruktion som läses om hoppet tas. Annars sätts instr_failure hög. Orsaken till det är NOP-testet. VID TRAP En TRAP är ett avbrott och behandlas av processorn som ett ovillkorligt hopp med förutbestämd destinationsadress. De instruktioner som direkt följer denna destinationsadress kallas för TRAP-hanterare och ska avslutas med instruktionen RFT. Det finns två typer av TRAP-funktioner, mjukvarugenererat TRAP och hårdvarugenererat TRAP. Komparatorn C1 kontrollerar om den lästa instruktionen är TRAP. I så fall ges signal till D3 och D4 som lagrar NOP och PCS (NOP_trap och PCS_trap). 21

Vid ett hårdvarugenererat TRAP sätts vippan D1 om inte den samtidigt upplästa instruktionen är en hoppinstruktion eller om den upplästa instruktionen befinner sig i en sk. delay-slot. Vippan D1 och D2 genererar pulserna trap och ins_nop till som infogar en TRAP- följt av en NOP-instruktion enligt figur 4. Signalen busy förblir hög tills TRAP-hanteraren är klar och den hårdvarugenererade TRAP-signalen återigen blir låg. Detta innebär att processorn inte tar emot ytterligare en TRAP innan traphanteraren är klar. Både vid hårdvarugenererad- och vanlig TRAP sätts vippan D15 TRAP_BUSY vilken används i ID-steget för att kontrollera att RFT inte exekveras utanför TRAPhanteraren. För att få detta beteende förhindras även uppräkning av programräknaren under en cykel vid trap. Figur 4:. Timingdiagram för infogning av TRAP VID RFT (Return From Trap) Denna instruktion avslutar TRAP-hanteraren. Komparatorn C1 kontrollerar om den lästa instruktionen är RFT. I så fall sätts en signal vilken sätter vippan D5 som ger signalen rft_fin. När både rft_fin blir hög och HW_TRAP blir låg nollställs D1 (se VID TRAP). Signalen ställer också om multiplexrarna M3 och M6 vilket innebär att PCS samt NOP testerna utförs på det data som finns lagrat i D3 och D4 (NOP_trap och PCS_trap) istället för D7 och D9. VID RETRY IF-steget har tre stycken FIFO-register (First In First Out) PC_stack, NOP_stack och PCS_stack. Dessa register lagrar samma PC, NOP och PCS för varje uppläst instruktion, som ges till ID-steget. Räknaren PIPE_counter räknar i intervallet 0 5 styr vilken position i registren som data ska lagras. Den position (räknarens aktuella värde) som data lagras på motsvarar den instruktion som finns i WB-steget. Signalen RETRY ställer om multiplexrarna M1, M3 och M5 så att: M1: XPC <= PC_stack M3: NOP <= NOP_stack M5: PCS <= PCS_stack Detta bara för att inte PCS- samt NOP-testerna ska generera felsignalerna im_failure och instr_failure vid återkörning av en instruktion. RETRY sätter även signalen TRAP_RETRY (vippa D16) vilken möjliggör omkörning av instruktionen RFT. 22

FAILURE BUS Denna buss genomlöper hela pipelinen och innehåller samtliga felsignaler som finns i systemet då den når WB-steget. I IF-steget ges bit 0 och bit 1 av felsignalerna instr_failure och im_failure. im_failure sätts hög om PCS-testet fallerar. instr_failure sätts hög om NOP-testet fallerar eller om den genererade bergerkoden för instruktionen ej överensstämmer med INB. Vid reset ettställs alla bitar utom b0 och b1 i FAILURE_BUS som vidarebefordras till ID-steget via vippan D14. De övriga vipporna D6-D12 utgör stegets register, och vidarebefordrar data till ID-steget. Vippan D13 ger en av läsadresserna (ADDR2) till registerbanken i ID-steget. Orsaken till att den är placerad i IF-steget beror på syntesverktyget som inte kunde skapa ett block- RAM om inte samtliga adressbussar kom från register. Beroende på adresseringsmoden (AM) sätts ADDR2 till antingen dest (AM = 00 : mux_dest) eller de 5 lägsta bitarna i SRC2 (AM!= 00 : mux_src2) av M7. Se den tekniska beskrivningen av ID-steget för mer information om adresseringsmoder. Om processorn försätts i feltyst läge förhindras uppräkningen av programräknaren i IFsteget av två signaler (safe och safe2). Detta block är konstruerat med följande VHDL-beskrivningar (bilaga 13; KRETS 1), IF_stage Port map fil för IF-steget samt pipelineregister IM Läser data från instuktionsminne, genomför samtliga tester i detta steg PC_COUNTER Ökar programäknaren PC_MUX Väljer mellan programräknare genererad vid taget hopp eller den från PC_COUNTER 8.1.2 ID-steget FUNKTION Detta steg avkodar resultatet av IF-steget till datafält och styrsignaler. Steget består främst av fyra block: Registerbanken, branchblocket, IMM_XIMM blocket, forwarding blocket samt decode-blocket. Registerbanken innehåller 31 st. register som alla kan läsas eller skrivas. Alla data (med undantag från TRAP-exekvering) lagras i registerbanken tillsammans med sina bergerkoder. I de 5 mest signifikanta bitarna lagras den adress som data är avsedd att skrivas till. Branchblocket utvärderar villkoren för hopp samt beräknar den nya adressen till instruktionsminnet. Branchblocket beräknar även den nya adressen för ovillkorliga hopp (RESET, TRAP, RFT). DECODE-blocket avkodar den inkommande operationskoden till olika styrsignaler till de övriga blocken i systemet. IMM_XIMM-blocket avgör beroende på adresseringsmoden om src2 är en adress som ska läsas i registerbanken eller om src2 i sig utgör data som ska användas i senare beräkningar. 23

Forwarding-blocket kontrollerar om någon instruktion längre fram i pipelinen har samma måladress som någon av src1 eller src2. I så fall läses det data som respektive måladress motsvarar direkt ifrån piperegistret. FELDETEKTERING IMM_XIMM-blocket upptäcker fel adresseringsmoden samt ifall instruktionerna TRAP och RFT har ett felaktigt register angivet i dest. Om ett fel upptäcks sätts felsignalen addr-failure hög. I detta block sätts även TAGs (dvs kanalidentitet för multiplexrar) för respektive adresseringsmod eller om det är en TRAP. Dessa TAGs jämförs sedan i ett mindre block som heter src2_mux med TAGs som genererats av assemblatorn. Om fel upptäcks ges SRC2 en felaktig bergerkod och signalen imm_ximm_failure sätts hög. DECODE blocket upptäcker om det fått en otillåten instruktion och sätter i så fall felsignalen decode_failure hög. Branch blocket upptäcker om det fått en felaktig kombination av insignaler, samt om instruktionen RFT exekveras felaktigt. Om fel upptäcks sätter blocket felsignalen branch_failure hög. Beräkningen av hoppets måladress i instruktionsminnet kontrolleras i IF steget och jämförelsen kontrolleras senare med hjälp av bergerkoder i EX-steget samt i BP-steget. Forwardingblocket kontrollerar att rätt data läses från piperegistren med hjälp av TAGs som hårdvarumässigt läggs till bussarna som är anslutna mellan forwardingblocket och motsvarande register. TEKNSK BESKRIVNING Se bilaga 3 DECODE-blocket Detta block har operationskoden som insignal och utifrån den sätter blocket en styrbuss CTRL enligt: CTRL (bit) Flagga 0 Branch flag 1 Trap flag 2 Return from trap flag 3 Används ej 4 Används ej 5 Forward not allowed flag 6 Disble reg_file test flag 7 TST instruktion flag Tabell 2: Innebörd av bitarna i CTRL-bussen 24

Decode-blocket sätter dessa flaggor enligt följande tabell: OP B7 B6 B5 B4 B3 B2 B1 B0 BEQ 0 0 1 0 0 0 0 1 BNE 0 0 1 0 0 0 0 1 RFT 0 0 1 0 0 1 0 1 TRP 0 1 1 0 0 0 1 1 RIO 0 0 1 0 0 0 0 0 LDW 0 1 1 0 0 0 0 0 PUT 0 0 1 0 0 0 0 0 SW 0 0 1 0 0 0 0 0 PRT 0 0 1 0 0 0 0 0 SFE 0 0 1 0 0 0 0 0 TST 1 0 0 0 0 0 1 0 RST 1 0 1 0 0 0 0 1 OTHERS 0 1 0 0 0 0 0 0 Tabell 3: Bitarna i CTRL-bussen för olika instruktioner Om en odefinierad instruktion eller instruktionen TST ges till decode-blocket kommer signalen decode_failure att sättas hög. IMM/XIMM-blocket Detta block avkodar SRC2 med avseende på instruktionens adresseringsmod i följande tre moder: Register, immediate och extended immediate. Vilken som används bestäms av följande: ADDR_MODE = 00 - Register = 01 - Immediate = 10 - Extended Immediate = 11 - Inte använd Adresseringsmoden styr multiplexern M3 som väljer en av tre bussar till XDATA2 (29b). Vid register-mode (REG) ansluts XDATA2 till registerbankens ena databuss (reg_data2). Vid immediate-mode (IMM) ges de första 12 bitarna av SRC2. Den tolfte biten (teckenbiten) bestämmer om b13-b24 är endast ettor (sign extended) eller endast nollor. Bitarna b25-b29 är bergerkoden för talet. Om CTRL-bussens b1 (TRAP) eller b2 (RFT) är höga kontrollerar komparatorn C5 att data som ligger på bussen DESTin är B 11111 (register 31) annars sätts signalen addr_failure. Vid extended immediate-mode är de 12 första bitarna alltid nollor och de efterföljande 12 bitarna SRC2. De sista 5 bitarna är bergerkoden. Multiplexern M4 bestämmer om bussen DDEST ska få data från registerbanken eller innehålla PC:n beroende på b0 i bussen CTRL (om instruktionen är en branch). Multiplexern M5 bestämmer om bussen DATA2 ska vara XDATA2 (se ovan) eller DDEST beroende på b0, b1 och b2 i bussen CTRL (om instruktionen är en TRAP). Multiplexrarna M3-M5 övervakas av så kallade multiplexeridentiteter (TAGs) dessa är inte utritade i beskrivningen. Testet syftar till att kontrollera dataflödet genom multiplexrarna och följer principen som visas nedan i figur 5. 25

Figur 5: Princip för övervakning av dataflöde Identiteterna läggs till bussarna i IMM_XIM -steget och kontrollen görs i blocket SRC2_MUX. Skillnaden från figur 5 är att assemblatorn också har förutsagt identiteten som jämförs. Alltså används två komparatorer och två multiplexrar. Identiteterna från assemblatorn läses från bussen imm_xim_tag som kommer från IF-steget. Om fel upptäcks i kontrollen sätts felsignalen imm_ximm_failure hög samt att data (DATA2) förändras så att det har felaktig bergerkod. REGISTERBANKEN Registerbanken består av två två-ports RAM-minnen (BM1 och BM2) med vardera 32x34 bitar. Orsaken till detta är att ett två-ports RAM-minne kan läsa respektive skriva från/till en adress per klockcykel. Genom att använd två st. sådana RAM-minnen kan två adresser läsas och en skrivas per klockcykel. Varje klockcykel skrivs data WRITE_DATA till adressen WRITE_ADDR till båda RAM-blocken. De 5 högsta bitarna i det skrivna data innehåller WRITE_ADDR. Skrivning av registerbanken sker på negativ flank medan läsning sker på positiv flank. Data läses sedan från respektive RAM-block med adresserna src1_addr och src2_addr som ger data på bussarna DATA1 och DATA2. Vid läsning jämförs läsadressen med de 5 högsta bitarna i det lästa data, om dessa inte överensstämmer sätts felsignalen rbank_failure hög. Denna kontroll genomförs inte för de instruktioner som sätter bit 6 i bussen CTRL hög. Detta test är inte utritat i beskrivningen av ID-steget. src2_addr utgörs av de första 5 bitarna i SRC2 och kommer från IF-steget (ADDR2). Detta på grund av att det måste sitta register på samtliga adressbussar till RAM-blocken så att det syntesverktyg som används ska implementera minnena som riktiga RAM-block i FPGA:n (och inte som enskilda vippor för varje bit). Se även teknisk beskrivning av IFsteget. Insignalerna check och extra_check förhindrar oberoende av varandra skrivning till registerbanken. Om någon av signalerna blir hög blir write_enable låg och ingen skrivning av minnet kan förekomma. extra_check är inte utritad i beskrivningen av IDsteget. Data som lagras i registerbanken är alltså organiserat på följande sätt: b34-b30 Adressen som data avsågs skrivas till b29-b35 Bergerkoden för lagrat data b24-b00 Data BRANCH-blocket Detta block beräknar hoppvektorn (NEXT_PC) samt verifierar hoppvillkor. Komparatorn C1 kontrollerar om instruktionen är ett hopp och ger 4 styrsignaler om den är ett hopp enligt nedanstående tabell, 26