Einrichten einer Entwicklungsumgebung f¼r ein System-On-A - KIT

Einrichten einer Entwicklungsumgebung für ein System-On-A-Chip(SoC) mit

Softcore-CPU(VHDL) und Entwickeln von Testprogrammen

PROJEKTBERICHT

für die Prüfung zum

Bachelor of Engineering

des Studienganges Informationstechnik

an der

Dualen Hochschule Baden-Württemberg Karlsruhe

von

Aaron Frueh

21.01.2010

Bearbeitungszeitraum 12 Wochen

Matrikelnummer 115834

Kurs TIT08

Ausbildungsfirma Karlsruher Institut für Technologie

Betreuer Dipl. Ing. Stefan Dietze

Projektbericht Aaron Frueh

AF - 2

Inhalt

1 Einleitung................................................................................................................ 4

2 Einführung .............................................................................................................. 5

2.1 FPGA ........................................................................................................................ 5

2.2 IP-Cores bei FPGAs .................................................................................................. 7

2.2.1 Hard-Core ........................................................................................................... 7

2.2.2 Soft-Core ............................................................................................................ 8

3 Konzeption ............................................................................................................. 9

3.1 Konzept 1 – Linux Full ............................................................................................ 9

3.2 Konzept 2 – Linux Min ......................................................................................... 10

3.3 Konzept 3 – MC FlashExt - MC mit externem Flash .......................................... 10

3.4 Konzept 4 – MC-Flash - MC mit internem Netzflash ......................................... 11

3.5 Auswahl eines Soft-Cores .................................................................................... 12

3.6 Anbindung ans Ethernet ...................................................................................... 13

4 Testprogramm eines PHY-Chips mit dem ARM-Develop-Kit ................................ 14

5 Softcore CPU Leon 3 ............................................................................................ 15

5.1 Entwicklungsgeschichte ...................................................................................... 15

5.2 Erstellen des Cores .............................................................................................. 16

5.3 Entwickeln auf dem Leon .................................................................................... 17

5.3.1 Ein Simples Beispiel ....................................................................................... 17

5.3.2 Der Simulator - TSIM ...................................................................................... 18

5.3.3 Der Hardware Monitor – GRMON .................................................................. 20

6 Lösungskonzept mit Linux.................................................................................... 21

6.1 Snapgear Linux .................................................................................................... 21

6.2 Testboard - Xilinx Spartan 3A ............................................................................. 21

6.3 Linux 2.6 Kompilieren ......................................................................................... 22

6.4 Optimierung der Größe ........................................................................................ 25

6.5 Autostart Befehle in das Bootscript einbauen ................................................... 26

7 Lösungskonzept als Microcontroller .................................................................... 27

7.1 Der Ethernet IP-Core GRETH ............................................................................... 27

7.2 Verwendung von Linux Treibern .......................................................................... 29


AF - 3

7.3 Testprogramm für den Greth auf MAC-Ebene .................................................... 32

8 Zusammenfassung und Ausblick ......................................................................... 37

Literaturverzeichnis ............................................................................................................ 38

Abbildungsverzeichnis ........................................................................................................ 40

Tabellenverzeichnis ............................................................................................................ 42

A. Anhang ................................................................................................................. 43

A1. Allgemeine Hinweise: ........................................................................................... 43

A2. Die Greth Register ................................................................................................ 44

A3. Installation Gaisler der Entwicklungsoberfläche unter Windows ..................... 47

A4. Installation Gaisler der Entwicklungsoberfläche unter Linux ........................... 47


AF - 4

1 Einleitung

Am 1. Oktober 2009 wurde das Karlsruher Institut für Technologie (KIT) als Zusammen-

schluss des Forschungszentrums Karlsruhe und der Universität Karlsruhe gegründet. Das

KIT gehört seit dem mit knapp 8000 Mitarbeitern zu einem der weltweit größten For-

schungs und Lehreinrichtungen. Ein Ziel unter anderen ist, das führende europäische

Zentrum der Energieforschung zu werden (1).

Im Rahmen dieser Umstellungen hat auch das Institut für Angewandte Informatik (IAI)

den Schwerpunkt „Energie“ gestärkt.

In dem Themenbereich Geothermie entstand die Idee, mit einem Sondenroboter in tiefe

Bohrungen vorzustoßen und dabei ein gekühltes Cargo-Modul mit einer Schnittstelle für

unterschiedlichste Mess–und Aufnahmegeräte zeitnah und hauptsächlich für wissen-

schaftliche Zwecke anzubieten. In 6000 Metern Tiefe und bei ca. 200°C soll eine dauer-

hafte Hochgeschwindigkeitsverbindung sichergestellt werden, um auch hohes Datenauf-

kommen, wie es bei einer hochauflösenden Kamera der Fall wäre, live übertragen zu

können. Damit man unterschiedliche Hardware anzusteuern und Messdaten verarbeiten

und versenden kann, wird ein Embedded System im Hochtemperaturbereich (HT) benö-

tigt. Dieses Teilprojekt wurde „HiTES“ (High Temperature Embedded System) genannt.

Da es einfacher realisierbar ist, wenige elektronische Komponenten in HT zu betreiben,

wurde die Strategie verfolgt, ein System-On-A-Chip (SoC) zu realisieren.

Um für dieses SoC maximale Flexibilität und dennoch umfangreiche Softwareunterstüt-

zung zu erhalten, wird versucht auf einem FPGA (Field Programmable Gate Array) eine

geeignete SoftCore-CPU zu betreiben und mit dieser dann eine Hochgeschwindigkeitsver-

bindung, vorzugsweise TCP/IP, aufzubauen. Dies soll entweder mit einer Linux-Variante

oder mit einer eigenen Lösung erfolgen.


AF - 5

2 Einführung

Im Folgenden wird eine Einführung in die Grundlagen und verwendeten Begriffe dieser

Projektarbeit gegeben.

2.1 FPGA

Der FPGA – Field Programmable Gate Array – zu Deutsch, eine programmierbare Matrix

von logischen Bausteinen und Speicherelementen, ist ein sehr flexibel einsetzbares Bau-

teil. Auf diesem können theoretisch alle Arten von digitalen Schaltungen realisiert wer-

den.

Der interne Aufbau eines FPGAs ist im Grundlegenden immer gleich. Es besteht aus pro-

grammierbaren Lookup-Tabellen (LUT) mit jeweils einem 1-Bit Flip-Flop (im Bild nicht zu

sehen). In aktuellen FPGAs werden noch Multiplexer (MUX) verbaut, welche schnelle Sig-

nalpfade, das Ansteuern bzw. Umgehen von Flip-Flops, Rückkopplungen oder Verbindun-

gen mit Nachbarblöcken erlauben. Die LUTs können abhängig von der Anzahl ihrer Ein-

gänge jede Binärfunktion realisieren, die dann als Wahrheitstabelle abgespeichert wird.

Im Vergleich der unterschiedlichen Architekturen (siehe Grafik oben), hat das rechte Bild

pro Slice achtmal so viele Möglichkeiten konfiguriert zu werden wie die Architektur im

linken Bild. Im rechten Bild können pro Slice bis zu 6-Bit Eingänge zu einem Ausgang de-

finiert werden oder auch 5 Bit Eingänge zu zwei Ausgängen. Im linken sind nur 4-Bit Ein-

gänge zu einem Bit Ausgang möglich. In der Theorie kann ein Virtex 5 Slice, acht Virtex 4

Abbildung 1 – FPGA Slice – Ein Xilinx Virtex 4 Slice (links) | Ein Xilinx Virtex 5 Slice (rechts) (2)


AF - 6

Slices ersetzen. In der Praxis schafft man es jedoch nicht, die Ressourcen komplett aus-

zunutzen und es können nur ungefähr zwei ersetzt werden (2).

Darüber hinaus enthält ein FPGA noch RAM-Blöcke, Multiplizierer, Taktgeneratoren und

Takterkenner (CDR1), wie SerDes2.

Ein FPGA ermöglicht grundsätzlich die parallele Abarbeitung von digitalen Schaltungen,

was zur Folge hat, dass hoch komplexe Aufgaben durch eine optimierte Implementierung

als IP-Core viel effizienter ausgeführt werden können. Ein IP-Core (siehe 2.22.2 unten) ist

ein Schaltungsmodul, welches einzeln oder mehrmals als Netzliste in eine FPGA Schal-

tung integriert werden kann.

Durch ihre Anpassungsfähigkeit sind FPGAs besonders bei System-on-a-Chip-Lösungen

(SoC) beliebt, denn es ist möglich, CPUs, Ethernet-Anbindung oder auch Feldbussunter-

stützung in einen einzigen FPGA zu integrieren. Darüber hinaus kann man alles, was auf

dem FPGA entwickelt wurde, später in einen ASIC3 portieren (3).

Die bekanntesten Programmiersprachen für FPGAs, VerlilogHDL4 und VHDL5 sind be-

schreibende Sprachen. Durch Definieren von Datentypen und Regeln wird die Funktiona-

lität beschrieben und daraus können sogenannte Netzlisten für die FPGAs generiert wer-

den. Diese Netzlisten sind der Schaltplan für den jeweiligen FPGA. Bei Xilinx™, Altera™

und Lattice™ muss die Netzliste bei jedem Powerup eingespielt werden, z.B. über ein ex-

ternes EEPROM oder Flash. Bei Actel™, einer Firma, die sich hauptsächlich auf Weltraum-

und Militäranwendungen spezialisiert hat, werden die Netzlisten durch einen internen

Flash gehalten und stehen beim Powerup sofort zur Verfügung.

1 CDR: Clock Data Recovery

2 SerDes: Häufig auch beim SGMII (Serial Gigabit Media Independent Interface) eingesetzt, ein Wandler

zwischen Parallelen und Seriellen Daten, mit der Möglichkeit dabei den Takt zu regenerieren.

3 Application Specific Integrated Circuit, ASIC - Anwendungsspezifische Integrierte Schaltung: Ein „fest“

gebrannter Chip. Die Netzlisten von FPGA’s können in solchen Chips verwirklicht werden – Für die

Massenproduktion zu empfehlen.

4 Verlilog Hardware Description Language

5 Very High Speed Integrated Circuit Hardware Description Language


AF - 7

2.2 IP-Cores bei FPGAs

IP-Cores gibt es als Netzliste oder als Quellcode z.B. in VHDL. FPGA-Hersteller wie Xilinx™

oder Altera™ stellen mit ihren Entwicklungswerkzeugen hauseigene IP-Cores zum Teil mit

Lizenz zu Verfügung. Darüber hinaus gibt es „Third Party“ Vendor IP-Cores und eine

Sammlung von Open Source Projekten auf OpenCores.org (4), die besser auf Hardware

unterschiedlicher Hersteller angepasst werden können.

IP-Cores können miteinander verknüpft werden und gemeinsam in den FPGA gebrannt

werden. Ebenfalls ist es möglich, den gleichen IP-Core mehrmals in einen FPGA einzu-

bauen und somit ist auch ein Multi-CPU-Core-System in einem einzigen FPGA-Chip reali-

sierbar.

2.2.1 Hard-Core

Hard-Cores sind als fertige Schaltung vom Hersteller unveränderbar in dem Chip des

FPGAs integriert. Der Vorteil dabei ist, dass Hard-Cores weniger Chipfläche belegen und

meist auch schneller arbeiten als mit frei programmierter Logik implementierte Soft-

Cores. Leider ist es schwierig, eigene Implementierung an den Hard-Core anzubinden.

Portierungen zu anderen Logikfamilien sind unmöglich. Beispiele von Hard-Cores sind

leistungsfähige Prozessoren, wie PowerPC-Cores oder Ethernet-Schnittstellen, die mit frei

programmierbarer FPGA-Logik auf einem Chip zusammengefasst werden können (5).

http://de.wikipedia.org/wiki/PowerPC

http://de.wikipedia.org/wiki/Ethernet


AF - 8

2.2.2 Soft-Core

Ein Soft-Core stellt einen IP-Core mit vollständiger Funktionalität gleich einer CPU bzw.

eines Mikrocontrollers dar. Die Taktraten, die man mit einem Soft-Core erreichen kann,

sind natürlich viel langsamer als auf einem entsprechenden Hard-Core.

Name Firma Programmierung Toolchain Lizenz Quellcode

LatticeMico32 Lattice™ (Open)

(6)

asm, C, C++ GCC, MSB Open

IP-Core

Ja, Verilog

Leon Aeroflex Gaisler™

(Open)

(7)

asm, C, C++ GCC (SPARC-

Kompatibel)

GPL Ja, VHDL

MicroBlaze Xilinx™

(8)

asm, C GCC, EDK EDK Nein

NIOS II Altera™

(9)

asm, C, C++ GCC, SOPC,

EDS

EDK Nein

OpenRISC (OpenCore)

(10)

asm, C, C++ GCC Open

IP-Core

Ja, Verilog

Plasma (OpenCore)

(11)

asm, C. C++ GCC (MIPS

Kompatibel)

GPL Ja, VHDL

ZylinCPU (ZPU) (OpenCore)

(12)

asm, C. C++ GCC GPL Ja, VHDL

Tabelle 1 – Beispiele unterschiedlicher Softcores (13)


AF - 9

3 Konzeption

In diesem Projekt werden sehr hohe Anforderungen an die Hardware gestellt. Deshalb ist

es nötig, für diese Projektarbeit mehrere Szenarien aufzuzählen und für die unterschied-

lichen Hardwarebedingungen passende Software-Lösungen zu finden. Die Konzepte ste-

hen für unterschiedliche Hardwareumsetzungen, wobei das Konzept „Linux Full“ die

Wunschlösung und das Konzept „MC-Flash“ die Notlösung darstellt. Im Laufe der Pro-

jektarbeit wird immer wieder auf die einzelnen Konzepte eingegangen.

3.1 Konzept 1 – Linux Full

Die bevorzugte Lösung wäre ein FPGA mit Softcore

und vollwertigem Linux, der bei 200°C (mit mög-

lichst geringer Kühlung) betrieben werden kann.

Um Linux betreiben zu können, wird externer Ram-

Speicher benötigt. Des Weiteren werden zwei Flash-

speicher, einer für die FPGA-Netzliste und einer für

das Linux-Boot Image, benötigt. Das interne RAM

würde hier dann als Puffer bzw. Cache für Linux

und bei eigenen Implementierungen der Bilderfas-

sung als Zwischenspeicher dienen

⊕ Vollwertiges Linux

⊕ Leichte Implementierung neuer Hardware-

Treiber durch ausführliche Bibliothek

⊕ Dateisystem (Filesystem) – Möglichkeit

Netzwerkressourcen anzubinden

⊖ Externe Anbindung von RAM nötig, benötigt mehr Platz und Leitungen

⊖ RAM ist sehr temperaturempfindlich

Abbildung 2 – Konzept 1 – Linux Full


AF - 10

3.2 Konzept 2 – Linux Min

Ziel dieser Lösung ist es, ein minimalistisches Linux

aufzusetzen, das komplett auf dem internen RAM

des FGPAs laufen kann. Dadurch fällt das externe

Ram komplett weg und es sind weniger Chips mit

eventueller Kühlung nötig. Ebenfalls würde sich die

Gesamtgröße der endgültigen Platine erheblich

verkleinern und einfacher werden(kein Daten-und

Adressbus). Die beiden Flashspeicher würden den-

noch benötigt werden. Wenn das Linux-Image noch

viel kleiner werden kann, dann ist es auch möglich,

alles in einem Flash-Speicher unterzubringen.

⊕ Linux

⊕ kein externes Ram

⊕ Leichte Implementierung neuer Hardware-

Treiber durch ausführliche Bibliothek

⊕ Dateisystem– Möglichkeit Netzwerkressourcen anzubinden

⊖ Hoher Aufwand, den internen Block-Ram als gewöhnlichen S-RAM anzubinden

3.3 Konzept 3 – MC FlashExt - MC mit externem Flash

Falls die minimale Linux-Version noch immer zu

groß für das interne RAM ist, muss eine eigene

Ansteuerung der kompletten Hardware, z.B. dem

Ethernet, entwickelt werden. Dies erfordert die

eigene Implementierung von Treibern sowie Initia-

lisierungen und Interrupt-Handling. Der zweite

Flash-Baustein für das Linux-Image würde nicht

mehr benötigt werden, sodass ein weiteres Bauteil

wegfiele.

⊕ Ein beinahe SOC, kein externes RAM

⊖ sehr schwer an neue Hardware anzupassen

(eigene Implementierung von Treibern)

⊖ kein Dateisystem

Abbildung 3 – Konzept 2 – Linux Min

Abbildung 4 – Konzept 3 – Microcontroller MC


AF - 11

⊖ keine Linux-Funktionalität

⊖ viel Programmieraufwand

3.4 Konzept 4 – MC-Flash - MC mit internem Netzflash

Falls es nicht möglich ist, die Flash-Bausteine bei

200C° zu betreiben, werden FPGA der Firma

Actel™ benötigt, die einen integrierten Flash-

speicher besitzen. Dieser Flashspeicher fasst nur

die Netzliste für den FPG. Es fallen noch weitere

Bauteile aus der Schaltung und im Schnitt könn-

ten höhere Betriebstemperaturen mit weniger

Kühlung erzielt werden. Das interne RAM ist je-

doch so klein, dass es auf keinen Fall möglich

ist, ein Linux zu betreiben.

⊕ SOC

⊕ kein Flash, kein RAM

⊖ VHDL bzw. VerilogHDL Anpassung nötig, da kein Mainstream FPGA

⊖ kein Dateisystem (Filesystem)

⊖ keine Linux-Funktionen

⊖ viel Programmieraufwand

Bei der Auswahl des FPGAs ist ebenfalls zu beachten, dass diese unterschiedlich viel an

„Logik“ fassen können. Dies führt bei Xilinx™ - und Altera™-Lösungen wahrscheinlich zu

keinen Problemen. Falls jedoch auf ein Actel™ FPGA zurückgegriffen werden muss, soll-

te folgende Tabelle beachtet werden.

Tabelle 2 –Vergleich der "Kapazität" pro Slice in der Praxis - (2)

Abbildung 5 – Konzept 4 – Microcontroller MC

mit internem Netzflash


AF - 12

3.5 Auswahl eines Soft-Cores

In „Tabelle 1 – Beispiele unterschiedlicher Softcores “ findet sich eine Übersicht der un-

terschiedlichen Softcores. Wie in den Konzepten (siehe Kapitel 3) beschrieben, sollte der

ausgewählte Softcore auf der Hardware unterschiedlicher Hersteller implementierbar

sein. Denn bei neuen HT-Chips eventuell der Hersteller gewechselt werden muss. Es

macht weniger Sinn, die herstellerspezifischen Soft-Cores von Xilinx™ und Altera™, also

MicroBlaze bzw. NIOS, zu verwenden, denn diese liefern nur ihre vorkompilierten Bit-Files

in optimierter Form für ihre FPGAs.

Der ZylinCPU ist ein sehr kleiner 32-Bit Prozessor. Das Ziel ist, dass möglichst viel Platz

auf dem FPGA übrig bleibt, um neben dem CPU weitere digitale Schaltungen (IP-Cores)

einbauen zu können. Der CPU dient dann hierbei eher als Kontrollschnittstelle, ist also für

das Projekt unterdimensioniert (12).

Übrig bleiben LatticMico32, OpenRISC und Leon3. In der Masterarbeit „Evaluation of

synthesizable CPU cores“ (14) wird ein Vergleich zwischen Leon2 und OpenRISC gezogen.

Es stellt sich heraus, dass Leon2 eindeutig leistungsfähiger ist. Des Weiteren bietet Leon

auch eine FT- (Fault Tolerant), also eine fehlerresistente Variante an, welche für den

Hochtemperaturbetrieb vorteilhaft sein könnte.

LatticeMico32 ist zwar ebenfalls ein OpenCore, jedoch ist dieser auch auf die FPGAs von

Lattice optimiert. Es wäre möglich, den Soft-Core auf andere FPGAs zu portieren. Der

Aufwand ist jedoch nicht abzuschätzen. Leon3 hingegen bietet für die unterschiedlichs-

ten FPGAs bereits konfigurierte Belegungen an, die nach Bedarf editiert werden können.

Die Entscheidung fällt folglich auf Leon bzw. Leon3.


AF - 13

3.6 Anbindung ans Ethernet

Die Anbindung an das Ethernet erfolgt über einen Ethernet-Core und einen PHY (siehe 4).

Als Ethernet-Core wurde der Greth von der Firma Gaisler™ gewählt (siehe 7.1). Greth un-

terstützt sowohl MII (Media Independent Interface) und RMII (Reduced Media Indepen-

dent Interface). Der Vorteil von RMII ist, dass aus Platzgründen die 16 Leitungen, die MII

benötigt, auf 10 bis sogar 6 Leitungen reduziert werden können, je nachdem, ob 10

MBit/s oder 100 MBit/s verwendet werden. Prinzipiell funktioniert dies, durch Erhöhung

der Taktrate des MII.

Abbildung 6 – Schematische Übersicht vom Leon mit der Anbindung an das Ethernet


AF - 14

4 Testprogramm eines PHY-Chips mit dem ARM-Develop-Kit

Dieses Testprogramm dient zum Hochtemperaturtest des PHYs DP83848YB. Um das

Testen einfacher zu gestalten, wurde es für das Development Board von ARM entwickelt

und nicht für Leon. Denn bei Leon werden zu viele weitere Programme benötigt.

Ein PHY bildet die Schnittstelle zur physikalischen Schicht. Er kodiert die Pakete bei Ge-

schwindigkeiten bis 100 MBit/s mit einem Manchester Codec und bei höheren Ge-

schwindigkeiten z.B. mit einem 8B10B Codec. Die Signale werden vom PHY entweder an

ein Kupfer oder Lichtwellenleiter-Medium geliefert. Die Grafik unten zeigt die Einordnung

eines PHYs in die OSI-Schichten. Ein PHY arbeitet also ausschließlich auf der physikali-

schen Ebene (gelb) und hat keine weitere Intelligenz. Alle höheren Schichten müssen in

der Software oder durch Soft-Cores implementiert werden.

Für die Implementierung des Treibers wurde der Basic-Emac-uip-Web-Testserver verwen-

det, welcher bereits einen Treiber für den DM9161A(15) implementiert hat. Mit dieser

Vorlage konnte ein Treiber für den DP83848YB (16) umgesetzt werden. Die Problematik

besteht darin, dass die Register komplett unterschiedlich sind. Somit mussten auch

Funktionalitäten anders implementiert und ausgelesen werden.

DM9161A DP83848YB

OUI: Organizationally Unique Identifier 0x606E 0x80017

PHYID1_OUI 0x0180 0x2000

PHYID2_OUI 0xB8A0 0x5C90

Abbildung 7 – Protokollstapel PHY

Tabelle 3 – Auszug der Identifier PHY DM9161A & DP 83848YB


AF - 15

5 Softcore CPU Leon 3

Die Firma Aeroflex Gaisler™ hat sich auf die Entwicklung von IP-Cores für FPGAs und

ASICs spezialisiert. Ihr Vorzeigeprodukt ist Leon, eine Soft-Core-CPU, die auf mehrere freie

und kommerzielle Betriebssysteme wie z.B. Linux angepasst wurde. Des Weiteren wird

eine umfassende Bibliothek an IP-Cores zur Verfügung gestellt, welche alle problemlos

mit Leon verknüpfbar sind.

5.1 Entwicklungsgeschichte

Leon 3 basiert auf der SPARC6 V8-Architektur. Die SPARC-Architektur wurde ursprünglich

von Sun Microsystems Inc™ entwickelt und von Fujitsu™ produziert. Im Jahr 1989 wur-

den die Rechte an der SPARC-Architektur an die SPARC International Inc. abgegeben,

welche bis heute die Open SPARC-Architektur weiterentwickelt hat und sie für jeden frei

zugänglich hält (17). Leon 3 obliegt komplett der GNU GPL Lizenz. Der komplette Source-

Code ist daher verfügbar und in alle möglichen FPGAs und ASICs portierbar. Außerdem ist

er multiprozessorfähig. Die Architektur erlaubt die Verwendung von bis zu 16 Prozessoren

in einem System, die entweder asymmetrisch (AMP7) oder symmetrisch (SMP8) arbeiten

können. Der Vorgänger Leon 2 wurde damals in Zusammenarbeit mit der ESA9 entwi-

ckelt. Leon 4 ermöglicht noch höhere Frequenzen, ist aber nur als kommerzielle Version

verfügbar. Alles, was auf Leon 3 entwickelt wird, kann auf Leon 4 portiert werden, falls

beschlossen würde, auf Leon 4 umzusteigen (7).

6 SPARC: Scalable Processor ARChitecture

7 AMP: asymmetric multiprocessing => asymmetrischer Multiprozessorbetrieb

8 SMP: synchronous multiprocessing => symmetrischer Multiprozessorbetrieb

9 ESA: European Space Agency

Abbildung 8 – Leon 3 – In einem Multiprozessor System (18)


AF - 16

5.2 Erstellen des Cores

In diesem Kapitel folgt eine Einführung in die grundlegende Erstellung von Leon. Zum

Testen wurde eine von der Firma Gaisler vorkompilierte Version verwendet, um Fehler

auszuschließen. Es wird immer der herstellerspezifische Compiler benötigt. Bei Xilinx™ ist

dies das Xilinx™ ISE. Darüber hinaus wird bei Windows noch für die Make-Erstellung ein

Linux-Subysystem wie MingW oder Cyqwin benötigt.

1. Das Package „grlib-gpl-1.0.21-b3848.tar.gz“ entpacken

2. Mit MingW oder Cygwin zum eben entpackten Ordner wechseln. „make help“ gibt

eine kurze Übersicht der Befehle

3. In den Unterordner des gewünschten Designs wechseln. Bei dem Beispiel in

„\designs\leon3-xilinx-xc3sd-1800“

4. „make xconfig“

Durch diesen Befehl können zahlreiche Einstellungen im Leon-Core vorgenommen

werden. Es können z.B. unterschiedliche Taktgeneratoren gewählt werden und

einzelne IP-Cores aktiviert und deaktiviert werden.

5. Nach dem Konfigurieren muss zuerst „make ise-map“ ausgeführt werden.

6. Danach wird durch „make ise“ eine Bitfile generiert


AF - 17

5.3 Entwickeln auf dem Leon

Die Firma Gaisler™ liefert eine modifizierte Entwicklungsumgebung von Eclipse 10 mit

einem eingebauten Bare-C Cross Compiler. Ein Cross-Compiler erlaubt, dass für ein ande-

res System ausführbarer Code erzeugt wird, der aber auf dem eigenen System nicht aus-

führbar ist. Es besteht die Möglichkeit entweder über GRMON (siehe 5.3.3) direkt auf der

Hardware zu debuggen oder mit einem Simulator, genannt TSIM (siehe 5.3.2), zu ver-

knüpfen. Eine Installationsanleitung für die Entwicklungsoberfläche finden Sie im An-

hang: A3 und A4

5.3.1 Ein Simples Beispiel

Bei dem im Folgenden aufgezeigten Beispiel „Hello World!“ ist zu beachten, dass eine

Standard-C-Bibliothek in das Projekt eingebunden werden muss. Diese ist dafür da, dass

die üblichen C-Funktionen auch verwendbar sind. Man könnte wie bei Linux die µCLib

verwenden, jedoch ist diese um einiges größer, da sie komplett auf Linux abgestimmt ist.

Die Firma Gaisler™ empfiehlt, sofern kein Linux gefahren wird, stattdessen die

NewLib1.13.0 zu verwenden, welche bei Gaisler™ heruntergeladen werden kann.

Dies muss unter in den Projekteinstellungen hinzugefügt werden:

C/C++ Build Settings SPARC Bare C Compiler Directories: (+I)

"..\..\newlib-1.13.0\newlib\libc\include"

"..\..\newlib-1.13.0\libgloss\sparc_leon\"

Und C/C++ Build Settings SPARC Bare C Linker Libaries (+L)

"..\..\newlib-1.13.0\"

10 Eclipse ist eine Open-Source Entwicklungsumgebung für mehrere Programmiersprachen. Sie kann mit

Plugins erweitert werden.


AF - 18

HelloWorld.c:

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

int main() {

printf("HelloWorld\n");

return 0;

}

5.3.2 Der Simulator - TSIM

TSIM ist eine von der Firma Gaisler™ bereitgestellte Leon3-Simulation, welche kostenlos

als EVAL-Version verfügbar ist. Leider ist es in der EVAL-Version z.B. nicht möglich, die

Größe des simulierten RAMs zu ändern. Weitere Informationen über die Funktionen von

TSIM befinden sich in der Dokumentation von Gaisler™.

In der Konsolenanwendung können die binären Leon-Files ausgeführt werden. An physi-

kalische Adressen können Breakpoints gesetzt werden, was jedoch sehr umständlich ist.

Eine sehr praktische Funktion ist, die Anzahl der Schritte und die benötigte Zeit auszuge-

ben.

Abbildung 9 – Cygwin mit Eval Version von TSIM, HelloWorld! wird geladen und ausgeführt


AF - 19

In Verbindung mit der Eclipse Oberfläche eignet sich der TSIM hervorragend zum Debug-

gen von Programmen.

1. In dem Debug-Pulldown-Menu auf Debug Configurations klicken.

2. Als Sparte den Debugger auswählen und mit „New…“ ein neues externes Ziel erstel-

len.

3. Einen repräsentativen Target Namen wählen und die Executable auswählen. Sofern

die PFAD-Variable korrekt gesetzt ist, genügt ein tsim-leon3. Ansonsten muss der

komplette PFAD zum Simulator angegeben werden. Die restlichen Einstellungen blei-

ben unverändert.

Abbildung 10 – TSIM Schnittstelle in der Eclipse Oberfläche konfigurieren


AF - 20

5.3.3 Der Hardware Monitor – GRMON

Von Grmon gibt es eine separate Anwendung. Diese wird Grmon-RCP genannt. Mit dieser

ist es möglich, die Hardware zu debuggen. Grmon-RCP liefert die CPU-Register, den

Cache, eine Anzeige des Speichers und vieles mehr.

Wie der TSIM kann der GRMON mit Eclipse verbunden werden, was das Debuggen von

Code direkt auf dem Chip ermöglicht.

Die Konfiguration verläuft ähnlich wie beim TSIM, bei Punkt 3 muss das Target von TSIM2

auf GRMON im Pull-Down-Menü geändert werden. Dann muss noch der UART Loopback

aktiviert werden.

Abbildung 11 – Debuggen mit Eclipse


AF - 21

6 Lösungskonzept mit Linux

In diesem Kapitel wird versucht, Konzept 1 „Linux Full“ und Konzept 2 „Linux Min“ zu

verwirklichen.

6.1 Snapgear Linux

Snapgear ist eine unbekanntere Linux Distribution für Embedded Systems11. Jedoch hat

die Firma Aeroflex Gaisler™ diese sehr gut an Leon angepasst. Sie verwenden die

Busybox (19) als Shell-und Tool-Anwendung. Diese versucht die normalen Linuxbefehle

für den Embedded Bereich besonders klein zu halten. Mit der Verbindung einer kleineren

optimierten C-Bibliothek, wie µCLib kann dies mehrere KByte Unterschied ausmachen.

6.2 Testboard - Xilinx Spartan 3A

Dies ist das Board, das zum Testen verwendet wurde. Es ist für das Projekt leider über-

dimensioniert. Es hat 128 MByte Ram und einen 64 MByte ROM-Speicher. Dies führt

während dem Testen zu Problemen, da das minimale System auf einem großen System

laufen muss. Eine Reduzierung des Speichers ist durch die MMU leider auch nicht mög-

lich. Es wird aber versucht, die Hardwareanforderungen für das minimale System abzu-

schätzen.

11 Der Ausdruck eingebettetes System (auch engl. embedded system) bezeichnet einen elektronischen

Rechner oder auch Computer, der in einen technischen Kontext eingebunden (eingebettet) ist. Dabei hat

der Rechner entweder die Aufgabe, das System, in das er eingebettet ist, zu steuern, zu regeln oder zu

überwachen. Oder der Rechner ist für eine Form der Daten- bzw. Signalverarbeitung zuständig,

beispielsweise beim Ver- bzw. Entschlüsseln, Codieren bzw. Decodieren oder Filtern.

Abbildung 12 – Xilinx™ Spartan3 1800 DSP


AF - 22

6.3 Linux 2.6 Kompilieren

Um Snapgear Linux zu kompilieren wird Linux-Umgebung empfohlen. Denn im Linux-

Source-Code befinden sich Dateien, die den gleichen Dateinamen tragen, jedoch eine

unterschiedliche Groß- und Kleinschreibung aufweisen, was bei Windows zu Problemen

führt.

1. Die Pakete „snapgear-2.6-p40.tar.bz2“ und „sparc-uclinux-3.4.4-1.0.3.tar.bz2“

entpacken (siehe auch A4.).

2. Im Verzeichnis an dem das Linux entpackt wurde wechseln und „make xconfig“

eingeben. Daraufhin erscheint folgendes Fenster.

Um genauere Optionen einstellen zu können muss bei Kernel- und Usersettings

ein ‚y‘ für yes ausgewählt werden. Wichtig ist auch die korrekte LibC-Version aus-

zuwählen. Hier wird uclibc verwendet, denn diese braucht am Ende deutlich weni-

ger Ressourcen.

3. Um den grundlegenden Netzwerksupport zu aktivieren, muss unter Networking

„TCP/IP Networking“ aktiviert werden. Ebenfalls muss unter den Network Devices

Abbildung 13 – (oben) make xconfig Start Start Screen | (unten) Kernel/Libary/Defaults Selection


AF - 23

„Ethernet 10/100 Mbit“ und „Generic Media Independent Interface (MII)“ Treiber

aktiviert werden. Die folgenden Screenshots können möglicherweise einen Ein-

blick geben, wie viele unterschiedliche Konfigurationen es gibt. Dies sind nur die

Einstellungen für den Kernel, es fehlen noch die Einstellungen für die Komanndo-

Shells und für jegliche Anwendungen, die man verwenden möchte. Dies wird in

den Vendor/User Settings vorgenommen. Am wichtigsten sind hier die Einstellun-

gen zur BusyBox, die viele Funktionalitäten einer normalen Shell mit einer klei-

neren Version ersetzt.

Abbildung 14– (oben) Kernel Konfigurations Fenser | (unten) Busybox Konfigurationsfenster


AF - 24

4. Nachdem die Einstellungen gemacht wurden, muss nur noch „make“ eingegeben

werden. Das Script handhabt den Rest von allein.

5. Um Linux zu booten, muss grmon-eval in der Konsole mit folgendem Befehlt ge-

startet werden: „grmon-eval -xilusb -mmu -nb“

Daraufhin kann mit dem „Load“-Befehl das eben generierte Linux-Image geladen

werden und dann mit „run“ ausgeführt werden. Dabei muss über den seriellen

Port eine Verbindung zum Leon aufgebaut werden.

Somit ist „Konzept 1 – Linux Full“ erfüllt. Das Image hat eine Größe von 3,8 MByte und

ist somit zu groß für „Konzept 2 – Linux Min“.


AF - 25

6.4 Optimierung der Größe

Um die Größe des Images zu reduzieren, müssen nicht benötigte Funktionen deaktiviert

werden. Besonders schwierig ist es, die Größe des Kernels zu verringern. Dort verbrau-

chen die Ethernet-Treiber auffallend viel Speicher, ca. 500 KByte. Durch das Deaktivieren

von IPV6 lassen sich ca. 200 KByte einsparen. Des Weiteren können durch Herausneh-

men der Kernel-Debug-Informationen und der Log-Dateien weiter KByte eingespart wer-

den. Die Größe des Kernels konnte von ca. 1500 KByte auf 1164 KByte reduziert werden

(siehe Abbildung 15).

Außerdem konnten die Daten von ca. 800KByte

auf 176Kbyte und die Initialisierungsdaten von

ca. 1500 KByte auf 676 KByte reduziert werden.

Um dies zu erreichen wurden viele Funktionen

der Busybox deaktiviert:

Archivier Unterstützung

Paket Installation mit apt-get

Webserver httpd

Texteditoren wie z.B. VI

Das Ausschalten vieler kleiner Funktionen, wie

das Umbenennen, Erstellen, Löschen von Datei-

en oder auch die Farbcodierung des „ls“-Befehls

(ein Kommando zum Anzeigen der aktuellen Da-

teien und Ordner im Verzeichnis) hat keine merk-

liche Ersparnis der Größe gebracht: weniger als 1

KByte.

In der Anwendung des in diesem Projektbericht

erreichten minimalen Linux-Images, kann man

sehen, dass zum laufenden Betrieb nur

800Kbyte Ram benötigt werden (siehe Abbildung

16). Das heißt also, dass der Kernel einmal komplett in das RAM geladen werden muss

Abbildung 15 – Bootup | Größenunterteilung des Images („reserved“ entspricht dem freiem Speicher im Ramblock)

Abbildung 16 – Linux Min, Meminfo


AF - 26

und danach wieder genügend Platz wäre, um andere Programme nacheinander zu initia-

lisieren und zu laden. Wenn es möglich wäre, den Ethernet-Treiber als einzelnes Modul

aus dem Gesamtimage auszulagern und dann erst zum Kernel hinzuzufügen nachdem

dieser gebootet hat, könnte man die Grenze von einem MByte unterschreiten. Prinzipiell

wäre es dann möglich, das Linux-System unter einem MByte Ram zu betreiben.

6.5 Autostart Befehle in das Bootscript einbauen

Das Ziel ist, von Anfang an einen Telnet-Server zu starten. Dazu muss herausgefunden

werden, wie die Befehle in das Binary-File hinein kompiliert werden kann.

Es gibt zwei Möglichkeiten, um den Bootup-Vorgang zu verändern. Die erste Möglichkeit

ist das Verändern einer relativ komplizierten C-Datei. Diese Datei hat einen eigenen

Handler, der unterschiedliche Initialisierung je nach Abhängigkeit nacheinander aufruft.

Diese wird von der Busybox überschrieben und befindet sich unter „/user/Busybox/init/“.

Um aber den Telnet-Server selbstständig zu starten, genügt ein einfacher automatisch

ausgeführter Linux Befehl. Um dies zu erreichen, muss die rcS-Datei

„/vendors/gaisler/leon3mmu/romfs/ etc/init.d/“ geändert werden. Dort können normale

Linux Befehle eingebaut werden und diese werden dann beim Booten ausgeführt.

Der Befehlssatz des kleinen Linux genügt nicht, um einen Telnet-Nutzer automatisch am

Anfang zu generieren. Deshalb muss am Anfang ein Passwort eingegeben werden. Eine

Möglichkeit wäre es, den Telnet-Server so zu bearbeiten, dass er keine Nutzerauthentifi-

zierung mehr benötigt. Dann könnte das Image durch Deaktivieren der Nutzerverwaltung

nochmals verkleinert werden.

Abbildung 17 – Automatischer Start vom Telnet Server und Anlegen von einem Neuen Nutzer


AF - 27

7 Lösungskonzept als Microcontroller

Um auf Konzept 3 und 4 hinzuarbeiten, wird nun versucht, eine alternative Implementie-

rung eines einfachen Betriebssystems zu realisieren. Die erste Anforderung ist die Inbe-

triebnahme der Hochgeschwindigkeitsverbindung, also des Ethernets.

7.1 Der Ethernet IP-Core GRETH

Der GRETH (Gaisler Research Ethernet) ist der von Gaisler™ bereitgestellte IP-Core zur

Ethernet-Ansteuerung. Der GRETH ist in der Lage, mehrere Pakete zu versenden und zu

empfangen, ohne dass dafür ein Eingreifen der CPU nötig ist. Der Greth ist ein Device,

das auf den Speicherbereich der CPU gelegt ist. Die Register können also direkt von der

CPU verändert werden. Die internen Register vom GRETH sind im Anhang 44A2 zu finden.

Über das MDIO Interface ist Greth in der Lage, Informationen vom PHY, wie z.B. deren

Adresse, auszulesen.

Abbildung 18 – Der interne Aufbau von Greth


AF - 28

Funktionsweise Pakete Versenden (Tx DMA12 Interface)

GRETH greift auf die Pakete, die er zu versenden hat, immer direkt und selbstständig zu.

Damit er weiß, wo die Pakete liegen, hat er diese Struktur. Das Adressfeld wird mit einer

Adresse im Speicher belegt, an der sich die zu versendenden Pakete befinden. Dies ist

aber meistens nicht nur ein Feld, sondern eine ganze Tabelle mit Adressen. Diese wird

dann vom GRETH nacheinander abgearbeitet und kann mit der Wrap-Flag (WR) zurückge-

setzt werden.

Wichtig ist, dass das „Trasmitter Discriptor Pointer“ – Register (Abbildung 29 – GRETH

Transmit Descriptor & Table Base Address Register s. 46) auf den Speicherbereich gelegt

wird, indem diese Deskriptor-Tabelle abgelegt ist.

Um die Pakete letztlich zu versenden, müssen die Enable-Flags (EN) gesetzt werden. Da-

mit GRETH weiß, dass neue Pakete zum Versenden vorhanden sind, wird das Transmit

Enable-Flag (TE) im Control-Register gesetzt (Abbildung 24 – Das GRETH Control Register

s. 44).

12 DMA: Direct Memory Access

Abbildung 19 – GRETH-Descriptor: Pakete Versenden (20)


AF - 29

Funktionsweise Pakete Empfangen (Rx DMA Interface)

Genau wie auch beim Versenden von Paketen, schreibt GRETH die Pakete selbstständig

in den Speicher. Statt einer Tabelle, in denen die Pointer auf die Pakete zum Versenden

liegen, muss hier ein Pointer-Puffer-Bereich festgelegt werden. Auch beim Empfangen der

Pakete wird automatisch der Pufferbereich durchlaufen und kann ebenfalls mit dem

Wrap-Flag (WR) zurückgesetzt werden. Es ist möglich, bei jedem empfangenen Paket ein

Interrupt auszulösen. Dafür muss das Interrupt Enable (IE) und im Control-Register das

Receive Interrupt (RI) gesetzt werden. Falls der Puffer nicht geleert wird, kommt es zu

einem Fehler.

7.2 Verwendung von Linux Treibern

Der erste Ansatz war, die Treiber von Linux abzulösen und in einem eigenen System zu

verwenden. Es stellte sich aber heraus, dass dies nicht so einfach ist, denn Linux ver-

wendet bei seinen Treibern eine universelle Struktur der Anbindung an den Kernel. Das

Linux Device Model (Linux Geräte Modell) (s. 362-411 (21)).

Abbildung 20 – GRETH-Descriptor: Pakete Versenden (20)


AF - 30

Dieses Beispiel zeigt wie ein Maus-Treiber mit der Device-Klasse verknüpft ist. Die ge-

samte Device-Struktur in einem Diagramm darzustellen ist nahezu unmöglich, denn diese

hat mehrere 100 Knoten in denen die Treiber verknüpft werden.

Linux unterscheidet dabei normalerweise zwischen drei Klassen von Devices: dem Char-

Modul, dem Block-Modul und dem Network-Modul. Es ist dem Programmierer überlassen,

diese so zu verwenden.

Character-Device (Char-Modul):

Ein Character-Device stellt ein Device dar, indem die Daten-Streams im Vordergrund ste-

hen, also Lese– und Schreibzyklen auf dem Dateisystem. Beispiele für ein Character-

Device sind die Konsole (/dev/console) oder auch der serielle Port (/dev/ttyS0). Ein Cha-

racter-Device hat also immer einen Bereich im Linux-File-System. (s.6 (21))

Block-Device (Block-Modul):

Wie ein Character-Device hat auch das Block-Device einen festen Knoten im Dateisystem.

Ein typisches Block-Device ist eine Festplatte. Der Unterschied zu einem Charakter Devi-

ce ist für einen Nutzer nicht sichtbar, jedoch haben beide eine komplett andere Anbin-

dung zum Kernel. Ein Block-Device kann nur Input-Output Kommandos handhaben, wel-

che einen oder mehrere Blöcke versenden. (s.7 (21))

Network-Device (Network-Module):

Ein Network-Device bzw. Interface wird vollkommen anders gehandhabt als die Block–

bzw. Character-Devices. Das Network-Interface hat keine repräsentative Datei im

Abbildung 21 – Verknüpfung von einem Maus Treiber in der Device-Klasse s.363 (21)


AF - 31

Filesystem, denn die üblichen Lese- und Schreibzyklen machen bei einem Netzwerk kei-

nen Sinn. Der übliche Unix-Ansatz „alles ist eine Datei“, ist nicht anwendbar. Obwohl viele

Netzwerkapplikationen, wie TCP, Stream orientiert sind, weiß das der Netzwerktreiber

nicht. Dieser ist darauf ausgelegt nur Pakete zu empfangen und zu versenden. Die höhe-

ren Schichten spielen dabei keine Rolle. Er behandelt nur Pakete.

Der größte Unterschied ist, dass ein normaler Treiber Antworten auf die Anfragen des

Kernels gibt. Ein Netzwerk muss asynchron empfangene Pakete von seiner Außenwelt

handhaben. Während ein Block-Treiber vom Kernel gefragt wurde, Puffer zum Kernel zu

senden, versucht der Netzwerktreiber seine empfangenen Pakete zum Kernel zu senden.

Der Kernel muss dann diese puffern. Dies stellt einen komplett anderen Ablauf dar (S.

497 (21)).

Dies ist der Vorgang einer Initialisierung eines PCI-Treibers in Linux. Bei einem Netzwerk-

treiber wird von dem Device ein Netdevice initialisiert und die Anbindung zum Kernel ist

unterschiedlich. Es gibt z.B. keinen „hotplug“. Ansonsten kann diese Grafik die Komplexi-

tät der Treiberanbindung in Linux gut darstellen und zeigen, wieso nicht einfach die Trei-

ber aus dem Linux-Source-Code herauszulösen sind.

Die besondere Art von Netzwerktreibern und deren anderen Anbindung an den Kernel

macht diese besonders komplex (21).

Abbildung 22 – Treiberinitialisierung bei Linux – S.329 (21)


AF - 32

7.3 Testprogramm für den Greth auf MAC-Ebene

Das Testprogramm für den Greth auf MAC-Ebene soll dazu dienen, den Greth-Ethernet-

Core unter Leon testen zu können. Auf die wichtigsten Bestandteile wird in diesem Kapi-

tel eingegangen.

Festlegen einer Greth Struktur

struct greth_info {

greth_regs *regs; /* Address of controller registers. */

unsigned char esa[6]; //Ethernet Source Adress (MAC Adresse)

unsigned int gbit;

unsigned int phyaddr;

unsigned int edcl;

struct descriptor *txd;

struct descriptor *rxd;

unsigned int txpnt;

unsigned int rxpnt;

unsigned int txchkpnt;

unsigned int rxchkpnt;

};

Das Struct Greth_info stellt den internen allgemeinen Aufbau, in der während des Be-

triebs alle Informationen gehalten werden dar. Die Greth Register müssen auf den kor-

rekten Adressbereich vom GRETH gelegt werden. Die Adresse könnte universell beim Ini-

tialisieren durch eine AMBA13-Abfrage festgelegt werden. In dem Testprogramm wurde

die Adresse jedoch über den GRMON ausgelesen und dann im Programmcode fest zuge-

wiesen.

Die Adresse des *regs Pointers wird wie folgt auf die richtige Adresse initialisiert:

#define GRETH_ADDR 0x80000f00

struct greth_info greth;

int main(void) {

greth.regs = (greth_regs *) GRETH_ADDR;

/*…*/ }

Die Hardware-Adresse 0x80000F00 wird über den (greth_regs *) Cast, dem *regs

Pointer zugewiesen. Somit befindet sich die Registerstruktur schließlich im korrekten Be-

reich. Für die greth_regs Struct wird das Schlüsselwort „volatile“ benötigt.

13 AMBA = Advanced Microcontroller Bus Architecture, ist ein Bus der von ursprünglich von ARM 1996

verwendet wurde. Er dient zur internen Verbindung zwischen mehreren Cores (IP-Cores) in einem Chip. Eine

wichtige Funktion ist z.B. der Plug&Play Support Über den AMBA Bus können die einzelnen Cores gesucht

werden.


AF - 33

Volatile (in C, C++ und C#) macht dem Compiler kenntlich, dass die Variable auch von

anderen Prozessen, also dem GRETH selbst, modifiziert werden kann. Die Hardware-

Register vom GRETH liegen direkt im Speicherbereich von der CPU durch volatile ist es

also möglich auf den Speicher gemappte Geräte richtig anzusteuern. Diese Variablen

können jederzeit gelesen und geschrieben werden. Der Compiler weiß dadurch, dass er

mit diesen Variablen keine Optimierungen durchführen darf.

Ein kurzes Beispiel zum Schlüsselwort Volatile:

static int foo;

void bar (void) {

foo = 0;

while (foo != 255)

; }

Die Funktion „bar“ geht in eine Endlosschleife über, so lange „foo“ ungleich 255 ist. Ein

intelligenter Compiler würde hier aber erkennen, dass „foo“ immer 0 ist. Mit großer

Wahrscheinlichkeit würde er die while abfrage wie folgt abändern:

void bar_optimized(void) {

foo = 0;

while (true)

; }

Dadurch wird in der Schleife eine Abfrage gespart. Genauso würde es sich bei anderen

Abfragen abspielen. Wenn der Variable das Schlüsselwort „volatile“ zugewiesen wird, wird

keine Optimierung vom Compiler durchgeführt. Denn die Variable könnte sich jederzeit

ändern.

static volatile int foo;

void bar (void) {

foo = 0;

while (foo != 255)

; }


AF - 34

Die Greth Register:

Anhand der Register Offset Tabelle kann die Greth_Regs Struktur definiert werden:

typedef struct _greth_regs {

volatile int control;

volatile int status;

volatile int esa_msb;

volatile int esa_lsb;

volatile int mdio;

volatile int tx_desc_p;

volatile int rx_desc_p;

volatile int edclip;

} greth_regs;

Die Erläuterung der einzelnen Register befindet sich im Anhang A2.

struct descriptor { volatile int ctrl; volatile int addr; };

Das Deskriptor-Struct ist repräsentativ für die „Senden-“ und „empfangen-Deskriptoren“,

die oben erklärt wurden. Diese müssen beim Initialisieren auf einen 1024 Byte Bereich

gelegt werden.

greth->txd = (struct descriptor *) almalloc(1024);

greth->rxd = (struct descriptor *) almalloc(1024);

save((int)&greth->regs->tx_desc_p, (unsigned int) greth->txd);

save((int)&greth->regs->rx_desc_p, (unsigned int) greth->rxd);

Initialisierung

Bei der Initialisierung kann GRETH den angeschlossenen PHY durch das MDIO-Interface

selbstständig feststellen. Die gesamte Initialisierung ist zu umfangreich, um sie im Rah-

men dieser Arbeit aufzuführen.

Tabelle 4 – Greth Register (20)


AF - 35

Funktion greth_tx

inline int greth_tx(int size, char *buf, struct greth_info *greth) {

if ((load((int)&(greth->txd[greth->txpnt].ctrl)) >> 11) & 1) {

return 0;

}

greth->txd[greth->txpnt].addr = (int) buf;

if (greth->txpnt == 127) {

greth->txd[greth->txpnt].ctrl = GRETH_BD_WR | GRETH_BD_EN | size;

greth->txpnt = 0;

} else {

greth->txd[greth->txpnt].ctrl = GRETH_BD_EN | size;

greth->txpnt++;

}

greth->regs->control = load((int)&(greth->regs->control)) | GRETH_TXEN;

return 1;

}

Als erstes wird abgefragt, ob das 11te Bit in dem Deskriptor des Pakets gesetzt ist. Falls

nicht, ist das TE-Flag nicht aktiviert und man verlässt die Funktion. Ansonsten wird das

Adressfeld nun mit der Adresse des Puffers belegt, an dem sich das Paket befindet. Dann

wird abgefragt, ob sich Pointer auf dem letzten Element befindet (127 * 8 = 1016

nächstes Paket 1024). Falls ja, wird das Wrap-Flag gesetzt, damit GRETH dann beim spä-

teren Versenden automatisch einen Reset durchführt. Zu allerletzt wird das Transceiver-

Enable-Flag (TE) im Control-Register gesetzt und GRETH fängt an, das Paket selbstständig

zu versenden.

Die Main des Testprogramms

int main(void) {

unsigned long long i;

unsigned char buf[1514]; //buf muss mit dem MAC frame gefuellt werden

clock_t t1, t2;

unsigned long long datasize;

double time, bitrate;

greth.regs = (greth_regs *) GRETH_ADDR;

/* Dest. addr */

buf[0] = DEST_MAC0; buf[1] = DEST_MAC1; buf[2] = DEST_MAC2;

buf[3] = DEST_MAC3; buf[4] = DEST_MAC4; buf[5] = DEST_MAC5;

/* Source addr */

buf[6] = SRC_MAC0; buf[7] = SRC_MAC1; buf[8] = SRC_MAC2;

buf[9] = SRC_MAC3; buf[10] = SRC_MAC4; buf[11] = SRC_MAC5;

memcpy(greth.esa, &buf[6], 6); //esa = ethernet source adress

/* Length 1500 */

buf[12] = 0x05;

buf[13] = 0xDC; //0x05DC = 1500

for (i = 14; i < 1514; i++) buf[i] = i; //befuellen mit random Werten

greth_init(&greth);


AF - 36

printf("\Sende 1500 Mbyte of data to .02x:%.02x:%.02x:%.02x:%.02x:

%.02x\n" ,buf[0],buf[1],buf[2], buf[3],buf[4], buf[5]);

int n = 0;

int groesse = 1024 * 1024; //1024 * 1024 * 1500 B = 1500 MB

t1 = clock();

while(n < groesse) {

n += greth_tx(1514, buf, &greth);

}

t2 = clock();

time = (double)(t2 - t1)/CLOCKS_PER_SEC;

printf("\nTime: %f\n", time);

datasize = (double)groesse*1500*8; /* In bits */

bitrate = (double) datasize/time;

printf("Bitrate: %f Mbps\n", bitrate/groesse);

return 0; }

Als erstes wird das Buffer-Array beschrieben. Dieses repräsentiert ein Paket. Es wird nach

den MAC-Frame-Richtlinien zuerst mit der Destination-MAC-Adresse und danach mit der

Source-MAC-Adresse gefüllt. Dann kommt das length Feld, und als letztes die Daten, wel-

che fortlaufend mit Zahlen beschrieben werden. GRETH hängt selbstständig noch das

CRC-Check Feld dahinter. Dann wird dieses Paket ca. eine Millionen Mal versendet, somit

werden insgesamt 1500 MByte Daten versendet und durch Messen der Zeit lässt sich

der Durchsatz feststellen.

Grmon>

total size: 50456 bytes (760.2 kbit/s)

read 237 symbols

Grmon> run

GRETH(10/100) Ethernet MAC at [0x80000f00]. Running 100 Mbps full duplex

Sending 1500 Mbyte of data to 00:1c:c0:19:38:54

Time: 7.295962

Bitrate: 1644.745408 Mbps

Program exited normally.

Grmon>

Die Zeitberechnung ist leider etwas unrealistisch. Es könnte noch ein Fehler in der Ver-

sand-Routine auftreten. Die Pakete kommen aber beim Empfänger an und dies ist für

den Funktionstest des GRETHs vorerst ausreichend.


AF - 37

8 Zusammenfassung und Ausblick

Die eingangs beschriebenen Bedingungen im Hochtemperaturbereich stellen besondere

Anforderungen an die Hardware. Dementsprechend wurden unterschiedliche Lösungs-

konzepte erarbeitet, um die Rahmenbedingungen des Betriebssystems festzulegen. Ein

geeigneter Soft-Prozessor wurde ausgewählt und in Betrieb genommen. Diese wurde so-

wohl mit Linux betrieben als auch mit Hardware-Testprogrammen und Benchmarks. Da-

rüber hinaus wurden erste Ansätze für ein alternatives Betriebssystem entwickelt.

In Zukunft müsste das Linux-System im Hochtemperaturbereich unter entsprechenden

Hardware-Bedingungen getestet werden. Falls ein Linux betrieben werden soll, muss die

Möglichkeit geschaffen werden, das Gesamtimage in einzelne Module aufzuteilen. An-

sonsten wird es nicht möglich sein, Linux unter diesen Rahmenbedingungen zu betrei-

ben. Im fertigen System könnte durch Einsetzen der FT-Variante von Leon, einer höheren

Temperatur standgehalten werden.


AF - 38

Literaturverzeichnis

1. KIT. über KIT. Karlsruher Institut für Technologie. [Online] 1. Oktober 2009.

http://www.kit.edu/ueber_kit.php.

2. FPGA Logic Cells - 1-CORE Technologies. http://www.1-core.com. [Online] 2004-

2009. http://www.1-core.com/library/digital/fpga-logic-cells/fpga-logic-cells.pdf.

3. FPGA Development - Gregori, Sven. www.unfug.org. [Online] 28. Mai 2008. [Zitat

vom: 10. Februar 2010.]

http://www.unfug.org/data/foils/ss08/UnFUG_FPGA_Development.pdf.

4. OpenCores. opencores.org. [Online] 1999-2010. http://www.opencores.org.

5. IP-Cores, (Wiki). wikipedia.org. [Online] 4. Oktober 2009.

http://de.wikipedia.org/wiki/IP-Core.

6. Lattice Semiconductor Corporation. www.latticesemi.com. [Online] 2010.

http://www.latticesemi.com/.

7. Aeroflex Gaisler. gaisler.com. [Online] 2008. http://www.gaisler.com/cms/.

8. Xilinx. xilinx.com. [Online] 2010. http://www.xilinx.com/.

9. Altera. altera.com. [Online] 1995-2010. http://www.altera.com/.

10. OpenRisc. Opencores.org. [Online] 1999-2010. http://opencores.org/project,or1k.

11. Plasma. Opencores.org. [Online] 1999-2010. http://opencores.org/project,plasma.

12. (ZPU), Zylin CPU. zylin.com. opencores.com. [Online] 2008-2009.

http://opensource.zylin.com/zpu.htm ;

http://www.opencores.org/project,zpu,overview.

13. FPGA Softcores. mikrocontroller.net. [Online] 2009.

http://www.mikrocontroller.net/articles/FPGA_Soft_Core.

14. Mattsson, Daniel und Christensson, Marcus. Evaluation of synthesizable CPU cores.

[Master Thesis (pdf)] Gothenburg : Chalmes Univeristy of Technology, 2004.

15. DM9161A, Datenblatt. DM9161A. [pdf] s.l. : Davicom, 2003.

16. DP83848YB Datenblatt. DP83848YB PHYTER® - Extreme Temperature. [pdf] s.l. :

National Semiconducter, 2008.


AF - 39

17. SPARC International, Inc - About. sparc.com. [Online] 1994-2010.

http://www.sparc.com/aboutOverview.html.

18. Leon3 Product Sheet - Aeroflex Gaisler AB. www.gaisler.com. [Online] 12. Januar

2008. Leon3 Produkt-Datemblatt.

http://www.gaisler.com/doc/leon3_product_sheet.pdf.

19. Busybox - Andersen, Erik. busybox.net. [Online] 1999-2008.

http://busybox.net/about.html.

20. Greth 10/100 MBit Ethernet MAC - Gaisler Reseach - Jiri Gaisler, Marko Isomaki.

www.gaisler.com. [Online] 1. August 2006. http://gaisler.com/doc/greth.pdf.

21. Jonathan, Corbet, Alessandro, Rubini und Kroah-Hartman, Greg. Linux Device Drivers.

http://lwn.net/Kernel/LDD3/ : s.n., 15. Janauar 2005.

22. Altera™. altera.com. [Online] 1995-2010. http://www.altera.com/.


AF - 40

Abbildungsverzeichnis

Abbildung 1 – FPGA Slice – Ein Xilinx Virtex 4 Slice (links) | Ein Xilinx Virtex 5 Slice

(rechts) (2) ................................................................................................................................. 5

Abbildung 2 – Konzept 1 – Linux Full ...................................................................................... 9

Abbildung 3 – Konzept 2 – Linux Min ................................................................................... 10

Abbildung 4 – Konzept 3 – Microcontroller MC ................................................................... 10

Abbildung 5 – Konzept 4 – Microcontroller MC mit internem Netzflash ........................... 11

Abbildung 6 – Schematische Übersicht vom Leon mit der Anbindung an das Ethernet .. 13

Abbildung 7 – Protokollstapel PHY ....................................................................................... 14

Abbildung 8 – Leon 3 – In einem Multiprozessor System (18) ........................................... 15

Abbildung 9 – Cygwin mit Eval Version von TSIM, HelloWorld! wird geladen und

ausgeführt ............................................................................................................................... 18

Abbildung 10 – TSIM Schnittstelle in der Eclipse Oberfläche konfigurieren ..................... 19

Abbildung 11 – Debuggen mit Eclipse .................................................................................. 20

Abbildung 12 – Xilinx™ Spartan3 1800 DSP ....................................................................... 21

Abbildung 13 – (oben) make xconfig Start Start Screen | (unten) Kernel/Libary/Defaults

Selection ................................................................................................................................. 22

Abbildung 14– (oben) Kernel Konfigurations Fenser | (unten) Busybox

Konfigurationsfenster ............................................................................................................ 23

Abbildung 15 – Bootup | Größenunterteilung des Images („reserved“ entspricht dem

freiem Speicher im Ramblock) .............................................................................................. 25

Abbildung 16 – Linux Min, Meminfo ..................................................................................... 25

Abbildung 17 – Automatischer Start vom Telnet Server und Anlegen von einem Neuen

Nutzer ...................................................................................................................................... 26

Abbildung 18 – Der interne Aufbau von Greth ..................................................................... 27

Abbildung 19 – GRETH-Descriptor: Pakete Versenden (20) ............................................... 28

Abbildung 20 – GRETH-Descriptor: Pakete Versenden (20) ............................................... 29

Abbildung 21 – Verknüpfung von einem Maus Treiber in der Device-Klasse s.363 (21) . 30

Abbildung 22 – Treiberinitialisierung bei Linux – S.329 (21) ............................................. 31

Abbildung 23 – PFAD Variable .............................................................................................. 43

Abbildung 24 – Das GRETH Control Register (20) ............................................................... 44

Abbildung 25 – Das GRETH Status Register (20) ................................................................ 45


AF - 41

Abbildung 26 – MAC Address MSB (20) ............................................................................... 45

Abbildung 27 – MAC Address LSB (20) ................................................................................ 45

Abbildung 28 – MDIO Control/Status Register (20) ............................................................ 46

Abbildung 29 – GRETH Transmit Descriptor & Table Base Address Register (20) ........... 46

Abbildung 30 – GRETH Receive Descriptor & Table Base Address Register (20) ............. 46

Abbildung 31 – GRETH EDCL IP-Register (20) ..................................................................... 47


AF - 42

Tabellenverzeichnis

Tabelle 1 – Beispiele unterschiedlicher Softcores (13) ......................................................... 8

Tabelle 2 –Vergleich der "Kapazität" pro Slice in der Praxis - (2) ....................................... 11

Tabelle 3 – Auszug der Identifier PHY DM9161A & DP 83848YB...................................... 14

Tabelle 4 – Greth Register (20) ............................................................................................. 34


AF - 43

A. Anhang

A1. Allgemeine Hinweise:

Xilinx™ Kabel wieder freigeben

Konsole öffnen „impact –batch“ eingeben “cleancablelock“ eingeben

Pfad Variable

Es kann sein, dass manche Programme die Benutzervariablen nicht verwenden, dann ist

es ratsam, diese unter die Systemvariablen einzutragen. Folgende Einträge werden für

Gaisler™ benötigt

c:\opt\bin;c:\opt\sparc-elf-3.4.4-mingw\bin;c:\opt\rtems-4.10-mingw\bin;c:\opt\grmon-

pro\win32;c:\opt\grmon-eval\win32;c:\opt\tsim-erc32\tsim\win32;c:\opt\tsim-

leon\tsim\win32;c:\opt\tsim-leon3\tsim\win32;c:\opt\tsim-

eval\tsim\win32;c:\opt\mkprom2;

Abbildung 23 – PFAD Variable


AF - 44

A2. Die Greth Register

Das GRETH Control Register:

Abbildung 24 – Das GRETH Control Register (20)


AF - 45

Das GRETH Status Register

GRETH MAC Adress MSB

GRETH Mac Adress LSB

Abbildung 25 – Das GRETH Status Register (20)

Abbildung 26 – MAC Address MSB (20)

Abbildung 27 – MAC Address LSB (20)


AF - 46

Das GRETH MDIO Control/Status Register

GRETH Transmit Descriptor & Table Base Address Register

GRETH Receive Descriptor & Table Base Address Register

Abbildung 28 – MDIO Control/Status Register (20)

Abbildung 29 – GRETH Transmit Descriptor & Table Base Address Register (20)

Abbildung 30 – GRETH Receive Descriptor & Table Base Address Register (20)


AF - 47

GRETH EDCL IP-Register

A3. Installation Gaisler der Entwicklungsoberfläche unter Windows

Unter Windows gibt es ein Installationspaket, das die Eclipse-Oberfläche, den Cross-

Compiler, TSIM, GRMON und andere Tools selbstständig installiert.

Die Installationspfade sollten auf c:/opt/ etc. bleiben, denn sonst müssen die PFAD Vari-

ablen von Hand nachgebessert werden, die die Installation selbstständig einträgt.

A4. Installation Gaisler der Entwicklungsoberfläche unter Linux

Die Versionen 3.3 und 3.4 sind die letzten, die von der Firma Gaisler™ als Unterstützung

angegeben wurde. Neuere Versionen sollten aber auch kompatibel sein.

- Die Eclipse IDE für C/C++ von eclipse.org herunterladen und installieren

Die Leon IDE kann nun über das Software Update Future installiert werden.

Unter Eclipse 3.4:

- Wähle Help->Software Updates...

- Wähle Available Software

- Wähle Add Site..., gib ein: http://gaisler.com/eclipse/lide/ und klick OK

- Nun kann man den Link erweitern und es erscheint eine Liste mit den verfügbaren

Plugins und Updates.

- Wähle LEON IDE und klick Install...

Eclipse muss neu gestartet werden bevor es die Plugins bzw. Updates anzeigen kann.

Unter Eclipse 3.3:

- Wähle Help->Software Updates->Find and Install...

- Wähle Search for new features to install...

- Wähle New Remote Site gib als Namen ein: „LEON IDE“ und als

URL: http://gaisler.com/eclipse/lide/

Abbildung 31 – GRETH EDCL IP-Register (20)

http://gaisler.com/eclipse/lide/

http://gaisler.com/eclipse/lide/


AF - 48

- Wähle Finish, und Eclipse sucht innerhalb der URL nach Updates oder installierba-

ren Features.

- Daraufhin wird ein Dialog erscheinen, indem man die verfügbaren Plugins auswäh-

len kann.

Des Weiteren müssen noch folgende Pakete entpackt werden:

Tool Paket Verzeichnis

GRMON grmon-eval-1.1.32.tar.gz \opt\ TSIM tsim-eval-2.0.10b.tar.gz \opt\ GrmonRCP1 GrmonRCP-0.9.6-eval-win32.zip \opt\ Bare C cross-compiler sparc-elf-3.4.4-1.0.31.zip \opt\ RTEMS cross-compiler sparc-rtems-4.8-gcc-4.2.2-1.1.1.zip \opt\ Newlib source code newlib-1.13.0-1.0.31.tar.gz \opt\src\ RTEMS 4.8 rtems-4.8-1.1.1-src.tar.bz2 \opt\rtems-4.8\src\ Mkprom2 mkprom2-2.0.25.tar.gz \opt\mkprom\

Pfadvariabeln setzen:

Temporär:

Bei den beiden C-Bibliotheken genügt es diese temporär zu setzen, beim Rest sollten die

Variablen dauerhaft gesetzt werden.

µCLib: export PATH=$PATH:/opt/sparc-uclinux-3.4.4/bin/ bzw.

GLib: export PATH=$PATH:/opt/sparc-linux-3.4.4/bin/

Dauerhaft:

Die PATH Variablen sind zwischen USER und ROOT strikt getrennt. Die meisten Aktionen

müssen aber als ROOT ausgeführt werden, deshalb muss die /etc/bash.bashrc geändert

werden. Normalerweise würde man im Homeverzeichnis ~/.bash_profile ändern, die

meist erst noch angelegt werden muss.

In dieser Datei fügen wir die Befehle am Anfang der Datei hinzu. Beim nächsten Start

eines Terminals sind die PATH variablen bereits initialisiert.

echo "PATH Variablen geadded"

export PATH=$PATH:/opt/sparc-uclinux-3.4.4/bin/

export PATH=$PATH:/opt/sparc-linux-3.4.4/bin/

export PATH=$PATH:/opt/bin

export PATH=$PATH:/opt/sparc-elf-3.4.4/bin

export PATH=$PATH:/opt/rtems-4.10/bin

export PATH=$PATH:/opt/grmon-eval/linux

export PATH=$PATH:/opt/tsim-eval/tsim/linux

export PATH=$PATH:/opt/mkprom2

Documents

Einrichten einer Entwicklungsumgebung f¼r ein System-On-A - KIT