Fakultät Informatik Institut für Technische Informatik Professur für VLSI-Entwurfssysteme, Diagnostik und Architektur Komplexpraktikum Prozessorentwurf SoSe 2015 Ansprechpartner Martin Zabel, martin.zabel@tu-dresden.de, INF/1099 1 Themenvorschläge Variante 1: Entwurf und Implementierung eines RISC-Mikroprozessors. Bei diesem Themenvorschlag steht im Fokus der Hardware-Entwurf eines 32-Bit-RISC-Prozessors auf einem FPGA-Prototypingboard auf der Basis des MIPS R2000. Zu entwerfen und implementieren sind die Kernkomponenten: Steuerwerk, Rechenwerk (Integer-ALU) und Bus-Interface. Dabei bestehen Wahlmöglichkeiten bezüglich der grundlegenden Konzepte, die auf den folgenden Seiten beschrieben sind. Die Implementierung erfolgt in der Sprache VHDL. Für Testprogramme steht ein C-Compiler zur Verfügung. Falls Sie gerne einen anderen Mikroprozessor auf einem FPGA entwerfen und implementieren möchten, so ist das ebenfalls möglich. Eine C-Toolchain sollte jedoch bereits verfügbar sein. Zu Prüfen ist, ob Lizenz-rechtlich ein Nachbau gestattet ist. Alternativ kann auch ein 8-Bit-Mikroprozessor mit einem Picoblaze-kompatiblen Befehlssatz implementiert werden. Es sind dieselben Kernkomponenten zu entwerfen, jedoch ohne Pipeline. Die SW-Programmierung erfolgt mittels Assembler. Variante 2: Implementierung des UDP/IP-Stacks in Hardware Für die High-Speed-Kommunikation zwischen PC und modernen FPGA-Boards bietet sich die Gigabit-Ethernet-Schnittstelle an. Der Ethernet MAC ist entweder bereits im FPGA integriert (z. B. im Virtex-5/6) oder wird vom FPGA-Hersteller als Soft-IP-Core angeboten. Die Kommunikation mit dem PC-Programm kann mit Raw-Ethernet-Frames erfolgen. Dies ist jedoch nicht sehr komfortabel und erfordert Root-Privilegien. Außerdem stellt insbesondere der Linux-Kernel dafür keine Kernel-Puffer bereit, so dass etwa 5-10% der Pakete verloren gehen, da die Applikation sie nicht schnell genug abholt / abholen kann. Ziel des Praktikums wäre ein modulares Hardware-Design, dass im Streaming-Mode beim Senden erst den UDP-Header, dann den IP-Header und dann Ethernet-Header anfügt. Beziehungsweise beim Empfangen dekodiert und Pakete filtert. Die Implementierung erfolgt in der Sprache VHDL. Die PC-Software für den Test kann wahlweise in C/C++/C# oder Java implementiert werden. 1
Variante 3: Eigene Entwurfsvorschläge Eigene Ideen und Entwicklungen sind immer herzlich willkommen. Die vorhandenen FPGA-Boards bieten neben Netzwerk- auch Audio-/Video- und SATA-Schnittstellen. In den FPGAs sind reichlich DSP-Blöcke für Algorithmen der digitalen Signalverarbeitung integriert. 2 Ablauf Entwurf und Implementierung erfolgen entweder als Einzelarbeit oder, vorzugsweise, als 2-er Team. Die Bedingungen dazu sind in den folgenden detaillierteren Beschreibungen genannt. Als Abschluss ist ein Praktikumsbeleg anzufertigen, der den Entwurf, die Implementierung und die Testfälle dokumentiert. Bei erfolgreicher Teilnahme erhält jeder Student einen Schein über 4 SWS. Abweichende Aufgabenstellungen für 2 SWS (IST Komplexpraktikum, oder INF kleines Praktikum) sind ebenfalls möglich. 3 Bereitgestellte Tools und Komponenten Für den Hardwareentwurf werden Ihnen folgende Tools und Komponenten zur Verfügung gestellt: Software-Entwicklungswerkzeuge: Eclipse CDT (Standard / Managed Make) GCC-Toolchain + Makefiles Architektur-Entwicklungswerkzeuge: Prozessorsimulator PROSIM für Architekturbeschreibungssprache TADL Hardware-Entwicklungswerkzeuge: Xilinx ISE 13 Chipscope 13 (On-Chip Logikanalysator) QuestaSim 10 (ähnlich ModelSim) IP-Komponenten mit Wishbone-Interface Speichercontroller für On-Chip-RAM des FPGAs, wahlweise mit Wishbone-Interface. SRAM-Speichercontroller (evtl. DDR2-SDRAM-Controller), UART, LCD-Controller, PS/2-Controller,.... FPGA-Prototyping-Boards: Virtex-5 ML505 Board Spartan-3E Starter Kit Spartan-3 Starter Kit b.w. 2
4 Details zum Themenvorschlag RISC-Mikroprozessor 4.1 Blockdiagramm für System-on-a-Chip Untenstehende Abbildung gibt das Blockdiagramm für das auf dem FPGA zu realisierende System-on-a-Chip wieder. Für eine Applikationen kann der Programmkode direkt im Boot-RAM abgelegt werden, wobei der externe Speicher dann als zusätzlicher (uninitialisierter) Speicher zur Verfügung steht. Eine Anbindung des Speichercontrollers an den Befehlsbus nebst Arbiter ist für diesen Anwendungsfall nicht erforderlich. Für komplexe Applikationen, die nicht im Boot-RAM ausreichend Platz finden, ist der externe Speicher auch als Programmspeicher zu nutzen. Da dieser aber nicht vorinitialisiert werden kann, ist für den Boot-RAM ein Boot-Loader zu implementieren, der den Kode der Applikationen z. B. von der seriellen Schnittstelle in den externen Speicher lädt. Zur Anpasung der Linker-Skripte gibt der Betreuer Auskunft. MIPS IF ID Instruction Bus MIPS Boot RAM SoC FPGA EX L/S WB Data Bus UART Arbiter Memory Controller... TXD RXD External Memory 4.2 Wahlmöglichkeiten 4.2.1 RISC-Pipeline Die RISC-Pipeline ist entweder mit 3 Stufen (Fetch, Decode, Execute) oder mit 5 Stufen (Fetch, Decode, Execute, Load / Store, Write-Back) zu implementieren. Daraus ergeben sich folgende Vor- und Nachteile. Bei der 3-stufigen Pipeline erfolgt die Abarbeitung von bspw. Load / Store-Operationen, mittels einer Mehrzyklensteuerung. Dazu besitzt der Dekoder einen Zustand, sodass für jeden EX-Zyklus ein Decode-Zyklus ausgeführt wird, der die Steuersignale bereitstellt. Vorteilhaft ist, dass kein Forwarding nötig ist. Dafür ist die Performance aufgrund des höheren CPI-Werts geringer. Die 5-stufige Pipeline entspricht dem vom MIPS bekannten Konzept, dass auch im Patterson and Hennessy: Rechnerorganisation und -entwurf behandelt wird. Für die höhere Performance, muss aber eine Forwarding-Einheit implementiert werden. Bei beiden Alternativen, ist ein Sprung während der Decode-Stufe zu dekodieren und auszuführen. Der parallel geholte Befehl wird im so genannten Branch Delay Slot auf jeden Fall ausgeführt. Weiterhin vom Compiler / Assembler beachtet werden Load-Use-Konflikte, sodass hier keine besondere Behandlung erforderlich ist. 3
4.2.2 Bussysteme Die erste Variante umfasst lediglich ein einfaches synchrones Protokoll mit getakteten Lese- und Schreibzugriffen und ohne Wartezustände. Nachteil dieser einfach zu implementierenden Variante ist, dass die Wiederverwendungsmöglichkeiten des eigenen Designs sinken, da selten Peripherie-Geräte ohne jegliche Wartetakte zur Verfügung stehen. Das gilt auch für die bereitgestellte UART sowie (teilweise) für die SRAM-Speichercontroller. Besser geeignet ist der Wishbone-Bus. Die Classic-Read-Zugriffe stellen sogar ein asynchrones Lesen bereit, während Schreiben immer synchron zur Taktflanke ist. Hierbei sind jedoch Wartetakte zu behandeln, die Peripherie-Geräte nach Belieben einfügen können. Für eine hohe Performance ist es zudem unerlässlich ebenfalls Burst-Zugriffe im Bus-Master zu implementieren. Die bereitgestellten Speichercontroller für den On-Chip-RAM (Slave) unterstützen bereits Bursts mit aufsteigenden Adressen. Auf Wunsch kann auch ein anderes, aber standardisiertes, Protokoll für Bussysteme implementiert werden. 4.3 Einzel- vs. Gruppenarbeit Einzelarbeit 2-er Team Rechenwerk ALU als Netzliste vorgegeben. ALU nur zum Testen vorgegeben, eigene Implementierung erforderlich. Steuerwerk Sehr einfaches Beispiel für den Einstieg bereitgestellt. Pipeline 3- oder 5-stufig 5-stufig Bussystem Einfaches synchrones Protokoll oder Wishbone-Bus Wishbone-Bus MIPS-Befehle ADD(U), ADDI(U), SUB(U), AND(I), OR(I), XOR(I), NOR(I), SLT(U), SLTI(U), SLL(V), SRL(V), SRA(V), J(R), JAL(R), BEQ, BNE, BLTZ, BLEZ, BGTZ, BGEZ, LW, SW LB, SB, LH, SH Hinweis zu den Arithmetik-Befehlen: Befehle wie ADD (vorzeichenbehaftet) sind zu implementieren, wobei die Behandlung eines eventuell auftretenden Overflows optional ist. b.w. 4
5 Details zum Themenvorschlag UDP/IP-Stack 5.1 Schnittstellen FPGA-seitig erfolgt der Datenaustausch mit den IP-Cores für den Ethernet-MAC streambasiert über einen Byte-kanal mit 125 MHz. Zusätzliche Steuersignale zeigen Start- und Ende von Paketen an sowie die Sendebereitschaft. Es steht ein einfacher UDP-Paket-Generator zu Verfügung, der die Nutzung der IP-Core-Schnittstelle demonstriert. Die Schnittstelle zwischen der Anwendungslogik und dem UDP/IP-Modul ist nach dem gleichen Prinzip streambasiert auszulegen. 5.2 Komponenten In Hardware (FPGA) sind folgende Komponenten zu implementieren: Zum Senden von Paketen vom FPGA zum PC UDP-Transmitter: Anfügen des UDP-Headers an das Datenpaket. Der Port wird statisch über VHDL-Generics festgelegt. Berechnung der UDP-Checksum. IP-Transmitter: Anfügen des IP-Headers an das UDP-Paket. IP-Adressen werden statisch über VHDL-Generics festgelegt. Berechnung der IP-Header-Checksum. Eth-Transmitter: Anfügen des Ethernet-Headers an das IP-Paket. MAC-Adressen werden statisch über VHDL-Generics festgelegt. Die CRC-Checksumme wird automatisch vom Ethernet MAC angefügt und muss nicht berechnet werden. Zum Empfangen von Paketen vom PC Eth-Receiver: Entfernen des Ethernet-Headers. Prüfung auf richtige MAC-Adressen, die statisch über VHDL-Generics festgelegt wird. Die CRC-Checksumme wird bereits vom Ethernet MAC geprüft. IP-Receiver: Entfernen des IP-Headers. Prüfung auf richtige IP-Adressen, die statisch über VHDL-Generics festgelegt wird. Prüfung der IP-Header-Checksum. UDP-Transmitter: Entfernen des UDP-Headers. Prüfung auf korrekten Port, der statisch über VHDL-Generics festgelegt wird. Prüfung der UDP-Checksum. 5.3 Größe der Datenpakete Die Größe der zu übertragenden Datenpakete ist durch den Ethernet-Frame abzüglich IP- und UDP-Header begrenzt. Fragmentierung von IP-Paketen ist nicht zu unterstützen. Bei zu dieser Größe sind Datenpakete variabler Größen zu unterstützen. Die IP-Header-Checksum muss demnach dynamisch zur Laufzeit berechnet werden. Ebenso ist die Berechnung der UDP-Checksumme zu implementieren. Bei einer Gruppenarbeit ist zusätzlich die dynamische Auflösung von IP-Adresen zu MAC-Adressen per ARP ist zu implementieren. Ebenso sollen Ping-Requests beantwortet werden. 5