Entwicklung eines synthesefähigen 8-Bit RISC-Prozessors in VHDL CAE - Seminar - C. Koegst, M. Scheffler Semester: D7 WS 2000 Prof. Dr.

Transkript

1 Entwicklung eines synthesefähigen 8-Bit RISC-Prozessors in VHDL CAE - Seminar - C. Koegst, M. Scheffler Semester: D7 WS 2000 Prof. Dr. Reichardt, Prof. Dr. Schubert

2 1. Einleitung Spezifikation Grundlegende Eigenschaften des Prozessors Von der Vorgabe abweichende Verbesserungen der Prozessoreigenschaften: OPCODE-Tabelle Struktur des Maschinencodes: Konzept Grundlegende Abläufe im System Die Komponenten Die ALU (Arithmetic logic unit) Quellcode Simulation Prozessor-Register Quellcode Simulation Pipeline Arithmetische Operationen Sprünge Load-/Store-Befehle Quellcode Simulation Adress-ALU Quellcode Simulation Simulation des Gesamtsystems Signalverläufe Teil Signalverläufe Teil Signalverläufe Teil Quellcode des Assemblerprogramms Quellcode der Testbench Quellcode des 16Bit-RAM-Modells...34 Seite 1

3 6. Implementierung Ergebnis der Implementierung Benötigte Hardwareressourcen Maximale Taktfrequenz Ergebnis/Anmerkungen Anhang Quellcode des RISC-Prozessors Literatur...47 Seite 2

4 1. Einleitung Die Entwicklung logischer Systeme erfordert mit steigendem Komplexitätsgrad, eine zunehmend abstraktere Beschreibung der Systemeigenschaften. Hardwarebeschreibungssprachen wie VHDL ermöglicht im Zusammenhang mit Rehkonfigurierbarer Logik eine Top-down -Entwicklung mit kurzem Designflow. Im Rahmen eines CAE-Seminars, soll ein Riscprozessor in VHDL entwickelt werden. Ziel ist es außerdem, eine Implementierung des Codes in eine FPGA durchzuführen, so dass auf Synthesefähigkeit des VHDL-Codes zu achten ist. Als Entwicklungs-tool steht das Programm Modelsim zur Verfügung. Eine detaillierte Spezifikation ist dem Folgenden Teil zu entnehmen. Auf die Grundlagen einer Risc-Prozessorarchitektur kann hier nicht eingegangen werden, es an dieser Stelle auf die am Ende genannte Literatur verwiesen. 2. Spezifikation Um ein befriedigendes Ergebnis erzielen zu können ist eine möglichst detaillierte Spezifizierung unerlässlich. Einige Punkte wurden erst währen der Entwicklung in die Spezifikation aufgenommen. 2.1 Grundlegende Eigenschaften des Prozessors RISC Prozessor mit 8-Bit Datenbreite und 11-Bit Adressbreite Von Neumann Architektur (gemeinsamer Daten- und Adressbus) Dreifache Adressierbarkeit (Quelle1, Quelle2, Ziel) 5-Stufige Pipeline Von der Vorgabe abweichende Verbesserungen der Prozessoreigenschaften: Reduzierung der Pipeline auf drei Stufen, bei gleicher Funktionalität Einfügen von NOP-Befehlen bei Sprüngen und Load-/Store-Befehlen, durch die Hardware Freie Zieladressierung (R0...R7) bei den Befehlen SHLA und LDA Seite 1

5 2.2 OPCODE-Tabelle Nr. Opcode und Operand Erläuterung Flag C Z 0 SHLA Register C Reg 0 Linksschieben 1 STA Reg0 RAM Absolutes Speichern LDA # Datum Reg0 Unmittelbares Laden 0 3 LDA RAM Reg Absolutes Laden 0 4 MOV R1,R2 R1 R2 Verschieben 0 5 ADD R1,R2,R3 R1+R2 R3 Addieren 6 SUB R1,R2,R3 R1-R2 R3 Subtrahieren 7 OR R1,R2,R3 R1 R2 R3 Oder-Verknüpfung 0 8 AND R1,R2,R3 R1 R2 R3 Und-Verknüpfung nicht vorhanden - 10 BR Sprungweite Relativer Sprung unbedingt BZ Sprungweite Relativer Sprung falls Z= BNZ Sprungweite Relativer Sprung falls Z= BGE Sprungweite Relativer Sprung falls C= BLT Sprungweite Relativer Sprung falls C= NOP Keine Operation - - Tabelle 1: OPCODE-Tabell : entsprechend dem Ergebnis geändert - : unverändert 0 : gelöscht Struktur des Maschinencodes: Load-/Store-Befehle: X OPCODE Memory Adresse Arithmetische Operationen: X OPCODE XX Quelle1 Quelle2 Ziel Seite 2

6 3. Konzept Im folgenden wird auf das System als Ganzes eingegangen. Anschließend werden die Komponenten gesondert dargestellt. Es wird zwischen Daten-, Adress- und Steuerpfaden unterschieden, um den sukzessiven Ablauf im Prozessor zu veranschaulichen. Während des Entwicklungsprozesses wurde die Spezifikation verändert (siehe 2.1.1), was sich in einer verbesserten Performance des Prozessors bzw. geringerem Hardware-Aufwand äußert. Das entwickelte Konzept sieht die Unterteilung des Prozessors in vier Komponenten vor: Register (8 x 8 Bit) ALU Pipeline Adress-ALU 3.1 Grundlegende Abläufe im System Die von der Adress-ALU auf den Datenbus angelegte Adresse, wird vom externen RAM asynchron verarbeite, d.h. es wird unmittelbar das entsprechende 16-Bit Datenwort auf dem Datenbus angelegt. Das schrittweise durchlaufen der Pipeline nt mit der Stufe P0 (Decode/Operands), in der bei Operationsbefehlen anhand der im Maschinencode enthaltenen Quelladresse/n, die jeweiligen Register adressiert werden. Mit dem nächsten Systemschritt erfolgt die Übernahme des Codes in die Stufe P1 (Execute) und der Registerdaten in die ALU-Register A und B. Die Pipelinestufe übergibt den Opcode and die ALU, so dass das Operationsergebnis mit dem nächsten Schritt in das Ergebnisregister C übernommen wird. Die nun in der Stufe P2 (Store) vorliegende Zieladresse, schaltet das Zielregister frei. Nach dem anschließenden Systemschritt, steht das Ergebnis im Register zur Verfügung. Parallel dazu wird bei jedem Schritt ein weiteres Maschinencodewort in die Pipeline übernommen, so dass im Betrieb bei jedem Takt ein Ergebnis berechnet wird. Sprung- und Load-/Store-Befehle führen zwingend zu einem Wartezyklus, da ein Codewort in der Stufe P0 ungültig wird. Weitere Ausführungen dazu im Folgenden. Seite 3

7 Register R0-R7 Register Enable (Ziel) Datenpfad Adresspfad Steuersignale ALU A/B/C-Reg Pipeline Register R0-R7 Store/Result Adressbus Adresssteuerung A-Reg B-Reg nop(int) Adress-ALU R0 ALU Befehl Flags Execute nop(int) Sprung Load/Store Register Enable (Quelle) C-Reg Decode/Operands Sprungweite Datenbus Bild 1: Signallaufplan des Prozessorsystems Seite 4

8 4. Die Komponenten In diesem Kapitel werden die einzelnen Komponenten des Systems erläutert. Im Speziellen wird auf die Programmierung nur dann eingegangen, wenn es zum Verständnis notwendig ist, Kenntnis der Syntax werden vorrausgesetzt. Die Funktionsfähigkeit wird jeweils durch einen Simulation belegt wird. Im Kapitel 5 erfolgt eine Simulation des Gesamtsystems. 4.1 Die ALU (Arithmetic logic unit) Der Programmteil ALU enthält die arithmetische Recheneinheit, und die im System benötigten Quellregister A und B, sowie das Ergebnisregister C. Die Umsetzung erfolgt prinzipiell in zwei Prozessen. Der erste Prozess zur synchronen Übernahme und Übergabe der Daten, sowie zum asynchronen Rücksetzen. Die Übernahme sämtlicher Ein- und Ausgangssignale erfolgt Taktsynchron (Prozess: synchron_alu), dadurch wird die Verwendung von DFF beim Implementieren erreicht. Die unter if Reset= 1 then formulierten Bedingungen beschreiben das Schaltnetz für einen asynchronen Reset der DFF. Unter elsif clk event and clk= 1 folgen die Bedingungen für eine synchrones Setzen der DFF. vom Registerblock (Quelle 1 u. 2) A-Reg B-Reg Datenpfad (8 Bit) Steuerpfad (2/4 Bit) Prozess synchron_alu Prozess alu ALU D-Bus Opcode Flags 4 2 D-Bus (Daten aus dem Speicher) C-Reg zum Registerblock (Ziel) Bild 2: Daten- und Steuerpfad der ALU Seite 5

9 Der zweite Prozess (alu) ist in Anlehnung an das Beispiel in [1] S.202 programmiert. Basis des Prozesses alu, ist eine case-abfrage, in der abhängig vom Befehle (Opcode) die endsprechenden Operationen erfolgen. Um Befehle ausführen zu können, die das Carry-bit ändern, ist es notwendig ein Ergebnisvektor (RESULT) zu erzeugen. Dessen Bitbreite muss um ein Bit größer sein als die der Operatoren (AVAR, BVAR), um den Übertrag aufnehmen zu können. Um das bei der Synthese das zu erzeugende Übergangsschaltnetz zu minimieren, wird bei Befehlen in der die ALU keine Berechnungen ausführt (Sprünge, Load/Store, NOP), dem Ergebnis der Zustand (don t care) zugewiesen. ( [1] S.72 ) Seite 6

10 4.1.1 Quellcode constant ZERO: std_ulogic_vector(7 downto 0) := (others=>'0'); signal A_int, B_int: std_ulogic_vector(7 downto 0); signal F: std_ulogic_vector (7 downto 0); signal ZFLG_int, CFLG_int: bit;.. synchron_alu: process (CLK, RESET) if RESET = '0' then -- Asynchroner Reset A_int <= (others=>'0'); B_int <= (others=>'0'); c_bus <= (others=>'0'); c_flag <='0'; -- Vermeiden von Latches z_flag <='0'; elsif (clk'event AND clk = '1') THEN A_int <= To_StdUlogicVector(a_bus); -- interne Kopie der A u. B Register B_int <= To_StdUlogicVector(b_bus); -- U-logic für Rechenoperationen c_bus <= To_StdlogicVector(F); -- Ergebnis synchron ausgeben => DFF case OPCODE is when SHLA LDA LDAA MOVE ADDA SUBA ANDA ORA => -- Bei bestimmten Befehlen: if F=ZERO then -- Z-Flag setzen wenn das Ergebnis = 0 ist z_flag <= '1'; else z_flag <= '0'; -- wenn Ergebnis!= 0, dann Z-Flag -- löschen when others => null; -- Bei anderen Befehlen Z-Flag unverändert end case; case OPCODE is when LDAA MOVE LDA ORA ANDA => c_flag<='0'; when SHLA ADDA SUBA => c_flag<= CFLG_int; when others=> null; end case; end process synchron_alu; -- Bei bestimmten Befehlen: -- C-Flag löschen -- Carrybit der letzten Rechn. übernehmen -- Bei anderen Befehlen C-Flag unverändert Seite 7

11 alu: process (A_int, B_int, d_bus, OPCODE) variable FVAR: std_ulogic_vector(7 downto 0); -- Deklaration variable BVAR, AVAR : std_logic_vector(7 downto 0); -- der Variablen variable RESULT : std_logic_vector(8 downto 0); BVAR:=std_logic_vector(B_int); -- Kopie als Variable für AVAR:=std_logic_vector(A_int); -- Rechenoperationen FVAR:= ZERO; -- Zur Vermeidung von Latches CFLG_int <='0'; case OPCODE is when LDAA => FVAR := To_StdUlogicVector(d_bus(7 downto 0)); -- Load: D-Bus asynchron lesen when MOVE LDA => FVAR:= B_int; -- MOVE,LDA: B-Register => Ergebnis when ORA => FVAR := A_int or B_int; -- OR: A-Reg /\ B-Reg => Ergebnis when ANDA => FVAR := A_int and B_int; -- AND: A-Reg v B-Reg => Ergebnis when SHLA =>CFLG_int<=To_Bit(B_int(7)); -- MSB ins C-Flag FVAR(7 downto 1) := B_int(6 downto 0); -- SHLA: Bits schieben, Carrybit FVAR(0):='0'; -- ins C-Flag(int) when ADDA=> RESULT:=('0' & AVAR) + ('0' & BVAR); -- ADD: A u. B um ein Bit mit 0 FVAR:=std_ulogic_vector(RESULT(7 downto 0)); -- erweitern und addieren CFLG_int<=To_Bit(RESULT(8)); Bit ins C-Flag(int) when SUBA=> RESULT:=('0' & BVAR) - ('0'& AVAR); -- SUB: A u. B um ein Bit mit 0 FVAR:=std_ulogic_vector(RESULT(7 downto 0)); -- erweitern und subtrahieren CFLG_int<=To_Bit(RESULT(8)); Bit ins C-Flag(int) when others=> FVAR:=(others=> - ); -- zur Minimierung end case; F <= FVAR; -- Ergebniszuweisung end process alu; Seite 8

12 4.1.2 Simulation In der Simulation soll exemplarisch die Funktion einiger Befehle gezeigt werden. Die Eingangssignale im Datenpfad (a_bus, b_bus) werden mit der ansteigenden Flanke des Taktes übernommen und dann in der ALU verarbeitet. Der Befehl wird durch das Signal Opcode (Steuerpfad) eingestellt. Mit der nächsten positiven Taktflanke, steht das Ergebnis am Ausgang (c_bus) zur Verfügung Bild 3: Simulation der ALU Erklärung zur Simulation : Nummer : A-Register (a_bus) B-Register (b_bus) Operation (Opcode) Ergebnis (c_bus) 1 x 02h SHLA (Linksschieben) 04h 2 02h 02h SUBA (Subtrahieren) 00h (Z-Flag gesetzt) 3 31h 04h ADDA (Addieren) 35h 4 31h 10h ANDA (UND-Verknüfung) 10h 5 x x LDAA (Load Adress) FEh (Lowbyte über d_bus eingelesen) Seite 9

13 4.2 Prozessor-Register Im Konzept sind acht interne Register mit der Standarddatenbreite von acht Bit vorgesehen. Die Ausgänge der Register können unabhängig voneinander auf die Busse a_bus und b_bus geschaltet werden. Um den Zugriff der Pipeline auf den b_bus beim LDA-Befehl ( Laden eines Immediate-Wertes ) zu ermöglichen, sind alle Registerausgänge als Tristate-Treiber ausgeführt (vgl. Kap. 4.3). Mit dem Signal en_quelle[7], werden alle Registerausgänge in den Tristate-Zustand versetzt. Diese Programmierung berücksichtigt gleichzeitig die innere Struktur der Zielhardware, in diesem Fall ein FPGA-Baustein. Die Verwendung von intern vorhandenen Tristate- Treibern, reduziert den Hardwareaufwand des Übergangsschaltnetzes zur Ansteuerung der Register. Alternativ kann die Busansteuerung über einen Tristate- Treiber erfolgen, dem ein Multiplexer vorgeschaltet ist. In der hier verwendeten Programmierung entfällt der Multiplexer. (vgl. [2] 7-65 ff. ) Der Aufwand der Programmierung ist größer, da prinzipiell pro Ausgang ein Prozess notwendig ist. Abhilfe schafft hier die Verwendung eine for-schleife. Datenpfad (8 Bit) Steuerpfad (8/4 Bit) Enablesignale Eingang ( en_ziel[3..0]) Enable-Signal R0 ( en_quelle[0] ) R0..R7 Enable-Signale Ausgang ( en_quelle[7..1] ) c_bus a_bus b_bus R0 d_bus Bild 4: Daten- und Steuerpfad des Registerblocks Seite 10

14 Um beim Store-Befehl Daten direkt über den D-Bus in den Speicher schreiben zu können, kann der Inhalt von R0 über einen gesonderten Tristate-Treiber auf den Datenbus geschaltet werden ( siehe Bild 4). Die Aktivierung diese Ausgangs muss unabhängig von der Ansteuerung der eigentlichen Ausgänge geschehen, so dass eine zusätzliche Steuerleitung (en_quelle[0]) notwendig ist. Wird ein Store-Befehl ausgeführt, während sich eine arithmetische Operation in der Vorbereitung befindet, so müssen gleichzeitig Register auf den a_bus/b_bus und d_bus geschaltet werden. Bei Zugriffen auf den Datenbus (d_bus) kann während diese Taktes kein Maschinencode übertragen werden, so dass ein Wartezyklus eingefügt werden muss. Im Kapitel 4.3 wird dieses Vorgangs ausführlich Erläuterung. Der VHDL-Code des Registerblocks enthält zehn Prozess. Einen Prozess zur taktsynchronen Übernahme der Eingangsdaten, sowie neun zur asynchronen Steuerung der Tristate-Treiber. Die Umsetzung in einzelnen Prozessen ist, wie eingangs erwähnt, notwendig, um jeden Registerausgang als Tristate-Treiber zur implementieren. Seite 11

15 4.2.1 Quellcode Signal Reg0: std_logic_vector(7 downto 0); Signal Reg1: std_logic_vector(7 downto 0); Signal Reg2: std_logic_vector(7 downto 0); Signal Reg3: std_logic_vector(7 downto 0); Signal Reg4: std_logic_vector(7 downto 0); Signal Reg5: std_logic_vector(7 downto 0); Signal Reg6: std_logic_vector(7 downto 0); Signal Reg7: std_logic_vector(7 downto 0); Signal en_ziel: std_logic_vector(3 downto 0); Signal en_quelle: std_logic_vector(7 downto 0);.. synchron_reg: process (CLK, RESET) if RESET = '0' then -- Register nreset asynchron löschen Reg0 <= (others=>'0'); Reg1 <= (others=>'0'); Reg2 <= (others=>'0'); Reg3 <= (others=>'0'); Reg4 <= (others=>'0'); Reg5 <= (others=>'0'); Reg6 <= (others=>'0'); Reg7 <= (others=>'0'); elsif (clk'event AND clk = '1') THEN case en_ziel(3 downto 0) is -- Auswahl des Zielregisters in Abhängigkeit von en_ziel[2..0] when "0000" => Reg0 <= c_bus; when "0001" => Reg1 <= c_bus; when "0010" => Reg2 <= c_bus; when "0011" => Reg3 <= c_bus; when "0100" => Reg4 <= c_bus; when "0101" => Reg5 <= c_bus; when "0110" => Reg6 <= c_bus; when "0111" => Reg7 <= c_bus; when others => null; end case; end process synchron_reg; -- ist en_ziel[3] = 1, so wird kein Reigister beschrieben Seite 12

16 as1: process (Reg0, en_quelle) -- Zuweisung der Tristate-Treiber if en_quelle(7 downto 4)= 0 then b_bus<=reg0; -- asynchrones Zuweisen des Registerinhaltes auf den Bus, bei else b_bus<= (others=>'z'); -- entsprechender Auswahl des Registers -- Wird das Register nicht ausgewählt, so wird dem Tristateif en_quelle(3 downto 1)=0 then a_bus<=reg0; -- Treiber Z zugewiesen. else a_bus<= (others=>'z'); end process as1;. (Prozess as2 bis as7 analog dazu). as8: process (Reg7, en_quelle) if en_quelle(7 downto 4)=7 then b_bus<=reg7; else b_bus<= (others=>'z'); if en_quelle(3 downto 1)=7 then a_bus<=reg7; else a_bus<= (others=>'z'); end process as8; store_r0: process (en_quelle, Reg0) -- Unabhängig von der Adressierung des A/B-Busses, wird der -- Treiber für den D-Bus gesteuert if (en_quelle(0) = '1') then d_bus <= (" " & Reg0); else d_bus <= (others=>'z'); end process store_r0; Seite 13

17 4.2.2 Simulation Bild 5: Simulation des Registerblocks Seite 14

18 Dargestellte Abläufe: 1. Laden eines Immediate-Wertes (LDA): Bei diesem Befehl werden alle Registerausgange zum B-Bus durch ein high-signal an en_quelle(7) in den Tristate- Zustand geschaltet. Die Pipeline-Stufe P0 schaltet das im Maschinencode enthaltenen Datum (01h) auf den B-Bus. Nach Durchlaufen der ALU und des C- Registers wird der Wert im Register2 gespeichert. 2. Laden zweier Operanden: Es wird das Register2 auf den B-Bus und das Register3 auf den A-Bus adressiert. en_quelle(6 downto 4) 2 en_quelle(3 downto 1) 3 3. Ergebnis nicht speichern : Ist in der ALU kein Ergebnis berechnet worden, wird kein Register zum Speichern adressiert. Durch das Einsetzen von don t care- Termen (vgl. S.7) ist der Inhalt des C-Registers ohnehin unbestimmt und wird in der Simulation nicht angezeigt. 4. Speichern eines Wertes im RAM (STA): Hier ist zu erkennen, dass bei Aktivieren des Tristate-Ausgangs von R0 (en_quelle(0)= high), der Inhalt auf den Datenbus gelegt wird. Unabhängig davon wir in Register5 ein Ergebnis übernommen und der Inhalt von Register4 auf den B-Bus adressiert. Seite 15

19 4.3 Pipeline Die Pipeline, kann als das zentrale Steuerelement im Prozessorsystem gelten. Hier werden sämtliche Steuersignale (außer C-/Z-Flag) generiert und an andere Module weitergeleitet. Bild 6 zeigt eine Übersicht über die internen und externen Signale des Pipelineblocks. Daten/Maschinencode (8/15 Bit) Steuersignale Adressdaten(11 Bit) Register 4 en_ziel Store/Result 10 ALU 4 2 Befehl Flags Execute nop_st 11 Sprungadresse 1 Sprung Load/Store 1 adr_bus Adress -ALU 8 15 nop_ex b_bus Register en_quelle 8 Decode/Operands 11 Sprungweite Adress -ALU 15 d_bus interne Signale sind straffiert dargestellt Bild 6: Daten-, Adress und Steuersignale der Pipeline Im Folgenden wird das Verhalten der Pipeline bei verschiedenen Befehlsarten erläutert. Basis der Programmierung ist die Erkennung des Befehl oder der Befehlsgruppe, der anschließend die Zuweisungen folgen. Die Programmierung der Befehlserkennung ist mit eine case when Abfrage realisiert worden, in der nachstehenden Erläuterung wird darauf nicht näher eingegangen. Seite 16

20 4.3.1 Arithmetische Operationen (SHLA, MOVE, AND, OR, ADD, SUB) Der Maschinencode besteht aus dem Opcode und Registeradresse der zwei Operanden und des Zielregisters. (siehe 2.2.1) In der Pipelinestufe P0 (Decode/Operands), die ursprünglich in zwei Stufen aufgeteilt war (Decode und Operands), erfolgt die Adressierung der Operanden. Die Zusammenfassung zu einer Stufe, erhoht die Performance, da bei einem Sprung nur ein Maschinencodewort ungültig wird. Mit jedem Takt wird ein Maschinencodewort vom Datenbus (d_bus) eingelesen, wenn Programmcode aus dem Speicher gelesen wird. Werden Daten über den D-Bus übertragen (Befehle: LDAA, STA), so wird dies durch das interne Signal nop_ex angezeigt und in das Pipelineregister der Stufe P0 wird mit dem nächsten Takt ein NOP-Befehl geschrieben. Analog dazu wird das Signal nop_ex in der Stufe P1 high gesetzt, wenn der Befehl LDAA oder STA ausgeführt wird. Ist ein Maschinencodewort eingelesen worden, werden in P0 die Bits 8 bis 3 des Maschinencodes zum Laden der Operanden auf die Bits 6 bis 1 des Signal en_quelle übertragen. Mit der nächsten Taktflanke wird das Codewort in die Pipelinestufe P1 (Execute) übergeben. In dieser Stufe werden die Bits 14 bis 11, mit dem Signal Opcode an die ALU übergeben. Taktsynchron erfolgt anschließend die Übernahme des Codewortes durch die Stufe P2 (Store). Die Bits 2 bis 0 dienen der Adressierung der Zielregisters, mit dem Signal en_ziel Sprünge (BRA, BZ, BNZ, BLT, BGT) Das schrittweise Durchlaufen des Maschinencodes durch die drei Stufen erfolgt in gleicher Weise wie unter beschrieben. Die in den Bit 0 bis 10 enthaltene relative Sprungweite, wird in der Stufe P0 an die Adress-Alu übergeben (sprungw), in der für den Fall eines Sprungs der neue Wert des Programmcounters berechnet wird. In der Execute Phase wird dann, in Abhängigkeit von den Flags, durch setzen des Signals sprung ein Sprung ausgelöst. Ist die Bedingung zum Ausführen eines Sprungs gegeben, wird auch das Signal nop_ex gesetzt, so dass beim nächsten Takt das zuvor in die Stufe P0 eingelesene Maschinencodewort verworfen und in P1 ein NOP-Befehl eingefügt wird. Seite 17

21 4.3.3 Load-/Store-Befehle (LDA, LDAA, STA) Wird der LDA Befehl in die Pipelinestufe P0 geladen, wird der im Maschinencode in den Bits 0 bis 7 enthaltenen Immediate-Wert auf den B-Bus (b_bus) gelegt. Die Registerausgänge werden in den Tristate-Zustand versetzt. Diese Realisierung erfordert keine zusätzliche Hardware, da die Register der Pipeline ohnehin Tristateausgänge besitzen und lediglich auf den B-Bus freigeschaltet werden müssen. Die ALU verarbeitet den LDA-Befehl wie eine MOVE-Befehl, da auch hier die Daten des B-Busses nur durchgeschoben werden. In der Storephase werden die Bits 8 bis 10 zur Adressierung des Zielregisters verwendet. Bei Befehlen die auf das RAM zugreifen, sind die Auswirkungen auf das Systemverhalten größer. Die in den Bits 0 bis 10 enthaltene absolute RAM-Adresse wird in der Executephase auf den Adressbus gelegt. Durch setzen des Signals loadorstore (P0) wird ein Anhalten des Programmcounters in der Adressalu erreicht. In der Phase P2 wird das Signal nop_st gesetzt, was, wie das Signal nop_ex, einen Wartezyklus einfügt. Der VHDL-Code der Pipeline enthält vier Prozesse. In dem Prozess synchron _pipe wird der Inhalt der Pipelineregister synchron an die nächste Stufe übergeben. Die Prozesse der einzelnen Stufen sind asynchrone Prozesse und sind als reine Schaltnetze programmiert, d.h. es werden bei der Implementierung keine Latches oder Flip-Flops erzeugt. Seite 18

22 4.3.4 Quellcode constant NOP_C: std_logic_vector(15 downto 0) := (others=>'1'); signal progdata_deop: std_logic_vector(15 downto 0); signal progdata_ex: std_logic_vector(15 downto 0); signal progdata_st: std_logic_vector(15 downto 0); signal nop_ex: bit; signal nop_st: bit;.. synchron_pipe: process (CLK, RESET) -- Übergabeprozess der Pipeline if RESET = '0' then progdata_deop <= NOP_C; -- Reset progdata_ex <= NOP_C; progdata_st <= NOP_C; elsif (clk'event AND clk = '1') THEN -- Übernahme des Maschinencodewortes mit ansteigender Flanke progdata_deop <= d_bus; -- ( durchlaufen der Pipelinestufen ) progdata_st <= progdata_ex; if nop_ex='1' or nop_st='1' then -- Einfügen eines NOP-Befehls, wenn zuvor ein Load-/Storebefehl oder ein Sprung progdata_ex <= nop_c; -- ausgeführt wurde else progdata_ex <= progdata_deop; end process synchron_pipe; dec_op: process (progdata_deop) b_bus <= (others=>'z'); en_quelle(7 downto 1) <=(others=>'0'); sprungw(10 downto 0) <= (others=>'0'); loadorstore <='0'; -- Prozess der Stufe P0 (Decode/Operands) -- Vorinitialisierung der Variablen zur Vermeidung von Latches case progdata_deop(14 downto 11) is -- Abfrage des Opcodes: when "0000" "0100" => -- Befehl: SHLA oder MOVE -> Nur Adressierung des B-Busses en_quelle(6 downto 4) <= progdata_deop(8 downto 6); when "0001" "0011" => -- Befehl: LDAA oder STA -> Loadorstore setzen, um den PC anzuhalten loadorstore <= '1'; when "0010" => -- Befehle: LDA -> Im Maschinencode enthaltenen Wert auf den B_Bus legen b_bus <= progdata_deop(7 downto 0); -- und Registerausgänge in den Tristate-Zustand versetzen en_quelle(7) <= '1'; when "0101" "0110" "0111" "1000" => -- Befehle: ADDA, SUBA, ORA, ANDA -> Adressierung der Operanden auf den A/B-Bus Seite 19

23 en_quelle(6 downto 1) <= progdata_deop(8 downto 3); when "1111" => null; -- Befehl: NOP -> keine Anweisung when others => -- Bei anderen Befehlen (alle Sprungbefehle) -> Rel. Sprungweite übergeben sprungw(10 downto 0) <= progdata_deop(10 downto 0); end case; end process dec_op; execute: process (progdata_ex) nop_ex <='0'; RNW <= '1'; sprung <= '0'; en_quelle(0) <= '0'; adr_bus <=(others=>'z'); -- Prozess der Stufe P1 (Execute): -- Vorinitialisierung der Variablen zur Vermeidung von Latches case progdata_ex(14 downto 11) is -- Abfrage des Opcodes: when "0000" => OPCODE <= SHLA; -- Setzen des Signals OPCODE when "0001" => OPCODE <= STA; -- Befehle: STA -> Speicheradresse des RAM auf dem Adressbus ausgeben, adr_bus <= progdata_ex(10 downto 0); -- Register R0 auf den D-Bus freigeben und RNW auf high (schreiben) setzen en_quelle(0) <= '1'; RNW <= '0'; when "0010" => OPCODE <= LDA; when "0011" => OPCODE <= LDAA; -- Befehle: LDAA -> Ladeadresse des RAM auf dem Adressbus ausgeben adr_bus <= progdata_ex(10 downto 0); when "0100" => OPCODE <= MOVE; when "0101" => OPCODE <= ADDA; when "0110" => OPCODE <= SUBA; when "0111" => OPCODE <= ORA; when "1000" => OPCODE <= ANDA; when "1010" => OPCODE <= BR; -- Befehl: BR -> Sprung mit dem Signal sprung auslösen und mit nop_ex= 1 sprung <= '1'; -- einen Wartezyklus einfügen nop_ex <= '1'; when "1011" => OPCODE <= BZ; -- Die folgenden Anweisungen geschehen analog zu denen des BR -Befehles, if z_flag = '1' then -- jedoch wird vorher das entsprechende Flag abgefragt sprung <= '1'; nop_ex <= '1'; when "1100" => OPCODE <= BNZ; if z_flag = '0' then sprung <= '1'; nop_ex <= '1'; Seite 20

24 when "1101" => OPCODE <= BGE; if c_flag = '0' then sprung <= '1'; nop_ex <= '1'; when "1110" => OPCODE <= BLT; if c_flag = '1' then sprung <= '1'; nop_ex <= '1'; when others => OPCODE <= NOP; end case; end process execute; store: process (progdata_st) -- Prozess der Pipelinestufe P2 (Store): nop_st <= '0'; -- Vorinitialisierung der Variablen zur Vermeideung von Latches case progdata_st (14 downto 11) is -- Abfrage des Opcodes: when "0000" "0101" "0110" "0111" "1000" "0100" => -- Befehl: SHLA, ADDA, SUBA -> en_ziel <= ('0' & progdata_st(2 downto 0)); -- Adressierung des Zielregisters when "0010" => -- Befehl: LDA -> Adressierung des Zielregisters en_ziel <= ('0' & progdata_st(10 downto 8)); -- mit den Bits 8 bis 10, da unteren Bits 0 bis 7 den Wert enthalten when "0011" => -- Befehl: LDAA -> Adressierung des registers R0 und einfügen eines en_ziel <="0000"; -- Wartezyklusses nop_st <='1'; when "0001" => -- Befehl: STA -> Wartezyklus einfügen, kein Zielregister adressieren nop_st <='1'; -- (kein Zileregister -> en_ziel(4) = high) en_ziel <="1000"; when others => en_ziel <= "1000"; -- kein Zielregister end case; end process store; Seite 21

25 4.3.5 Simulation Durchlaufen des Maschinencodes durch die Pipeline Bild 7: Simulation der Pipeline Seite 22

26 Anmerkungen zur Simulation : Zur besseren Übersichtlichkeit ist auf die Markierung der Signal die bei arithmetischen Befehlen verändert werden, verzichtet worden. Das Verhalten der Quell- und Zieladresssignale ist in der Gesamtsimulation detailliert ersichtlich. Dargestellte Abläufe: 1. Laden des Wertes 01h in das Register1: Der Wert wird über den B-Bus in die ALU und über den C-Bus in das Register1 transportiert. 2. Schreiben des Registerinhaltes von R0 (11h) an die Adresse 83h: zuerst wird das Signal loadorstore gesetzt, im Takt danach erfolgt die Adressierung und das Schreiben (RNW=0) über den D-Bus in das RAM. Der in die Pipelinestufe P0 eingelesene Wert wird im nächsten Takt gelöscht. 3. Sprung (BLT) um +1: Die relative Sprungweite wird übergeben (01h), im nächsten Takt erfolgt der Sprung (sprung=1) und die neue PC-Adresse wird ausgegeben. Der Sprung um +1 ist nicht in der Adressierung zu erkennen, da der PC im normalen Programmablauf auch um eins erhöht wird. 4. Laden von der RAM-Adresse 80h: Zum Anhalten des PC wird das Signal loadorstore gesetzt, im darauffolgenden Schritt wird die Adresse ausgegeben (80h) und das zu speichernde Datum (FEh) über den D-Bus in die ALU eingelesen. Die Übernahme in das Register0 erfolgt im nächsten Takt über den C-Bus. Seite 23

27 4.4 Adress-ALU Die Adress-Alu bildet das Steuerwerk zwischen Prozessor und RAM. Die Adress-Alu sorgt für das sequentielle Lesen des Programmcodes und ermöglicht es Daten aus dem RAM zu lesen und zu speichern. Eine weitere Aufgabe ist die Berechnung von Sprungadressen. Datenpfad Adresspfad Steuersignale Clock- und Reset Signale sind nicht dargestellt. Interne Signal sind straffiert. Adressbus LoadorStore Programmcounter PC +1 loadorstore Ausgabe Sprung pc sprung Sprungadresse Σ pc + sprungw_int RAM Adresssteuerwerk sprungw_int Sprungweite Datenbus Bild 8: Adress- und Steuerpfade der Adress-Alu Das Bild 8 zeigt in vereinfachter Form die Adress- und Steuerpfade der Adress-Alu. Da diese übersicht wenig über die Funktion aussagt, soll an dieser Stelle detaillierter auf die Abläufe eingegangen werden. Bei der Umsetzung der Adresssteuerung in VHDL macht sich die Reduzierung auf drei Pipelinestufen negativ bemerkbar. Es muss innerhalb eines Taktes die Sprungweite synchronisiert und die Sprungadresse berechnet werden. Eine systematische Schwierigkeit ist die Umschaltung der Adresse bei einem Sprung. NCS NOE Seite 24

28 Bei jeder ansteigenden Flanke wird am Adressbus der um eins inkrementierte PC- Wert ausgegeben um das nächsten Befehlswort aus dem RAM auszulesen. Bei einem Sprungbefehl wird das Signal sprung wird zur gleichen Zeit in der Execute- Stufe der Pipeline gesetzt und besitz einige ns später den Zustand high. Nun wird die parallel dazu berechnete Sprungadresse auf den Bus gelegt, der zuvor auf den Adressbus geschriebene PC-Wert ist ungültig. Dieser Zusammenhang macht einen asynchronen Ausgangsprozess in VHDL notwendig. Zusätzlich werden zwei weitere synchrone Prozesse benötig. Ein positiv Taktflankengesteuerter Prozess zur Berechnung des neuen PC-Wertes und ein negativ Taktflankengesteuerter Prozess zur internen Übernahme des alten PC-Wertes. Das Signal ls_flag ist eine synchronisierte Kopie des Signals loadorstore, das in der P0 Stufe der Pipeline gesetzt wird, wenn ein Befehl mit RAM-Zugriff erkannt wird. Die Synchronisierung ist notwendig, da die interne Übernahme des neuen PC-Wertes zur abfallenden Flanke geschieht und das asynchrone Signal loadorstore zu diesem Zeitpunkt seinen Zustand bereits verändert hat. Die Übernahme des um eins erhöhten PC-Wertes wird durch ein Low des ls_flag freigegeben, d.h. während eines Befehls mit RAM-Zugriff wird der Programmcounter angehalten. Wie eingangs erwähnt, ist auch die Synchronisierung der Sprungweite als Eingangssignal notwendig. Der Grund ist die Tatsache, dass die Entscheidung einen Sprung auszuführen einige ns nach der positiven Flanke erfolgt. Zu diesem Zeitpunkt ändert sich der Wert der Sprungweite jedoch bereits wieder. Seite 25

29 4.4.1 Quellcode signal pcaus: std_logic_vector(10 downto 0); signal pc: std_logic_vector(10 downto 0); signal sprungwint: std_logic_vector(10 downto 0); signal ls_flag:bit;.. a_ausgabe: process (ls_flag, sprung, pcaus, reset) -- Ausgabe Prozess: if reset='0' then -- Bei Reset: adr_bus<=(others=>'z'); -- Ausgang zum Adressbus in den Tristate-Zustand versetzen elsif sprung ='1' then -- Bei einem Sprung: adr_bus <= pc + sprungwint; -- PC + relative Sprungweite ausgeben elsif ls_flag='0' then -- Normaler Programmablauf: adr_bus<=pcaus; -- Zuvor inkrementierten PC-Wert ausgeben, wenn kein Load-/Store- else adr_bus<=( others=>'z'); end process a_ausgabe; -- Operation durchgeführt wird adr_plus: process (clk, reset) if reset='0' then pcaus<= (others=>'0'); ls_flag<='0'; elsif clk'event and clk = '1' then case loadorstore is when '1'=> ls_flag<='1'; ls_flag<='0'; end case; else null; end process adr_plus; when '0'=> pcaus<= pc + '1'; -- Bei Reset: -- PC auf 0 zurücksetzen -- Synchrones Load-/Store-Signal zurücksetzen -- Load-/Store-Signal synchron übernehmen -- sonst PC inkrementieren und Load-/Store-Signal zurücksetzen Seite 26

30 z_plus: process (clk, reset) if reset ='0' then pc <= (others=>'0'); sprungwint<=(others=>'0'); elsif clk'event and clk='0' then sprungwint <=sprungw; if ls_flag ='0' then if sprung='0' then pc <= pcaus; else pc <= pc + sprungwint; end process z_plus; end VERHALTEN; -- Interner Übernahmeprozess: -- Rücksetzen -- Synchrone Übernahme bei abfallender Flanke -- Sprungweite synchronisieren -- Wenn keine Sprung-/Load- oder Store-Operation durchgeführt -- wurde den letzten PC-Wert übernehmen, bei einem Sprung die -- Sprungadresse, sonst den alten PC-Wert beibehalten Seite 27

31 4.4.2 Simulation Bild 9: Simulation der Adress-Alu Dargestellte Abläufe: 1. Befehl mit RAM-Zugriff : Das Signal loadorstore wird intern synchron übernommen (ls_flag). Im darauffolgenden Takt wird der PC nicht inkrementiert und der Adress-Bus befindet sich im Tristate-Zustand, so dass die Zugriffsadresse übertragen werden kann. 2. Sprungbefehl : Die relative Sprungweite wird intern synchron übernommen (sprungwint)(-8d). Das Signal sprung löst den Sprung aus, es wird die Sprungadresse ausgegeben (11d-8d = 3d) und mit fallender Flanke intern in de PC übernommen. Seite 28

32 5. Simulation des Gesamtsystems In diesem Kapitel wird das Zusammenspiel aller Komponenten des Prozessors gezeigt. Die dazu notwendige Testumgebung wird mit einem in VHDL geschriebenen Modul erzeugt (Testbench.vhd). Die Umsetzung der Testbench orientiert sich an dem in [1] S.223 gezeigten Beispiel. Als externer Speicher dient ein von Prof. Dr. Reichardt zur Verfügung gestelltes, leicht modifiziertes 16Bit-RAM-Modell. Das RAM-Modell ermöglicht es über eine Programmierfunktion zu n der Simulation selbstständig Programmcode in dem RAM abzulegen. Der Programmcode wird dabei vorher mit einem Tabellenkommpeiler in eine HEX-Datei übersetzt, die dann bei Simulationsstart importiert wird. Das RAM-Modell wurde dahingehend verändert, dass bei einem Schreibzugriff dem Ausgang ohne Verwendung des Signals NOE, der Zustand Tristate zugewiesen wurde. Ohne diese Zuweisung kommt es in der Simulation zu einem Halten der letzten RAM- Ausgangszustandes und damit zu einem Buskonflikt auf dem D-Bus. ( Änderung an der Stelle -- MODIFIKATION:.. ) Die Signal NCS und NOE werden dauerhaft auf low gelegt, NCS wird prinzipiell nur bei Verwendung von mehreren RAM-Bausteinen benötigt. Die Programmierfunktion wird während des Power-On-Resets durchgeführt. Der verwendete Tabellenkommpeiler hasm lässt Änderungen der Übersetzungstabelle zu, so dass eine Anpassung an die individuelle Bitstruktur der Prozessorbefehle leicht möglich ist. Die modifizierte Übersetzungstabelle befindet sich im Anhang. Um die Leistungsfähigkeit des RISC-Prozessors zu zeigen und gleichzeitig die Funktion möglichst vieler Befehle zu zeigen, wurde ein Assemblerprogramm in Zusammenarbeit mit der Gruppe von M. Jurkat entwickelt. Gleichzeitig war so während er Entwicklungsphase ein Vergleich der Prozessoren möglich. Um die Simulation nachvollziehen zu können, sind ausgeführter Befehle, Operanden und Ergebnis markiert. Um die Befehle in der Darstellung voneinander abzugrenzen sind sie wie bereits im Kapitel 4. mit wechselnden Farben gekennzeichnet. Der dazugehörige Assembler-Code befindet sich unterhalb der Signalverläufe. Seite 29

33 5.1 Signalverläufe Teil 1 ORG 80h MEM1 DW 0AFFEH ; Vorbelegte Memory-Location MEM2 DW 0011H ; Vorbelegte Memory-Location MEM3 DW 0003H ; Vorbelegte Memory-Location ERG1 DW 0000H ; Leer Memory-Location ERG2 DW 0000H ; Leer Memory-Location ORG 000 START: LDA MEM2 ; Lade Speicherelement an Addresse MEM2 LDA #101H ; Lade Konstante 01h nach R1 MOV R0,R3 ; Verschiebe R0 nach R3 LDA MEM3 ; Lade Speicherinhalt von Addresse MEM3 LDA #210H ; Lade Konstante 10h nach R2 MOV R0,R4 ; Verschiebe nach R4 LOOP: SHL R1,R1 ; R1 nach links verschieben und ins R1 zurück ADD R2,R3,R3 ; R2(10H) + R3(11H) = R3(21H) SUB R4,R1,R4 ; R4(03h) - R1(01h) = R4(02h) * BNZ LOOP ; Sprung, da Z-Flag nicht gesetzt (rel. Sprungweite 4)* ; * nächste Seite Seite 30

34 5.2 Signalverläufe Teil 2 LOOP: SHL R1,R1 ; R1(02h) nach links verschieben und ins R1(04h) zurück ADD R2,R3,R3 ; R2(21h) + R3(11h) = R3(31h) SUB R4,R1,R4 ; R4(02h) R1(02h) = R4(00h) (Z-Flag = 1) BNZ LOOP ; Kein Sprung, da Z-Flag gesetzt ADD R3,R1,R0 ; R3(31h) + R1(04h) = R0(35h) AND R2,R3,R5 ; R2(10h) & R3(31h) = R5(10h) OR R1,R2,R6 ; R1(04h) R2(10h) = R6(14h) STA ERG1 ; 35h in Ergebnisspeicher 1 (83h = 131d) SUB R4,R0,R0 ; R4(00h) R0(35h) = R0(CBh) (C-Flag = 1) BLT WEITER ; springen, da C-Flag gesetzt* ; *nächste Seite Seite 31

35 5.3 Signalverläufe Teil 3 Endlosschleife BLT WEITER ; springen (rel. Sprungweite +1) TOT1: BR TOT1 ; Endlosschleife 1 WEITER: LDA MEM1 ; Lade AFh nach R0 STA ERG2 ; R0(CBh) in den Ergebnisspeicher 2 MOV R0,R7 ; R0 nach R7 verschieben TOT2: BR TOT2 ; Endlosschleife 2 END Seite 32

36 5.4 Quellcode des Assemblerprogramms #SYMLIST #ASSEMBLER risc_16 ; erzeuge Symbolliste ; Festlegung der Assembler-Tabelle ; Programm zum Testen von Addition, Subtraktion ; indirekter Adressierung ; bedingten Spruengen und Schleifen ; ; Adressen und Konstanten ORG 80h MEM1 DW 0AFFEH ; Vorbelegte Memory-Location MEM2 DW 0011H ; Vorbelegte Memory-Location MEM3 DW 0003H ; Vorbelegte Memory-Location ERG1 DW 0000H ; Leer Memory-Location ERG2 DW 0000H ; Leer Memory-Location ORG 000 ; Basisadresse fuer Programmcode START: LDA MEM2 ; Lade Speicherelement an Addr MEM2 LDA #101H ; Lade Konstante 01\h nach R1 MOV R0,R3 ; Verschiebe nach R3 LDA MEM3 ; Lade Speicherelement an Addr MEM3 LDA #210H ; Lade Konstante 10\h nach R2 MOV R0,R4 ; Verschiebe nach R4 LOOP: SHL R1,R1 ; R1 nach links verschieben und ins R1 zurück ADD R2,R3,R3 ; 1:(10H+11H->21H) 2:(21H+11H->31H) SUB R4,R1,R4 ; erst um 1, dann um 2 abziehen BNZ LOOP ; wenn R4 > 0 dann zurück ADD R3,R1,R0 ; 31H+4H->35H AND R2,R3,R5 ; 10H&31H->10H OR R1,R2,R6 ; 4H 10H->14H STA ERG1 ; 35H in Ergebnisspeicher 1 SUB R4,R0,R0 ; 0H-35H->CBH setzt Carrybit BLT WEITER ; springen TOT1: BR TOT1 ; Endlosschleife WEITER: LDA MEM1 ; Lade AFH nach R0 STA ERG2 ; CBH in Ergebnisspeicher 2 MOV R0,R7 ; Verschiebe nach R7 TOT2: BR TOT2 ; Endlosschleife END 5.5 Quellcode der Testbench -- testbench.vhd -- Testbench fuer den Mikroprozessor -- C.Koegst nach Vorlage von Prof.Dr.Reichardt use work.mp_pack.all; library ieee; use ieee.std_logic_1164.all; entity TESTBENCH is end TESTBENCH; architecture VERHALTEN of TESTBENCH is -- lokale Signale signal CLK : bit; signal RESET : bit; signal PROG, NCS, RNW, NOE: bit; signal D_BUS : std_logic_vector(d_breite-1 downto 0); signal ADR_BUS : std_logic_vector(a_breite-1 downto 0); Seite 33

37 -- Komponentendeklaration component RISC port (D_BUS : inout std_logic_vector(d_breite-1 downto 0); RESET,CLK : in bit; ADR_BUS : out std_logic_vector(a_breite-1 downto 0); NCS, RNW, NOE, PROG : out bit); end component; component HEX2RAM_16 port (D: inout std_logic_vector(15 downto 0); ADDRESSX: in std_logic_vector(a_breite-1 downto 0); NCS, RNW, NOE: in bit; PROG : in bit); end component; -- Komponentenkonfiguration for all: RISC use entity WORK.RISC(VERHALTEN); for all: HEX2RAM_16 use entity WORK.HEX2RAM_16(VERHALTEN); -- Komponenteninstanzierung COMP1: RISC port map(d_bus, RESET, CLK, ADR_BUS, NCS, RNW, NOE, PROG); COMP2: HEX2RAM_16 port map(d_bus, ADR_BUS, NCS, RNW, NOE, PROG); -- Taktgenerator TAKTGEN: process CLK <='0'; wait for 50 ns; CLK <='1'; wait for 50 ns; end process; RESET <='0', '1' after 80 ns; end VERHALTEN; 5.6 Quellcode des 16Bit-RAM-Modells -- HEX2RAM_16.vhd V Verwendbar fuer HEX-Dateien, die in HASM mit der Option W4 erstellt wurden. -- Achtung: dies Modell enthaelt nur ein 1kx16 RAM: A9..A0. -- Die Addressbits A15.. A10 werden mit '0' vorbelegt! -- Dadurch koennen die Ladezeiten in Modelsim drastisch reduziert werden! Verhaltensmodell fuer synchrones 16-Bit RAM, welches durch -- *.HEX-Datei initialisiert wird. -- Die Architektur besitzt zwei Funktionen: -- * "Programmieren" des Speichers mit Quellcode aus "RISC.HEX" -- * Schreiben / Lesen falls NCS='0' use work.mp_pack.all; -- System Package use std.textio.all; -- File I/O Package library ieee; use ieee.std_logic_1164.all; -- STD_LOGIC use ieee.std_logic_arith.all; -- Vektorarithmetik Steuerleitungen: -- NCS: notchip-select -- RNW: Read/notWrite -- NOE: notoutput Enable -- PROG: Programmieren, d.h. Einlesen der HEX-Datei -- Hinweis: Keine selbstdefinierten port-datentypen, um den Code im -- Schematic verwenden zu koennen!!! entity HEX2RAM_16 is generic ( DEL: time:=10 ns); port (D: inout std_logic_vector(15 downto 0); ADDRESSX: in std_logic_vector(a_breite-1 downto 0); -- unten: Abbildung auf 1k RAM!!! NCS, RNW, NOE, PROG: in bit); end HEX2RAM_16; Seite 34

38 architecture VERHALTEN of HEX2RAM_16 is signal ADDRESS: std_logic_vector(9 downto 0); -- nur bei 1k RAM!!! Konversionsfkt. eines mehrstelligen HEX-Strings in Integer-Zahl function HEXSTRING_TO_INT (ZKETTE : in string) return integer is variable ERGEBNIS : integer range 0 to 65535; -- Bis zu 16 Bit variable ZIFFER : integer range 0 to 15; -- erlaubte Ziffern variable FEHLER : boolean; ERGEBNIS :=0; -- Initialisierung FEHLER := false; for I in ZKETTE'range loop -- Schleife ueber Stringlaenge case ZKETTE(I) is when ' ' => ZIFFER:=0; when '0' => ZIFFER:=0;-- Umsetzung in unsigned when '1' => ZIFFER:=1; when '2' => ZIFFER:=2; when '3' => ZIFFER:=3; when '4' => ZIFFER:=4; when '5' => ZIFFER:=5; when '6' => ZIFFER:=6; when '7' => ZIFFER:=7; when '8' => ZIFFER:=8; when '9' => ZIFFER:=9; when 'A' => ZIFFER:=10; when 'B' => ZIFFER:=11; when 'C' => ZIFFER:=12; when 'D' => ZIFFER:=13; when 'E' => ZIFFER:=14; when 'F' => ZIFFER:=15; when 'a' => ZIFFER:=10; -- Kleinschreibung erlaubt when 'b' => ZIFFER:=11; when 'c' => ZIFFER:=12; when 'd' => ZIFFER:=13; when 'e' => ZIFFER:=14; when 'f' => ZIFFER:=15; when others => FEHLER:=true;-- Fehlererkennung end case; assert not FEHLER report "!!! Fehler in der Eingabedatei" severity error; -- Hex-Akkumulation des Ergebnisses: ERGEBNIS := ERGEBNIS + (ZIFFER * 16**(ZKETTE'high - I)); end loop; return ERGEBNIS; end HEXSTRING_TO_INT; RAM-Speicher als Signal-array: -- constant MEM_TIEFE : integer := 2**A_BREITE-1; constant MEM_TIEFE: integer := 1023; type MEM_TYPE is array (0 to MEM_TIEFE) of std_logic_vector(15 downto 0); signal MEM: MEM_TYPE :=(others =>(others =>'1')); -- mit '1' initialisieren -- dann werden leere Speicher -- positionen als NOP interpretiert ADDRESS <= ADDRESSX(9 downto 0); -- nur bei 1k RAM!!! Nicht synthesefähiger Prozess zum Einlesen der HEX-Datei in -- den Speicher MEM SPEICHER: process (PROG, NCS, ADDRESS, RNW) file SRCFILE: text is in "RISC.HEX";-- Quellcode-Filename variable SRC_LINE: line; -- Zeilenpuffer variable VALID: boolean; variable FIRST_CHAR: character; subtype BYTE_TYPE is string (positive range 1 to 2); -- 2-ASCIIs subtype WORD_TYPE is string (positive range 1 to 4); -- 4-ASCIIs variable BYTE : BYTE_TYPE; variable WORD: WORD_TYPE; variable NO_OF_BYTES, ID_CODE: integer range 0 to 255; variable ADDR, PROGWORD: integer range 0 to 65535; -- Addresse variable TEMPZ: std_logic_vector(15 downto 0) := (others =>'Z');-- Temporaerer Z-Vektor variable TEMPX: std_logic_vector(15 downto 0) := (others =>'X');-- Temporaerer X-Vektor Seite 35

39 if PROG='1' and PROG'event then while not endfile(srcfile) loop readline(srcfile, SRC_LINE); read (SRC_LINE, FIRST_CHAR, VALID); if not VALID and FIRST_CHAR /= ';' then exit; -- Format-/Lesefehler -- Kommentarzeilen, die mit ";" anfangen, ueberlesen if FIRST_CHAR /= ';' then read (SRC_LINE, BYTE, VALID); -- Anzahl der Datenbytes if not VALID then exit; NO_OF_BYTES := HEXSTRING_TO_INT(BYTE); read (SRC_LINE, WORD, VALID); -- Anfangsaddresse if not VALID then exit; ADDR := HEXSTRING_TO_INT(WORD); read (SRC_LINE, BYTE, VALID); -- Record Kennung if not VALID then exit; ID_CODE := HEXSTRING_TO_INT(BYTE); -- Keine Auswertung while NO_OF_BYTES > 0 loop read (SRC_LINE, WORD, VALID); -- Datenwort (16-bit) if not VALID then exit; PROGWORD := HEXSTRING_TO_INT(WORD); MEM (ADDR) <= CONV_STD_LOGIC_VECTOR (PROGWORD, 16); ADDR := ADDR + 1; -- naechste Adresse NO_OF_BYTES := NO_OF_BYTES - 1; -- Dekrementieren end loop; end loop; D <= TEMPZ after DEL; -- Nach dem Einlesen Datenbus hochohmig schalten assert valid report"--- Fehler beim Lesen der Eingabedatei ---" severity error; assert not endfile(srcfile) report"--- Einlesen beendet/ Datenbus hochohmig ---" severity note; -- normale RAM-Operation: elsif NCS = '0' then -- Speicher selektiert? if RNW ='1' then -- Lesen? if NOE='0' then -- Ausgabe freigegeben? -- Verwende Konversion unsigned -> Integer, -- Dafuer std_ulogic_vector als unsigned interpretieren: D <= MEM(conv_integer(unsigned(ADDRESS))) after DEL; elsif (D /= TEMPZ and D /= TEMPX) then --nur defin. Signale speich. D <= (others=>'z'); -- MODIFIKATION: Ausgangstreiber Tristate MEM(conv_integer(unsigned(ADDRESS))) <= D after DEL; else -- sonst Treiber abschalten D <= (others =>'Z') after DEL; end process SPEICHER; end VERHALTEN; Seite 36

40 6. Implementierung Eine grundlegende Vorgabe bei der Entwicklung des Prozessors in VHDL, war die Synthesefähigkeit des Codes. Auch das Erzeugen von Latches, musste vermieden werden. Es ist zwar grundsätzlich möglich Latches in FPGA-Bausteinen zu realisieren, doch erweisen sich rein synchrone Systeme als Störungsunempfindlicher. [2] 7-88 Meistens entstehen Latches ungewollt durch fehlende Rücksetzbedingungen zu n des Prozesse. Letztendlich ist beim Programmieren darauf zu achten, dass die Menge der zu implementierenden Hardware möglichst klein bleibt. Eine Optimierung des Code hinsichtlich eines geringen Hardwarebedarf konnte, aufgrund des immensen dafür notwendige Zeitaufwandes und der nur in der Fachhochschule zur Verfügung stehenden Software (Xilinx Foundation), nur in geringem Maße durchgeführt werden. 6.1 Ergebnis der Implementierung Zielhardware: Xilinx FPGA - XC4010xl, (package pc84, speed 3) Benötigte Hardwareressourcen Der Screenshot des Floorplaners der Synthesesoftware zeigt die benötigte Hardware: 33 IOB In-/Out-Blocks 149 DFF D-Flip Flops 158 BUFT Tristat-Treiber Bei den anderen aufgeführten Positionen handelt es sich um Hardware zur Realisierung der Übergangsschaltnetze, die hier nicht weiter untersucht werden soll. Bild 10: Screenshot des Floorplaners Seite 37

41 Bei der genaueren Untersuchung der Positionen fällt auf, dass die Anzahl der D-FF mit 149 um 15 zu gering ist, ein Einblick in die Protokolldatei schafft Klarheit. Auszug aus der Protokolldatei (erstellt nach der Optimierung): =================== Chip ver1-optimized =================== Summary Information: Type: Optimized implementation Source: ver1, up to date Status: 0 errors, 23 warnings, 0 messages Export: exported after last optimization Target Information: Vendor: Xilinx Family: XC4000XL Device: 4010XLPC84 Speed: xl-3 Chip Parameters: Optimize for: Speed Optimization effort: Low Frequency: 50 MHz Is module: No Keep io pads: No Number of flip-flops: 164 (tatsächliche Anzahl der D-FF) Number of latches: 0 Chip Design Hierarchy: risc: defined in c:\xilinx\active\projects\risc\risc.vhd Primitive reference count: BUFG 1 CY4 23 CY4_02 10 CY4_03 2 CY4_13 4 CY4_14 1 CY4_18 5 CY4_20 1 DFF 149 FMAP 223 HMAP 38 IBUF 9 IFD 15 (Die 15 fehlenden D-FF) OBUF 15 OBUFT 16 STARTUP 1 TBUF 158 Clocks: Required Estimated Period Rise Fall Freq Freq Signal (ns) (ns) (ns) (MHz) (MHz) default CLK_BUFGed... Seite 38

42 Das Ergebnis der Optimierung nachzuvollziehen gelingt nur mit Hilfe der Protokolldateien. Die genaue Anzahl der verwendeten Hardware lässt sich jedoch nachweisen: Verwendete Hardware: IOB-33 DFF-149(+15) s.o. BUFT-158 In-/Out-Blocks (Ges.:33) D-Flip Flops (Ges.: 164) Tristate-Buffer (Ges.:158) Reset 1 Z-/ls-Flag 2 Registerausgänge A-Bus 64 Progr 1 Sprungweiteint 11 Registerausgänge B-Bus 64 NOE 1 Pipeline R0-D-Bus Ausgang 8 NCS 1 PCaus 11 Adressbusausgang Adress-Alu 11 CLK 1 PC 11 Adressbusausgang Pipeline 11 RNW 1 Register 64 D-Bus 16 C-Reg (inkl. C-Flag) 9 Adress-Bus 11 A-/B-Register Maximale Taktfrequenz Die mit dem gewählten Baustein erreichte maximale Taktfrequenz beträgt 25,22 MHz. Der längste Pfad ist der Adressbus: (Auszug aus der Protokolldatei) Critical Path Timing: Arrival Required Cell Time Time Fanout Type (ns) (ns) Count Pin-Name... port /ver1-optimized/adr_b (längster Pfad) OBUF /ver1-optimized/c2926 OBUF /ver1-optimized/c2926 TBUF /ver1-optimized/c3085 TBUF /ver1-optimized/c3085 EQN /ver1-optimized/c3631 Die Verwendung der XE-version ließ eine Simulation der nach der Synthese exportierten Timing-Datei nicht zu, so dass die Untersuchungen hier endet. Auf der nachfolgenden Seite sind einige Bilder abgedruckt, die während der Implementierungsphase entstanden. Seite 39

43 Bild 11: H-Baum - Struktur des Implementierten CLK-Netzes (rechts) Bild 12: Übersicht über die benutzten Zellen im FPGA (links) Bild 13: Darstellung des gesamten Routings im FPGA (links) Bild 14: Einzelne Makrozelle (rechts) Seite 40

44 7. Ergebnis/Anmerkungen Die Entwicklung eines RISC-Prozessors im Rahmen des Seminars ist gelungen. Die gestellten Anforderungen sind erfüllt worden. Die nicht immer exakte Spezifizierung machte die Aufnahmen eigener Punkte in der Anforderungsliste notwendig, ermöglichte aber auch einen gewissen Spielraum. Die zur Verfügung stehend Software Modelsim XE 5.3 hat sich als geeignet und fehlerfrei erwiesen. Die Softwareumgebung kann leicht erlernt und intuitiv bedient werden. Leider fehlt eine frei erhältliche Software zum Implementieren für Xilinx FPGAs, so dass bei der Implementierung Abstriche hinsichtlich der Optimierung des Codes und der Untersuchung der synthetisierten Hardware gemacht werden mussten. Der Zeitaufwand für das Seminar, insbesondere für die Ausarbeitung, ist sehr hoch. Die notwendige Motivation ist allerdings durch das frei Arbeiten und die Thematik gegeben. C. Koegst M. Scheffler 8. Anhang Übersetzungstabelle des Kommpeilers ' 'Assembler fuer RISC-Prozessor CAE-Seminar WS 2000 ' J. Reichardt ' FH-Hamburg ' Fachbereich Elektrotechnik und Informatik ' Lehrgebiet Digitale Informationstechnik ' ' V ' ; Modifiziert C. Koegst 11/2000 ; 16 Bit Wortbreite des Prozessors (in Nibbles). Falls im Speichermodell ; eine Byte-orientierte Darstellung erfolgt, so muss hier w2 angegeben werden. w4 ; ; Fehlermeldungen: fa Adressbereich ueberschritten fd Datenfeld zu gross fs Sprung zu weit! fw DW-Definition fehlerhaft! fb DB-Definition fehlerhaft! ;Befehle: (aphabetische Reihenfolge) ;Achtung Hex-Codes, die mit A-F nen, MÜSSEN ;mit einer vorgestellten 0 nen, damit die HEX- ;Codes nicht als Fehler interpretiert werden! ; DB à {@1:-8b} ; Define Byte.DW à {@1:-16w} ; Define Word.SHL Rà,Rà {00h:5 ; Shift-Left Ra->Rb Seite 41