implementierung von softcore-prozessoren und/oder … fifo-source-code ... uart universal...
Post on 01-Apr-2018
237 Views
Preview:
TRANSCRIPT
Bachelor-Thesis
Implementierung von
Softcore-Prozessoren und/oder
weiteren IPs (Intellectual Properties)
in FPGAs
Fakultat Elektrotechnik und Informationstechnik
Artur Werner
Studiengang: Elektrotechnik / Informationstechnik
Fachrichtung: Kommunikationstechnik
Anschrift: Im Spatzenwinkel 3, 77694 Kehl-Marlen
Email-Adresse: arturwerner91@gmail.com
Telefon: 07854 9899971
Betreuer: Prof. Dr.-Ing. Elke Mackensen
Prof. Dr.-Ing. Axel Sikora
Bearbeitungszeitraum: 13. Marz 2017 bis 31. August 2017
Kurzfassung
In heutigen Low-Power-Anwendungen ist es mittlerweile Standard sogenannte System-
on-a-Chip (SoC)-Systeme zu entwickeln. Diese benotigen eine Recheneinheit, sowie nur
die notwendigste Hardware, um die Energieversorgung auch uber Energy-Harvester zu
ermoglichen.
Im Rahmen dieser Abschlussarbeit wurde der aktuelle Stand von verfugbaren Hardcore-
Prozessor (Hardcore) und Softcore-Prozessor (Softcore) evaluiert. Aufgrund der hohen
Anforderungen an den Prozessor in Low-Power-Systemen, wurden Hardcore-Prozessoren
fur die weitere Untersuchung ausgeschlossen. Obwohl diese sehr leistungstarke und
energieeffiziente Prozessoren sind, weisen Hardcore-Prozessoren nicht die notwendige
Flexibilitat in einer minimalen Konfiguration auf, um die Anspruche einer Low-Power-
Anwendung zu erfullen.
Aus diesem Grund wurden von verschiedenen Quellen Softcore-Prozessoren untereinan-
der mit zusatzlich, ausgewahlten Kriterien untersucht. Die Wahl fiel auf den NEO430,
welcher auf der Architektur des Mikrocontrollers MSP430 von Texas Instrument ba-
siert.
Mit dem NEO430 als Softcore, wurde ein Demonstrator-System entwickelt und auf
dem Development-Board DE2-115 von Terasic implementiert. Im Zuge der Entwick-
lung des Demonstrators wurden weiterhin frei verfugbare IP-Cores zur Anbindung an
den NEO430 untersucht. Der Demonstrator umfasste eine selbst entwickelte CRC-
Berechnung, um damit die Programmierbarkeit, die Funktionen des NEO430 zu testen
und dessen Ressourcenverbauch, sowie Erweiterbarkeit uber der Wishbone-Schnittstelle
zu evaluieren.
Die Evaluierung des Demonstrator-Systems ergab einen Ressourcenverbrauch von 1253
Logikelemente des Development-Boards. Neben dem Demonstrator wurden weitere
Konfigurationen, wie eine Minimale-, die Standard-Konfiguration und insbesondere
eine Konfiguration ohne der Wishbone-Schnittstelle evaluiert.
Durch die starke Verbreitung der MSP430-Serie in der Industrie, ist der NEO430 ein
interessanter Kandidat fur Low-Power-Systeme.
Artur Werner
Eidesstattliche Erklarung
Hiermit versichere ich eidesstattlich, dass die vorliegende Arbeit mit dem Thema
Implementierung von Softcore-Prozessoren und/oder weiteren IPs (Intel-
lectual Properties) in FPGAs
von mir selbststandig und ohne unerlaubte fremde Hilfe angefertigt worden ist, insbe-
sondere, dass ich alle Stellen, die wortlich oder annahernd wortlich oder dem Gedanken
nach aus Veroffentlichungen, unveroffentlichten Unterlagen und Gesprachen entnom-
men worden sind, als solche an den entsprechenden Stellen innerhalb der Arbeit durch
Zitate kenntlich gemacht habe, wobei in den Zitaten jeweils der Umfang der entnomme-
nen Originalzitate kenntlich gemacht wurde. Die Arbeit lag in gleicher oder ahnlicher
Fassung noch keiner Prufungsbehorde vor und wurde bisher nicht veroffentlicht. Ich
bin mir bewusst, dass eine falsche Versicherung rechtliche Folgen haben wird.
Datum, Ort Unterschrift
Artur Werner
Inhaltsverzeichnis
Inhaltsverzeichnis
Tabellenverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . III
Abbildungsverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IV
Listings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VI
Akronyme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VII
Glossar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IX
1 Einfuhrung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 Motivation der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Definition der Aufgabenstellung und Ziele der Arbeit . . . . . . . . . . . 3
1.3 Struktureller Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . 4
2 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3 Stand der Technik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1 Mikroprozessoren und Mikrocontroller . . . . . . . . . . . . . . . . . . . . 8
3.1.1 Speicherarchitekturen . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.2 Befehlssatzarchitekturen . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2 System-on-Chip (SoC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.1 Intellectual Property Cores . . . . . . . . . . . . . . . . . . . . . . . 13
3.3 FPGA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.4 VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4.1 Aufbau eines VHDL-Modells . . . . . . . . . . . . . . . . . . . . . . 15
3.4.2 Simulation eines VHDL-Modells . . . . . . . . . . . . . . . . . . . . 17
4 Analyse und Vergleich bestehender Hardcore- und Softcore-Prozessoren . 19
4.1 Hardcore-Prozessoren in FPGAs . . . . . . . . . . . . . . . . . . . . . . . 20
4.2 Kriterien fur die Auswahl eines Softcore-Prozessors . . . . . . . . . . . . 20
4.2.1 Ergebnis einer ersten Auswahl in Frage kommender Softcore-Prozessoren 21
Artur Werner I
Inhaltsverzeichnis
4.2.2 Detaillierter Vergleich vorausgewahlter Softcore-Prozessoren . . . . 24
4.3 Auswahl eines Prozessorkerns fur die Implementierung eines Demonstrators 26
4.3.1 Vorstellung des NEO430 Softcore-Prozessors . . . . . . . . . . . . . 26
4.3.2 Unterschiede des NEO430 zum MSP430 Mikrocontroller . . . . . . 28
5 Konzept und Implementierung eines Demonstrator-Systems . . . . . . . . 31
5.1 Aufbau des Demonstrator-Systems . . . . . . . . . . . . . . . . . . . . . . 31
5.2 Implementierung des Softcores NEO430 . . . . . . . . . . . . . . . . . . . 33
5.2.1 Das CPU-Modul des NEO430 . . . . . . . . . . . . . . . . . . . . . 40
5.2.2 Interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.2.3 General Purpose Input Output (GPIO) . . . . . . . . . . . . . . . . 42
5.2.4 Universal Synchronous/Asynchronous Receiver Transmitter (USART) 43
5.2.5 Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.2.6 Watchdog-Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.3 Wishbone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.3.1 Wishbone-Spezifikation . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.3.2 Verschaltungsarten von Wishbone . . . . . . . . . . . . . . . . . . . 47
5.3.3 Wishbone-Slave-Implementierung . . . . . . . . . . . . . . . . . . . 49
5.4 Implementierung eines CRC-Moduls . . . . . . . . . . . . . . . . . . . . . 51
5.4.1 Berechnung CRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.4.2 Implementierung CRC . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.4.3 Simulationsergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.5 Anbindung eines frei verfugbaren FIFO-Moduls . . . . . . . . . . . . . . 60
5.5.1 IP-Modul FIFO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.5.2 Erweiterung mit Wishbone . . . . . . . . . . . . . . . . . . . . . . . 61
5.6 C-Programmierung des NEO430 . . . . . . . . . . . . . . . . . . . . . . . 63
5.6.1 Genereller Software-Setup . . . . . . . . . . . . . . . . . . . . . . . 63
5.6.2 Programm-Entwicklung . . . . . . . . . . . . . . . . . . . . . . . . 63
5.6.3 Programm-Compilierung . . . . . . . . . . . . . . . . . . . . . . . . 67
5.6.4 Programm-Upload . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.6.5 Nutzung einer Entwicklungsumgebung . . . . . . . . . . . . . . . . 70
6 Evaluation der Implementierung eines NEO430 System . . . . . . . . . . 73
6.1 Programmierung des NEO430 . . . . . . . . . . . . . . . . . . . . . . . . 74
6.2 Vergleich der Prozessor-Anforderungen . . . . . . . . . . . . . . . . . . . 74
6.3 Ressourcen- und Energievebrauch . . . . . . . . . . . . . . . . . . . . . . 76
7 Zusammenfassung und Ausblick . . . . . . . . . . . . . . . . . . . . . . . . 79
Quellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
II Artur Werner
Tabellenverzeichnis
Tabellenverzeichnis
4.1 Ubersichtstabelle der Softcore-Prozessoren . . . . . . . . . . . . . . . . . 22
4.2 Detaillierte Ubersicht vorausgewahlter Softcore-Prozessoren . . . . . . . 25
5.1 Bezeichnung der vier Interrupts . . . . . . . . . . . . . . . . . . . . . . . 42
5.2 Bedeutung der Signalnamen des Wishbone-Interfaces . . . . . . . . . . . 45
5.3 Tabellarische Darstellung der Codeworter . . . . . . . . . . . . . . . . . 51
5.4 Wahrheitstabelle XOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.1 Vergleich der Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . 75
6.2 Logik- und Speicher-Ressourcenverbrauch . . . . . . . . . . . . . . . . . 77
Artur Werner III
Abbildungsverzeichnis
Abbildungsverzeichnis
1.1 Konzept eines SoC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3.1 Implementierungsarten von Embedded Systems . . . . . . . . . . . . . 7
3.2 Allgemeiner Aufbau eines Computersystems . . . . . . . . . . . . . . . 9
3.3 Komponenten eines Von-Neumann-Rechners . . . . . . . . . . . . . . . 10
3.4 Aufbau einer Harvard-Architektur . . . . . . . . . . . . . . . . . . . . . 11
3.5 Architektur eines Cyclone IV Field Programmable Gate Array (FPGA) 14
3.6 Testbench eines DUTs . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1 Cyclone V SoC Architektur . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2 Architektur NEO430 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3 Speicheradressierung des NEO430 . . . . . . . . . . . . . . . . . . . . . 27
4.4 Auswahl MSP430-Peripherie . . . . . . . . . . . . . . . . . . . . . . . . 29
5.1 Hardware Konfiguration fur NEO430-Test-Implementation . . . . . . . 31
5.2 Aufbau Demonstrator-System . . . . . . . . . . . . . . . . . . . . . . . 32
5.3 Top-Level-Modul NEO430 . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.4 Interne Verschaltung Top-Level Design Teil 1 . . . . . . . . . . . . . . . 37
5.5 Interne Verschaltung Top-Level Design Teil 2 . . . . . . . . . . . . . . . 38
5.6 Interne Verschaltung Top-Level Design Teil 3 . . . . . . . . . . . . . . . 39
5.7 Aufbau Modul NEO430 CPU . . . . . . . . . . . . . . . . . . . . . . . 40
5.8 Master-/Slave-Schnittstelle . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.9 Synchrones Handshaking-Protokoll . . . . . . . . . . . . . . . . . . . . 46
5.10 Punkt-zu-Punkt Verbindung . . . . . . . . . . . . . . . . . . . . . . . . 47
5.11 Data flow Verbindung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.12 Shared Bus Verbindung . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.13 Crossbar Switch Verbindung . . . . . . . . . . . . . . . . . . . . . . . . 48
5.14 Berechnung CRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.15 Aufbau CRC-Encoder-Schaltung . . . . . . . . . . . . . . . . . . . . . . 53
5.16 Optimierte CRC-Encoder-Schaltung . . . . . . . . . . . . . . . . . . . . 54
5.17 Simulationsfenster von 3 CRC-Berechnungen . . . . . . . . . . . . . . . 59
5.18 Prinzip einer FIFO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
IV Artur Werner
Abbildungsverzeichnis
5.19 Serielle Konfiguration in TeraTerm . . . . . . . . . . . . . . . . . . . . 68
5.20 Text Interface im Konsolenfenster . . . . . . . . . . . . . . . . . . . . . 69
5.21 Datei senden mit TeraTerm . . . . . . . . . . . . . . . . . . . . . . . . 69
5.22 Ubertragen der ausfuhrbaren, binaren Datei . . . . . . . . . . . . . . . 69
5.23 Adressenanderung in make.bat . . . . . . . . . . . . . . . . . . . . . . . 71
5.24 Compiler Pfadangabe in compile.bat . . . . . . . . . . . . . . . . . . . 71
5.25 Image-Generator Pfadangabe in compile.bat . . . . . . . . . . . . . . . 71
5.26 NEO430-Applikation-Image-Datei Pfadangabe in compile.bat . . . . . . 71
5.27 Projekt Eigenschaften . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.28 Projekt-Kompilierung mit Hammer-Icon . . . . . . . . . . . . . . . . . 72
Artur Werner V
Listings
Listings
3.1 Beispiel UND-Gatter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.1 Komponenten Deklaration . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.2 Komponenten Inkludierung . . . . . . . . . . . . . . . . . . . . . . . . 36
5.3 Konstrukt record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.4 Wishbone-Signale in der Entity . . . . . . . . . . . . . . . . . . . . . . 45
5.5 Wishbone-Slave-Anbindung . . . . . . . . . . . . . . . . . . . . . . . . 50
5.6 Entity des CRC-Moduls . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.7 Deklaration von Signalen und Konstanten . . . . . . . . . . . . . . . . 55
5.8 Zahlprozess der Zustandmaschine . . . . . . . . . . . . . . . . . . . . . 56
5.9 Zustandsmaschine des Schieberegister . . . . . . . . . . . . . . . . . . . 57
5.10 Erweiterung Wishbone . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.11 FIFO-Source-Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.12 Einbindung der Header-Dateien . . . . . . . . . . . . . . . . . . . . . . 64
5.13 Deklaration von Einstellungen . . . . . . . . . . . . . . . . . . . . . . . 64
5.14 Initialisierung der Schnittstellen . . . . . . . . . . . . . . . . . . . . . . 65
5.15 Lauflicht-Programm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.16 Programm der CRC-Berechnung . . . . . . . . . . . . . . . . . . . . . . 66
VI Artur Werner
Akronyme
Akronyme
ADC Analog-Digital-ConverterALU Arithmetic Logic UnitAMBA Advanced Microcontroller Bus ArchitectureARM Advanced RISC Machines LimitedASIC Application-specific Integrated Circuit (IC)
BSD Berkeley Software Distribution
CISC Complex Instruction Set ComputerCPLD Complex Programmable Logic Device (PLD)CPU Central Processing UnitCRC Cyclic Redundancy Check
DAC Digital-Analog-ConverterDSP Digitaler SignalprozessorDUT Device Under Test
EEPROM Electrically Erasable Programmable Read-Only Me-mory
FIFO First-In-First-OutFPGA Field Programmable Gate ArrayFPU Floating Point UnitFRAM Ferroelectric Random Access Memory
GCC GNU Compiler CollectionGPIO General Purpose Input OutputGPL General Public License
Hardcore Hardcore-ProzessorHPS Hard Processor System
IC Integrated CircuitIDE Integrierte EntwicklungsumgebungIO Input/OutputIP Intellectual PropertyIP-Modul Intellectual Property ModulISA Instruction Set Architecture
Artur Werner VII
Akronyme
LED Light Emitting DiodeLGPL Lesser General Public LicenseLM32 LatticeMico32LM8 LatticeMico8LUT Look-Up-Table
MIT Massachusetts Institute of TechnologyMSB Most Significant Bit
PC Program CounterPLD Programmable Logic DevicePLL Phase Locked Loop
RAM Random-Access MemoryRISC Reduced Instruction Set ComputerRMW Read-Modify-WriteROM Read-Only Memory
SoC System-on-a-ChipSoftcore Softcore-ProzessorSPI Serial Peripheral Interface
TI Texas Instruments
UART Universal Asynchronous Receiver TransmitterUSART Universal Synchronous/Asynchronous Receiver
Transmitter
Verilog VerilogVHDL Very High Speed Integrated Circuit Hardware Des-
cription Language
XOR Exklusiv-Oder
VIII Artur Werner
Glossar
Glossar
Field Programmable Gate ArrayEin Field Programmable Gate Array (FPGA) ist ein integrierter Schaltrkreis IC,in welchen eine logische Schaltung geladen werden kann. Auf Deutsch ubersetztbedeutet FPGA Feld programmierbare (Logik-)Gatter-Anordnung. FPGAs stelleneine Weiterentwicklungen der PLDs dar.
Hardcore-ProzessorMit einem Hardcore-Prozessor bezeichnet man Prozessoren die in einem program-mierbaren Logikbaustein bereits als Hardware-Modul eingebettet sind, also diephysikalische Integration in den Silizium Chip eines FPGA.
Intellectual Property ModulMit einem Intellectual Property (IP)-Modul wird das geistigte Eigentum des Ent-wickler vom Modul bezeichnet.
Softcore-ProzessorEin Softcore-Prozessor ist ein Prozessorkern, welcher durch eine Hardwarebe-schreibungssprache als Quelltext oder bereits als vor synthetisierte Netzliste vor-liegt. Dieser kann anschließend auf programmierbarer Logik wie z.B. FPGA,Application-specific IC (ASIC), Complex PLD (CPLD) implementiert werden.
System-on-a-ChipUnter System-on-a-Chip (SoC) versteht man die Integration aller oder einesgroßen Teils der Funktionen eines programmierbaren elektronischen Systems aufeinem Chip, also einem IC.
Universal Asynchronous Receiver TransmitterUnter Universal Asynchronous Receiver Transmitter (UART, dt. Universellerasynchroner Empfanger/Sender), versteht man eine elektronische serielle Schnitt-stelle, die zur asynchronen Datenubertragung zwischen zwei Geraten genutztwird.
VerilogVerilog ist eine Hardware-Beschreibungssprache. Mit dieser lassen sich Operatio-nen und Verhalten von digitalen integrierten Schaltungen beschreiben.
Very High Speed Integrated Circuit Hardware Description LanguageVery High Speed Integrated Circuit Hardware Description Language (VHDL)ist eine Hardware-Beschreibungssprache. Mit dieser lassen sich Operationen undVerhalten von digitalen integrierten Schaltungen beschreiben.
Artur Werner IX
Einfuhrung
1 Einfuhrung
In dieser Bachelorarbeit wird aufgezeigt, welche Softcore-Prozessoren derzeit verfugbar
sind. Mit welchen Argumenten, die Auswahl eines Softcores optimal erfolgt. Wie ein
NEO430-Softcore, basierend auf dem 16-Bit MSP430 von Texas Instrument, auf einen
Altera-FPGA dem Cyclone IV implementiert wird. Welche Moglichkeiten bestehen, den
NEO430 zu programmieren und um eigene oder frei verfugbare IP-Module, am Beispiel
einer Cyclic Redundancy Check (CRC)-Implementierung, zu erweitern. Abschließend
werden die genutzten Ressourcen des FPGAs evaluiert und auf weitere mogliche For-
schungsarbeiten eingegangen.
1.1 Motivation der Arbeit
Heutzutage ist es Standard in technischen Anwendungen Mikrocontroller einzusetzen.
Mit sogenannten SoC fuhrt man die Idee voran, ein System mit moglichst wenigen
Komponenten zu realisieren und versucht eine vollstandige Systemlosung, auf Basis
eines Mikrocontrollers (siehe Abb. 1.1), auf einem Chip unterzubringen. Bei der Ent-
wicklung solcher Systeme entstehen neue Herausforderungen durch Abkundigungen
von Mikrocontroller.
Zum einem besteht die Moglichkeit das System auf einen neuen Mikrocontroller zu
portieren, welches den Kosten und Zeitaufwand einer Neuentwicklung eines SoCs ent-
spricht. Zum anderen ist die Entwicklung eines eigenen Prozessorkerns nur unter großem,
personellen und zeitlichen Aufwand moglich. Insbesondere der langfristige Support des
Prozessorkerns und die kontinuierliche Weiterentwicklung der Entwicklungsumgebung
ist durch kleine Unternehmen oder Forschungseinrichtungen nicht zu leisten [1].
Der Entwurf von SoC-Systemen erfordert die Integration eines Prozessorkerns. Gerade
an den Entwurf von drahtlos kommunizierenden Sensor-SoC-Systemen, die eventuell
noch per Energy-Harvesting betrieben werden sollen, sind hohe Anforderungen gestellt,
die naturlich bei der Integration eines Prozessorkerns berucksichtigt werden mussen.
Artur Werner 1
Einfuhrung
Abbildung 1.1: Konzept eines SoC [2]
Bei der Integration eines Prozessorkerns in ein Low-Power-SoC-System konnen drei
Ansatze verfolgt werden:
• Die Implementierung eines Hardcore-Prozessors. Hierunter versteht man das Vor-
liegen der Prozessor-Hardware-Komponenten in Form eines vorliegenden Layouts
in einer vorgegebenen Zieltechnologie. Der derzeitige Trend bei FPGAs besteht,
leistungsfahige Hardcore-Prozessor in FPGAs zu integrieren.
• Die Implementierung eines Softcore-Prozessors. Hier liegt der Prozessor als syn-
thetisierbarer”Software-Code“ in einer noch nachtraglich anderbaren Hardwa-
rebeschreibungssprache wie VHDL oder als vorkompilierte, optimierte Netzliste
vor.
• Die Implementierung eines eigens entwickelten Prozessorkerns. Dies ist eine Va-
riante, einen optimalen Prozessorkern zu entwerfen. Dieser Ansatz hat jedoch
verschiedene Nachteile, wie zum Beispiel der Entwicklung und Pflege der ent-
sprechenden Entwicklungswerkzeuge (Programmierumgebung, Compiler...) und
fuhrt dazu, dass dieser Ansatz nicht weiter verfolgt wird.
Aufgrund dessen liegt der Fokus in der Entwicklung eines SoC-Systems bei der In-
tegration von Hardcore- und Softcore-Prozessoren. Die Prozessor-Integration in SoC-
Systemen unterliegt hohen Anforderungen. Daher wird die Variante mit dem Softcore-
Prozessor gegenuber der Variante des Hardcore-Prozessors verfolgt, da die Implemen-
tierung eines Softcore-Prozessors wesentliche Vorteile hat.
2 Artur Werner
Einfuhrung
1.2 Definition der Aufgabenstellung und Ziele der
Arbeit
In dieser Arbeit soll die Implementierung eines Softcore-Prozessors und/oder weiteren
IPs in FPGAs evaluiert werden. Dazu stehen folgende Aufgaben an:
• Analyse und Vergleich von Hardcore- und Softcore-Prozessoren bei verschiedenen
FPGA-Herstellern oder Open-Source-Quellen
• Auswahl eines geeigneten Prozessorkerns, welcher die Anforderungen, die an den
Prozessor gestellt sind, erfullt
• Evaluation des implementierten Prozessorkerns
– wie erfolgt die Entwicklung einer Anwendung
– wie erfolgt die Programmierung und das Debugging der Anwendung
– wie erfolgt die Erweiterbarkeit des Prozessors
• Ermittlung des Ressourcenverbrauchs
Weitere detaillierte Anforderungen die an den Prozessor gestellt sind, sind im Kapitel
2”Anforderungen“ vorzufinden.
Auf Grund der verfugbaren Softcore-Prozessoren, welche die aufgestellten Anforde-
rungen erfullen, wurden im Zuge der Implementierung folgende Aspekte eines aus-
gewahlten Softcore-Prozessors untersucht:
• Wie schnell ist es moglich den Softcore-Prozessor auf einem FPGA zu implemen-
tieren?
• Welche weitere Hardware-Komponenten werden durch den Softcore abgedeckt?
• Welche Moglichkeiten bestehen, den Softcore um eigene oder auch frei verfugbare
IP-Module zu erweitern?
• Welche Moglichkeiten der Programmierung und des Debuggens sind fur den
Softcore-Prozessor vorhanden?
• Welche Ressourcen werden von der Implementierung im FPGA verbraucht?
Das Ziel der Arbeit ist es, die Aufgaben und Aspekte zielgerichtet durchzufuhren, die
Vorgehensweise und Arbeitsschritte zu dokumentieren, sowie erzielte Ergebnisse zu
prasentieren und evaluieren.
Artur Werner 3
Einfuhrung
1.3 Struktureller Aufbau der Arbeit
Im Kapitel 2”Anforderungen“ werden die Anforderungen an die Arbeit und den Pro-
zessorkern aufgelistet.
In Kapitel 3”Stand der Technik“ werden die Grundlagen zu Mikroprozessoren und
Mikrocontroller, sowie System-on-Chips, FPGAs und der Hardwarebeschreibungsspra-
che VHDL erlautert.
Das Kapitel 4”Analyse und Vergleich bestehender Hardcore- und Softcore-Prozessoren“
widmet sich der Untersuchung von Hardcore- und Softcore-Prozessoren und mit wel-
chen Prinzipien die Wahl auf den NEO430-Softcore-Prozessor erfolgte.
In Kapitel 5”Konzept und Implementierung eines Demonstrator-Systems“ wird der
Aufbau des NEO430, die Implementierung einer CRC-Berechnung und das Wishbone-
Interface an einer FIFO sowie dem CRC-Modul erklart. Weiterhin wird die Program-
mierung des NEO430 behandelt.
Die Evaluation der FPGA-Konfiguration, den Zeitaufwand der Implementierung, ver-
wendete Programme, sowie das Programmieren des NEO430 und Ressourcenverbrauchs
wird in Kapitel 6”Evaluation der Implementierung eines NEO430 System“ aufgezeigt.
Kapitel 7”Zusammenfassung und Ausblick“ schließt die Arbeit ab.
4 Artur Werner
Anforderungen
2 Anforderungen
Um die Aufgabenstellung umzusetzen wird im folgenden auf die genauen Anforderun-
gen der Arbeit und des Prozessors eingegangen.
Die Aufgaben dieser Arbeit richten sich im Wesentlichen an die Untersuchung der
Anforderungen eines Prozessorkerns. Die Auswahl eines Prozessorkerns in Low-Power-
Systemen steht vor großen Herausforderungen. Dazu gehort die wichtigste Anforderung
bei der Entwicklung, dass alle Komponenten eine geringe Strom- beziehungsweise Leis-
tungsaufnahme besitzen. Diese Anforderung gilt auch fur den zu integrierenden Pro-
zessorkern. Daher mussten zuerst die Anforderungen analysiert und festgelegt werden.
Der Prozessorkern soll folgende Anforderungen erfullen ...
A1 ... aus Sicht der Anwendung der Low-Power-Systeme auf einem FPGA und/o-
der ASIC kostengunstig implementierbar sein.A2 ... auf einer bekannten Prozessorarchitektur basieren, um Standardtools der
Industrie zu verwenden.A3 ... mit einer Entwicklungsumgebung der Industrie den Prozessor programmie-
ren und debuggen.A4 ... in einer Hardwarebeschreibungssprache wie VHDL vorliegen und program-
mierbar sein .A5 ... eine standardisierte Schnittstelle aufweisen, uber welche weitere Kompo-
nenten hinzugefugt und angebunden werden konnen.A6 ... bezogen auf die Anwendung, bevorzugt ein 8-Bit oder 16-Bit Prozessor sein.
Mit großeren Prozessoren wird der Energieverbrauch großer.A7 ... einen geringen Energiebedarf haben. Eine Versorgung uber Batterie oder
Energy-Harvester soll moglich sein.A8 ... einen geringen Ressourcenaufwand aufweisen. Dazu sind verschiedene Kon-
figurationsmoglichkeiten des Prozessors hilfreich, um den Prozessor an die An-
wendung anzupassen und nur die notwendigen Komponenten auf einem Chip
zu integrieren. Dadurch sinkt auch unmittelbar der Energieverbrauch und die
benotigte Chipflache.
Artur Werner 5
Stand der Technik
3 Stand der Technik
Embedded Systems sind Systeme die aus einer Kombination von Computer-Hardware
und Software bestehen. Diese werden explizit fur eine Anwendung entworfen oder sind
Bestandteil eines großeren Systems und erfullen in diesem eine spezielle Funktion.
Dabei weisen Embedded Systems folgende Merkmale auf [3, Kapitel 2]:
• Sie fuhren eine Funktion (wiederholt) aus.
• Unterliegen strengen Anforderungen bezuglich Kosten, Energieverbrauch, Ab-
messungen usw.
• und konnen auf ihre Umwelt in Echtzeit reagieren.
Eine geeignete Wahl der Implementierungsart ist dabei unmittelbar von den Anfor-
derungen an das Systems abhangig. Softwareseitig konnen Vielzweck-, Spezial- und
anwendungsspezifische Befehlssatz-Prozessoren (ASIP) zum Einsatz kommen. Fur die
Hardware stehen programmierbare Hardware, wie FPGAs und anwendungsspezifische
Hardware als ASIC zur Verfugung (siehe Abb. 3.1) [4, Kapitel 2.2].
Abbildung 3.1: Implementierungsarten von Embedded Systems [4]
Artur Werner 7
Stand der Technik
Sind die Anforderungen der Software fur ein Embedded System sehr allgemein, so
sollte ein Vielzweck-Prozessor eingesetzt werden. Dieser ist fur hohe Leistungsanfor-
derungen, Programmierbarkeit und allgemein sehr flexibel ausgelegt. Sie sind jedoch
relativ teuer und verbrauchen viel Energie. Wird die Anforderung spezieller, werden
Spezial-Prozessoren , Digitale Signalprozessoren (DSP) und Mikrocontroller interessan-
ter, sowie auch effizienter in der Umsetzung einer Anwendung.
Das gleiche gilt auch fur die Anforderungen der Hardware. Ist die Anwendung allgemei-
ner, hat man mit FPGAs und PLDs Plattformen, die uber hohe Programmierbarkeit
verfugen. ASICs hingegen sind nicht mehr so flexibel, weisen dafur die beste Perfor-
mance bei relativ geringem Energieverbauch auf.
Das Embedded System kann also als ein Ein-Chip-System (SoC) durch die oben ge-
nannten Komponenten zusammengesetzt werden, besitzt dadurch spezielle Hardware
und Software, ist dafur nicht mehr flexibel, weist aber die beste Performance bei ge-
ringstem Leistungsverbrauch auf.
3.1 Mikroprozessoren und Mikrocontroller
In der Abb. 3.1 sieht man das Mikrocontroller unter der Kategorie Prozessoren steht.
Fur Embedded Systems ist ublicherweise ein Mikrocontroller, der die Recheneinheit
reprasentiert. Der Mikrocontroller ist jedoch weit aus mehr wie nur ein Prozessor.
Computer die auf einen Chip Prozessor, Speicher und Eingabe-/Ausgabebausteine (sie-
he Abb. 3.2) unterbringen, werden als Mikrocontroller bezeichnet [5, Kapitel 1.2.5]. Der
Prozessor, oder Central Processing Unit (CPU) oder auch Mikroprozessor, wenn die
CPU auf einem Chip integriert ist, hat zwei grundlegende Aufgaben [5, Kapitel 1.2.1]:
• Steuerung des gesamten Ablaufs, innerhalb der CPU als auch im gesamten Com-
puter
• Bearbeitung von Daten und Ausfuhrung von arithmetischen und logischen Ope-
rationen
Diese Aufgaben fuhrt die CPU mit Maschinenbefehlen, welche sich im Programmab-
schnitt des Zentralspeichers befinden, durch. Mit diesen Befehlen ist die CPU in der
Lage eine Operation auf Daten durchzufuhren um die Ergebnisse beispielsweise an
Peripheriebausteine weiterzureichen.
8 Artur Werner
Stand der Technik
Abbildung 3.2: Allgemeiner Aufbau eines Computersystems [6, Kapitel 2.1]
Dieser Informationsfluss zwischen Speicher, CPU und Peripherie erfolgt uber Buslei-
tungen, der die Baugruppen eines Computers miteinander verbindet [5, Kapitel 1.2.4].
Der Bus besteht aus Adressbusleitungen und Steuerbusleitungen, an den die Bausteine
parallel miteinander verbunden werden. Die CPU steuert uber diesen Leitungen den
Informationsfluss und lost das Problem der Parallelisierung, so dass immer nur ein
Baustein senden, beziehungsweise empfangen darf.
Artur Werner 9
Stand der Technik
3.1.1 Speicherarchitekturen
In der Speicherarchitektur gibt es zwei verbreitete Referenzmodelle, die Von-Neumann-
Architektur und die Harvard-Architektur.
Von-Neumann-Architektur
Abbildung 3.3: Komponenten eines Von-Neumann-Rechners [7]
Der Aufbau der Von-Neumann-Architektur ahnelt des bereits vorgestellten allgemei-
nen Aufbau eines Computersystems (siehe Abb. 3.2). Es gibt in dieser Architektur nur
einen Speicher, der durch das Speicherwerk in Abb. 3.3 dargestellt ist. In diesem Spei-
cher werden das Programm und die Daten abgelegt.
Verbunden werden die Komponenten des Von-Neumann-Rechners uber ein internes
Bus-System. Uber diesen werden Daten vom Ein-/Ausgabewerk zum Speicher oder zur
CPU transportiert. Damit die Daten nicht verloren gehen, regelt das Steuerwerk uber
Adressen den Verkehr auf dem Bus-System. Somit laufen Daten und Adressen uber
den gleichen Bus.
Durch diesen Aufbau kann ein Computer nur sequentiell arbeiten. Ein Problem der
bei dieser Architektur entsteht, ist der Von-Neumann-Flaschenhals, produziert durch
einen Engpass zwischen Prozessor und Speicher. Die Verarbeitungsgeschwindigkeit der
CPU ist mit der Zeit deutlich schneller angestiegen, wie die des Bus-Systems oder der
Speicher, welches das Problem des Von-Neumann-Flaschenhals weiter fordert [6, Ka-
pitel 4.3]. Eine Losung fur dieses Problem sind parallel aufgebaute Architekturen.
10 Artur Werner
Stand der Technik
Harvard-Architektur
Die Harvard-Architektur verfolgt den Ansatz einer parallelen Architektur und trennt
physikalisch den Programm- und Datenspeicher. Ebenfalls getrennt ist das Bus-System,
jeder Speicher und E/A-Baustein wird separat angesprochen [6, Kapitel 4.4] (siehe
Abb. 3.4).
Abbildung 3.4: Aufbau einer Harvard-Architektur [6]
Die Harvard-Architektur lost das Problem des Von-Neumann-Flaschenhals und kann
komplett parallel arbeiten. Als Nachteil dieser Architektur ist der große Aufwand fur
die Bus-Systeme zu nennen. Ein weiterer Nachteil, es muss im Voraus bereits festgelegt
werden wie groß der Speicher fur das Programm und die Daten sein sollen. Denn
es ist nicht moglich Daten im Programmspeicher, beziehungsweise Programmteile im
Datenspeicher abzulegen.
Artur Werner 11
Stand der Technik
3.1.2 Befehlssatzarchitekturen
Neben den Speicherarchitekturen gibt es noch weitere Rechnerarchitekturen. Mit dem
Complex Instruction Set Computer (CISC)-Befehlssatz fuhrte IBM in den 1970er Jah-
ren einen Begriff ein um von einem neuen Reduced Instruction Set Computer (RISC)-
Befehlssatz abzugrenzen [8].
CISC-Befehlssatz
Der CISC-Befehlssatz umfasst umfangreiche und komplexe Maschinenbefehle. Ein kom-
plexer Maschinenbefehl setzt sich aus mehreren einfachen Befehlen zu einem Mikropro-
gramm zusammen und kann daher vom Prozessor nicht unmittelbar ausgefuhrt werden.
Das und der relativ langsame Zugriff auf den Programmspeicher, sorgen dafur das die
Maschinenbefehle komplexer werden und CISC-Prozessoren mehrere Takte fur die Ab-
arbeitung eines Befehls benotigen.
CISC-Prozessoren sind die am meisten eingesetzten Prozessoren und konnen mehr als
500 verschiedene Befehle in ihrem Befehlssatz enthalten [6, Kapitel 4.1].
RISC-Befehlssatz
Mit der Entwicklung neuer Prozessoren in den 1970er Jahren, sind neue Befehle in die
Befehlssatze aufgenommen worden. Alte, weniger gebrauchliche Befehle blieben erhal-
ten. Betrachtet man die verwendeten Befehle eines Programmes, ließen sich mit etwa
20 % der Befehle eines CISC-Prozessors circa 80 % eines Programmes abdecken. Das
entspricht der 80-20 Regel des Paretoprinzipes [6, Kapitel 4.2]. Aus diesem und noch
weiteren Grunden liegt der Fokus bei der Entwicklung eines RISC-Prozessors auf den
etwa 20 % wichtigsten Befehlen. Die gewonnene Chipflache der verworfenen restlichen
80 % Befehle wird genutzt, um den RISC-Prozessor mit mehr Cache und weiteren Re-
gistern auszustatten, wodurch dieser schneller wird.
Ein in der Industrie weitverbreiteter Prozessor basiert auf der Advanced RISC Machi-
nes Limited (ARM)-Architektur und sind heute mit dem ARMv8 und ARMDynamiq
in der 8. beziehungsweise 9. Generation [9].
12 Artur Werner
Stand der Technik
3.2 System-on-Chip (SoC)
Mikrocontroller sind Computer, die mit anderen Bausteinen verbunden werden konnen,
um ein anwendungsspezifisches System zu kreieren. Ein SoC realisiert solch ein voll-
standiges System auf einem einzigen Chip [1, Kapitel 3.6.1]. SoCs konnen auf ver-
schiedenen mikroelektronischen Technologien, wie FPGAs und ASICs implementiert
werden.
Manche Systeme sind zu komplex, um diese auf einen Chip zu integrieren. Diese werden
daher in optimierte Subsysteme unterteilt und auf einzelne Chips verlagert.
3.2.1 Intellectual Property Cores
Die meisten SoCs werden mit Hilfe eines sogenannten Intellectual Property Moduls
(IP-Moduls) entwickelt. IP-Module sind wiederverwendbare Hardwarebausteine und
erfullen eine spezielle Aufgabe. Sie sind durch Drittanbieter oder Open-Source-Entwick-
ler verifiziert. Die IP-Module liegen entweder als Soft-IP-Modul oder als Hard-IP-Modul
vor.
Soft-IP-Modul
Soft-IP-Module sind mit einer Hardwarebeschreibungssprache geschrieben und liegen
in einer Bibliothek als quelloffener Text oder als vor synthetisierte Netzliste vor.
Hard-IP-Modul
Hard-IP-Module sind bereits als einzelne Chips oder in sogenannten SoC-FPGAs im
gleichem Siliziumchip des FPGAs integriert.
Bei SoCs gibt es noch weitere Begrifflichkeiten wie:
• System-on-Programmable-Chip (SoPC),
• Programmable-System-on-Chip (PSoC),
• und Multiprocessor-System-on-Chip (MPSoC).
Artur Werner 13
Stand der Technik
3.3 FPGA
Ein FPGA ist ein Chip mit konfigurierbarer Logik. Mit einer Hardwarebeschreibungs-
sprache, die in Kapitel 3.4”VHDL“ vorgestellt wird, kann eine logische Funktion durch
den Entwickler auf den FPGA”programmiert“ werden [10, Kapitel 7.2.3].
Der Aufbau eines FPGAs und die Bezeichnung der Elemente eines FPGAs sind her-
stellerabhangig. Daher wird der Aufbau eines FPGAs an der Cyclone IV Familie von
Altera vorgestellt, da dieser in dieser Arbeit eingesetzt wird (siehe Abb. 3.5).
Abbildung 3.5: Architektur eines Cyclone IV FPGA [11]
Die vertikal angeordneten, konfigurierbaren Logikelemente (LEs) sind die Hauptbe-
standteile eines FPGAs und besitzen nach der Konfiguration die Logik einer Schal-
tung. Die LE werden von Ein-/Ausgabe-Pins (I/O pins), sowie Phasenregelschleifen
(englisch Phase Locked Loop (PLL)) umgeben und werden uber programmierbare Lei-
tungen miteinander verbunden. Der FPGA besteht zusatzlich noch aus Speicher (em-
bedded memory oder Block-RAM), Multiplizierer und Elemente zum Taktmanagment
[11]. Ein LE besteht aus folgenden Eigenschaften; ein programmierbares Register und
einem Look-Up-Table (LUT) mit vier Eingangen, welcher jede mogliche Kombination
aus vier Variablen umsetzen kann [12].
Altera bietet neben der Cyclone-Familie noch weitere Serien mit Stratix, Arria und
MAX an, um FPGAs in verschiedenen Einsatzbereichen bereitzustellen. Neben Altera
sind weitere bekannte FPGA-Hersteller Xilinx, Lattice, Microsemi und Actel am Markt
vertreten.
14 Artur Werner
Stand der Technik
3.4 VHDL
Very High Speed Integrated Circuit Hardware Description Language (VHDL) ist ei-
ne Hardwarebeschreibungssprache mit der die Funktion einer digitalen Schaltung als
algebraisches Modell umgesetzt werden kann [13, Kapitel 4].
3.4.1 Aufbau eines VHDL-Modells
Fur die Beschreibung eines Modells sind zwei Bestandteile notwendig:
• eine entity, entspricht der Schnittstellenbeschreibung, damit Eingange und Aus-
gange definiert sind
• mindestens einer architecture, entspricht der funktionalen Beschreibung, damit
der Ausgang entsprechend einer Rechenvorschrift aus den Eingangssignalen ge-
setzt werden kann
Mit dem nachfolgendem Listing 3.1 soll naher beschrieben werden, wie ein VHDL-
Modell aufgebaut ist. In Zeile 1 wird eine Standard-Bibliothek eingebunden, um den
Datentyp std logic verwenden zu konnen. Dieser Datentyp muss bei der Signalbeschrei-
bung, wie in den Zeilen 6-8, angegeben werden. Mit entity beginnt die Schnittstellenbe-
schreibung eines Modells, hier soll beispielsweise ein UND-Gatter beschrieben werden.
Das Gatter benotigt zwei Eingange, die mit a beziehungsweise b bezeichnet werden.
Die Verknupfung der Eingange wird auf den Ausgang q ausgegeben.
In Zeile 11 befindet sich die architecture des Modells. Zwischen den Zeilen 12-14 erfolgt
die Funktionsbeschreibung des UND-Gatters. Mit einem -- erfolgt ein Kommentar und
sollten wie auch in ublichen Programmiersprachen nicht vernachlassigt werden, denn
sie dienen zum Verstandnis des geschriebenen Programmes.
In dem vorliegendem Beispiel handelt es sich um eine nebenlaufige Signalzuweisung.
Dem Signal q wird mit dem logischen Ausdruck und dem Zuweisungsoperator”<=“
ein Signalwert zugewiesen [13, Kapitel 4.3.3].
Eine andere Moglichkeit Signale auch synchron zu zuweisen, wird in der zweiten ar-
chitecture behave 2 vorgestellt. Zum einen wird in Zeile 19 ein lokales Signal temp
deklariert, auf welches nur innerhalb dieser architecture zugegriffen werden kann. Zum
anderen wird mit Prozessen ein zweites allgemeingultigeres Modellierungskonzept vor-
gestellt [13, Kapitel 7.2].
Artur Werner 15
Stand der Technik
1 library ieee;
2 use ieee.std logic 1164.all;
3
4 entity and gate is −− Beginn entity, and gate = Name des Modells
5 port(
6 a: in std logic; −− Eingang a
7 b: in std logic; −− Eingang b
8 clk: in std logic; −− Eingang Takt
9 q: out std logic); −− Ausgang q
10 end; −− ende entity
11
12 architecture behave of and gate is −− Verhalten von and gate
13 begin
14 q <= a and b; −− Rechenvorschrift
15 end behave;
16
17
18 architecture behave 2 of and gate is
19 signal temp: std logic; −− Deklaration eines lokalen Signals
20 begin
21 output process: process(clk) −− Ausgang Prozess
22 begin
23 if(rising edge(clk)) then −− Abfrage positive Taktflanke
24 temp <= a and b; −− Rechenvorschrift auf lokales Signal
25 q <= temp; −− Ausgabe
26 end if;
27 end process;
28 end behave 2;
Listing 3.1: Beispiel UND-Gatter
In einer architecture konnen mehrere Prozesse parallel arbeiten. Ein Prozess wird aktiv,
wenn sich ein Signal in seiner Sensitivitatsliste andert. Im Listing 3.1 befindet sie
sich in Zeile 21. Der Prozess output process reagiert auf das Eingangssignal clk. Dieser
wechselt seinen Wert von einer logischen 0 auf eine logische 1 und umgekehrt in einer
bestimmten Frequenz. Bei jedem Wechsel wird der Prozess aktiv und fragt in Zeile 23,
ob das Taktsignal einen positiven Flankenwechsel durchfuhrt. Erst dann wird synchron
mit dem Takt, eine logische Operation von a und b durchgefuhrt und das Ergebnis auf
das interne Signal temp geschrieben. Anschließend wird das interne Signal temp auf den
Ausgang q geschaltet. Die Abarbeitung in einem Prozess erfolgt demnach sequentiell.
16 Artur Werner
Stand der Technik
3.4.2 Simulation eines VHDL-Modells
Da die Beschreibung von Hardware-Komponenten nicht fehlerfrei erfolgt, wird ein Test-
verfahren benotigt. Dazu werden sogenannte Testbenches eingesetzt (siehe Abb. 3.6).
Abbildung 3.6: Testbench eines DUTs [13, Kapitel 4.4]
Testbenches sind ebenfalls VHDL-Dateien, besitzen jedoch keine entity, verfugen al-
so uber keine Schnittstelle nach außen. Das Device Under Test (DUT) wird in die
Testbench eingebunden und uber Stimuli-Signale angeregt. Diese Stimuli werden im
architecture Teil der Testbench festgelegt. Das richtige Verhalten des DUTs wird an
den zu erwarteten Ausgangssignalen verifiziert. Die Simulation kann mit einem VHDL-
Simulator wie ModelSim grafisch in einem Zeitdiagramm nachvollzogen werden.
Das Thema Simulation von VHDL-Modellen ist hiermit nur leicht angeschnitten und
dient nur zum grobem Verstandnis. Es gibt zahlreiche Literatur, [10] oder [13] um nur
zwei zu nennen, die auf dieses Thema genauer eingehen.
Artur Werner 17
Analyse und Vergleich bestehender Hardcore- und Softcore-Prozessoren
4 Analyse und Vergleich bestehender
Hardcore- und Softcore-Prozessoren
In diesem Kapitel wird beschrieben wie die Analyse des Marktes, der Vergleich von
Prozessoren und wie die Auswahl fur einen geeigneten Prozessorkern erfolgt. Anschlie-
ßend wird der NEO430 Softcore-Prozessor vorgestellt und auf Unterschiede zu dem
MSP430 hingewiesen.
Begonnen hat die Recherche mit verschiedenen Prozessortypen in Form von Hardcore-
und Softcore-Prozessoren. Erste Anlaufstellen sind Webseiten wie www.github.com,
www.opencores.org, www.mikrocontroller.net, sowie den Webseiten der FPGA-
Hersteller.
Xilinx und Intel(Altera) bieten Hardcore-Prozessoren von ARM mit den aktuellsten
Cortex-Prozessoren an. Mit ihren Zynq-FPGAs bietet Xilinx SoCs an, die Single-
Cortex-A9 Prozessoren bis hin zu Dual-Cortex-R5 und Quad-Cortex-A53 Prozessoren
integrieren [14]. Intel(Altera) verbauen in ihren Cyclone V, Arria V, Arria 10 und Stra-
tix 10 FPGAs, ebenfalls Single-Cortex-A9 Prozessoren und Quad-Cortex-A53 Prozesso-
ren [15]. Es ist nicht verwunderlich das Intel und Xilinx auf die ARM-Prozessoren bau-
en, diese sind namlich weit verbreitete Prozessoren und mit ARM ein industriefuhrender
Lieferant [9].
Artur Werner 19
Analyse und Vergleich bestehender Hardcore- und Softcore-Prozessoren
4.1 Hardcore-Prozessoren in FPGAs
In Abb. 4.1 ist ein SoC auf Basis der Cyclone V Architektur abgebildet. Das Hard Pro-
cessor System (HPS) beinhaltet einen ARM Cortex-A9 Prozessor, sowie zusatzlicher
Schnittstellen und wird auf dem gleichem Siliziumchip des FPGAs integriert.
Abbildung 4.1: Cyclone V SoC Architektur [16]
Da solch ein SoC sehr umfangreich und fur sehr komplexe, große Projekte oder Sys-
teme ausgelegt ist und der Prozessor des HPS nicht in einer minimalen Konfiguration
verwendet werden kann, liegt der weitere Fokus in dieser Arbeit nur noch auf Softco-
re-Prozessoren.
4.2 Kriterien fur die Auswahl eines Softcore-Prozessors
Neben den Anforderungen die in Kapitel 2 vorgestellt sind, sind weitere Kriterien not-
wendig, um Softcore-Prozessoren miteinander vergleichen zu konnen. Die Prozessoren
besitzen verschiedene Eigenschaften und werden in ihren Dokumentationen auf unter-
schiedliche Weise erlautert, wodurch der direkte Vergleich erschwert wird. Die Aus-
wahl der Vergleichskriterien wurde durch ein Paper unterstutzt [17], welches auf der
24. Internationalen”Field Programmable Logic and Applications (FPL)“ Konferenz
veroffentlicht wurde.
In diesem Paper hat eine Gruppe von Ingenieuren, uber 180 Open-Source-Prozessoren
untersucht und Prinzipien vorgestellt, um einen geeigneten Softcore-Prozessor aus-
zuwahlen. Von den 180 sind 68 Softcore-Prozessoren aufgefuhrt, aus welchen sieben
20 Artur Werner
Analyse und Vergleich bestehender Hardcore- und Softcore-Prozessoren
Open-Source-Prozessoren ausgewahlt wurden und auf einer Altera-FPGA-, sowie Xilinx-
FPGA-Plattform implementiert und mit den Softcore-Prozessoren NIOS II und Mi-
croBlaze verglichen. Die dort aufgefuhrten wichtigsten Kriterien fur einen Vergleich
sind:
• Art der Lizenzierung,
• Befehlssatzarchitektur (ISA),
• Compiler & Assembler,
• FPGA & ASIC Verifikation,
• sowie Dokumentation.
Die Kriterien sind nach ihrer Prioritat sortiert und sorgten unmittelbar dafur, welche
Prozessoren ausgeschlossen und welche fur die weitere Untersuchung beibehalten wor-
den sind.
Fur diese Arbeit wurden die oben genannten Vergleichskriterien, durch folgende Kri-
terien erweitert:
• Hardwarebeschreibungssprache des Softcores,
• Wortbreite des Prozessors,
• Schnittstelle fur Erweiterbarkeit,
• und Verfugbarkeit als Open-Source.
4.2.1 Ergebnis einer ersten Auswahl in Frage kommender
Softcore-Prozessoren
Die meisten analysierten Open-Source-Prozessoren sind auf der Internetplattform www.
opencores.org aufgefuhrt und werden dort bereits in verschiedenen Entwicklungs-
stadien angegeben. Die Projekte der Prozessoren durchlaufen die sechs Stufen, Pla-
nung, Pre-Alpha, Alpha, Beta, Stabil und Ausgereift. Alle Prozessoren die sich vor der
Stabilen Entwicklungsstufe befinden, sind fur einen weiteren Vergleich nicht relevant.
Das erleichtert die Untersuchung der verbleibenden Prozessoren und die Ubersicht ist
gewahrleistet.
Prozessoren die sich bereits im Stabilen Entwicklungsstadium befinden, beinhalten alle
vorgesehen Funktionen, enthalten eventuell kleine Bugs, sind aber zuverlassig einsetz-
bar.
Bei weiteren Quellen fur Softcore-Prozessoren ist nicht notwendigerweise der Ent-
wicklungsstatus angegeben oder keine Dokumentation vorhanden, weshalb diese nicht
Artur Werner 21
Analyse und Vergleich bestehender Hardcore- und Softcore-Prozessoren
naher betrachtet wurden und schwerer zu bewerten sind. Mit allen hier genannten
Aspekten, wurden 36 Softcore-Prozessoren in dieser Arbeit verglichen und in einer
Ubersichtstabelle (siehe Tabelle 4.1) festgehalten.
Tabelle 4.1: Ubersichtstabelle der Softcore-Prozessoren
22 Artur Werner
Analyse und Vergleich bestehender Hardcore- und Softcore-Prozessoren
Eine wichtige Kategorie die aus der Tabelle 4.1 zu entnehmen ist, ist die Lizenz. Mi-
croBlaze, PicoBlaze, Nios II und der Cortex-M1 stehen unter einer zahlungspflichtigen
Lizenz. Mit Proprietary (deutsch: firmeneigen, geschutzt) sind diese Prozessoren Ei-
gentum der jeweiligen Firma.
Fur Open-Source-Projekte stehen verschiedene Open-Source-Lizenzen zur Verfugung.
Die bekanntesten und auch in dieser Tabelle vorzufinden sind:
• General Public License (GPL)
• Lesser General Public License (LGPL)
• Massachusetts Institute of Technology (MIT)
• Berkeley Software Distribution (BSD)
Die GPL-Lizenz gibt vor, wenn ein unter der GPL-lizenziertes Werk vertrieben wird,
diese nur unter der gleichen Lizenz vertrieben werden darf [18]. Die LGPL-Lizenz lost
diese Einschrankung [19]. Die MIT-Lizenz [20] und BSD-Lizenz [21] gehoren zu den
Freizugigen Open-Source-Lizenzen, mit denen eine Wiederverwertung von lizenzierten
Inhalten erlaubt wird. All die genannten Lizenzen erlauben es, Software auszufuhren,
zu studieren, zu andern und zu verbreiten.
Bei der Compiler & Assembler Kategorie ist mit der GNU Compiler Collection (GCC)
eine Compilersammlung gegeben, die in der Lage ist mehrere Programmiersprachen zu
ubersetzen [22] und wird daher von den meisten Prozessoren benutzt.
Das letzte wichtige Kriterium ist die Schnittstellen Kategorie. Hier sind zum einen
Advanced Microcontroller Bus Architecture (AMBA), zum anderen Wishbone vor-
zufinden. Beide definieren detailliert, wie eine Kommunikation zwischen Modulen zu
erfolgen hat. AMBA ist eine Spezifikation von ARM und wird unter anderem mit
ARM-Prozessoren genutzt [9]. Wishbone hingegen ist eine Open-Source-Spezifikation
und wurde durch opencores.org erstellt [23].
Wie man in der Tabelle 4.1 erkennen kann, sind die einzelnen Prozessoren farblich ko-
diert. Die Kodierung soll die Auswahl visuell unterstutzen. Rot markierte haben zwei
oder mehr Unstimmigkeiten, gelb markierte eine und grune keine Unstimmigkeit mit
den Kriterien. Die grun markierten, sind Prozessoren mit denen ohne weitere Bedenken
ein System aufgebaut werden kann.
An der Tabelle 4.1 wird ersichtlich, dass einige Prozessoren rot markiert sind. Wie zum
Beispiel den miniMIPS Softcore-Prozessor mit der Nummer 16 gelistet. An diesem, so-
wie an weiteren rot markierten Prozessoren, fehlen wichtige Angaben bezuglich Archi-
tektur, Schnittstelle oder Lizenz. Ohne eine vorhandene beziehungsweise ausfuhrliche
Dokumentation konnen notwendige Informationen nicht sichergestellt und verifiziert
werden.
Artur Werner 23
Analyse und Vergleich bestehender Hardcore- und Softcore-Prozessoren
4.2.2 Detaillierter Vergleich vorausgewahlter Softcore-Prozessoren
Die grun markierten Prozessoren LEON3, LatticeMico32, LatticeMico8 und NEO430
aus der Tabelle 4.1 finden sich in einer detaillierten Ubersichtstabelle (siehe Tabelle 4.2)
wieder, um von denen einen geeigneten Prozessor auszuwahlen. Die Tabelle beinhaltet
zusatzliche Informationen, bezuglich weiteren Eigenschaften mit denen der Prozessor
ausgestattet ist und genaueren Kenndaten.
Beginnend mit der Befehlssatz-Architektur, verwenden der LEON3 und LatticeMico32
(LM32) die RISC-Architektur, der NEO430 hingegen eine CISC-Architektur. Der Lat-
ticeMico8 (LM8) verwendet eine Custom-Architektur mit circa 50 Befehlen und ahnelt
daher einem CISC-Befehlssatz.
Der LEON3 und LM32 sind 32-Bit Prozessoren, der NEO430 ein 16-Bit Prozessor und
der LM8 ein 8-Bit Prozessor.
Mit einem Multiplizierer, sowie Dividierer sind der LEON3 und LM32 ausgestattet,
der LEON3 besitzt zusatzlich noch eine Floating Point Unit (FPU). Uber einen Cache
verfugen der LEON3 und LM32. Fur den LM8 gibt es keine Angabe in der Dokumen-
tation, das heißt es wird davon ausgegangen, dass der LM8, sowie der NEO430 keinen
Cache nutzen.
Wahrend der NEO430 216 Adressen im Speicher ansprechen kann, konnen die anderen
drei bis zu 232 Adressen ansprechen.
Zu guter Letzt besitzt jeder Prozessor, uber die gangigste Peripherie. Hier ergeben sich
nur kleine Unterschiede, wie zum Beispiel bei den verfugbaren Interrupt Kanalen.
Die Entscheidung, welcher Prozessor ausgewahlt werden soll, ist ganz davon abhangig,
welche Anwendung, beziehungsweise welches System entwickelt werden soll.
Der LEON3 und LM32 verfugen uber jede mogliche Hardware-Komponenten und
konnen daher sehr allgemein eingesetzt werden. Fur eine Low-Power-Anwendung je-
doch ungeeignet, da diese 32-Bit Prozessoren sind und dadurch mehr Energie ver-
brauchen. Der LM8 ist wie der kleine Bruder des LM32 und schon eher geeignet. Die
drei genannten Softcore-Prozessoren erfullen jedoch die Anforderung nicht, auf einer
bekannten Prozessor-Architektur zu basieren. Der NEO430 ist hier eher ein Nischen-
Prozessor. Mit einer Wortbreite von 16-Bit konnte dieser fur Anwendungen mit 32-
und/oder 8-Bit Werten eingesetzt werden. Der relativ kleine Speicher von 64 kByte
sollte fur Anwendungen in Low-Power-Systeme ausreichen.
24 Artur Werner
Analyse und Vergleich bestehender Hardcore- und Softcore-Prozessoren
Tabelle 4.2: Detaillierte Ubersicht vorausgewahlter Softcore-Prozessoren
Artur Werner 25
Analyse und Vergleich bestehender Hardcore- und Softcore-Prozessoren
4.3 Auswahl eines Prozessorkerns fur die
Implementierung eines Demonstrators
Die Entscheidung fur einen Prozessor fiel in dieser Arbeit auf den NEO430. Die Tat-
sache, dass dieser Prozessor auf der MSP430-Architektur basiert, machte ihn fur die
Nutzung und Untersuchung, beziehungsweise welche Moglichkeiten der NEO430 bietet,
sehr interessant.
4.3.1 Vorstellung des NEO430 Softcore-Prozessors
Der NEO430 verfugt uber Standard-Komponenten, wie Timer, einen Watchdog-Timer
(WDT), einer Wishbone-Schnittstelle (WB32), sowie USART-Schnittstelle, GPIOs,
einen internen Bootloader und internen Speicher fur Programm Code und Daten.
Optionale, bereits vorhandene Module sind in Abbildung 4.2 mit einer gestrichelten
Umrandung dargestellt. Diese konnen weggelassen werden, um die Große des Systems
zu minimieren und Ressourcen zu sparen. Das erfolgt uber die Generic-Konfiguration
im Top-Level-Design der VHDL-Code-Implementierung.
Die Wishbone-Schnittstelle ermoglicht die Anbindung von zusatzlicher Hardware, wo-
durch ein System optimal an die Anforderung angepasst werden kann.
Der NEO430 ist kein MSP430 Klon. Er wurde von Stephan Nolting, dem Entwickler
des NEO430 Projektes, komplett neu entwickelt [24]. Ein Vorteil ist, das es moglich
ist den msp430-gcc Compiler von Texas Instruments (TI) zu verwenden, um damit die
Software-Entwicklung des NEO430 durchzufuhren.
Die bereitgestellten Dateien (VHDL-Source-Code, Dokumentation, Programmierdatei-
en) sind so aufgebaut, dass der NEO430 sofort mit einem Test-Setup auf einen FPGA
geladen und die verschiedenen Fahigkeiten des NEO430 evaluiert werden konnen.
Die Generierung des C-Programmes erfolgt uber ein einziges”make“ Kommando und
ermoglicht schnelle Anderungen des Programmes.
Abbildung 4.2: Architektur NEO430 [24]
26 Artur Werner
Analyse und Vergleich bestehender Hardcore- und Softcore-Prozessoren
Der Speicher wird zwar durch einen Programmspeicher (IMEM) und Datenspeicher
(DMEM) getrennt, ist aber wie in der folgenden Abbildung 4.3 zu sehen, adressiert.
Das bedeutet, dass der NEO430 ein auf der Von-Neumann-Architektur basierendes
System ist.
In Kontrast zu den originalen MSP430, hat der NEO430 kein Spezial-Funktionsregister
zu Beginn des Speichers, sondern alle speziellen Funktionen, wie Schnittstellen und In-
put/Output (IO)-Gerate sind im Speicherbereich IO Devices am Ende des adressierten
Speichers angesiedelt.
Wie man in der Abbildung 4.3 sieht, kann der IMEM maximal 32 kB und der DMEM
28 kB Speicher umfassen. Es ist moglich zusatzlichen Speicher uber die Wishbone-
Schnittstelle anzubinden, jedoch keinen Code von diesem auszufuhren.
Abbildung 4.3: Speicheradressierung des NEO430 [24]
An der Adresse 0xF000 im Bootloader ROM befindet sich das Programm des Boot-
loaders. Dieser ist sehr nutzlich und eignet sich optimal in der Evaluationsphase eines
Programm-Tests, da das Programm jederzeit uber die Universal Asynchronous Recei-
ver Transmitter (UART)-Schnittstelle hochgeladen werden kann. Des Weiteren bietet
der Bootloader eine automatische Boot-Konfiguration, welches das automatische Boo-
ten aus einem uber die Serial Peripheral Interface (SPI)-Schnittstelle angebundenen
EEPROM ermoglicht. Mit dem EEPROM wird die Integration eines nichtfluchtigen
Programmspeichers ermoglicht.
Fur ein fortgeschrittenes System ist der Bootloader womoglich nicht weiter erwunscht
und kann uber die Generic-Konfiguration aus dem Design entfernt werden. In diesem
Fall wird das System aus dem IMEM bei der Adresse 0x0000 gestartet.
Artur Werner 27
Analyse und Vergleich bestehender Hardcore- und Softcore-Prozessoren
4.3.2 Unterschiede des NEO430 zum MSP430 Mikrocontroller
Da der NEO430 kein MSP430 Klon ist, sind diverse Unterschiede mit der MSP430
Produktlinie von TI vorhanden. Die wesentlichen Unterschiede sind [24]:
• Komplett unterschiedlich implementierte Prozessormodule, mit unterschiedlicher
Funktionalitat.
• Kein Hardware Multiplizierer.
• Speziell angepasste Speicheradressierung, benotigt das NEO430 Linker und Com-
piler Skript.
• Nur 4 CPU-Interrupt-Kanale (anstatt von 16 des MSP430).
• Eine Taktdomane fur den kompletten Prozessor.
• CISC-ahnliche Befehle.
• Ein Energiesparmodus, Schlaf-Modus.
• Wishbone-kompatible Schnittstelle zur Anbindung von IP-Modulen.
• Internen Bootloader mit Text Interface (uber UART).
Die Unterschiede sollen nicht von der Nutzung des NEO430 abschrecken und sind auch
nicht direkt als”negative“ oder
”positive“ Attribute anzusehen. Zum Beispiel, bedeutet
der fehlende Hardware-Multiplizierer nicht, dass der NEO430 keine Multiplikationen
durchfuhren kann, sondern er ist in der Lage diese per Software durchzufuhren, welche
lediglich mehr Taktzyklen benotigt als es eine optimierte Hardware wurde.
Oder das der NEO430 nur 4 Interrupt-Kanale anstatt der 16 eines MSP430 besitzt. Es
besteht die Moglichkeit weitere Interrupts zu integrieren, wenn ein Interrupt-Controller
an Wishbone angebunden wird.
Mit der Wishbone-kompatiblen Schnittstelle ist es moglich, eine Anwendung an ihre
Anforderung anzupassen. Dies ist mit einem gangigen MSP430 nur bedingt moglich.
Entweder sind bei einem MSP430-Modell zu wenige Komponenten vorhanden und muss
auf das nachst großere Modell umsteigen oder es sind uberschussige Komponenten vor-
handen, welche unter Umstanden unnotig mehr Platz verbrauchen.
Neben den bereits genannten Unterschieden, gibt es noch weitere, mit denen ein MSP430-
Mikrocontroller von TI angeboten wird.
28 Artur Werner
Analyse und Vergleich bestehender Hardcore- und Softcore-Prozessoren
Abbildung 4.4: Auswahl MSP430-Peripherie [25]
Mit dieser Grafik in Abbildung 4.4 ermoglicht TI Entwicklern, sich uber die einzel-
nen Schnittstellen zu erkundigen und einen passenden Mikrocontroller auszusuchen.
Wird ein Mikrocontroller mit FRAM-Technologie, Komparatoren, Verstarker, sowie
Analog-Digital-Converter (ADC) und Digital-Analog-Converter (DAC) benotigt, wird
anschließend eine Ubersicht uber vorhandene Mikrocontroller aufgelistet, die nach den
eingegeben Parametern sortiert wird.
Der Entwickler ist somit in der Lage einen geeigneten Mikrocontroller auszusuchen. Die-
ser ist jedoch nicht optimal fur ein Low-Power-System ausgelegt, da unnotige Hardware-
Komponenten nicht weggelassen werden konnen. Dadurch entsteht erhohter Platz- und
Energiebedarf des Mikrocontrollers.
Mit dem NEO430 und der Wishbone-Schnittstelle, kann jedes beliebige und notwendige
IP-Modul angebunden werden. Dadurch kann jedes System optimal an die Anforde-
rung der Anwendung angepasst werden.
Das ist besonders wichtig, wenn aus diesem System ein ASIC erstellt werden soll,
der fur Low-Power-Anwendungen vorgesehen ist. Jede unnotige Hardware-Komponente
verbraucht Energie, sowie zusatzliche Chipflache. Wenn dies eingespart werden kann,
ist dies fur den Einsatz in einem Low-Power-System umso besser und es konnen mehr
Funktionen in einen einzelnen SoC untergebracht werden.
Artur Werner 29
Konzept und Implementierung eines Demonstrator-Systems
5 Konzept und Implementierung eines
Demonstrator-Systems
In diesem Kapitel wird auf den Aufbau des Demonstrator-Systems, die Implementie-
rung des NEO430, der Wishbone-Schnittstelle, des CRC-Moduls, dem FIFO-Modul
und die Programmierung eines Programms fur den NEO430 eingegangen.
5.1 Aufbau des Demonstrator-Systems
Die bereitgestellten Open-Source-Dateien fur den NEO430-Prozessor (VHDL-Code,
Dokumentation, Programmierdateien usw) sind so aufgebaut, dass dieser sofort mit
einem Test-Setup auf einen FPGA geladen und die verschiedenen Fahigkeiten ausge-
testet werden konnen (siehe Abb. 5.1) [24, Kapitel 4].
Abbildung 5.1: Hardware Konfiguration fur NEO430-Test-Implementation [24]
Artur Werner 31
Konzept und Implementierung eines Demonstrator-Systems
Dieser Aufbau implementiert die Standard-Einstellung des NEO430. Das umfasst GPIOs,
Timer und Watchdog-Timer, USART- und Wishbone-Schnittstelle, sowie 4 kB
Programm- und 2 kB Datenspeicher und 2kB Boot Read-Only Memory (ROM) fur
den Bootloader.
Fur den Test-Setup wird ein low-aktiver Reset (Taster), eine Taktdomane, 8 LEDs und
ein Computer mit UART-Schnittstelle benotigt.
Im ersten Schritt wird ein neues Projekt in der Entwicklungsumgebung des genutzten
FPGAs angelegt. Bei einem FPGA von Intel (Altera) ist es die Quartus Entwick-
lungsumgebung. Als nachstes wird in der neo430 top.vhd Datei die Generics fur die
Standard-Einstellung festgelegt. Anschließend mussen die Ein- und Ausgangssignale
der neo430 top.vhd Datei an die Pins des FPGAs zugeordnet werden. Im letzten Schritt
wird die HDL-Kompilierung durchgefuhrt und der generierte Bitstream kann auf den
FPGA geladen werden.
In diesem Test-Setup wird nun eine Light Emitting Diode (LED) blinken und verdeut-
licht dadurch den Status des Bootloaders. Mit einem UART-Terminal-Programm wird
das Text-Interface des Bootloaders sichtbar. Nach acht Sekunden (einstellbar) startet
der Bootloader das Programm. Die Anwendung fuhrt nun ein Lauflicht aus und lasst
die LEDs in einem 2-Hz-Takt nacheinander aufleuchten.
Die gewonnenen Kenntnisse des Test-Setup werden genutzt, um ein Beispielprojekt
(siehe Abb. 5.2) zu entwickeln. Dazu wird ein selbst entwickeltes CRC-Modul uber die
Wishbone-Schnittstelle angebunden. Uber die UART-Schnittstelle und dem Terminal-
Programm wird eine 4 Byte große Information, bestehend aus 2 Byte Daten und 2 Byte
CRC, gesendet. Das Programm erhalt diese Information und gibt diese an das Wishbo-
ne angebundene CRC-Modul weiter. Das CRC-Modul uberpruft, ob die empfangenen
2 Byte CRC vom Word mit dem eigens berechneten CRC ubereinstimmt. Wenn das
der Fall ist, werden die empfangenen 2 Byte Daten an 8 LEDs ausgegeben. Die LEDs
dienen zur visuellen Uberprufung der empfangenen Daten.
Abbildung 5.2: Aufbau Demonstrator-System
Zur Evaluierung des Aufwands bereits bestehende IP-Module uber Wishbone anzubin-
den, wird eine weitere Anwendung entwickelt die ein frei verfugbares First-In-First-Out
(FIFO)-Modul implementiert.
32 Artur Werner
Konzept und Implementierung eines Demonstrator-Systems
Wie auch das FIFO-Modul, ist nicht jedes frei verfugbare IP-Modul mit einer Wishbone-
Schnittstelle implementiert. Im ersten Schritt muss die Wishbone-Slave-Anbindung im-
plementiert werden, um anschließend an den NEO430 angebunden werden zu konnen.
Die Anwendung mit dem FIFO-Modul, soll 2 Byte große Daten uber die UART-
Schnittstelle empfangen, in der FIFO abspeichern und bei Anfrage auf LEDs aus-
geben.
5.2 Implementierung des Softcores NEO430
Die Quelldaten fur den NEO430 stehen unter der LGPL-Lizenz und konnen daher frei
genutzt, verandert und weiter vertrieben werden, solange dieses Copyright nicht ent-
fernt und Ableitungen dieses Projektes mit dem originalen Copyright versehen sind.
Die Verteilung ist ohne Garantie auf Funktion des Prozessors und daher ist es wichtig,
zumindest im Groben einen Uberblick und ein gewisses Verstandnis fur den Aufbau
des NEO430 zu erhalten.
Der grobe Aufbau und die einzelnen Modulen wurde bereits im Kapitel 4.3.1 kurz an-
geschnitten. In den folgenden Kapiteln wird auf die nahere Funktion eingegangen. Wie
die Kommunikation zwischen CPU und den Modulen erfolgt, wird mit den nachfolgen-
den drei Abbildungen 5.4, 5.5 und 5.6 erklart. Das Top-Level-Design des NEO430 sieht
wie folgt aus (siehe Abb. 5.3).
Eingangsseitig befinden sich:
• Takt (clk i),
• Reset (rst i),
• externer Interrupt (irq i),
• 16 parallele GPIO-Eingange (gpio i),
• UART-”Receive Data“ (uart rxd i),
• SPI-”Master Input, Slave Output“ (spi miso i),
• 32-Bit Wishbone Daten Eingang (wb dat i),
• Wishbone Acknowledge (wb ack i).
Signale die vom NEO430 herausgefuhrt werden sind:
• 16 parallele GPIO-Ausgange (gpio o),
• UART-”Transmit Data“ (uart txd o),
• SPI Schnittstelle mit:
– SPI Takt (spi sclk o),
Artur Werner 33
Konzept und Implementierung eines Demonstrator-Systems
– SPI-”Master Output, Slave Input“ (spi mosi o),
– SPI Chipselect (spi cs o)
• und das Wishbone Interface mit:
– 32-Bit Adresse (wb addr o),
– 32-Bit Daten (wb dat o),
– Write Enable (wb we o),
– 4-Bit Daten Select (wb sel o),
– Strobe (wb stb o),
– Cycle (wb cyc o).
Abbildung 5.3: Top-Level-Modul NEO430
34 Artur Werner
Konzept und Implementierung eines Demonstrator-Systems
1 component neo430 wb interface
2 port (
3 −− host access −−4 clk i : in std ulogic; −− global clock line
5 rden i : in std ulogic; −− read enable
6 wren i : in std ulogic vector(01 downto 0); −− write enable
7 addr i : in std ulogic vector(15 downto 0); −− address
8 data i : in std ulogic vector(15 downto 0); −− data in
9 data o : out std ulogic vector(15 downto 0); −− data out
10 −− wishbone interface −−11 wb adr o : out std ulogic vector(31 downto 0); −− address
12 wb dat i : in std ulogic vector(31 downto 0); −− read data
13 wb dat o : out std ulogic vector(31 downto 0); −− write data
14 wb we o : out std ulogic; −− read/write
15 wb sel o : out std ulogic vector(03 downto 0); −− byte enable
16 wb stb o : out std ulogic; −− strobe
17 wb cyc o : out std ulogic; −− valid cycle
18 wb ack i : in std ulogic −− transfer acknowledge
19 );
20 end component;
Listing 5.1: Komponenten Deklaration
In der neo430 package .vhd Datei, welche von der neo430 top .vhd inkludiert wird, wer-
den die einzelnen Module mit dem component Stichwort deklariert (siehe Listing 5.1,
Zeile 1). Anschließend kann das Modul neo430 wb interface inkludiert werden (siehe
Listing 5.2, Zeile 1).
Hier wird dem Modul die Bezeichnung neo430 wb32 inst (Zeile 1) gegeben.
In der port map (ab Zeile 2) erfolgt die Signalzuweisung von internen Signalen an die
Ein- und Ausgange des Moduls. Das erfolgt, beispielsweise in Zeile 7 mit dem Zuwei-
sungsoperator (=>). Dem Eingang addr i wird das Signal vom internen CPU-Bus,
cpu bus.addr zugewiesen.
Der interne CPU-Bus besteht aus funf Signalen und wird mit dem Konstrukt record
zusammengefuhrt. In Listing 5.3 wird gezeigt, wie dieser angewendet wird. Der Befehl
record ahnelt dem Befehl struct von der Programmiersprache C und wird in VHDL
genutzt um entities und port maps zu vereinfachen, sowie verschiedene Datentypen,
wie std ulogic, std ulogic vector, boolean, integer, et cetera zusammenzufuhren.
Diese Vorgehensweise, also Deklaration der Komponente und Instanziierung wird in
der Datei neo430 top.vhd fur alle erforderlichen Module fortgefuhrt. Als Ergebnis erhalt
man ein Top-Level-Design, welches die verschiedenen vorgestellten Module (Kapitel 4.3.1)
mit internen Signalen verbindet, Module untereinander verbindet und die Ein- und
Ausgangssignale verschaltet (siehe Abb. 5.4, 5.5, 5.6).
Artur Werner 35
Konzept und Implementierung eines Demonstrator-Systems
1 neo430 wb32 inst: neo430 wb interface
2 port map (
3 −− host access −−4 clk i => clk i, −− global clock line
5 rden i => io rd en, −− read enable
6 wren i => io wr en, −− write enable
7 addr i => cpu bus.addr, −− address
8 data i => cpu bus.wdata, −− data in
9 data o => wb rdata, −− data out
10 −− wishbone interface −−11 wb adr o => wb adr o, −− address
12 wb dat i => wb dat i, −− read data
13 wb dat o => wb dat o, −− write data
14 wb we o => wb we o, −− read/write
15 wb sel o => wb sel o, −− byte enable
16 wb stb o => wb stb o, −− strobe
17 wb cyc o => wb cyc o, −− valid cycle
18 wb ack i => wb ack i −− transfer acknowledge
19 );
20 end generate;
Listing 5.2: Komponenten Inkludierung
1 type cpu bus t is record
2 rd en : std ulogic;
3 wr en : std ulogic vector(01 downto 0);
4 addr : std ulogic vector(15 downto 0);
5 rdata : std ulogic vector(15 downto 0);
6 wdata : std ulogic vector(15 downto 0);
7 end record;
Listing 5.3: Konstrukt record
Aus den Abbildung 5.2, 5.3 und 5.4 wird ersichtlich das der NEO430 nach der Von-
Neumann-Architektur (Kapitel 3.1.1) aufgebaut ist. Jedes Modul ist an den CPU-Bus
angeschlossen, uber dem Informationen wie Adresse und Daten laufen. In Abbildung 5.5
sieht man, dass die Module neo430 usart, neo430 gpio und neo430 timer jeweils einen
Interrupt auslosen konnen. Ein Interrupt-System legt nach einer Prioritat fest, welcher
Interrupt zuerst von der CPU bearbeitet wird.
Alle Module verarbeiten Eingangssignale mit Prozessen (siehe Listing 3.1 Zeile 21,
Kapitel 3.4.1) und werden fur das weitere Verstandnis nicht weiter betrachtet. Lediglich
das Modul neo430 cpu wird im folgenden Kapitel 5.2.1 naher vorgestellt.
36 Artur Werner
Konzept und Implementierung eines Demonstrator-Systems
Abbildung 5.4: Interne Verschaltung Top-Level Design Teil 1
Artur Werner 37
Konzept und Implementierung eines Demonstrator-Systems
Abbildung 5.5: Interne Verschaltung Top-Level Design Teil 2
38 Artur Werner
Konzept und Implementierung eines Demonstrator-Systems
Abbildung 5.6: Interne Verschaltung Top-Level Design Teil 3
Artur Werner 39
Konzept und Implementierung eines Demonstrator-Systems
5.2.1 Das CPU-Modul des NEO430
Das Herzstuck des NEO430 befindet sich hinter dem Modul neo430 cpu. Bestehend
aus vier weiteren Modulen (siehe Abb. 5.7), werden hier die Signale fur den CPU-Bus
generiert.
Abbildung 5.7: Aufbau Modul NEO430 CPU
40 Artur Werner
Konzept und Implementierung eines Demonstrator-Systems
neo430 control
Hinter diesem Modul befindet sich die Zustandsmaschine des NEO430. Aufgeteilt in
sieben Hauptzustande
• Reset
• Fetch
• Decode
• Trans
• Pushcall
• RETI
• IRQ
arbeitet die Zustandsmaschine mit mehreren Teilzustanden und umfasst damit insge-
samt 28 Zustande. Der wichtigste Zustand Reset, initialisiert die Boot-Adresse und
setzt das komplette System in einen definierten Zustand. Im Fetch Zustand, wird der
nachste Befehl geholt, auf Interrupts uberpruft, den Program Counter (PC) aktuali-
siert und in den Decode Zustand gewechselt, in welchem ein Befehl ausgefuhrt wird.
Der Trans Zustand unterteilt sich in neun Teilzustanden und ist im wesentlichen fur
den Transfer der zu bearbeitenden Daten zustandig. Im Pushcall Zustand wird ein
Stack generiert, damit der aktuelle Zustand im Speicher abgelegt wird und ein Interrupt
bearbeitet werden kann. Mit dem RETI Zustand wird von der Interruptverarbeitung
zuruckgekehrt, der Stack aufgelost und der alte Zustand vor dem Interrupt wiederher-
gestellt. Der letzte Zustand IRQ verarbeitet einen Interrupt.
neo430 addr gen
Hier erfolgt die Adressen-Berechnung und das Adressen-Register befindet sich in die-
sem Modul.
neo430 alu
Die Arithmetic Logic Unit (ALU) berechnet arithmetische und logische Funktionen.
neo430 reg file
In diesem Modul befinden sich der Program Counter (PC), generelle Daten- und Sta-
tusregister.
Artur Werner 41
Konzept und Implementierung eines Demonstrator-Systems
5.2.2 Interrupts
Der NEO430 besitzt 4 unabhangige Interrupt-Kanale (siehe Tabelle 5.1).
IRQ Name Prioritat Quelle
IRQVEC Timer 1 (hochste) Timer generiert Interrupt,
wenn Schwellwert erreicht wird
IRQVEC USART 2 UART Rx verfugbar oder
UART Tx abgeschlossen oder
SPI Ubertragung abgeschlossen
IRQVEC GPIO 3 GPIO Pin Anderung
IRQVEC EXT 4 (niedrigste) Externe Interrupt Anfrage
Tabelle 5.1: Bezeichnung der vier Interrupts [24]
Der Timer hat die hochste Prioritat und der externe Interrupt die niedrigste. Treffen
mehrere Interrupts auf, werden diese nach ihrer Prioritat in eine Warteschlange einge-
reiht.
Wenn mehr Interrupts benotigt werden, kann ein selbst erstellter Interrupt-Controller
mit dem Wishbone-Bus verbunden werden. Dieser regelt und verwaltet alle an ihm
auftretenden Interrupts und triggert den externen Interrupt Kanal (IRQVEC EX) des
NEO430.
5.2.3 GPIO
Der parallele GPIO-Controller bietet ein einfachen 16-Bit parallelen Eingangs- und
Ausgangsport [24]. Sie konnen sowohl außerhalb des Chips LEDs treiben, als auch in-
tern fur Kontrollsignale verwendet werden.
Der Eingangsport verfugt uber einen globalen Interrupt, der auf vier verschiedene Pe-
gelanderungen: Low-Level, High-Level, fallende Flanke und steigende Flanke reagiert.
Auf welche Pegelanderung reagiert werden soll wird im GPIO CTRL Register an der
Adresse 0xFFB4 festgelegt.
42 Artur Werner
Konzept und Implementierung eines Demonstrator-Systems
5.2.4 USART
Der USART ist eine Standard serielle Schnittstelle fur Chip-externe Kommunikation
[24]. Implementiert werden zwei Untermodule
• UART Modul
• SPI Modul.
Das USART-Modul liefert einen Interrupt-Ausgang und reagiert wie in Kapitel 5.2.2
beschrieben. Das Berechnen der jeweiligen Baudraten ist nicht notwendig und wird
mittels einer Funktion aus der neo430 usart.c Datei durchgefuhrt.
Das UART-Modul kommuniziert nach der Standard-Konfiguration mit 8 Datenbits, 1
Stopbit und keinem Parity Bit. Diese Einstellung ist fix und muss auf der Gegenseite
entsprechend eingestellt sein. Das SPI-Modul ist ebenfalls auf einen 8-Bit Datentrans-
fer festgelegt.
In der Header-Datei neo430 usart.h befinden sich zahlreiche Funktionen fur die Da-
tenubertragung uber UART oder SPI.
5.2.5 Timer
Ein Timer wird in jeder Echtzeit abhangiger Anwendung benotigt und wird im NEO430
Standardmaßig synthetisiert. Der Timer-Interrupt wird immer in einem bestimmten
Zeitintervall ausgelost. Dieses Intervall wird mit Prescaler Bits im Kontrollregister
TMR CT gesetzt. Das Zeitintervall wird aus dem Haupttakt, Prescaler und Tick-
Frequenz
tthresh =fmain
ftick ∗ PRSC
berechnet.
5.2.6 Watchdog-Timer
Der Watchdog-Timer ist dazu da, um den Prozessor zu uberwachen und diesen vor
einer Fehlfunktion wie zum Beispiel einem Softwareversagen zu bewahren. Dazu muss
die Software dem Watchdog-Timer standig mitteilen, dessen Zahler zuruckzusetzen. Ist
das nicht der Fall und der Zahler erreicht seinen Maximalwert, wird ein System-Reset
durchgefuhrt [24].
Artur Werner 43
Konzept und Implementierung eines Demonstrator-Systems
5.3 Wishbone
Die Wishbone-Kommunikationsschnittstelle ist eine SoC-Interconnection-Architektur
fur IP-Module [23]. Der Nutzen dieser Architektur findet sich in der Design-Wiederver-
wendung von IP-Modulen, sowie einer standardisierten Integration und Kommunikati-
on zwischen mehreren IP-Modulen auf einem SoC wieder.
Bevor diese Spezifikation erstellt wurde, war es schwer verschiedene nicht-standardisierte
IP-Module miteinander zu verbinden und auf einen Chip zu integrieren. Hinzu kommt
die Tatsache, dass es an einer gelaufigen Schnittstellen-Spezifikation mangelte, mit der
es moglich war große Projekte zu entwickeln. Dies waren zwei der drei großen Beweg-
grunde fur die Entstehung der Wishbone-Spezifikation.
Der Wishbone zeichnet sich durch folgende Merkmale aus:
• Einfacher, kompakter, logischer IP-Modul fur Hardware-Schnittstellen, mit ge-
ringem Verbrauch an Logikgatter
• Unterstutzt strukturierte Design-Methoden fur große Projekte
• Beliebte Datentransfer Bus-Protokolle wie:
– READ/WRITE cycle
– BLOCK transfer cycle
– Read-Modify-Write (RMW) cycle
• Unterstutzt Big Endian und Little Endian
• Variable Modul Verbindungsmethoden wie
– Point-to-point
– Shared bus
– Crossbar switch
– Data flow interconnection
– Off chip
• Handshaking Protokoll
• Datentransfer
• Synchrones Design
• Einfache Zeitspezifikation
Weitere Merkmale sind in dem Dokument der Wishbone-Spezifikation [23] aufgelis-
tet.
44 Artur Werner
Konzept und Implementierung eines Demonstrator-Systems
5.3.1 Wishbone-Spezifikation
Die Wishbone-Spezifikation gibt nicht nur vor, wie der Signalname aufgebaut sein soll,
sondern auch welche Informationen uber die gangigen Signale ubertragen werden. So
zum Beispiel muss ein Eingang mit dem Suffix”
i“ und ein Ausgang mit”
o“ gekenn-
zeichnet werden. Mit dem Listing 5.4 und der Tabelle 5.2 werden die Bedeutungen der
Signale des Wishbone-Interfaces erklart.
1 port ( −− Wishbone Slave Interface −−2 clk i : IN std ulogic;
3 rst i : IN std ulogic;
4 wb addr i : IN std ulogic vector(2 downto 0);
5 wb dat i : IN std ulogic vector(31 downto 0);
6 wb stb i : IN std ulogic;
7 wb cyc i : IN std ulogic;
8 wb we i : IN std ulogic;
9 wb sel i : IN std ulogic vector(03 downto 0);
10 wb ack o : OUT std ulogic;
11 );
Listing 5.4: Wishbone-Signale in der Entity
Signalname Bedeutung
wb addr i Adressen Eingangsarray,
bis zu 232 Adressen einstellbar
wb dat i Binares Daten Eingangsarray,
maximale Portgroße von 64-Bit
wb stb i Mit dem Strobe Eingang, wenn aktiv,
darf der Slave mit einem Acknowledgment antworten
wb cyc i Der Cycle Eingang,
weist auf einen aktiven Bus Transferzyklus hin
wb we i Mit dem Write Enable Eingang,
ist entweder ein Schreib- oder Lesezugriff gemeint
wb sel i Mit dem Select Eingang,
wird auf den gultigen Datenbereich des Daten
Eingangsarrays hingewiesen
wb ack o Mit dem Acknowledgment Ausgang,
terminiert der Slave einen Buszyklus
Tabelle 5.2: Bedeutung der Signalnamen des Wishbone-Interfaces
Artur Werner 45
Konzept und Implementierung eines Demonstrator-Systems
Die Signale eines Slaves sind mit einem Master wie in der Abbildung 5.8 verschaltet.
Vom Master gehen Adressen und Daten raus. Er gibt an, ob die Daten auf dem Bus
gultig sind. Und negiert einen gultigen Buszyklus, wenn dieser ein Acknowledge eines
Slaves erhalt. Die Schnittstelle kann ohne SYSCON Modul arbeiten. Fur großere Pro-
jekte sollte dieser jedoch in Betracht gezogen werden, da von ihm aus Master wie Slave
mit einem vom System separaten Takt- und Resetsignal versorgt werden.
Abbildung 5.8: Master-/Slave-Schnittstelle [23]
Standard-Wishbone-Handshaking-Protokoll
Der Wishbone kann mit asynchronen und synchronen Slaves kommunizieren. Ein gu-
tes Design arbeitet jedoch definierter, wenn dieser synchron arbeitet. Daher wird im
folgenden kurz auf ein synchrones Kommunikationsprotokoll eingegangen.
In der Abbildung 5.9 gibt der Master mit den Signalen cyc o und stb o einen aktiven
Buszyklus an und spricht einen Slave an. Dieser antwortet bei der nachsten steigenden
Flanke des Taktes mit einem synchronen Acknowledgment.
Abbildung 5.9: Synchrones Handshaking-Protokoll [23]
46 Artur Werner
Konzept und Implementierung eines Demonstrator-Systems
5.3.2 Verschaltungsarten von Wishbone
Die Wishbone-Spezifikation uberlasst dem Systementwickler die Aufgabe, wie seine
IP-Module verbunden werden sollen. Es gibt vier definierte Typen einer Wishbone-
Verschaltung:
• Point-to-point
• Data flow
• Shared bus
• Crossbar switch
Punkt-zu-Punkt
Die erste und einfachste Verbindung ist die Punkt-zu-Punkt Verbindung und verbin-
det zwei Wishbone-kompatible Module miteinander. Im Regelfall wird ein Master mit
einem Slave verbunden (siehe Abb. 5.10).
Abbildung 5.10: Punkt-zu-Punkt Verbindung [23]
Data flow
Die nachste Verbindung ist der Data flow und reprasentiert eine sequentielle Anein-
anderreihung von mehreren IP-Modulen (siehe Abb. 5.11). Diese Verbindung wird ge-
nutzt, wenn Daten in einer Sequenz verarbeitet werden sollen. Dieser Prozess wird pi-
pelining genannt. Die IP-Module besitzen jeweils die Master- und Slave-Schnittstelle.
Abbildung 5.11: Data flow Verbindung [23]
Artur Werner 47
Konzept und Implementierung eines Demonstrator-Systems
Shared Bus
Der Shared Bus ist ein System-Bus der mehrere parallele Teilnehmer miteinander ver-
bindet. Das konnen mehrere Master und Slaves sein. Da mehrere Master an dem Bus
beteiligt sind, bedarf es einem Arbitrierer. Dieser ist in Abbildung 5.12 nicht eingezeich-
net und regelt den Zugriff der Master auf den Bus. Der Arbitrierer kann auf verschie-
dene Arten konfiguriert sein, so dass er per Prioritat oder Round-Robin Verfahren den
Zugriff der Master verteilt. Ein Vorteil dieser Verbindung ist der geringe Logikgatter-
und Verbindungsressourcenverbrauch. Nachteilig ist, dass die Master eventuell warten
mussen bevor sie auf den Bus zugreifen durfen.
Abbildung 5.12: Shared Bus Verbindung [23]
Crossbar Switch
Die Crossbar Switch ahnelt dem Shared Bus. Ist jedoch in der Lage mehrere Master
mit Slaves gleichzeitig kommunizieren zu lassen (siehe Abbildung 5.13). Ein Arbitrierer,
nicht eingezeichnet, regelt wiederum den Zugriff der Master auf die Slaves.
Abbildung 5.13: Crossbar Switch Verbindung [23]
48 Artur Werner
Konzept und Implementierung eines Demonstrator-Systems
5.3.3 Wishbone-Slave-Implementierung
Die Wishbone-Spezifikation gibt nicht vor, wie die Implementierung aussehen soll. Sie
gibt vor, wie die Kommunikation erfolgen soll.
Daher ist der Entwickler fur die Implementierung von Schreib- und Lesezugriffe zustandig.
Beim NEO430 gibt es bereits Funktionen, um Daten an einen Wishbone-Slave zu sen-
den oder anzufordern.
Im Slave muss die Adresse festgelegt werden. Dies konnen eine oder mehrere Adressen
sein, je nach dem wie viele Funktionen das IP-Modul implementiert. Fur die CRC-
Implementierung in dieser Arbeit reicht eine Adresse aus. Ein Schreib- oder Lese-
zugriff erfolgt uber das Signal wb we i, welches in der Tabelle 5.2 aus Kapitel 5.3.1
erlautert wird. Des Weiteren muss sichergestellt werden, wie die Signalerkennung des
Bus-Systems erfolgt.
Unabhangig von der Verbindungsart, wird dies uber ein Prozess gelost, welches im
Listing 5.5 zu sehen ist. Uber die Abfrage der Signale wb stb i und wb cyc i in Zeile
7 wird gepruft, ob ein gultiger Buszyklus aktiv ist. Anschließend wird gepruft (Zeile
8 und 21), ob es sich um einen Schreib- oder Lesezugriff handelt. Im nachsten Schritt
(Zeile 9 und 22), wird die Adresse uberpruft die vom Master aus auf den Bus geschrie-
ben wird. Stimmt die Adresse mit diesem Modul uberein, wird mit der Case-Anweisung
(Zeile 11) das wb sel i Signal gepruft, damit der Slave auf die richtigen Daten zugreift
und diese auf ein internes Signal weitergeben kann (Zeile 13). Im Anschluss daran,
wird noch das Acknowledgment gesetzt (Zeile 18), um den Master mitzuteilen, dass
der Buszyklus nun negiert werden konnen.
Bei dieser Implementierung wurde auf eine allgemeingultige Losung gesetzt, damit diese
einfach ubernommen und auf die jeweiligen Anforderungen eines IP-Moduls angepasst
werden kann.
Artur Werner 49
Konzept und Implementierung eines Demonstrator-Systems
1 −− wb read/write process
2 read write proc: process(clk i)
3 begin
4 if(rising edge(clk i)) then
5 if(rst i = ’0’) then
6 −− global reset
7 elsif((wb stb i = ’1’) AND (wb cyc i = ’1’)) then
8 if(wb we i = ’1’) then −− write access
9 case wb addr i is
10 when slave addr => −− slave address
11 case wb sel i is
12 when "0011" => −− die unteren 2 Bytes von wb dat i(31
downto 0)
13 data in <= wb dat i(15 downto 0);
14 −− start crc <= ’1’;
15 when others =>
16 data in <= (others => ’0’);
17 end case;
18 wb ack <= ’1’;
19 when others =>
20 end case;
21 elsif(wb we i = ’0’) then −− read access
22 case wb addr i is
23 when slave addr => −− slave address
24 −− do smthfor read access
25 wb ack <= ’1’;
26 when others =>
27 end case;
28 end if;
29 else −− (wb stb i OR wb cyc i) = ’0’
30 wb ack <= ’0’;
31 end if;
32 end if;
33 end process read write proc;
Listing 5.5: Wishbone-Slave-Anbindung
50 Artur Werner
Konzept und Implementierung eines Demonstrator-Systems
5.4 Implementierung eines CRC-Moduls
Der CRC ist Teil einer leistungsfahigen Gruppe von fehlererkennenden Codes. Wie
aus der Bezeichnung des Codes zu entnehmen ist, handelt es sich um zyklische Codes.
Das bedeutet, dass eine zyklische Verschiebung der Bits eines Codewortes zu einem
anderen zulassigem Codewort fuhrt [26, Kapitel 6.4.3]. Ein Codewort c(z) entspricht
der Zeichenkette eines bestimmten Zeichens z (siehe Tabelle 5.3).
Zeichen z Codewort c(z)
A 00
B 01
C 10
.. ..
Tabelle 5.3: Tabellarische Darstellung der Codeworter
Die CRC-Codierung ist direkt an die Polynome aus der Mathematik gebunden.
Ein Codewort mit der Folge: 1010
entspricht einem Polynom: 1 ∗ x3 + 0 ∗ x2 + 1 ∗ x1 + 0 ∗ x0 = x3 + x1.
Ein CRC sind die angehangten Prufbits einer Nachricht, dessen Lange dem Gewicht
g eines Generatorpolynoms entspricht. Ist das Generatorpolynom ein Polynom vierten
Grades, so sieht ein Generatorpolynom wie folgt aus 1∗x3+0∗x2+1∗x1+0∗x0 = x3+x1
und der Nachricht wird ein CRC von drei Prufbits angehangt, da dies dem Gewicht
des Generatorpolynoms entspricht.
Artur Werner 51
Konzept und Implementierung eines Demonstrator-Systems
5.4.1 Berechnung CRC
Die Berechnung eines CRCs erfolgt mit der Polynomdivision. Die Polynomdivision bei
binaren Zahlenwerten (0 und 1) entspricht einer Modulo Zwei Addition beziehungswei-
se einem Exklusiv-Oder (XOR)-Gatter. Mit der nachfolgenden Abbildung 5.14 wird
die Modulo Zwei Addition und die Erzeugung des CRCs erklart.
Abbildung 5.14: Berechnung CRC
Die grunen Informationsbits (aus Abbildung 5.14) in binarer Form 10101010 entspricht
dem Hexadezimalen Wert: 0xAA oder in dezimaler Form der Zahl 170. Sie dient hier als
Beispiel. Das Generatorpolynom dritten Grades ist orange gekennzeichnet: 1101. Fur
die Berechnung des CRCs mussen den Informationsbits eine Initialisierungssequenz,
die drei Bit lang ist, angehangt werden. Die Initialisierungssequenz kann entweder aus
einer Reihe von Einsen oder Nullen bestehen.
Im ersten Schritt werden die ersten vier Bit der Nachricht, mit dem Polynom nach dem
XOR-Verfahren verrechnet. Das XOR-Gatter besitzt folgende Wahrheitstabelle 5.4:
52 Artur Werner
Konzept und Implementierung eines Demonstrator-Systems
A B Y
0 0 0
0 1 1
1 0 1
1 1 0
Tabelle 5.4: Wahrheitstabelle XOR
Dadurch ergibt sich in der XOR-Verrechnung von 1010 und 1101 der Wert 0111. Die
fuhrende Null wird durch aufrucken des funften Bit in der Nachricht ausgestoßen. So er-
gibt sich der nachste Wert 1111. Einer XOR-Verrechnung mit 1111 folgt der Wert 0100,
an welchem die Polynomdivision nicht durchgefuhrt werden kann, da keine fuhrende
Eins steht.
Dieses Prinzip zieht sich durch bis am Ende der Rest 110 ubrig bleibt. Dieser Restwert
ist nun das CRC-Ergebnis, welches an die ursprunglichen Informationsbits angehangt
und anschließend versendet wird. Der Empfanger, wenn keine Bitfehler auftreten, erhalt
diese Nachricht, bei der die letzten drei Bit dem CRC entspricht (siehe Abb. 5.14 rechte
Berechnung).
Der Empfanger fuhrt nun die Polynomdivision, mit dem gleichem Generatorpolynom
durch. Am Ende kommt als Rest 000 heraus, welches der ursprunglichen Initialsierungs-
sequenz entspricht. Dadurch weiß nun der Empfanger das kein unentdeckter Bitfehler
aufgetreten ist.
5.4.2 Implementierung CRC
Zyklische Codes haben den Vorteil, dass die Berechnung des CRCs und die empfangs-
seitige Fehlererkennung sich mit Schieberegistern sehr gut in Hardware umsetzen lasst
[27]. Die Abbildung 5.15 zeigt ein seriell aufgebautes Schieberegister.
Abbildung 5.15: Aufbau CRC-Encoder-Schaltung [26]
Artur Werner 53
Konzept und Implementierung eines Demonstrator-Systems
Das Schieberegister wird von rechts befullt und mit jeder steigenden Taktflanke werden
die Inhalte der einzelnen Elemente nach links durchgereicht [26].
Die XOR-Gatter mit den verschalteten UND-Gatter bilden das Generatorpolynom.
Bedeutet an den gr Eingangen der UND-Gatter liegt entweder eine Eins oder eine Null
an. Das letzte D-Flip-Flop verbindet den anderen Eingang der UND-Gatter. Dadurch
gelangen nur dann die Koeffizienten des Generatorpolynoms an die XOR-Gatter, wenn
das linke Element, also das Most Significant Bit (MSB) des Schieberegisters eine Eins
hat. Steht im MSB hingegen eine 0, wird solange nach links geschoben bis wieder eine
fuhrende Eins auftritt.
Das Schieberegister aus Abbildung 5.15 kann weiter vereinfacht werden. Zum einen
sieht man, dass das fuhrende XOR-Gatter nicht genutzt wird, sowie jedes UND-Gatter
dessen gr Eingang einen Null-Koeffizienten hat weggelassen werden kann. Daraus resul-
tiert eine optimierte Schaltung die in Abbildung 5.16 dargestellt ist. Die leeren Blocke
sind die Elemente des Schieberegisters und mit XOR-Gatter an das Generatorpolynom
verknupft. Diese Vereinfachung ist nur fur ein bestimmtes Generatorpolynom, dem Po-
lynom mit den Koeffizienten 1101 ausgelegt.
Abbildung 5.16: Optimierte CRC-Encoder-Schaltung [26]
Implementierung in VHDL
Das Generatorpolynom wurde auf 0xA7 = ”11010111” festgelegt. Da das CRC-Modul
uber die Wishbone-Schnittstelle angebunden wird, sind in dem Listing 5.6 zum einen
die notigen Signale fur das Wishbone-Slave-Interface, sowie die Signale dat o und
crc check o vorzufinden. Die Wishbone-Signale und wie die Kommunikation erfolgt,
wird im Kapitel 5.3.1 und 5.3.3 erlautert.
Das Signal crc check o gibt aus ob die CRC-Uberprufung korrekt oder falsch ist,
wahrend dat o die Informationsbits an LEDs ausgibt, wenn die Uberprufung korrekt
ist.
54 Artur Werner
Konzept und Implementierung eines Demonstrator-Systems
1 library ieee;
2 use ieee.std logic 1164.all;
3 entity wb crc8 is
4 port (
5 −− Wishbone Slave Interface −−6 clk i : IN std ulogic; −− global clock line
7 rst i : IN std ulogic; −− gloab asynchron reset
8 wb addr i : IN std ulogic vector(2 downto 0); −− address
9 wb dat i : IN std ulogic vector(31 downto 0); −− data input
10 wb stb i : IN std ulogic; −− strobe
11 wb cyc i : IN std ulogic; −− valid cycle
12 wb we i : IN std ulogic; −− write enable; ’1’ = write, ’0’ = read
13 wb sel i : IN std ulogic vector(03 downto 0); −− byte enable for data
14 wb ack o : OUT std ulogic; −− transfer acknowledge
15 crc check o : OUT std ulogic := ’0’; −− crc check valid
16 dat o : OUT std ulogic vector(7 downto 0) −− data output
17 );
18 end wb crc8;
Listing 5.6: Entity des CRC-Moduls
In der architecture wurden benotigte Konstanten und interne Signale festgelegt (siehe
Listing 5.7). Die Konstante slave addr ist fur das Ansprechen des Moduls notwendig
und polynom beinhaltet das Generatorpolynom. Fur die Signale sind data out, data in
und tmp buffer als Puffersignale, mit shift register das Schieberegister, start crc als
Hilfssignal und state als Zustandssignal fur eine Zustandsmaschine deklariert.
1 −− konstanten −−2 constant slave addr : std ulogic vector(2 downto 0) :="001"; −− slave
address 0x1
3 constant polynom : std ulogic vector(7 downto 0) :="11010111"; −− 0xA7
Generatorpolynom (x7 + x6 + x4 + x2 + x1 + 1)
4 −− interne signale −−5 signal data out : std ulogic vector(7 downto 0) :=(others => ’0’); −− k
Datenbits k=8
6 signal data in : std ulogic vector(15 downto 0) :=x"0000"; −− n Codebits
n=11 −> da crc 3 bits
7 signal wb ack : std ulogic := ’0’;
8 signal shift register : std ulogic vector(6 downto 0) :="0000000"; −− (n
−k) stufiges Schieberegister
9 signal tmp buffer : std ulogic vector(15 downto 0);
10 signal start crc : std ulogic := ’0’;
11 signal state : integer := 15;
Listing 5.7: Deklaration von Signalen und Konstanten
Artur Werner 55
Konzept und Implementierung eines Demonstrator-Systems
Weiterhin befinden sich in der architecture drei Prozesse:
• der Wishbone Lese- und Schreibzugriffsprozess,
• ein Zahlprozess fur die Zustandsmaschine,
• und ein CRC Uberprufungsprozess, welches die Zustandsmaschine implementiert.
Der Zahlprozess dekrementiert vom Signal state, beginnend bei 15, den Wert 1. Dadurch
wird das Element des tmp buffer angeben, welches als nachstes in das shift register
eingeschoben wird.
Bei einem globalen Reset oder wenn die Berechnung des CRCs abgeschlossen ist, wird
das state Signal auf den Initialwert 15 zuruckgesetzt.
1 −− zaehl prozess der zustandsmaschine
2 count proc: process(clk i, start crc)
3 begin
4 if(rising edge(clk i)) then
5 if(start crc = ’1’ AND state /= (−1)) then
6 state <= state − 1;
7 elsif(start crc = ’0’ OR rst i = ’0’) then
8 state <= 15;
9 end if;
10 end if;
11 end process count proc;
Listing 5.8: Zahlprozess der Zustandmaschine
Die Zustandsmaschine des Schieberegister ist im crc check Prozess implementiert (sie-
he Listing 5.9). Zu Beginn in Zeile 6 wird das tmp buffer mit den einkommen Daten
initialisiert. Anschließend findet eine Uberprufung des Resets (Zeile 7 - 10) und eines
abgeschlossenen Wishbone Transfers (Zeile 11 - 15) statt.
Fur das Verstandnis reicht die Betrachtung von drei Zustanden aus, die restlichen
sind gleich aufgebaut. Der Zustand (-1) in Zeile 18 wird genutzt um das Ende der
CRC-Berechnung zu kennzeichnen. Ab Zeile 19 findet die Uberprufung mit der Initiali-
sierungsequenz statt. Trifft das zu, werden die Ausgange crc check o und dat o gesetzt.
In Zeile 25 wird die CRC-Berechnung beendet und das Modul ist bereit fur die nachste
Uberprufung.
Nun zum Schiebe Algorithmus. Dazu sind die Zustande 0 bis 15 gleich aufgebaut.
Mit der Anweisung in Zeile 27 wird das MSB des Schieberegisters auf eine fuhrende
Eins uberpruft. Ist das der Fall wird das nachste Element aus dem tmp buffer einge-
schoben, die XOR-Verknupfung mit dem Generatorpolynom durchgefuhrt und in das
56 Artur Werner
Konzept und Implementierung eines Demonstrator-Systems
Schieberegister reingeschrieben. Wenn dem nicht so ist, erfolgt wie in Zeile 30 nur eine
Schiebeoperation.
1 −− ueberprueft codewort dateninput ob CRC "0000000" ergibt
2 crc check: process(clk i, state)
3 begin
4 if(rising edge(clk i)) then
5 −− Initialisierung des tmp buffers −− data 8 bit −− crc 7 bit
6 tmp buffer <= ’0’ & data in(15 downto 8) & data in(6 downto 0);
7 if(rst i = ’0’) then
8 shift register <= (others =>’0’);
9 crc check o <= ’0’;
10 end if;
11 if((wb stb i = ’0’) AND (wb cyc i = ’0’) AND (wb ack = ’1’)) then
12 start crc <= ’1’;
13 shift register <= (others =>’0’);
14 crc check o <= ’0’;
15 dat o <= x"00";
16 elsif(start crc = ’1’) then
17 case state is
18 when −1 =>
19 if (shift register = "0000000") then −− CRC Pruefung
20 crc check o <= ’1’; −− true
21 dat o <= data out;−− data output
22 else
23 crc check o <= ’0’; −− false
24 end if;
25 start crc <= ’0’;−− crc berechnung beendet
26 when 0 =>
27 if((shift register(6)) = ’1’) then
28 shift register <= (shift register(5 downto 0) & tmp buffer(0)) XOR
polynom(6 downto 0);
29 else
30 shift register <= (shift register(5 downto 0) & tmp buffer(0));
31 end if;
32 when 1 =>
33 if((shift register(6)) = ’1’) then
34 shift register <= (shift register(5 downto 0) & tmp buffer(1)) XOR
polynom(6 downto 0);
35 else
36 shift register <= (shift register(5 downto 0) & tmp buffer(1));
37 end if;
38 when 2 =>
39 .
40 .
Listing 5.9: Zustandsmaschine des Schieberegister
Artur Werner 57
Konzept und Implementierung eines Demonstrator-Systems
5.4.3 Simulationsergebnisse
Mit einer Simulation soll nun die Funktion des CRC-Moduls und die Wishbone-Anbind-
ung verifiziert werden. Hierfur wurde eine Testbench geschrieben, die mehrere CRC-
Berechnungen durchfuhren lasst. Insgesamt sind 256 verschiedene Daten, von 0x00 bis
0xFF, moglich. In der Testbench wurden lediglich 32 CRC-Berechnungen durchgefuhrt,
von denen drei CRC-Berechnungen, sowie Zugriffe in der Abbildung 5.17 zu sehen sind.
In Abschnitt 1 (siehe Abbildung 5.17) sind die Signale wb stb, wb cyc und wb we zu
sehen. Mit diesen erfolgt der erste Zugriff auf das Modul. Mit der ersten steigenden
Taktflanke, nachdem die Signale gesetzt wurden, reagiert das CRC-Modul mit einem
Acknowledgment. Mit der folgenden, steigenden Taktflanke fallen die Wishbone-Signale
auf den Low-Pegel und sobald das Signal wb ack ebenfalls negiert, beginnt die interne
CRC-Berechnung des Moduls. Auf den Inhalt des Schieberegister kann uber die Test-
bench nicht zugegriffen werden, da Zwischenergebnisse nicht ausgegeben werden.
Da es sich um eine serielle CRC-Implementierung handelt, benotigt die Berechnung
genau 16 Takte fur 16-Bit Nachrichten. Bei einer Taktfrequenz von 50 MHz entspricht
das eine Berechnungszeit von 320 ns.
Nach dieser Zeit erfolgt im Abschnitt 2 die Bestatigung einer erfolgreichen Berech-
nung, welches mit dem High-Pegel des crc check Signals verdeutlich wird. Bei dem
ersten Beispiel handelt es sich, um die Berechnung des CRCs von 0x00. Das entspricht
einem CRC von ”0000000”. Dieses Ergebnis ist fur die CRC-Berechnung nichtssagend,
damit wird aber der Zugriff uber Wishbone betatigt.
Im Abschnitt 3 ist eine weitere Berechnungsbestatigung zu sehen, die die Daten 0x01
und das zugehorige CRC ”1010111” uberpruft. Wie man erkennen kann, wird die Be-
rechnung mit dem Signal crc check bestatigt.
Die weiteren 32 Berechnungen der Testbench erfolgten ohne Fehler und daher kann zu-
mindest anhand der Simulation davon ausgegangen werden, dass das CRC-Modul seiner
geforderten Funktion entspricht. Als nachster Schritt steht die Prufung in Hardware
aus, indem das CRC-Modul in den NEO430 eingebunden wird (siehe Kapitel 5.6.2).
58 Artur Werner
Konzept und Implementierung eines Demonstrator-Systems
Abbildung 5.17: Simulationsfenster von 3 CRC-Berechnungen
Artur Werner 59
Konzept und Implementierung eines Demonstrator-Systems
5.5 Anbindung eines frei verfugbaren FIFO-Moduls
Eine Anforderung dieser Arbeit war es, neben der Implementierung eines eigenen IP-
Moduls, ein frei verfugbares IP-Modul uber Wishbone anzubinden. Frei verfugbare
IP-Module sind von drei Quellen beziehbar:
• der Webseite opencores.org
• einer Bibliothek
• dem Internet
Die IP-Module sind unterschiedlich implementiert und konnen eine Wishbone-Schnittstelle
besitzen oder auch nicht.
5.5.1 IP-Modul FIFO
Ausgewahlt wurde ein FIFO-Modul [28]. Eine FIFO arbeitet nach dem Prinzip First-In-
First-Out. In ein Array oder einem Warteschlangen-ahnlichen Speicherprinzip, konnen
Daten der Reihe nach abgelegt und wieder abgeruft werden.
Abbildung 5.18: Prinzip einer FIFO [29]
So wird wie in Abbildung 5.18, zuerst der Buchstabe A und anschließend B in die FIFO
reingeschrieben und befinden sich demnach an den Positionen 0 und 1. Bei den nachsten
zwei Lesezugriffen der FIFO wird zuerst der Buchstabe A und danach B gelesen.
60 Artur Werner
Konzept und Implementierung eines Demonstrator-Systems
Die FIFO wurde auf www.freerangefactory.org gefunden und dessen Source-Code
ist auf Github zu finden [28]. Die zugehorige Dokumenation [30] gibt Auskunft uber
die Implementierung der FIFO und wie diese genutzt werden soll.
Im Falle eines Schreibvorgangs, wird die FIFO nur dann beschrieben, wenn diese nicht
voll ist, das Signal WRITE aktiv gehalten wird und Daten am Eingangssignal
DATA IN, wahrend einer steigenden Taktflanke, vorhanden sind.
Im Listing 5.11 ist der Source-Code der FIFO zu sehen. In Zeile 1 wird ein gultiger
Zugriff gepruft. Im Prozess data srl (Zeile 3 bis 10) werden Daten an eine freie Position
der FIFO geschrieben. Daten ausgegeben werden in Zeile 11, entsprechend der Position
des Pointers. Die Position des Pointers wird in einem weiteren Prozess (Zeile 27 bis 38)
festgelegt. Ab Zeile 39 werden interne Signale an die Ausgange weitergegeben.
Die Umsetzung der FIFO weicht der Beschreibung aus der Dokumentation ab. Denn
in Zeile 11 erfolgt eine Ausgabe der Daten, welche sich an der Position des Pointers
befinden. Dies fuhrt zu einer unkontrollierten Ausgabe auf dem data out Ausgangssi-
gnal.
5.5.2 Erweiterung mit Wishbone
Da bei dieser FIFO die Wishbone-Anbindung fehlt, wurde diese mit dem Beispiel aus
Listing 5.5 erweitert. Hinzu kamen kleine Anderungen der FIFO (siehe Listing 5.10).
Die Ein- und Ausgaben der Daten wurden in den Prozess der Wishbone-Anbindung
aufgenommen, um hier die unkontrollierte Ausgabe zu verhindern.
1 if(write = ’1’) then −− write access
2 case wb addr i is
3 when slave addr => −− slave address
4 case wb sel i is
5 when "0001" =>
6 data in <= wb dat i(7 downto 0);
7 when others =>
8 ..
9 elsif(read = ’1’) then −− read access
10 case wb addr i is
11 when slave addr => −− slave address
12 data out <= fifo store(pointer);
13 ..
Listing 5.10: Erweiterung Wishbone
Artur Werner 61
Konzept und Implementierung eines Demonstrator-Systems
1 valid write <= ’1’ when ( read = ’1’ and write = ’1’ )
2 or ( write = ’1’ and pointer full = ’0’ ) else ’0’;
3 data srl :process( clk )−− data store SRL’s
4 begin
5 if rising edge( clk ) then
6 if valid write = ’1’ then
7 fifo store <= fifo store( fifo store’left − 1 downto 0) & data in
;
8 end if;
9 end if;
10 end process;
11 data out <= fifo store( pointer );
12 process( clk)
13 begin
14 if rising edge( clk ) then
15 if reset = ’1’ then
16 empty <= ’1’;
17 elsif empty = ’1’ and write = ’1’ then
18 empty <= ’0’;
19 elsif pointer zero = ’1’ and read = ’1’ and write = ’0’ then
20 empty <= ’1’;
21 end if;
22 end if;
23 end process;
24 valid count <= ’1’ when ((write = ’1’ and read = ’0’ and pointer full =
’0’ and empty = ’0’ )
25 or(write = ’0’ and read = ’1’ and pointer zero = ’0’ )
26 ) else ’0’;
27 process( clk )
28 begin
29 if rising edge( clk ) then
30 if valid count = ’1’ then
31 if write = ’1’ then
32 pointer <= pointer + 1;
33 else
34 pointer <= pointer − 1;
35 end if;
36 end if;
37 end if;
38 end process;
39 −− Detect when pointer is zero and maximum
40 pointer zero <= ’1’ when pointer = 0 else ’0’;
41 pointer full <= ’1’ when pointer = srl length − 1 else ’0’;
42 −− assign internal signals to outputs
43 full <= pointer full;
44 half full int <= std logic vector(to unsigned(pointer, pointer vec));
45 half full <= half full int(half full int’left);
46 data present <= not( empty );
Listing 5.11: FIFO-Source-Code
62 Artur Werner
Konzept und Implementierung eines Demonstrator-Systems
5.6 C-Programmierung des NEO430
In diesem Kapitel wird auf die Programmierung des NEO430 eingegangen und welche
Schritte notwendig sind.
5.6.1 Genereller Software-Setup
Fur den generellen Software-Setup sind drei Schritte notwendig [24]:
• Das Herunterladen der letzten Version des TI msp430-gcc Compilers [31]
• Entpacken und Installieren der Dateien in einem beliebigem Verzeichnis, wichtig
fur Compilier Skript
• Große des Speicher von IMEM und DMEM in neo430 linker script.x angeben
5.6.2 Programm-Entwicklung
Die Erstellung des Programms erfolgt in einem Texteditor wie zum Beispiel Notepad++
oder einer beliebigen Entwicklungsumgebung (Kapitel 5.6.5). Die bereitgestellten Da-
teien des NEO430 sind modular aufgebaut und verwenden mehrere Header-Dateien
• neo430.h
• neo430 gpio.h
• neo430 usart.h
• neo430 cpu.h
• neo430 wishbone.h
um Register, Funktionen und Variablen zu definieren.
Das Inkludieren dieser Dateien erfolgt in einer gemeinsamen Hauptdatei, der”main.c“
(siehe Listing 5.12).
Artur Werner 63
Konzept und Implementierung eines Demonstrator-Systems
1 //Libraries
2 #include <stdint.h>
3 #include <string.h>
4 #include "neo430/neo430.h"
5 #include "neo430/neo430 gpio.h"
6 #include "neo430/neo430 usart.h"
Listing 5.12: Einbindung der Header-Dateien
Bevor die eigentliche Hauptfunktion beginnt sind wichtige Einstellungen vorzunehmen
(siehe Listing 5.13):
• Deklaration globaler Variablen
• Definition von Wishbone-Slave-Adressen
• Konfiguration fur UART-Schnittstelle
• Prototypen von Funktionen
1 //Global Variables
2 uint8 t wb config = 0; // transfer size in bytes (1, 2, 4)
3 char buffer[9],
4 uint32 t last message;
5 uint8 t i=0;
6 char c;
7 //Wishbone Slave address
8 uint32 t wb port addr = 0x000;
9 uint32 t wb crc addr = 0x001;
10 //Configuration
11 #define BAUD RATE 19200
12 //Function prototypes
13 void delay(uint16 t t);
14 uint32 t hex str to uint32(char ∗buffer);
Listing 5.13: Deklaration von Einstellungen
Anschließend erfolgt die Initialisierung der Register des NEO430, dazu gehort die
Ubergabe der Baudrate an die UART-Schnittstelle und der Wishbone-Schnittstelle
(siehe Listing 5.14).
64 Artur Werner
Konzept und Implementierung eines Demonstrator-Systems
1 int main(void){2 //setup UART
3 uart set baud(BAUD RATE);
4 USI CT = (1<<USI CT EN) | (5<<USI CT SPIPRSC0) | (63<<USI CT SPICS0);
5
6 // intro text
7 uart br print("\nCRC Testprojekt\n");8
9 //check if GPIO was synthesized, exit if n GPIO is available
10 if(!(SYS FEATURES & (1<<SYS GPIO EN))){11 uart br print("Error! No GPIO unit synthesized");
12 return 1;
13 }14
15 // default config
16 // wb sel = "0011" for crc
17 wb config = 1;
18 WB32 CT = (1<<WB32 CT EN) | (1<<WB32 CT TO EN) |19 (0<<WB32 CT WBSEL3) | (0<<WB32 CT WBSEL2) |20 (1<<WB32 CT WBSEL1) | (1<<WB32 CT WBSEL0) | (0<<WB32 CT PMODE);
21 gpio port set(0); //deactivate all LEDs
Listing 5.14: Initialisierung der Schnittstellen
Nach diesem kommt nun die eigentliche Funktion des Programms. Eine Lauflicht-
Implementation sieht wie folgt aus (siehe Listing 5.15). Mit diesem Programm wird
im Wesentlichen nur getestet, ob der NEO430, welcher auf dem FPGA konfiguriert ist,
ein Programm aus dessen Programmspeicher abarbeiten kann.
1 while (1){2 if(i == 0x00)
3 {4 i = 0x80;
5 }6 else
7 {8 i >>=1;
9 }10 gpio port set(0x00FF & 1); // set output port and increment counter
11 delay(10); // wait some time
12 }
Listing 5.15: Lauflicht-Programm
Artur Werner 65
Konzept und Implementierung eines Demonstrator-Systems
Daher wird hier nun das Programm der CRC-Berechnung aufgezeigt (siehe Listing 5.16).
1 while (1){2 // wait until data available on uart
3 { uart br print("\nWaiting for first character\n");4 c = uart getc();
5 uart putc(c);
6 buffer[0] = c;
7 }8 // wait until data available on uart
9 { uart br print("\nWaiting for second character\n");10 c = uart getc();
11 uart putc(c);
12 buffer[1] = c;
13 }14 // wait until data available on uart
15 { uart br print("\nWaiting for third character\n");16 c = uart getc();
17 uart putc(c);
18 buffer[2] = c;
19 }20 // wait until data available on uart
21 { uart br print("\nWaiting for fourth character\n");22 c = uart getc();
23 uart putc(c);
24 buffer[3] = c;
25 }26 //print last message
27 uart br print("\nLast message:");
28 uart print hex dword(last message);
29 uint32 t w data = hex str to uint32(buffer);
30 uart br print("\nWriting ’0x");
31 uart print hex word(w data & 0xFFFF);
32 uart br print("’ to [0x");
33 uart print hex dword(wb crc addr);
34 uart br print("]... ");
35 //save last message
36 last message = w data;
37 // (w data & 0x00FF) −> unteren 16 bits
38 if(wishbone write16(wb crc addr,(w data & 0x00FF))){39 uart br print("Error! Device not responding!\n");40 }41 else{ uart br print("Done.\n");}42 }
Listing 5.16: Programm der CRC-Berechnung
66 Artur Werner
Konzept und Implementierung eines Demonstrator-Systems
Das CRC-Programm testet die empfangenen Daten der UART-Schnittstelle, indem es
vier Zeichen nacheinander empfangt und in einen Puffer schreibt. Anschließend werden
die empfangenen Daten als Bestatigung an das Terminal zuruckgeschickt und mit der
Funktion wishbone write16 an das Wishbone angebundene CRC-Modul versendet.
Dadurch wird die Wishbone-Schnittstelle getestet. Das Ergebnis der CRC-Berechnung
ist an den LEDs am FPGA Board zu sehen und kann dort visuell verifiziert werden.
Der Test der CRC-Implementierung ist somit Hardware- und Softwareseitig erfolgreich
abgeschlossen.
5.6.3 Programm-Compilierung
Fur das Compilieren eines Programms sind folgende Schritte zu befolgen [24]
• Offnen der compile.bat Datei aus dem sw/common Ordner und Suche nach dem
”User Configuration“ Abschnitt
• Angabe des absoluten Systempfades des Compiler binary Ordners in der
BIN PATH Variable
• Wechsel in einen beliebigen Beispiel-Ordner des NEO430 Projektes sw/example
• Dort kann nun die Datei main.c mit einem Texteditor oder einer beliebigen Ent-
wicklungsumgebung geoffnet und abgeandert werden
• Ausfuhrung des Compilier-Skriptes make.bat
• Dadurch wird das generierte Programm-Image in die neo430 application image.vhd
geladen
• Anschließend muss nur noch das Top-Level-Design des NEO430,
neo430 top.vhd synthetisiert werden und kann danach auf den FPGA geladen
werden.
• Das Programm befindet sich lauffahig im IMEM Programmspeicher
Artur Werner 67
Konzept und Implementierung eines Demonstrator-Systems
5.6.4 Programm-Upload
Da dieser vorher beschriebene Vorgang aufwendig ist, besteht die Moglichkeit das
Programm uber die UART-Schnittstelle hochzuladen, wahrend der NEO430 auf dem
FPGA konfiguriert ist. Bei der Compilierung eines Programmes, wird eine binare Datei
main.bin erstellt. Diese Datei kann uber die UART-Schnittstelle hochgeladen werden.
Zuerst muss eine Verbindung vom Computer mit dem FPGA hergestellt werden. Ge-
nutzt wird das Terminal-Programm TeraTerm, die gleiche Prozedur kann mit jedem
Terminal-Programm durchgefuhrt werden:
• Verbindung der UART-Schnittstelle des FPGAs mit einem COM Port des Com-
puters, Verwendung eines USB-to-Serial Adapter moglich
• Starten des Terminal-Programms, beispielhaft mit TeraTerm [32]
• Verbindung mit COM Port offnen und folgende Parameter einstellen (siehe Abb. 5.19)
– 19200 Baud
– 8 data bits
– 1 stop bit
– kein Parity bit
– kein transmisson/flow control protocol (just raw byte mode)
Abbildung 5.19: Serielle Konfiguration in TeraTerm [24]
Anschließend muss der NEO430 auf dem FPGA uber den Reset-Button zuruckgesetzt
werden, damit der Bootloader startet. Wahrend die Bootloader LED blinkt und das
Text-Interface des Bootloader in der Konsole (siehe Abb. 5.20) auftaucht, muss irgend-
eine Taste am Computer betatigt werden, um den automatischen Boot-Prozess des
68 Artur Werner
Konzept und Implementierung eines Demonstrator-Systems
Bootloaders abzubrechen.
Abbildung 5.20: Text Interface im Konsolenfenster [24]
Mit dem Eingeben des Buchstaben”u“ wird der Befehl
”Upload“ ausgefuhrt. Der
Bootloader wartet an dieser Stelle auf die binare Datei”main.bin“. In TeraTerm muss
nun die Option”Datei senden“ ausgewahlt werden (siehe Abb. 5.21).
Abbildung 5.21: Datei senden mit TeraTerm [24]
Im nachsten auftauchendem Fenster den Hacken bei Option: Binary setzen (siehe
Abb. 5.22).
Abbildung 5.22: Ubertragen der ausfuhrbaren, binaren Datei [24]
Artur Werner 69
Konzept und Implementierung eines Demonstrator-Systems
Wenn im Terminal ein ok erscheint, liegt nun das Image des Programms im Pro-
grammspeicher des NEO430. Das Programm kann anschließend aus dem Terminal mit
”s“ gestartet werden.
5.6.5 Nutzung einer Entwicklungsumgebung
Eine Integrierte Entwicklungsumgebung (IDE) ist eine Sammlung von verschiedenen
angebotenen Computerprogrammen, wie Editor, Compiler, Linker und Debugger. Fur
die Softwareentwicklung und dem Entwickler ein großer Vorteil, da die Bedienung,
Entwicklung und Verwaltung eines Projektes mit einem einzigen Programm abgedeckt
wird.
Die Eclipse IDE ist ein quelloffenes Programm, welches ursprunglich fur die Program-
miersprache Java entwickelt wurde [33]. Eine Anforderung in dieser Arbeit ist es, den
NEO430 auf Kompatibilitat mit einer Entwicklungsumgebung zu untersuchen. Diese
ist im wesentlichen gegeben, da die Erstellung eines Programms mit einem beliebigen
Texteditor-Programm moglich ist. Das NEO430 Projekt nutzt zur Kompilierung eine
Batch-Datei, mit der aus dem Programm eine binare Datei fur den NEO430 erstellt
wird.
Im nachsten Abschnitt wird auf die Einbindung der Skripte in die Eclipse IDE einge-
gangen die das NEO430 Projekt nutzt.
Eclipse IDE
Der erste Schritt befasst sich mit dem Anlegen eines Projektes. Anschließend wird
diesem Projekt folgende Dateien hinzugefugt:
• NEO430-Header-Dateien vom Pfad ../sw/lib
– neo430.h
– neo430 wishbone.h
– neo430 usart.h
– neo430 gpio.h
– neo430 cpu.h
• eine beliebige main.c als Vorlage und die Batch-Datei make.bat
vom Pfad ../sw/example
• compile.bat, crt0.asm, main.elf und neo430 linker script.x
vom Pfad ../sw/common
70 Artur Werner
Konzept und Implementierung eines Demonstrator-Systems
Anschließend mussen in den Dateien compile.bat und make.bat Anderungen vorgenom-
men werden.
make.bat
In dieser Datei muss in Zeile 27 der absolute Pfad des Eclipse-Projekt angegeben wer-
den (siehe Abb. 5.23).
Abbildung 5.23: Adressenanderung in make.bat
compile.bat
In dieser Datei erfolgt die absolute Pfadangabe in Zeile 30 des MSP430 Compiler (siehe
Abb. 5.24).
Abbildung 5.24: Compiler Pfadangabe in compile.bat
Dann die absolute Pfadangabe des Image Generators in Zeile 72 (siehe Abb. 5.25).
Abbildung 5.25: Image-Generator Pfadangabe in compile.bat
Abschließend die absolute Pfadangabe der neo430 application image.vhd Datei in Zeile
107 (siehe Abb. 5.26).
Abbildung 5.26: NEO430-Applikation-Image-Datei Pfadangabe in compile.bat
Artur Werner 71
Konzept und Implementierung eines Demonstrator-Systems
Der letzte notwendige Schritt ist die Builder-Einstellungen im Eclipse-Projekt einzu-
stellen. Auf dieses kann per Rechtsklick des Projektnamens oder aus der Tab-leiste un-
ter Projekt und Properties zugegriffen werden. In dem neuen Fenster (siehe Abb. 5.27),
auf C/C++ Build klicken, damit im rechten Abschnitt des Fensters auf den Tab Buil-
der Settings zugegriffen werden kann.
Unter Builder muss nun der Builder Type auf External Builder eingestellt werden. Und
beim Build command muss folgender Ausdruck $ProjDirPath\make.bat eingetragen
werden. Mit Apply und Ok werden die Einstellungen ubernommen.
Abbildung 5.27: Projekt Eigenschaften
Ein Projekt kann nun jederzeit mit dem Hammer-Icon kompiliert werden (siehe Abb. 5.28).
Abbildung 5.28: Projekt-Kompilierung mit Hammer-Icon
72 Artur Werner
Evaluation der Implementierung eines NEO430 System
6 Evaluation der Implementierung
eines NEO430 System
Dieses Kapitel behandelt die Konfiguration des FPGAs und die verwendeten Program-
me, um ein NEO430 Projekt auf den FPGA zu laden. Anschließend erfolgt die Evalua-
tion zur Programmierung des NEO430 und einer Ubersicht des Ressourcenverbrauchs,
die der NEO430 vom FPGA benotigt.
Fur diese Arbeit stand ein DE2-115 Development-Board von Terasic zu Verfugung.
Auf diesem ist ein Cyclone IV FPGA der Firma Altera verbaut. Der FPGA bietet an
die 115.000 Logikelemente, sowie integrierte Speicherblocke die 9 kBit umfassen.
Die Konfiguration des FPGAs erfolgt mit der Entwicklungsumgebung Quartus Prime
16.1 Lite Edition. In dem befindet sich ein Pin-Planner uber dem die Pins des Cyclone
IV FPGA mit dem Top-Level-Design des NEO430 Projektes verbunden werden. Von
dem Board wurden 8 LEDs, ein Taster fur Reset, die UART-Schnittstelle und 8 GPIO-
Pins fur die Anbindung eines EEPROMs genutzt. Das Synthetisieren des Projektes
erstellt eine .sof Datei mit der uber die JTAG Schnittstelle der FPGA konfiguriert
wird.
Der NEO430 Softcore-Prozessor konnte innerhalb von zwei Tagen, mit dem Test-Setup
(siehe Kapitel 5.1) auf den FPGA konfiguriert werden. Diese Zeitangabe beinhaltet das
Herunterladen des Prozessors und die Einarbeitung der Dokumentation.
Das Demonstrator-System mit der CRC-Implementierung benotigte 10 Tage, da eine
Einarbeitung in die Funktionsweise der CRC-Berechnung, die Umsetzung des CRC-
Moduls in VHDL, die Entwicklung der Testbench und Simulation des CRC-Moduls,
sowie Einarbeitung der Wishbone-Spezifikation, Implementierung im CRC-Modul und
die Entwicklung des C-Programms notwendig war.
Artur Werner 73
Evaluation der Implementierung eines NEO430 System
6.1 Programmierung des NEO430
Die Programmierung des NEO430 erfolgt uber zwei Methoden:
• uber der UART-Schnittstelle
• uber die SPI-Schnittstelle, welches ein EEPROM anbindet
Die erste Methode wurde bereits in Kapitel 5.6.4 gezeigt und eignet sich besonders gut
in der Entwicklungsphase. Die UART-Schnittstelle und der Bootloader ermoglichen das
standige Hochladen eines neuen Programmes, um zum Beispiel Fehler im Programm
zu korrigieren oder die konfigurierte Hardware fur verschiedene Programme zu testen.
Man erspart sich die Zeit das Projekt in Quartus neu zu synthetisieren und jedes mal
den FPGA neu zu konfigurieren.
Die zweite Methode nutzt einen nicht-fluchtigen EEPROM-Speicherbaustein. Dieses
ist uber die SPI-Schnittstelle des NEO430 mit dem Prozessor verbunden. Beschrieben
wird das EEPROM einmalig mithilfe des Bootloaders und der UART-Schnittstelle. Der
Bootloader ist zusatzlich in Lage automatisch das Programm aus dem EEPROM zu
beziehen und auszufuhren. Das erfolgt, wenn der Prozessor zuruckgesetzt wird und von
der Adresse des Bootloaders startet. Es besteht die Moglichkeit die Konfigurationsda-
tei fur den FPGA ebenfalls im gleichen oder einen anderen EEPROM abzuspeichern.
Dadurch kann das System, nach einem Verlust der Spannungsversorgung, den FPGA
selbst konfigurieren und den NEO430 mit einem Programm versorgen.
6.2 Vergleich der Prozessor-Anforderungen
Im Kapitel 2 wurden Anforderungen an den Prozessor genannt. In diesem Kapitel wer-
den die Anforderungen aufgezeigt, die der NEO430 erfullt.
Die Implementierung auf einen ASIC stellt kein Problem dar. Als Entwicklungsumge-
bung wurde Eclipse getestet (siehe Kapitel 5.6.5). Debuggen des NEO430 funktioniert
nach der altmodischen Methode, in dem Testcode genutzt wird. Ein interaktives De-
buggen funktioniert nicht, da eine Debugger-Einheit im NEO430 fehlt.
74 Artur Werner
Evaluation der Implementierung eines NEO430 System
Anfo
rderu
ng
Besch
reib
ung
NE
O430
A1
...au
sSich
tder
Anw
endung
der
Low
-Pow
er-System
eau
fF
PG
Aim
plem
entierb
ar,Ja
auf
einem
FP
GA
und/o
der
ASIC
kostengu
nstig
implem
entierb
arsein
ASIC
,vielversp
rechen
d
A2
...au
fein
erb
ekannten
Prozessorarch
itektu
rbasieren
MSP
430A
rchitek
tur,
Ja
A3
...m
itein
erE
ntw
icklu
ngsu
mgeb
ung
der
Industrie
Eclip
se,fu
nktion
iert
den
Prozessor
program
mieren
und
deb
uggen
Program
mieren
,Ja
Deb
uggen
,N
ein
A4
...in
einer
Hard
wareb
eschreib
ungssp
rache
wie
VH
DL
NE
O430
liegtin
VH
DL
vor
vorliegenund
program
mierb
arsein
Program
mieren
,Ja
Deb
uggen
,N
ein
A5
...ein
estan
dard
isierteSch
nittstelle
aufw
eisen,
ub
erw
elche
weitere
NE
O430
mit
Wish
bon
eau
sgestattet
Kom
pon
enten
hin
zugefu
gtund
angeb
unden
werd
enkon
nen
und
erfolgreichgetestet
A6
...b
ezogenau
fdie
Anw
endung,
NE
O430
istein
16-Bit
Prozessor,
bevorzu
gtein
8-Bit
oder
16-Bit
Prozessor
sein.
eignet
sichfu
rklein
eund
großeSystem
e
Mit
großerenP
rozessorenw
irdder
Energieverb
rauch
großer
A7
...gerin
genE
nergieb
edarf
hab
en.
Ein
eV
ersorgung
ub
erN
icht
getestet
Batterie
oder
Energy
-Harvester
sollm
oglichsein
A8
...gerin
genR
essourcen
aufw
and
aufw
eisenJa,
siehe
Kap
itel6.3
verschied
ene
Kon
figu
rationsm
oglichkeiten
des
Prozessors
Ja,
Stan
dard
,M
inim
al,..
nur
notw
endige
Kom
pon
enten
wah
lweise
zusch
altbar
Tabelle 6.1: Vergleich der Anforderungen
Artur Werner 75
Evaluation der Implementierung eines NEO430 System
6.3 Ressourcen- und Energievebrauch
Die Implementierung des NEO430 auf einem FPGA verbraucht dessen Logikelemente
und embedded Speicher (Kapitel 3.3). Der verwendete Cyclone IV FPGA bietet 115k
Logikelemente an, sowie integrierte Speicherblocke die 9 kBit umfassen.
Als Referenzwert dient der Wert 1188 LE aus der Dokumentation vom NEO430 [24].
Genutzt wurde ebenfalls ein Cyclone IV FPGA der etwa 22k Logikelemente umfasst.
Bei diesem Verbrauch wurde der NEO430 in seinen default-Einstellungen integriert, das
heißt die Referenzimplementierung umfasst jedes Modul des NEO430 (Kapitel 4.3.1),
sowie 4 kB Programm-, 2 kB Datenspeicher und 2 kB Speicher des Bootloaders. Mit
den gleichen Einstellungen wurde der NEO430 auf dem Cyclone IV des DE2-115
Development-Boards implementiert. Die Ergebnisse der eigenen Implementierung sind
in der Tabelle 6.2, in der Default-Konfiguration dargestelllt.
Es wurde im Gegensatz zur Referenzimplementierung 1094 LE und 9,256 kB Speicher
verbraucht. Der Unterschied im Ressourcenverbrauch ist auf die Große der FPGAs
zuruckzufuhren. Im Cyclone IV Handbuch [12] ist vermerkt, dass der FPGA aus der
NEO430 Dokumentation die Maße 14 mm x 14 mm hat und der in dieser Arbeit ge-
nutzte FPGA 29 mm x 29 mm groß ist. Das bedeutet das Speicher und Logikelemente
auf kleinerem Raum verdrahtet werden mussen.
In Tabelle 6.2 ist zu dem der Ressourcenverbrauch weiterer getesteter Konfigurationen
dargestellt.
• Minimale Konfiguration; implementiert nur die CPU, sowe 4 kB Programm-, 2kB
Datenspeicher und 2 kB Speicher des Bootloaders. Das CPU-Modul des NEO430
verbrauch 676 LE.
• Default Konfiguration mit maximalem Speicher; hierfur wurde die maximal adres-
sierbare Speicherkapazitat von 64 kB des NEO430 getestet. Verbraucht werden
68,648 kB integrierter Speicher des FPGAs, sowie 1114 LE.
• Default Konfiguration ohne Wishbone-Interface; bei einem Verbrauch von 1051
LE und einem Differenzvergleich mit der default-Konfiguration, verbraucht das
Wishbone-Interface in etwa 40 LE.
• Default Konfiguration mit CRC-Modul; die Beispielanwendung mit dem CRC-
Modul wird uber Wishbone mit dem NEO430 in seinen Standard-Einstellungen
verbunden und verbraucht hierfur 1253 LE, von denen 160 LE das CRC-Modul
mit seinem Wishbone-Slave-Interface beansprucht. Der Verbrauch von 160 im
Vergleich mit der Minimalen Konfiguration von 676 LE ist relativ gesehen sehr
viel fur ein CRC-Modul.
76 Artur Werner
Evaluation der Implementierung eines NEO430 System
Der implementierte NEO430 arbeitet mit einer Frequenz von 50 MHz die das DE2-115
Development Board zur Verfugung stellt. Aus der Dokumentation des NEO430 geht
hervor, dass dieser auf der Altera-Cyclone IV-Plattform mit etwa 116 MHz betrieben
werden kann [24]. Bei in dieser Arbeit verwendetem FPGA ergab der Synthetisierungs-
bericht in der Default-Konfiguration mit CRC-Modul eine maximale Frequenz von etwa
104 MHz.
Konfiguration Logikelemente Speicher
minimale 676 9,256 kB
default 1094 9,256 kB
default, max. Speicher 1114 68,648 kB
default, ohne Wishbone 1051 9,256 kB
default, mit CRC Modul 1253 9,256 kB
Referenzwert 1188 9,896 kB
Tabelle 6.2: Logik- und Speicher-Ressourcenverbrauch
Energievebrauch
Der Energieverbrauch des NEO430 und dessen Komponenten wurden nicht getestet.
Ein Energieverbrauch laut [34], wird mit internen Spannungsmessungen ermittelt und
anschließend auf die einzelnen System-Komponenten heruntergebrochen, um auf den
Verbrauch von Prozessorkern, Speicher und I/O-Gerate Ruckschlusse zu ziehen. Da-
durch erreichen sie eine ungefahre Abschatzung des Energieverbrauches.
Fur eine erste Einschatzung des Energieverbrauch vom NEO430 sicherlich ein guter
Ansatz, jedoch ist die Messung stark davon abhangig mit welchen Komponenten der
NEO430 auf den FPGA konfiguriert wird, ob die Konfiguration optimiert auf den
FPGA geladen wurde, mit welcher Frequenz der NEO430 arbeitet und wie optimiert
das C-Programm geschrieben ist, so dass die CPU des NEO430 oft in den Schlafzu-
stand und somit in einen Energiesparmodus versetzt wird.
Daher ist der Energieverbrauch mit einem ASIC, welches den NEO430 integriert, bes-
ser geeignet und es ist ein besserer, direkter Vergleich mit einem gangigen MSP430
moglich, um zu uberprufen ob der NEO430 mit dem Verbrauch des MSP430 mithalten
kann.
Artur Werner 77
Zusammenfassung und Ausblick
7 Zusammenfassung und Ausblick
In Anwendungen fur Low-Power-Soc-Systeme mochte man zunehmend ein komplettes
System auf einem Chip integrieren. Hierfur wird oftmals eine Recheneinheit bezie-
hungsweise ein Prozessor benotigt. Fur Low-Power-Systeme ist die Integrierung eines
Prozessors an hohe Anforderungen gebunden.
Daher wurde in dieser Arbeit der aktuelle Stand von verfugbaren Hardcore- und Softcore-
Prozessoren untersucht. Unter Einbeziehung der Randbedingungen einer Low-Power-
Anwendung, lag der Fokus in dieser Arbeit auf Softcore-Prozessoren. Verschiedene
Softcore-Prozessoren wurden untereinander mit zusatzlichen Kriterien verglichen.
Ausgewahlt wurde der NEO430 Softcore-Prozessor. Der NEO430 basiert auf der Be-
fehlssatz Architektur eines MSP430 von Texas Instrument. Die Implementierung des
NEO430 wurde auf einem DE2-115 Development Board von Terasic durchgefuhrt. Die-
ser verbaut einen Cyclone IV FPGA von Altera.
Mit dem NEO430 als Recheneinheit wurde ein Beispiel System konzipiert, welches
als erstes ein Lauflicht und anschließend eine CRC-Berechnung implementiert. Das
CRC-Modul wurde fur diese Arbeit entwickelt und implementiert eine serielle CRC-
Berechnung, sowie ein Wishbone Interface zur Anbindung an den NEO430.
Im Zuge dessen wurde die Programmierbarkeit, Erweiterbarkeit und der Ressourcenver-
brauch des NEO430 evaluiert. Das CRC-Modul und die Wishbone Schnittstelle wurde
zuerst mit einer Simulation und anschließend mit dem NEO430 auf dem Development
Board verfiziert.
Durch die starke Verbreitung der MSP430-Serie in der Industrie, ist der NEO430 ein
interessanter Kandidat fur Low-Power-SoC-Systeme. Diese Arbeit zeigt, dass die we-
sentlichen Anforderungen an den Softcore-Prozessor fur Integration in Low-Power-Soc-
Systemen mit dem NEO430 erfullt werden:
• Der NEO430 verfugt uber eine 16-Bit Architektur mit optionalen Komponenten,
durch denen ein minimaler Logikverbrauch ermoglicht wird.
• Der NEO430 ist mit einer standardisierten Wishbone-Schnittstelle ausgestat-
tet, uber die einfach weitere Komponenten an das System angebunden werden
konnen.
Artur Werner 79
Zusammenfassung und Ausblick
• Durch sein freies Lizenzmodell und den in VHDL verfugbaren Source-Dateien
kann der NEO430 auf einer beliebigen Zieltechnologie implementiert werden
• Bei dem NEO430 handelt es sich um einen gut dokumentierten Softcore, mit dem
es moglich ist innerhalb weniger Tage einen Prozessor lauffahig zu implementie-
ren. Ein großerer Zeitaufwand entsteht, wenn zusatzlich eigene implementierte
oder frei verfugbare Module uber Wishbone angebunden werden sollen.
Der NEO430 bringt jedoch auch Nachteile bei der Programmierung mit sich. Er kann
unter Nutzung des MSP430-Befehlssatzes uber UART und mit Hilfe der Entwicklungs-
umgebung von Eclipse programmiert werden. Die Standard-Entwicklungsumgebung
Code Composer Studio von TI kann derzeit nicht genutzt werden, um damit den
NEO430 zu programmieren und zu debuggen. Weiterhin ist ein On-Chip-Debuggen
nicht moglich und nur uber aufwandig hinzugefugter Test-Code moglich.
Dennoch ist der NEO430-Softcore-Prozessor ein sehr interessanter Kandidat fur eine
Integration in Low-Power-SoC-Systemen.
Ausblick
Um die Anforderungen an den NEO430 vollstandig zu erfullen, erfordert es einer De-
bugging Einheit im NEO430 System, sowie einer USB-Programmier- und Debugging-
Schnittstelle, um mit Standard Entwicklungsumgebungen wie Code Composer Studio
zu entwickeln. Dazu muss die Debugging Einheit an den internen Bus angekoppelt und
Zugriff auf die CPU Einheit gewahrt bekommen.
Weiterhin ist die Uberlegung wert, ein Echtzeit Betriebssystem wie FreeRTOS auf
den NEO430 zu implementieren. Notwendige Hardware wie Timer und Interrupt ste-
hen vom NEO430 bereit. Das Betriebssystem steuert die Abarbeitung von mehreren
Aufgaben und kann in einem großeren System, sowie einem kleinen Low-Power-System
Einsatz finden.
Zu guter Letzt steht noch die Implementierung auf einen ASIC aus. An diesem kann der
NEO430 in einem echten System getestet und verifiziert werden. Zusatzlich kann der
Energieverbrauch des NEO430 mit einem gleichwertigen MSP430 verglichen werden.
80 Artur Werner
Quellen
Quellen
[1] Brinkschulte, U.; Ungerer, T.; 2010. Mikrocontroller und Mikroprozessoren.
Springer-Verlag Berlin Heidelberg. 3. Auflage ISBN 978-3-642-05398-6
[2] SoC Abbildung.
http://www.directindustry.de/prod/cypress-semiconductor/
product-34220-200113.html, Zugriff 23.6.2017
[3] Gessler, R.; 2014. Entwicklung Eingebetteter Systeme, Vergleich von Entwick-
lungsprozessen fur FPGA- und Mikroprozessor-Systeme Entwurf auf Systemebe-
ne. Springer Vieweg. 1. Auflage ISBN 978-3-8348-2080-4
[4] Lange, W.; Bogdan, M.; 2013. Entwurf und Synthese von Eingebetteten Systemen,
Ein Lehrbuch.
Oldenbourg Verlag ISBN 978-3-486-71840-9
[5] Muller, H; Walz, L.; 2005. Mikroprozessortechnik.
Vogel Business Media. 7. Auflage ISBN 978-3834330239
[6] Hellmann, R.;2013. Rechnerarchitektur, Einfuhrung in den Aufbau moderner
Computer.
De Gruyter Oldenbourg. 1. Auflage ISBN 978-3-486-72003-7
[7] Wikipedia. Komponenten einer Von-Neumann-Architektur.
https://upload.wikimedia.org/wikipedia/commons/thumb/d/db/
Von-Neumann_Architektur.svg/220px-Von-Neumann_Architektur.svg.png
Zugriff 13.07.2017.
[8] Wikipedia. Complex Instruction Set Computer.
https://de.wikipedia.org/wiki/Complex_Instruction_Set_Computer
Zugriff 17.07.2017
Artur Werner i
Quellen
[9] ARM Processors Homepage.
https://www.arm.com/products/processors Zugriff 17.07.2017
[10] Gehrke, W:; Winzker, M.; Urbanski, K.; Woitowitz, R.; 2016.
Digitaltechnik - Grundlagen, VHDL, FPGAs, Mikrocontroller.
Springer Vieweg. 7. Auflage ISBN 978-3-662-49731-9.
[11] Altera. Cyclone IV Architektur.
https://www.altera.com/products/fpga/cyclone-series/cyclone-iv/
features.html Zugriff 18.07.2017
[12] Altera. Cyclone IV Handbook.
https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/
literature/hb/cyclone-iv/cyclone4-handbook.pdf
[13] Reichardt, R.; 2013. Lehrbuch Digitaltechnik - Eine Einfuhrung mit VHDL.
De Gruyter Oldenbourg 3. Auflage ISBN 978-3-486-72765-4
[14] Xilinx. SoC Portfolio.
https://www.xilinx.com/products/silicon-devices/soc.html
Zugriff 20.07.2017
[15] Intel (Altera). SoC Portfolio.
https://www.altera.com/products/soc/portfolio.html Zugriff 20.07.2017
[16] Intel (Altera). Cyclone V SoC Features.
https://www.altera.com/products/soc/portfolio/cyclone-v-soc/
features.html Zugriff 20.07.2017
[17] Rui Jia, Colin Yu Lin, Zhenhong Guo, Rui Chen, Fei Wang, Tongqiang Gao,
Haigang Yang.
Published in: Field Programmable Logic and Application (FPL)
A Survey of Open Source Processors for FPGAs.
INSPEC Accession Number: 14692827
[18] Wikipedia. GPL Lizenz.
https://de.wikipedia.org/wiki/GNU_General_Public_License
Zugriff 16.04.2017
ii Artur Werner
Quellen
[19] Wikipedia. LGPL Lizenz.
https://de.wikipedia.org/wiki/GNU_Lesser_General_Public_License
Zugriff 16.04.2017
[20] Wikipedia. MIT Lizenz.
https://de.wikipedia.org/wiki/MIT-Lizenz Zugriff 16.04.2017
[21] Wikipedia. BSD Lizenz.
https://de.wikipedia.org/wiki/BSD-Lizenz Zugriff 16.04.2017
[22] Wikipedia. GCC.
https://de.wikipedia.org/wiki/GNU_Compiler_Collection
Zugriff 21.07.2017
[23] OpenCores. Wishbone B4 specification.
https://opencores.org/cdn/downloads/wbspec_b4.pdf
[24] Nolting, S.; The NEO430 Processor.
April 2017 https://github.com/stnolting/neo430, Zugriff 5.4.2017.
[25] Texas Instrument. Peripheriebauteile.
http://www.ti.com/lsds/ti_de/microcontrollers-16-bit-32-bit/msp/
peripherals.page Zugriff 21.06.2017
[26] Hoffmann, D.; 2014. Einfuhrung in die Informations- und Codierungstheorie.
Springer Vieweg. 1. Auflage ISBN 978-3-642-54002-8
[27] Pehl, P.; 2001. Digitale und Analoge Nachrichtenubertragung, Signale, Codierung,
Modulation, Anwendungen.
Huthig Verlag. 2. Auflage ISBN 3-7785-2801-7
[28] IP-Modul FIFO.
http://freerangefactory.org/cores/memory_core/srl_fifo/index.html,
Source Code https://github.com/fabriziotappero/ip-cores/blob/memory_
core_srl_fifo/rtl/srl_fifo_16.vhd Zugriff 6.6.2017
[29] Fibi. First In First Out - PEPS Bilddatei.
http://de.wikipedia.org/w/index.php?title=Datei:FIFO_PEPS.png&
filetimestamp=20040708055803&#file Zugriff 9.08.2017
Artur Werner iii
Quellen
[30] FIFO Dokumentation.
https://github.com/fabriziotappero/ip-cores/blob/memory_core_srl_
fifo/doc/srl_fifo_core.pdf Zugriff 6.6.2017
[31] Texas Instrument. MSP430 Compiler Toolchain.
http://software-dl.ti.com/msp430/msp430_public_sw/mcu/msp430/
MSPGCC/latest/index_FDS.html Zugriff 3.5.2017
[32] TeraTerm. UART Terminal Programm.
https://ttssh2.osdn.jp/index.html.en Zugriff 3.5.2017
[33] Eclipse IDE.
https://de.wikipedia.org/wiki/Eclipse_(IDE) Zugriff 21.07.2017
[34] Giefers, H., Polig, R., Hagleitner, C.,
Journal of Signal Processing Systems (2016) Volume 85: Seite 307.
https://doi.org/10.1007/s11265-015-1057-6
iv Artur Werner
top related