Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal...

100
Bachelor-Thesis Implementierung von Softcore-Prozessoren und/oder weiteren IPs (Intellectual Properties) in FPGAs Fakult¨ at Elektrotechnik und Informationstechnik Artur Werner Studiengang: Elektrotechnik / Informationstechnik Fachrichtung: Kommunikationstechnik Anschrift: Im Spatzenwinkel 3, 77694 Kehl-Marlen Email-Adresse: [email protected] Telefon: 07854 9899971 Betreuer: Prof. Dr.-Ing. Elke Mackensen Prof. Dr.-Ing. Axel Sikora Bearbeitungszeitraum: 13. M¨ arz 2017 bis 31. August 2017

Transcript of Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal...

Page 1: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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: [email protected]

Telefon: 07854 9899971

Betreuer: Prof. Dr.-Ing. Elke Mackensen

Prof. Dr.-Ing. Axel Sikora

Bearbeitungszeitraum: 13. Marz 2017 bis 31. August 2017

Page 2: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter
Page 3: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 4: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter
Page 5: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 6: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter
Page 7: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 8: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 9: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 10: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 11: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 12: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 13: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 14: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 15: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 16: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter
Page 17: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 18: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 19: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 20: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 21: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 22: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter
Page 23: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 24: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 25: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 26: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 27: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 28: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 29: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 30: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 31: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 32: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 33: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 34: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter
Page 35: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 36: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 37: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 38: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 39: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 40: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 41: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

Analyse und Vergleich bestehender Hardcore- und Softcore-Prozessoren

Tabelle 4.2: Detaillierte Ubersicht vorausgewahlter Softcore-Prozessoren

Artur Werner 25

Page 42: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 43: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 44: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 45: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 46: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter
Page 47: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 48: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 49: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 50: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 51: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 52: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 53: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

Konzept und Implementierung eines Demonstrator-Systems

Abbildung 5.4: Interne Verschaltung Top-Level Design Teil 1

Artur Werner 37

Page 54: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

Konzept und Implementierung eines Demonstrator-Systems

Abbildung 5.5: Interne Verschaltung Top-Level Design Teil 2

38 Artur Werner

Page 55: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

Konzept und Implementierung eines Demonstrator-Systems

Abbildung 5.6: Interne Verschaltung Top-Level Design Teil 3

Artur Werner 39

Page 56: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 57: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 58: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 59: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 60: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 61: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 62: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 63: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 64: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 65: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 66: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 67: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 68: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 69: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 70: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 71: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 72: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 73: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 74: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 75: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

Konzept und Implementierung eines Demonstrator-Systems

Abbildung 5.17: Simulationsfenster von 3 CRC-Berechnungen

Artur Werner 59

Page 76: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 77: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 78: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 79: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 80: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 81: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 82: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 83: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 84: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 85: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 86: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 87: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 88: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 89: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 90: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 91: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 92: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 93: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 94: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter
Page 95: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 96: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 97: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 98: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 99: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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

Page 100: Implementierung von Softcore-Prozessoren und/oder … FIFO-Source-Code ... UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous/Asynchronous Receiver Transmitter

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