Post on 11-Feb-2022
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
Projektbericht Aaron Frueh
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
Projektbericht Aaron Frueh
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.
Projektbericht Aaron Frueh
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)
Projektbericht Aaron Frueh
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
Projektbericht Aaron Frueh
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).
Projektbericht Aaron Frueh
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)
Projektbericht Aaron Frueh
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
Projektbericht Aaron Frueh
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
Projektbericht Aaron Frueh
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
Projektbericht Aaron Frueh
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.
Projektbericht Aaron Frueh
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
Projektbericht Aaron Frueh
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
Projektbericht Aaron Frueh
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)
Projektbericht Aaron Frueh
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
Projektbericht Aaron Frueh
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.
Projektbericht Aaron Frueh
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
Projektbericht Aaron Frueh
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
Projektbericht Aaron Frueh
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
Projektbericht Aaron Frueh
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
Projektbericht Aaron Frueh
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
Projektbericht Aaron Frueh
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
Projektbericht Aaron Frueh
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“.
Projektbericht Aaron Frueh
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
Projektbericht Aaron Frueh
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
Projektbericht Aaron Frueh
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
Projektbericht Aaron Frueh
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)
Projektbericht Aaron Frueh
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)
Projektbericht Aaron Frueh
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)
Projektbericht Aaron Frueh
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)
Projektbericht Aaron Frueh
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.
Projektbericht Aaron Frueh
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)
; }
Projektbericht Aaron Frueh
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)
Projektbericht Aaron Frueh
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);
Projektbericht Aaron Frueh
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.
Projektbericht Aaron Frueh
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.
Projektbericht Aaron Frueh
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.
Projektbericht Aaron Frueh
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/.
Projektbericht Aaron Frueh
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
Projektbericht Aaron Frueh
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
Projektbericht Aaron Frueh
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
Projektbericht Aaron Frueh
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
Projektbericht Aaron Frueh
AF - 44
A2. Die Greth Register
Das GRETH Control Register:
Abbildung 24 – Das GRETH Control Register (20)
Projektbericht Aaron Frueh
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)
Projektbericht Aaron Frueh
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)
Projektbericht Aaron Frueh
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)
Projektbericht Aaron Frueh
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