Automatische Adaption von Hardware-Acceleratoren für

Automatische Adaption von Hardware-Acceleratoren für
Technische Universit¨at Chemnitz
Straße der Nationen 62
09111 Chemnitz
Automatische Adaption von
Hardware-Acceleratoren fu
¨r
Verhaltenssimulation
Diplomarbeit
Fakult¨at f¨
ur Informatik
Studiengang Informatik
Professur Technische Informatik
Vertiefungsrichtung Eingebettete Systeme
von
Marcel Flade
Dorfstraße 81
09526 Pfaffroda-Hallbach
vorgelegt bei
Prof. Dr. habil. Wolfram Hardt
im
September 2004
I
Dank und Erkl¨
arung
Diese Arbeit entstand an der Professur Technische Informatik der Technischen Universit¨at Chemnitz. Ich m¨ochte hiermit besonders Herrn Prof. Dr.
habil. Wolfram Hardt f¨
ur das interessante Thema und die engagierte Betreuung w¨ahrend der Anfertigung dieser Arbeit danken. Auch f¨
ur die Bereitstellung von Rechnern, sowie Hard- und Software durch die Professur
und die Technische Universit¨at Chemnitz spreche ich an dieser Stelle meinen Dank aus. Ebenfalls sei mir gestattet, den Mitarbeitern der Professur,
speziell Markus Scheithauer, f¨
ur die Diskussion fachlicher Fragen und hilfreichen Anregungen zu danken. Nicht zuletzt gilt mein Dank Kathrin Kasecker
f¨
ur das intensive Korrekturlesen dieser Arbeit und meiner Familie f¨
ur ihre
Unterst¨
utzung.
Hiermit erkl¨are ich, dass ich die vorliegende Arbeit selbstst¨andig verfasst und
keine anderen als die angegebenen Quellen und Hilfsmittel benutzt, sowie
Zitate kenntlich gemacht habe.
Chemnitz, im September 2004
II
III
Inhaltsverzeichnis
1 Einfu
¨ hrung
1
1.1
Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . .
5
1.2
Gliederung der Arbeit . . . . . . . . . . . . . . . . . . . . . .
5
2 Stand der Technik
7
2.1
SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.2
Intellectual Properties . . . . . . . . . . . . . . . . . . . . . .
9
2.3
Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4
2.3.1
Simulation mit SystemC . . . . . . . . . . . . . . . . . 15
2.3.2
Hardwaresimulation mit ModelSim . . . . . . . . . . . 16
2.3.3
HW/SW-Cosimulation . . . . . . . . . . . . . . . . . . 17
2.3.4
Hardware-Akzeleratoren . . . . . . . . . . . . . . . . . 20
2.3.4.1
Tharas - Hammer 100 . . . . . . . . . . . . . 21
2.3.4.2
Mentor Graphics - VStation . . . . . . . . . . 23
2.3.4.3
Aptix - System Explorer
TM
. . . . . . . . . . 24
Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3 Die Methode der Adaptierung
3.1
Das Hardware/Software-Interface . . . . . . . . . . . . . . . . 29
3.1.1
3.2
3.3
29
Anforderungsanalyse f¨
ur das HW/SW-Interface . . . . 33
Der Interfaceblock als HW/SW-Interface . . . . . . . . . . . . 36
3.2.1
Das Modell des Interfaceblocks . . . . . . . . . . . . . 36
3.2.2
Analyse der Leistung des Interfaceblocks . . . . . . . . 38
3.2.3
Erweiterung des Interfaceblocks . . . . . . . . . . . . . 39
Technische Umsetzung der Adaptierung durch einen Simulationsinterfaceblock . . . . . . . . . . . . . . . . . . . . . . . . 44
3.3.1
Die hardwareseitige Implementierungsplattform . . . . 44
3.3.2
Umsetzung des HW/SW-Interfaces . . . . . . . . . . . 45
3.3.3
Der PHSW . . . . . . . . . . . . . . . . . . . . . . . . . 48
IV
3.4
3.3.4
Der PHHW-in . . . . . . . . . . . . . . . . . . . . . . . . 51
3.3.5
Der SHHW . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.3.6
Der PHHW-out . . . . . . . . . . . . . . . . . . . . . . . 53
3.3.7
Die Controlunit . . . . . . . . . . . . . . . . . . . . . . 54
Anwendungsm¨oglichkeiten . . . . . . . . . . . . . . . . . . . . 60
4 Der Simulationsinterfaceblock-Generator
63
4.1
Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.2
Arbeitssweise . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.2.1
Eingaben und Ausgaben . . . . . . . . . . . . . . . . . 64
4.2.2
Die internen Datenstrukturen . . . . . . . . . . . . . . 64
4.2.3
4.3
Die Datenstruktur ENTITY STRUCTUR . . 65
4.2.2.2
Die Datenstruktur PORT LIST . . . . . . . . 67
4.2.2.3
Die Datenstruktur GENERIC LIST . . . . . 68
4.2.2.4
Die Datenstruktur WORD LIST . . . . . . . 69
4.2.2.5
Die Datenstruktur FILELIST . . . . . . . . . 70
Der Programmablauf . . . . . . . . . . . . . . . . . . . 70
Benutzung des Programms . . . . . . . . . . . . . . . . . . . . 75
4.3.1
Programmstart und -aufbau . . . . . . . . . . . . . . . 75
4.3.2
Die Analyse der Quelldatei . . . . . . . . . . . . . . . . 76
4.3.3
Festlegung von Signalparametern . . . . . . . . . . . . 77
4.3.4
Weitere Parameter . . . . . . . . . . . . . . . . . . . . 78
4.3.5
Die Generierung . . . . . . . . . . . . . . . . . . . . . . 80
¨
Uberblick
u
¨ber die generierten Dateien . . . . . . . . . 82
4.3.6
4.4
4.2.2.1
Verbesserungsm¨oglichkeiten und Fazit . . . . . . . . . . . . . . 85
5 Demonstrator
87
5.1
Bedeutung eines Demonstrators . . . . . . . . . . . . . . . . . 87
5.2
Aufbau und Funktionsweise . . . . . . . . . . . . . . . . . . . 87
5.3
Nachweis der Funktion . . . . . . . . . . . . . . . . . . . . . . 90
5.4
Betrachtungen zur Simulationszeit . . . . . . . . . . . . . . . . 93
5.4.1
Geschwindigkeit der parallelen Schnittstelle . . . . . . 94
V
5.4.2
5.5
Vergleich der Simulationszeiten . . . . . . . . . . . . . 96
Schlussfolgerungen . . . . . . . . . . . . . . . . . . . . . . . . 100
6 Zusammenfassung und Ausblick
103
6.1
Zusammenfassung der Arbeit . . . . . . . . . . . . . . . . . . 103
6.2
Ausblick f¨
ur den erweiterten Interfaceblock . . . . . . . . . . . 105
6.3
Ausblick f¨
ur den Simulationsinterfaceblock-Generator . . . . . 106
A Herleitung der Formel zur Berechnung der Taktfrequenz der
IP-Emulation
107
B Hinweise zur Nutzung von SystemC in Mircrosoft Visual
C++ 6.0
109
C Gegenu
¨ berstellung der Simulationsdaten
111
D Inhalt der Quellcode-CD
127
D.1 Verzeichnis DOC . . . . . . . . . . . . . . . . . . . . . . . . . 128
D.2 Verzeichnis PROGRAMME . . . . . . . . . . . . . . . . . . . 128
D.3 Verzeichnis SOURCES . . . . . . . . . . . . . . . . . . . . . . 130
D.4 Verzeichnis TESTDESIGNS . . . . . . . . . . . . . . . . . . . 130
Literaturverzeichnis
135
Abku
¨ rzungsverzeichnis
141
VI
VII
Abbildungsverzeichnis
1.1
Schema eines modularen Designs . . . . . . . . . . . . . . . .
1
1.2
Aktuelle Methode des Hardwareentwurfsprozesses . . . . . . .
2
1.3
Y-Diagramm nach Gajski . . . . . . . . . . . . . . . . . . . .
3
1.4
X-Diagramm nach Rammig . . . . . . . . . . . . . . . . . . .
4
1.5
P-Chart Entwurfsstrukturierung . . . . . . . . . . . . . . . . .
4
2.1
Logo von SystemC
. . . . . . . . . . . . . . . . . . . . . . .
7
2.2
Gegenw¨artige und SystemC Designmethodik . . . . . . . . . .
8
2.3
Darstellung von Moores Gesetz . . . . . . . . . . . . . . . . . 10
2.4
SoC aus IPs und selbstentwickelten Komponenten . . . . . . . 11
2.5
IPQ als Kommunikation von IP-User und IP-Serviceprovidern
2.6
Simulation eines Modells mit SystemC . . . . . . . . . . . . . 15
2.7
r
Logo von ModelSim
. . . . . . . . . . . . . . . . . . . . . . . 16
2.8
HW/SW-Cosimulation mit dem Bus-Modell . . . . . . . . . . 17
2.9
HW/SW-Cosimulation mit einem ISS . . . . . . . . . . . . . . 18
TM
12
2.10 HW/SW-Cosimulation mit dem Hardware-Modell . . . . . . . 18
2.11 HW/SW-Cosimulation mit dem compilierten Modell . . . . . . 19
2.12 HW/SW-Cosimulation mit Hardwareemulation
. . . . . . . . 19
r
2.13 Hammer 100 System von Tharas . . . . . . . . . . . . . . . . 21
TM
2.14 VStation
Pro System von Mentor Graphics . . . . . . . . . . 23
TM
r
2.15 Aptix
System Explorer
. . . . . . . . . . . . . . . . . . . . 24
3.1
Adaptierung durch Konvertierung . . . . . . . . . . . . . . . . 30
3.2
Adaptierung eines Simulators . . . . . . . . . . . . . . . . . . 30
3.3
Schematischer Aufbau eines SRAM-basierten FPGA . . . . . . 31
3.4
Allgemeines Hardware/Software-Interface . . . . . . . . . . . . 32
3.5
Genaueres Modell des Hardware/Software-Interface . . . . . . 32
3.6
Ablauf der Synchronisation durch das HW/SW-Interface . . . 35
3.7
Makrostruktur des Interfaceblock . . . . . . . . . . . . . . . . 37
VIII
3.8
Verbindung von SW- und HW-Task durch einen IFB . . . . . 39
3.9
HW-Interface des IFB . . . . . . . . . . . . . . . . . . . . . . 40
3.10 SW-Interface des IFB . . . . . . . . . . . . . . . . . . . . . . . 41
3.11 Physisches HW/SW-Interface im IFB . . . . . . . . . . . . . . 41
3.12 Controlunit zur Steuerung von Hardware und Software . . . . 42
3.13 Teilung der Controlunit . . . . . . . . . . . . . . . . . . . . . . 42
3.14 Controlunit in Software und Hardwareteil geteilt . . . . . . . . 43
3.15 Digilent 2E Developmentboard mit Xilinx Spartan 2E FPGA . 45
3.16 Protokollautomat des EPP-Protokoll . . . . . . . . . . . . . . 47
3.17 Detailierter Aufbau des PHSW . . . . . . . . . . . . . . . . . . 48
3.18 Ablaufplan zur Umsetzung des PHSW . . . . . . . . . . . . . . 50
3.19 Detailierter Aufbau des PHHW-in . . . . . . . . . . . . . . . . . 51
3.20 Detailierter Aufbau des SHHW . . . . . . . . . . . . . . . . . . 53
3.21 Detailierter Aufbau des PHHW-out . . . . . . . . . . . . . . . . 54
3.22 Detailierter Aufbau der Controlunits . . . . . . . . . . . . . . 55
3.23 FSM der Controlunit . . . . . . . . . . . . . . . . . . . . . . . 58
4.1
Eingaben und Ausgaben des SimIFB-Generators . . . . . . . . 64
4.2
Syntaxdiagramm einer VHDL-Entity . . . . . . . . . . . . . . 72
4.3
Erzeugung der Quelldateien des SimIFBs aus Templates . . . 73
4.4
Ansicht des Simulationsinterfaceblock-Generators nach dem
Programmstart . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.5
Ansicht des Feldes Analyseparameter . . . . . . . . . . . . . . 76
4.6
Der Simulationsinterfaceblock-Generator nach der Analysephase 77
4.7
Ansicht der Felder zur Einstellung der Signalparameter . . . . 78
4.8
Der Simulationsinterfaceblock-Generator nach der Einstellung
der Signalparameter
4.9
. . . . . . . . . . . . . . . . . . . . . . . 78
Detailierte Ansicht des Feldes zur Einstellung weiterer Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.10 Der Simulationsinterfaceblock-Generator bei der Generierung
des HW-Teils . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
IX
4.11 Der Simulationsinterfaceblock-Generator bei der Generierung
der Skripte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.12 Der Simulationsinterfaceblock-Generator bei der Generierung
des SW-Teils . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
¨
4.13 Uberblick
u
¨ber die Verzeichnisstruktur der generierten Daten . 83
5.1
Aufbau des Designs RISC-CPU . . . . . . . . . . . . . . . . . 88
5.2
Aufbau des Demonstrators . . . . . . . . . . . . . . . . . . . . 90
5.3
Schnittstellendefinition der originalen Integer-Executionunit . 91
5.4
Festlegung der Datentypen im Simulationsinterfaceblock-Generator
5.5
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Aufbau der Hardware zur Geschwindigkeitsmessung . . . . . . 95
X
XI
Tabellenverzeichnis
2.1
Simulationsaufwand von verschiedenen Entwurfsebenen . . . . 14
2.2
r
Technische Daten des Aptix
System Explorer
3.1
Vergleich serielle und parallele Schnittstelle . . . . . . . . . . . 46
3.2
Grundfunktionen zum Zugriff auf die parallele PC-Schnittstelle 49
3.3
Die Register der hardwareseitigen Controlunit . . . . . . . . . 56
3.4
Belegung der Kontroll- und Statusregister der CUHW . . . . . 57
3.5
Ausgaben der Clockcontrol-FSM . . . . . . . . . . . . . . . . . 59
3.6
Funktionen der CUSW . . . . . . . . . . . . . . . . . . . . . . . 60
4.1
Aufbau der Datenstruktur ENTITY STRUCTUR . . . . . . . 65
4.2
Funktionen zur Datenstruktur ENTITY STRUCTUR . . . . . 66
4.3
Aufbau der Datenstruktur PORT LIST . . . . . . . . . . . . . 67
4.4
¨
Uberblick
zu den Funktionen zur Datenstruktur PORT LIST . 68
4.5
Aufbau der Datenstruktur GENERIC LIST . . . . . . . . . . 69
4.6
Aufbau der Datenstruktur WORD LIST . . . . . . . . . . . . 69
4.7
¨
Uberblick
zu den Funktionen zur Datenstruktur WORD LIST
4.8
Aufbau der Datenstruktur FILELIST . . . . . . . . . . . . . . 70
4.9
¨
Uberblick
zu den Funktionen zur Datenstruktur FILELIST . . 70
TM
. . . . . . . 25
69
¨
4.10 Uberblick
zu den Dateien im Verzeichnis Hardware . . . . . . 84
5.1
Funktionen der entwickelten Integer-Executionunit . . . . . . . 89
5.2
Die Modi der Software zur Geschwindigkeitsmessung . . . . . 94
5.3
Ermittelte Geschwindigkeiten der parallelen Schnittstelle . . . 96
5.4
Simulationszeiten der originalen und der modifizierten RISCCPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
5.5
Das Datenaufkommen des generierten Moduls . . . . . . . . . 98
XII
¨
1 EINFUHRUNG
1
1
Einfu
¨ hrung
Die Entwicklung eines digitalen technischen Systems unterliegt heutzutage
hohen Anforderungen hinsichtlich Entwicklungszeit und Entwicklungskosten.
Der Gewinn, den ein Produkt erzielt, f¨allt umso gr¨oßer aus, je schneller es auf
dem Markt verf¨
ugbar ist. Das Ziel des Entwicklungsprozesses liegt demzufolge darin, ein Produkt schnell und mit m¨oglichst geringen Entwicklungskosten
auf den Markt zu bringen.
Ein Schritt in diese Richtung stellt ein modulares Design dar. Es folgt dem
Grundsatz, dass ein System aus verschiedenen Modulen aufgebaut ist (vgl.
Abbildung 1.1). Die Entwicklung und der Test der einzelnen Module kann
unabh¨angig voneinander erfolgen. Somit kann der Entwicklungsaufwand auf
mehrere Personen oder Teams verteilt werden und die Entwicklungszeit reduziert sich durch die Parallelisierung der Entwurfsarbeit. Das Gesamtsystem
ergibt sich aus der Zusammenf¨
uhrung und Kopplung der einzelnen Module.
M1
M1.1
M1.3
M3
M1.2
M2
System
Abbildung 1.1: Schema eines modularen Designs
Einen weiteren Vorteil dieses Konzeptes stellt die Wiederverwendung (Reuse)
von bereits entwickelten Modulen in neuen Systemen dar. Diese Intellectual
Properties (IPs, vgl. Abschnitt 2.2) verk¨
urzen den Entwicklungsaufwand f¨
ur
neue Systeme erheblich, da diese Module nicht neu entwickelt werden m¨
ussen.
¨
Im Idealfall k¨onnen sie ohne Anderungen
in das Design eingebunden werden.
Ein aktuelles Problem mit dem die Entwickler konfrontiert sind, bildet eine
L¨
ucke im Entwurfsprozess. Abbildung 1.2 stellt diesen Sachverhalt dar. Die
¨
1 EINFUHRUNG
2
C, C++
System Level Model
Manual Conversion
Refine
Analysis
VHDL/Verilog
Results
Simulation
Synthesis
Rest of Process
Abbildung 1.2: Aktuelle Methode des Hardwareentwurfsprozesses, Quelle
[Opeb]
Entwicklung eines Systems beginnt mit einer Spezifikation auf Systemebene.
Die daf¨
ur verwendete Sprache ist meist C oder C++. Die Spezifikation wird
schrittweise analysiert und verfeinert. Dabei durchl¨auft die Systementwicklung verschiedene Abstraktionsebenen des Entwurfsprozesses (vgl. Abbildung
1.3 und 1.4). Das Ergebnis eines erfolgreichen Entwurfsprozesses besteht in
der Implementierung des Systems, die wie in der Spezifikation festgelegt arbeitet.
Ab einem Verfeinerungsgrad, der einer Verhaltensbeschreibung entspricht,
reichen die bestehenden Beschreibungsm¨oglichkeiten von C/C++ nicht mehr
aus und es muss auf eine Hardwarebeschreibungssprache, wie zum Beispiel
VHDL oder Verilog, u
¨bergegangen werden. Dieser Schritt stellt beim aktuellen Entwurfsprozess noch ein Hindernis dar, da er vom Entwickler von
Hand durchgef¨
uhrt werden muss. Dieser Prozess beansprucht viel Zeit und
ist fehleranf¨allig. Nach der Konvertierung muss das Design ausgiebigen Tests
unterzogen werden, um sicherzustellen, dass die Konvertierung mit der Spezifikation u
¨bereinstimmt. Dadurch verl¨angert sich die Entwicklungszeit und
teure Resourcen werden gebunden.
W¨
unschenswert ist nun ein Entwurfssystem, das es erlaubt, den Entwurf
von Hardware u
¨ber alle Entwurfsebenen modular und in einer einheitlichen
¨
1 EINFUHRUNG
3
Systemebene
Algorithmische Ebene
Verhaltenssicht
Funktionelle Ebene
Systemspezifikation
Algorithmen
Registertransfers
Boolsche Gleichungen
Differentialgleichungen
Struktursicht
Gatterebene
Integrierter Schaltkreis
Subsysteme, Busse
Schalterebene
Module, Leitungen
Gatter, Flipflops, Leitungen
Elektrische
Transistoren
Ebene
Masken, Polygone
Zellen
Blöcke
Superblöcke
Physikalische Gliederung
Physikalische Sicht
Abbildung 1.3: Das Y-Diagramm nach Gajski. Es zeigt die verschiedenen
Sichten und Abstraktionsebenen beim Hardwareentwurf.
Beschreibungssprache durchzuf¨
uhren. F¨
ur den zunehmend wichtiger werdenden Entwurf von eingebetteten Systemen sollte das Entwurfssystem zudem
die Unterst¨
utzung der daf¨
ur ben¨otigten Entwurfsdimensionen (vgl. Abbildung 1.5) gew¨ahrleisten. Außerdem sollte es die Verwendung von Intellectual
Properties auf jeder Verfeinerungsebene f¨
ur den Entwurf und den Test des
Systems unterst¨
utzen.
Um diese Anforderungen zu erf¨
ullen, wurde SystemC (Abschnitt 2.1) entwickelt. SystemC unterst¨
utzt den modularen Entwurfsprozess von der Systemspezifikation bis zur Register-Transfer-Ebene. Außerdem erlaubt es Hardware/Software-Codesign, was f¨
ur die Entwicklung von HW/SW-Systemen
vorteilhaft ist. Die Einbindung von sprachfremden Intellectual Properties ist
als Netzliste m¨oglich. Eine Netzliste ist eine synthetisierte Register-TransferBeschreibung. In h¨oheren Abstraktionsebenen k¨onnen diese Intellectual Properties nicht in ihrer Originalform verwendet werden. Zur Simulation eines
Systems in diesen Abstraktionsebenen muss ein Modell der IP erstellt werden. Dieser Prozess ist fehleranf¨allig und kostet Zeit und Geld, was den Erfolg
des Produktes weniger gut ausfallen lassen kann.
¨
1 EINFUHRUNG
4
Verhaltenssicht
Struktursicht
Systemebene
Algorithmische Ebene
Funktionelle Ebene
Gatterebene
Schalterebene
Elektrische Ebene
Testsicht
Physikalische Sicht
Abbildung 1.4: Das X-Diagramm nach Rammig. Gegen¨
uber dem YDiagramm nach Gajski bringt es die Testsicht zus¨atzlich in jede Entwurfsebene mit ein.
Die Umgehung der Erstellung eines Modells der Intellectual Property k¨onnte
den Entwurfsprozess weiter beschleunigen. Jedoch muss dazu eine L¨osung
gefunden werden, um die originalen IPs bereits in die Simulation h¨oherer
Abstraktionsebenen einzubinden. Die Entwicklung einer solchen L¨osung ist
Ziel der vorliegenden Arbeit.
Spezifikation
SW-Synthese
Betriebssystem
Modellierung
Entwurfssichten
HW-Sythese
Verifikation
Analyse
Rapid-Prototyping
Entwurfsebenen
Abbildung 1.5: Die P-Chart Entwurfsstrukturierung nach [Har02] f¨
ur den
Entwurf von HW/SW-Systemen
¨
1 EINFUHRUNG
1.1
5
Aufgabenstellung
Der Entwurf von Hardware-Software-Systemen wurde bisher dadurch erschwert, dass eine L¨
ucke im Entwurfsprozess zwischen der System-LevelBeschreibung und der Hardwarebeschreibung existierte. Um diese L¨
ucke zu
schließen, wurde SystemC entwickelt.
Jedoch ist ein Nachteil dieser Systementwurfsprache, dass man bisher entwickelte Komponenten in VHDL oder Verilog, so genannte Intellectual Properties, erst auf Netzlistenebene in SystemC einbinden kann. F¨
ur die Simulation von h¨oheren Abstraktionsebenen muss erst ein SystemC Modell der
Komponente erstellt werden. Das bedeutet zus¨atzliche Entwicklungsarbeit
und damit h¨ohere Entwurfskosten.
In dieser Arbeit soll ein Co-Simulationsansatz auf Systemebene untersucht
werden. Dabei soll die bereits synthesef¨ahige VHDL-Komponente auf einem
FPGA abgearbeitet werden und mit der Simulation der restlichen SystemCKomponenten gekoppelt werden. Der Entwurfsaufwand reduziert sich und
das Verhalten des Systems mit der realen Intellectual Property kann untersucht werden.
Zur einfacheren und schnelleren Adaptierung des FPGA an die SystemC-Simulation, soll ein automatisiertes Verfahren entwickelt werden. Der Vorteil
eines automatisierten Verfahrens besteht darin, Zeit und Kosten bei der Vorbereitung der Simulation zu sparen.
1.2
Gliederung der Arbeit
Das Thema dieser Arbeit ist die Automatische Adaption1 von HardwareAcceleratoren fu
¨ r Verhaltenssimulation. Das erste Kapitel enth¨alt eine
kurze Einf¨
uhrung in die Thematik und die Aufgabenstellung. Kapitel 2 beschreibt den aktuellen Stand von Techniken, auf die diese Arbeit aufbaut oder
die mit dem Thema verwandt sind. Mit der Methode der Adaptierung von
Hardwareakzeleratoren an die SystemC Verhaltenssimulation besch¨aftigt sich
Kapitel 3. Ein allgemeines L¨osungskonzept wird darin vorgestellt und darauf
1
F¨
ur den englischen Begriff Adaption wird im weiteren Verlauf dieser Arbeit der deutsche Begriff Adaptierung verwendet.
6
¨
1 EINFUHRUNG
aufbauend eine technische Umsetzung geboten. Kapitel 4 beschreibt die Automatisierung des vorgestellten L¨osungskonzeptes durch ein, im Rahmen dieser Arbeit entwickeltes, Programm. Der Nachweis u
¨ber die korrekte Funktion
der erarbeiteten L¨osungen wird in Kapitel 5 an einem Beispiel durchgef¨
uhrt.
Das 6. Kapitel fasst die Ergebnisse der Arbeit zusammen und gibt einen Ausblick auf Zukunftsperspektiven und M¨oglichkeiten der Weiterentwicklung.
2 STAND DER TECHNIK
2
7
Stand der Technik
Dieses Kapitel besch¨aftigt sich mit dem aktuellen Stand der Techniken, auf
die diese Arbeit aufbaut. Zun¨achst erfolgt eine Beschreibung der noch jungen
Systementwurfssprache SystemC. Der zweite Teil des Abschnittes definiert
den Begriff der Intellectual Properties und umreißt deren Bedeutung. Anschließend wird auf die Rolle der Simulation bei der Hardwareentwicklung
eingegangen und einige Beispiele f¨
ur Simulationswerkzeuge, darunter auch
Hardwareakzeleratoren vorgestellt. Das Ende des Kapitels faßt die hier gewonnen Erkenntnisse zusammen und arbeitet noch einmal kurz die Vor- und
Nachteile aktueller Techniken heraus.
2.1
SystemC
TM
SystemC 2 ist eine standardisierte Systementwurfs- und Verifikationssprache. Sie wurde im September 1999 eingef¨
uhrt und durch die OSCI (Open
TM
SystemC
Initative) standardisiert. Die OSCI ist ein Konsortium gr¨oßerer EDA-Firmen und IP-Providern. Mitglieder dieses Konsortiums sind zum
Beispiel ARM Ltd., Cadence Design Systems Inc., Synopsys Inc., Motorola,
Panasonic und andere. Mehr Informationen zu den Mitgliedern des Konsortiums befinden sich auf der Homepage von SystemC [Opea].
2
SystemC ist ein eingetragenes Warenzeichen der Open SystemCTM Initiative.
Abbildung 2.1: Logo von SystemC
TM
, Quelle [Opea]
8
2 STAND DER TECHNIK
SystemC Model
C, C++
System Level Model
Manual Conversion
Refine
Simulation
Analysis
VHDL/Verilog
Refinement
Results
Simulation
Synthesis
Synthesis
Rest of Process
Rest of Process
Gegenw¨artige Designmethodik
SystemC Designmethodik
Abbildung 2.2: Gegenw¨artige und SystemC Designmethodik, Quelle [Opeb]
SystemC ist eine C++ Klassenbibliothek und nutzt somit die M¨oglichkeit,
C++ durch Klassenbibliotheken zu erweitern ohne neue syntaktische Konstrukte hinzuzuf¨
ugen. Der Entwickler kann somit die ihm vertraute Sprache C++ und die damit verbundenen Entwicklungswerkzeuge weiterhin verwenden. SystemC wird u
¨ber die Open Source Lizenz [VA ] vertrieben. Die
Bibliothek kann somit kostenlos genutzt werden. Der Nutzer enth¨alt mit
der Bibliothek ein kostenloses Entwurfs- und Simulationspaket. Es enth¨alt
die notwendigen Konstrukte um Systemarchitekturen, inklusive Hardwaretiming, Nebenl¨aufigkeit und reaktivem Verhalten, zu modellieren, die nicht in
Standard C++ enthalten sind. Außerdem verf¨
ugt die Bibliothek bereits u
¨ber
einen Simulator mit dem die entworfenen Designs getestet werden k¨onnen.
Die Beschreibung des Simulators folgt in Abschnitt 2.3.1.
Mit SystemC kann ein Entwickler effektive zyklengenaue Modelle von Softwarealgorithmen, Hardwarearchitekturen und Schnittstellen eines System-onChip- (SoC) und System-Level-Designs beschreiben. Außerdem bietet es die
M¨oglichkeit eine ausf¨
uhrbare Spezifikation zu erstellen. Auch Hardware/Software-Codesign, welches in heutigen Systemen eine immer gr¨oßere Bedeutung
erlangt, wird unterst¨
utzt.
SystemC unterst¨
utzt den Systementwurf von der Spezifikation bis zur RegisterTransfer-Ebene. Bei bisher verwendeten Beschreibungsm¨oglichkeiten bestand
2 STAND DER TECHNIK
9
eine L¨
ucke im Entwurfsprozess. Zum Beispiel stehen in C/C++ keine geeigneten Beschreibungsmittel f¨
ur Hardware zur Verf¨
ugung, da Konzepte, wie
Nebenl¨aufigkeit und ein Zeitmodell, fehlen. Deshalb war bisher eine manuelle Konvertierung von einem C/C++ Verhaltensmodell in eine, durch eine
Hardwarebeschreibungssprache modellierte, Regsiter-Transfer-Beschreibung
notwendig. Abbildung 2.2 stellt die bisher und auch gegenw¨artig verwendete
Designmethode und die Designmethodik von SystemC gegen¨
uber.
Als junges Entwurfssystem gibt es allerdings noch Einschr¨ankungen. So ist
beim Softwaredesign die Einbindung von Echtzeitbetriebssystemen (RTOS)
noch nicht m¨oglich. Eine Verbesserung soll Version 3 von SystemC bringen.
TM
r
Als Werkzeuge zur Synthese kommt der CoCentric
SystemC Compiler
r
der Firma Synopsys [Syn] zum Einsatz. Er erlaubt sowohl eine Synthese von
der Register-Transfer-Ebene als auch von der Verhaltensebene. Der Compiler
ist jedoch nicht in der kostenfreien Klassenbibliothek enthalten und muss
TM
r
gesondert gekauft werden. Mehr Informationen zum CoCentric
SystemC
Compiler sind in [Syn03] zu finden.
2.2
Intellectual Properties
Gorden Moore formulierte 1965 das nach ihm benannte Mooresche Gesetz.
Es besagt, dass sich die Anzahl der Transistoren auf einer gegebenen Fl¨ache
Silizium etwa alle 18 Monate verdoppelt. Abbildung 2.3 stellt diesen Sachverhalt grafisch dar. Dieses Gesetz hat bis heute noch G¨
ultigkeit und wird
nach Meinung von Experten auch noch 10 Jahre seine G¨
ultigkeit behalten.
F¨
ur die Hardwareentwickler ergibt sich die Konsequenz, dass auf der gleichen Fl¨ache Silizium eine immer gr¨oßere Funktionalit¨at untergebracht werden kann. Die Folge ist ein System-on-Chip-Design, bei dem versucht wird,
ein digitales System auf einem einzigen Chip zu implementieren.
Der Vorteil einer System-On-Chip-L¨osung ist eine gr¨oßere Zuverl¨assigkeit
gegen¨
uber Systemen aus mehreren Chips. Schwachstellen liegen bei diesen
Systemen vor allem in der physischen Verdrahtung der Chips untereinander.
Der Nachteil eines System-on-Chip ist eine gr¨oßere Spezialisierung der Funktion. Mit einer gr¨oßeren F¨
ulle an Funktionen sinkt das Anwendungsfeld der
Chips. Doch je kleiner das Anwendungsfeld, desto weniger St¨
uckzahlen werden vom Chip gebraucht. Jedoch m¨
ussen sich mit dem Verkauf des Chips auch
10
2 STAND DER TECHNIK
Abbildung 2.3: Darstellung von Moores Gesetz, Quelle [Int]
die Entwurfskosten amortisieren. Damit sich der Entwurf von SoC-L¨osungen auch weiterhin lohnt, m¨
ussen die Entwicklungskosten und die Time-to3
Market sinken.
Strategien zur Senkung der Entwicklungskosten und der Time-to-market stellen zum Einen eine weitere Entwurfsautomatisierung und zum Anderen die
Wiederverwendung bereits entwickelter Komponenten dar. Die Wiederverwendung von Komponenten basiert auf der Nutzung von Intellectual Properties.
Intellectual Properties (dt. Geistiges Eigentum) ist nach der allgemeinen Definition jedes Produkt des menschlichen Intellekts, das einzigartig, neuartig und nicht offensichtlich ist. Dazu geh¨oren literarische, k¨
unstlerische und
wissenschaftliche Arbeiten, Leistungen von K¨
unstlern, Erfindungen auf allen Gebieten der menschlichen Erkenntnis, wissenschaftliche Entdeckungen,
industrielle Designs, eingetragene Waren- und Dienstleistungsmarken, Handelsnamen und Kennzeichnungen sowie alle weiteren Rechte aus intellektueller T¨atigkeit in den Gebieten der Industrie, Wissenschaft, Literatur oder
Kunst. [Wor, Mar02, Mic04]
3
Time-to-market gibt die Zeit an, die von der Idee bis zur Marktreife eines Produktes
vergeht.
2 STAND DER TECHNIK
11
Custom
Design
IP
Custom
Design
IP
IP
IP
Custom
Design
Custom
Design
IP
Abbildung 2.4: Aufbau eines System-on-Chip aus IPs und selbstentwickelten
Komponenten
Eine Intellectual Property (IP) im Sinne der Hardwareentwicklung stellt eine
Hardwarekomponente dar, die bereits entwickelt wurde. Diese Komponenten
werden in neue Designs neben selbst entwickelten Komponenten eingebunden
¨
(Abbildung 2.4), im Idealfall ohne daran Anderungen
vornehmen zu m¨
ussen.
Dadurch entf¨allt die Entwicklung dieser Teilsysteme im Entwurfsprozess und
Entwicklungszeit wird eingespart.
Die IP kann in verschiedenen Beschreibungen vorliegen [Har04]. Man unterscheidet zwischen Hard-IPs und Soft-IPs. Hard-IPs besitzen ein vorgegebenes Layout und Timing. Sie haben fixe Schnittstellen. Die Optimierung der
IPs ist in Bezug auf Geschwindigkeit, Siliziumfl¨ache und Leistungsaufnahme
getroffen. Sie sind leicht zu verifizieren, außerdem halbleiterhersteller- und
technologieabh¨angig. Jedoch besitzen sie den Nachteil, dass sie unflexibel
sind.
Soft-IPs basieren auf einer synthetisierbaren Beschreibung ausgehend von
einer Hardwarebeschreibungssprache wie zum Beispiel VHDL oder Verilog.
Eine Soft-IP ist vorcompiliert als Netzliste oder als Quellcode verf¨
ugbar. Sie
sind halbleiterhersteller- und technologieunabh¨angig konzipiert. Soft-IPs sind
flexibel und zum Teil parametrisierbar.
Das Konzept der IPs wird als wichtiger Schritt angesehen, um die Entwicklungszeiten von Hardware zu verringern. Vor allem f¨
ur die System-on-ChipEntwicklung stellt es ein Schl¨
usselkonzept dar.
12
2 STAND DER TECHNIK
Jedoch gibt es bei der IP-Nutzung noch einige Hindernisse. Zum Beispiel
stellt sich die Frage nach einem einheitlichen Qualit¨atkriterium f¨
ur IPs, um
bei der Auswahl von IPs einheitliche Vergleichskriterien zu haben. Zu den
Qualit¨atsmerkmalen einer IP z¨ahlen unter anderem der Umfang der Dokumentation, Skripte zur Logiksynthese, Applikationsbeispiele, Simulationsergebnisse, Testdaten und Verifikationsergebnisse.
Um bestehende Hindernisse bei der Nutzung und dem Handel von IPs zu
bew¨altigen, wurde das Projekt IPQ [ipq] ins Leben gerufen. Die Zielsetzung des Projektes liegt darin, eine entscheidende Verbesserungen f¨
ur die
Qualit¨atssicherung bei der Anwendung und Entwicklung von IP-Modulen zu
erzielen. Dazu geh¨oren Spezifikationsmethoden, eine intelligente IP-Suche,
Eingangschecks von IPs, Verfahren zur IP-Anpassung und Beitr¨age zur Standardisierung.
Das dabei auftretende Problem lag im Nichtvorhandensein eines einheitlichen
Beschreibungsstandards u
¨ber Firmengrenzen hinweg. Jede Firma benutzt ihre eigenen internen Standard und verzichtet auch ungern auf diese, da eine
Umstellung mit hohen Kosten verbunden ist. Dadurch wird der IP-Handel erschwert, denn die IPs m¨
ussen nach dem Kauf manuell an den firmeninternen
Standard angepasst werden.
Provider A: IP
IP
…
Provider B: IP
IP
IP
IP User
…
IP
Provider C: Simulation
IP1 IP2 IP3
IP4
IP6
Provider D: Synthese
Provider E: Simulation
Abbildung 2.5: IPQ soll eine standardisierte Kommunikation von IP-User
und verschiedenen IP-Serviceprovidern erlauben. Quelle [VH04]
2 STAND DER TECHNIK
13
Zur L¨osung des Problems musste ein standardisiertes und von den Firmen
akzeptiertes Austauschformat gefunden werden. Dieses Format musste außerdem die M¨oglichkeit bieten, eine firmeninterne Beschreibungen in das standardisierte Format zu konvertieren, aber auch den Weg vom standardisierten
in firmeninterne Formate gew¨ahrleisten. Als L¨osung wurde das IPQ-Format
entwickelt. Es basiert auf XML-Schema. Außerdem fand die Entwicklung
zahlreicher Tools statt, die zum Beispiel das Suchen einer IP vereinfachen.
Weitere Informationen zu diesem Thema bieten [ipq], [VLKH04], [VH04] und
[VLH+ 03].
Mit Hilfe des IPQ-Formates und der dazu entwickelten Tools wird eine standardisierte Kommunikationsm¨oglichkeit von IP-Usern und IP-Serviceprovidern
(vgl. Abbildung 2.5) geboten. Das System ist bereits einsatzf¨ahig. Jedoch
scheitert sein Einsatz durch teilweise ungekl¨arte rechtlichen Fragen zum IPHandel und zur IP-Nutzung. Doch auch f¨
ur dieses Problem wird sich eine
L¨osung finden und eine intensivere Nutzung von IPs beim Systementwurf
wird Einzug halten. Damit lassen sich dann die Entwicklungszeit und -kosten
weiter senken.
2.3
Simulation
Der Begriff Simulation wurde vom Verein Deutscher Ingenieure (VDI) in
der Richtlinie 3633 [Ver96] wie folgt definiert: Simulation ist ein Verfahren
”
zur Nachbildung eines Systems mit seinen dynamischen Prozessen in einem
experimentierbaren Modell, um zu Erkenntnissen zu gelangen, die auf die
Wirklichkeit u
¨bertragbar sind.
Im weiteren Sinne wird unter Simulation das Vorbereiten, Durchf¨
uhren und
Auswerten gezielter Experimente mit einem Simulationsmodell verstanden.
Mit Hilfe der Simulation kann das zeitliche Ablaufverhalten komplexer Systeme untersucht werden.“
Die Simulation ist ein wichtiges Werkzeug beim Hardwareentwurf, um ein
System w¨ahrend des Entwurfsprozesses zu testen und Fehler fr¨
uhzeitig zu
lokalisieren und zu beseitigen. Die Durchf¨
uhrung von Simulationen soll den
Nachweis erbringen, dass der verfeinerte Entwurf noch mit der Spezifikation
des Systems u
¨bereinstimmt.
Den Ausgangspunkt einer Hardwaresimulation bildet eine Beschreibung in einer Hardwarebeschreibungssprache (HDL, engl. Hardware Description Language). Die wichtigsten Sprachen sind VHDL, Verilog und SystemC. Auf
14
2 STAND DER TECHNIK
Entwurfsebene
Verhalten
Register-Transfer
Gatter (Logik)
Schalterebene
Elektrische Ebene
Geometrie
Aufwand (relativ)
1
10
100
1 000
10 000
100 000 - 1 000 000
Tabelle 2.1: Simulationsaufwand von verschiedenen Entwurfsebenen, Quelle
[M¨
ul02]
Basis dieser Beschreibung wird von einem Simulationswerkzeug ein Simulationsmodell erstellt. Ein Simulationsmodell kann unterschiedliche Abstraktionsebenen eines Systems nachbilden. Dabei erh¨oht sich der Detailgrad des
Simulationsmodells mit steigender N¨ahe zur Implementierung.
Mit steigendem Detailgrad n¨ahert sich die Genauigkeit des Simulationsmodells stark dem realen System an. Durch die Ber¨
ucksichtigung von Verz¨oge¨
rungszeiten von Gattern und Leitungen, sowie dem Ubergang
zu einer vierwertigen Logik, entsprechen die Ergebnisse der Simulation den real zu erwarteten Daten des zu implementierenden Systems.
Der hohe Detailgrad der Simulation wirkt sich jedoch stark auf die Simulationsgeschwindigkeit aus. Durch eine steigende Anzahl zu ber¨
ucksichtigender
Parameter in einem Simulationsschritt, steigt der Simulationsaufwand stark
an und die Simulationsgeschwindigkeit verringert sich. Tabelle 2.1 stellt diesen Sachverhalt dar. Dauert eine Simulation auf der Verhaltensebene nur ein
paar Minuten, kann die gleiche Simulation auf Gatterebene durchaus mehrere
Stunden beanspruchen. Deshalb sollte bei der Vorbereitung einer Simulation
darauf geachtet werden, welche Genauigkeit die Simulationsdaten zur Verifizierung der aktuellen Entwurfsebene besitzen m¨
ussen und dementsprechend
das Simulationsmodell auszuw¨ahlen.
Es existieren eine Vielzahl von Simulatoren und Simulationsmethoden, die
die Simulation unterschiedlicher Abstraktionsebenen beherrschen. Einige Simulatinsmethoden versuchen zudem, dem Zeitverlust, der durch genauere
Modelle entsteht, mit verschiedenen Ans¨atzen entgegenzuwirken. Eine kleine Auswahl von Simulatoren und Simulationsmethoden sollen die folgenden
Abschnitte vorstellen.
2 STAND DER TECHNIK
2.3.1
15
Simulation mit SystemC
SystemC ist eine C++ Klassenbibliothek in der auch ein Simulator vorhanden
ist. Eine ausf¨
uhrliche Beschreibung von SystemC enth¨alt Abschnitt 2.1.
Der Ablauf der Simulation ist in Abbildung 2.6 dargestellt. Den Ausgangspunkt stellt das in SystemC beschriebene Modell eines Systems dar. Die
einzelnen Module des Modells und der Testbench werden von einem C++Compiler u
¨bersetzt und mit dem Simulationskern aus der Bibliothek zusammengelinkt. Das Ergebnis ist ein ausf¨
uhrbares Programm, welches die
Simulationsergebnisse erzeugt.
SystemC
Bibliothek
C++
Compiler
Linker
Modell
Testbench
Ausführbares
Programm
(Simulator)
Simulationsergebnisse
Abbildung 2.6: Simulation eines Modells mit SystemC
Die SystemC-Simulation ist zyklusbasiert. Die Aktualisierung von Prozes¨
sen und Signalen erfolgt mit dem Ubergang
des Taktsignals. Die Folge ist,
dass die Genauigkeit der Simulation auf eine Taktperiode beschr¨ankt ist. Die
SystemC-Bibliothek enth¨alt zur Simulationssteuerung einen zyklusbasierten
Scheduler. Er behandelt alle Ereignisse von Signalen und f¨
uhrt die Prozesse
aus, deren Eingangssignale sich ¨andern. Die manuelle Simulationskontrolle
ist beschr¨ankt auf das Starten, Stoppen und schrittweises Ausf¨
uhren der Simulation durch SystemC-Funktionen.
Die Ausgabe der Simulationsergebnisse kann in Tracefiles erfolgen. Dazu bietet die Bibliothek spezielle Funktionen, die es auch erlauben, die Tracefiles
in verschiedenen Formaten zu generieren. Formate die unterst¨
utzt werden
sind das Integrated Signal Data Base (ISDB) Format, Waveform Intermediate Format (WIF) und das Value Change Dump (VCD) Format. Eine andere
M¨oglichkeit die Simulationsdaten auszugeben, besteht in der Nutzung von
vorhandenen C++-Ausgabefunktionen wie cout.
16
2 STAND DER TECHNIK
Weitere Informationen zu SystemC und der Simulation damit finden sich im
Benutzerhandbuch [Opeb] sowie in der funktionalen Spezifikation [Ope02].
2.3.2
Hardwaresimulation mit ModelSim
r
ModelSim
ist eine HDL-Simulationssoftware, die von der Firma Model
Technology [Mod] entwickelt wurde. Model Technology ist eine betriebseigene Tochtergesellschaft von Mentor Graphics [Mena]. ModelSim unterst¨
utzt
die Simulation von VHDL, Verilog und SystemC. Dabei k¨onnen Simulationsmodelle von der Verhaltenssimulation u
¨ber Netzlistenmodelle bis hin zur
platzierten und trassierten Schaltung mit einem genauen Zeitmodell simuliert
werden. Den Simulator gibt es f¨
ur alle g¨angigen Betriebssysteme.
ModelSim
®
r
Abbildung 2.7: Logo von ModelSim
, Quelle [Mod]
Zum Simulator geh¨ort ein Projektmanager zur Kontrolle der Simulation.
Zus¨atzlich bietet er eine integrierte Debugumgebung, die es erlaubt, auf alle Signale des Designs zuzugreifen. Der Verlauf der einzelnen Signale wird
mit einem Waveformbetrachter visualisiert und kann dadurch genau verfolgt
werden. Ein Wizard und Templates erlauben dem Benutzer, Testbenches
schnell zu erstellen. ModelSim benutzt als Simulationssprache eine Tcl basierte Skriptsprache. Dadurch k¨onnen an den Simulator leicht andere Programme angebunden werden.
Die Simulation erfolgt auf die folgende Weise. Die Hardwarebeschreibung
wird zun¨achst plattformunabh¨angig u
¨bersetzt. Anschließend erzeugt der Compiler daraus einen maschinenspezifischen Code f¨
ur die ausf¨
uhrende Maschine,
der zur Laufzeit optimiert wird. Die Ausf¨
uhrung des Codes erzeugt die Simulationsdaten des Modells. ModelSim zeichnet die Ausgaben des Codes auf
und stellt sie zur Auswertung dem Nutzer zur Verf¨
ugung.
Von ModelSim existieren verschiedene Versionen. Die meisten Features stellt
die LE Version zur Verf¨
ugung. Mehr Informationen zum Simulator bietet die
Homepage von Model Technology [Mod] und das Handbuch zu ModelSim
[Mod03].
2 STAND DER TECHNIK
2.3.3
17
HW/SW-Cosimulation
Hardware/Software-Codesign ist ein Schl¨
usselkonzept, um die Entwicklung
moderner Hardware/Software-Systeme zu vereinfachen und zu beschleunigen. Anstatt Hardware und Software getrennt zu entwickeln und beide Bereiche im Anschluss m¨
uhevoll zusammenzuf¨
ugen, erlaubt Hardware/SoftwareCodesign die Entwicklung beider Bereiche zu parallelisieren. Die Cosimulation von Hardware und Software liefert dabei ein wichtiges Hilfsmittel, um
das Design zu testen und zu verifizieren.
Die HW/SW-Cosimulation verfolgt zwei konkurrierende Ziele. Das erste Ziel
besteht darin, die Simulation mit der gr¨oßtm¨oglichen Geschwindigkeit zu betreiben. Dem entgegen steht ein hoher Detailgrad der Simulationsergebnisse.
Zum Erreichen einer hohen Genauigkeit der Simulationsergebnisse werden
Modelle mit einem hohen Detailgrad verwendet. Aber je mehr Details simuliert werden, umso geringer ist die Simulationsgeschwindigkeit. Aus diesem
Grund existieren verschiedene Ans¨atze zur HW/SW-Cosimulation, die versuchen, die Simulationsgeschwindigkeit zu erh¨ohen und dabei m¨oglichst genaue
Ergebnisse zu erzielen.
Der urspr¨
ungliche Ansatz besteht darin einen Hardwaresimulator zu nutzen. Die Simulation findet unter Nutzung einer einzigen Simulationsumgebung statt, in der sowohl Hardware als auch die darauf ausgef¨
uhrte Software
simuliert wird. Dieser Ansatz bietet eine geringe Simulationsgeschwindigkeit,
da das simulierte Hardwaremodell einen hohen Detailgrad besitzt. Der Vorteil besteht darin, dass keine Schnittstellen zu anderen Systemen notwendig
sind.
Zur Beschleunigung der Simulation kann ein Bus-Modell verwendet werden (Abbildung 2.8). Ein Bus-Modell ist eine Hardwarebeschreibung, die nur
ein ereignisdiskretes Modell des Bus-Interfaces des Prozessors simuliert. Die
Befehlsinterpreter
SW
Bus-Modell
HDL
Hardwaresimulator
Backplane
Abbildung 2.8: HW/SW-Cosimulation mit dem Bus-Modell
18
2 STAND DER TECHNIK
Instructionset-Simulator
SW
Hardwaresimulator
Backplane
Abbildung 2.9: HW/SW-Cosimulation mit einem Instruction-set-Simulator
Funktionalit¨at des Prozessors, dass heißt die Applikationssoftware, f¨
uhrt ein
Befehlsinterpreter aus. Er verf¨
ugt u
¨ber Information zu den ben¨otigten Taktzyklen einer Sequenz von Befehlen zwischen zwei I/O-Operationen auf dem
Bus. Dieses Modell ist n¨
utzlich, um die low-level Interaktion der Kommunikation auf dem Prozessorbus zu simulieren. Jedoch ist es unter Umst¨anden
nicht einfach, ein genaues Busmodell eines Prozessors zu erstellen.
Einen anderen Ansatz verfolgen Instruction-set Simulatoren (ISS). Ihn
stellt Abbildung 2.9 dar. Ein ISS bildet ein Modell der Befehlssatzarchitektur
eines speziellen Prozessors nach. Das Modell enth¨alt alle Details eines ereignisdiskreten Prozessormodells, welches die volle Funktionalit¨at des Prozessors
bereitstellt. Dieser Cosimulationsansatz verbindet einen Hardwaresimulator,
auf dem die Hardwarekomponenten simuliert werden und den ISS, der die
Ausf¨
uhrung der Software u
¨bernimmt.
Die Heterogene Cosimulation verfolgt die Kopplung von Hardware- und
Software-Entwicklungstools. Dies erlaubt die schnelle Ausf¨
uhrung von Software-Anwendungscode auf einer simulierten Hardware. Die Cosimulation verschiedener Hardwarekomponenten und der Software l¨auft in einem heterogenen Netzwerk aus PC’s oder Workstations.
Der Ansatz des Hardware-Modells, wie ihn Abbildung 2.10 zeigt, kann
zu
simulierende
Software
Realer
Prozessor
HW
Hardwaresimulator
Backplane
Abbildung 2.10: HW/SW-Cosimulation mit dem Hardware-Modell
2 STAND DER TECHNIK
19
zu simulierende
Software
Softwaretransformation
Ausführender
Prozessor
HW
Hardwaresimulator
Backplane
Abbildung 2.11: HW/SW-Cosimulation mit dem compilierten Modell
benutzt werden, falls der Zielprozessor bereits existiert. Zur Ausf¨
uhrung der
Software findet der Zielprozessor statt eines Simulators Verwendung. Damit
ist eine Echtzeitausf¨
uhrung der Software m¨oglich. Die Simulation der Hardwarekomponenten findet durch einen Hardwaresimulator statt, der mit dem
Prozessor gekoppelt ist.
Beim compilierten Modell kommt der Prozessor des ausf¨
uhrenden Rechners zum Einsatz (Abbildung 2.11). Die zu simulierende Software wird in Code dieses Prozessors transformiert und auf diesem ausgef¨
uhrt. Eine Schnittstelle verbindet die Softwareausf¨
uhrung mit dem Hardwaresimulator, der die
Ergebnisse der Hardwarekomponenten berechnet.
Die h¨ochste Simulationsgeschwindigkeit erzielt unter allen Ans¨atzen die Hardwareemulation, welche Abbildung 2.12 veranschaulicht. Dieses Verfahren
nutzt programmierbare Hardwarebausteine, wie zum Beispiel FPGAs. Auf
Basis dieser Bausteine werden die entwickelten Hardwarekomponenten implementiert. Die Softwareausf¨
uhrung findet auf dieser Implementierung statt.
Hardwarebeschreibung
des Prozessors
zu simulierende
Software
Implementierung
FPGA
Hardwaresimulator
Backplane
Abbildung 2.12: HW/SW-Cosimulation mit Hardwareemulation
20
2 STAND DER TECHNIK
Die Geschwindigkeit, die dieser Ansatz erreicht, kann bis zu einem Zehntel
der realen Ausf¨
uhrungsgeschwindigkeit betragen.
Bei der Verwendung von mehreren Simulatoren spielt die Schnittstelle zwischen ihnen eine große Rolle. Die Schnittstelle stellt in den meisten F¨allen
den gr¨oßten Engpass dar und ist somit ein wichtiger Faktor f¨
ur die resultierende Simulationsgeschwindigkeit. Die Kopplung der Simulatoren kann auf
verschiedene Arten erfolgen.
Die Simulatoren k¨onnen parallel arbeiten und dabei durch einen Synchronisationsmechanismus f¨
ur den Datenaustausch gekoppelt sein. Das hat zur
Folge, dass ein schneller Simulator eventuell lange auf einen langsameren
warten muss. Außerdem entsteht durch die Synchronisation ein hoher Kommunikationsoverhead f¨
ur die Schnittstellen.
Ein anderer Kopplungsansatz besteht in einer Master-Slave-Simulation. Dabei u
¨bernimmt ein Simulator die Rolle des Masters und ruft andere Simulatoren auf, wenn er Ergebnisse von ihnen ben¨otigt. Bei der Ausf¨
uhrung mehrere
Simulatoren auf einem Prozessor bringt diese Variante Vorteile. Erstens wird
jeweils nur ein Simulator ausgef¨
uhrt, dem die gesamte Prozessorleistung zur
Verf¨
ugung steht. Zus¨atzlich verringert sich der Kommunikationsoverhead, da
nur wenige Synchronisationsdaten ausgetauscht werden m¨
ussen.
Die Hardware/Software-Cosimulation stellt ein wichtiges Werkzeug dar, um
die Entwicklung f¨
ur zuk¨
unftige Hardware/Software-Systeme zu beschleunigen und zu vereinfachen. Eine ausf¨
uhrlichere Beschreibung der Cosimulationsans¨atze bieten [Vra98] und [Har04].
2.3.4
Hardware-Akzeleratoren
Der Nachteil einer HDL-Simulationssoftware ist die stark sinkende Simulationsgeschwindigkeit mit steigendem Detailgrad und steigender Designgr¨oße.
Um diesen Nachteil der Simulation zu vermeiden, werden Hardwareakzeleratoren eingesetzt. Sie emulieren das System auf FPGAs oder simulieren es
auf Spezialprozessoren. Dadurch steigert sich die Geschwindigkeit der Simulation zum Teil erheblich. Nach Angaben einiger Hersteller solcher Systeme
liegt der Beschleunigungsfaktor zwischen 10 und 10 000.
Ein Hardwareakzeleratorsystem besteht allgemein aus einer Spezialhardware
und einem Softwarepaket. Die Spezialhardware hat die Aufgabe, die Simulation oder Emulation durchzuf¨
uhren und die Simulationsergebnisse zu liefern.
2 STAND DER TECHNIK
21
Das Softwarepaket ist daf¨
ur zust¨andig, den ausf¨
uhrbaren Code bzw. die Konfigurationsdaten f¨
ur den Hardwareakzelerator aus einer HDL-Beschreibung
zu compilieren bzw. zu generieren. Außerdem hat es die Aufgabe, die Kommunikation zwischen dem Hostrechner und dem HW-Akzelerator zu managen. Dies beinhaltet den compilierten Code in den HW-Akzelerator zu laden,
Befehle zur Steuerung und zum Debuggen an den HW-Akzelerator zu senden
und die Simulationsdaten zu empfangen und aufzuzeichnen.
2.3.4.1
Tharas - Hammer 100
r
Den Hardwareakzelerator Hammer
100 stellt die Firma Tharas Systems
[Thaa] her. Es ist ein Simulationssystem, das aus Spezialprozessoren besteht.
Die Prozessoren berechnen das Simulationsmodell, das aus einer Hardwarebeschreibungssprache kompiliert wurde.
Das System besteht aus bis zu 8 Boards mit je 16 Spezialprozessoren je
nach Ausbaustufe. Die Prozessoren sind in 0,18 Mikrometertechnologie mit
5 Metallisierungsebenen gefertigt. Das System ist in einem CompactPCIGeh¨ause untergebracht, wie in Abbildung 2.13 zu sehen ist.
Die Prozessoren sind speziell daf¨
ur gebaut, um Hardwarebeschreibungskonstrukte zu beschleunigen. Alle Prozessoren k¨onnen miteinander kommunizieren und in jedem Befehlszyklus gemeinsam Daten benutzen. Das Geh¨ause
r
Hammer
100 System
r
Prozessorboard des Hammer
100
r
Abbildung 2.13: Hammer
100 System von Tharas, Quelle [Thab]
22
2 STAND DER TECHNIK
nutzt eine gesch¨
utzte Backplane, um eine hohe Prozessorkonnektivit¨at zu
liefern. Die Busarchitektur wurde speziell entworfen, um den hohen Kommunikationsanforderungen eines hoch parallelen Rechensystems gerecht zu
werden.
Als Hardwarebeschreibungssprachen werden der IEEE Verilog 1364-2001 und
der IEEE VHDL 1076-2002 Standard unterst¨
utzt. Der Compiler analysiert
eine Hardwarebeschreibungssprache auf syntaktische und semantische Korrektheit. Aus der Beschreibung generiert er optimalen, parallelen Code f¨
ur
die Spezialprozessoren. Der Compiler u
¨bersetzt bis zu 50 Millionen RTLGatter¨aquivalente je Stunde.
Das Hammer 100 System unterst¨
utzt verschiedene Hardwarebeschreibungskonstrukte, wie zum Beispiel Latches, mehrere Takte, Gated Clocks und Modelle mit Signalst¨arken. Alle synthetisierbaren Verilog und VHDL Konstrukte
k¨onnen beschleunigt werden. Dar¨
uber hinaus ist es auch m¨oglich, Testbenches zu beschleunigen, sowie Modelle mit Verz¨ogerungszeiten auszuf¨
uhren.
Zur Software geh¨ort auch der Runtime Manager. Er erleichtert die Laufzeitkontrolle der Hardware und die Kommunikation zwischen dem Akzelerator
und dem Host-Software-Simulator. Die Hammer 100 Software erlaubt eine
nahtlose Integration von existierenden Verifikationsumgebungen. Somit kann
eine verteilte Ausf¨
uhrung der Simulation auf dem Hammer 100 und einem
Software-HDL-Simulator ebenfalls vollzogen werden.
Der Debugger kommuniziert mit dem Hardware Trace-Buffer, um w¨ahrend
des Debuggen des Designs einen schnellen Datengewinn aus dem Akzelerator zu gew¨ahrleisten. Das Debugging wird in Hardware ausgef¨
uhrt und ist
dadurch sehr schnell. Auch schrittweises Debugging des Designs ist m¨oglich.
Die Aufzeichnung der Simulationsdaten kann in einem Tracefile erfolgen.
Nach Angaben von Tharas Systems [Thab] beschleunigt das Hammer 100
System die Simulation um den Faktor 10 bis 10000 gegen¨
uber dem schnellsten Software-HDL-Simulator. Die Ausbaustufen des Hammer 100 sind f¨
ur 2,
4, 8, 16 und 32 Millionen Gatter¨aquivalente ausglegt. Bei einer Zusammenschaltung mehrerer Hammer 100 simuliert das System bis zu 64, 96 oder 128
Millionen Gatter¨aquivalente. Der Preis des Simulationssystems liegt zwischen
2,65 und 7,5 US-Cent pro Gatterequivalentkapazit¨at.
Mehr Informationen zu diesem System bietet die Homepage von Tharas Systems [Thaa] und die Brosch¨
ure zum Hammer 100 System [Thab].
2 STAND DER TECHNIK
2.3.4.2
23
Mentor Graphics - VStation
Das VStation-System von Mentor Graphics [Mena] gliedert sich in zwei Teile.
TM
Die Hardwareseite bildet die VStation PRO und das Softwarepaket heißt
TM
VStation TBX. Das System stellt eine komplette Umgebung bereit, die es
erm¨oglicht, komplexe Designs von 1,6 bis 120 Millionen Gatter zu verifizieren.
Die VStationPRO ist eine FPGA-basierte Emulationsumgebung, die sich aus
mehreren Boards zusammensetzt und dadurch leicht skalierbar ist. Ein Board
besitzt die Ressources, um entweder 1,67, 3,33 oder 6,67 Millionen Gatter zu
emulieren. Die Emulationsgeschwindigkeit des Systems reicht von 500 KHz
bis 2 Mhz. Nach außen stellt das System je nach Ausbaustufe zwischen 512
und 4608 I/O-Verbindungen bereit.
TM
Der VStationPRO VirtualLogic Compiler erlaubt ein direktes Mapping des
Designs von der Register-Transfer-Ebene auf die FPGAs der VStationPRO
ohne zuvor eine Synthese auszuf¨
uhren. Dadurch werden Signalnamen und die
Hierarchie des Designs beibehalten. Eine Simulator¨ahnliche Debugumgebung
erm¨oglicht es, alle Signale des Designs zu u
¨berwachen. Auch Quellcodedebugging mit Haltepunkten und das Anzeigen von Waveforms wird unterst¨
utzt.
Die Software VStationTBX (TestBench-XPress) liefert zus¨atzlich noch eine Verifikationsumgebung f¨
ur die Simulation und Emulation. Es werden die
Sprachen SystemC und SystemVerilog unterst¨
utzt. VHDL kann nur als RTBeschreibung verarbeitet werden. VStationTBX erlaubt eine schnelle Kommunikation zwischen der VStationPRO, einem Simulator und den Verifikationsprogrammen auf dem Hostrechner.
Abbildung 2.14: VStation
[Men03]
TM
Pro System von Mentor Graphics, Quelle
24
2 STAND DER TECHNIK
Weiterf¨
uhrende Informationen zum VStation-System finden sich auf der Homepage der VStation [Menb]. Produktbeschreibungen zur VStationPRO liefern [Menc] und [Men03]. Mehr Informationen u
¨ber den VStationTBX enthalten [Mend] und [Men04].
2.3.4.3
Aptix - System Explorer
TM
TM
r
Der Aptix
System Explorer (Abbildung 2.15) ist ein System f¨
ur Emulation, Rapid Prototyping und HW/SW-Cosimulation. Es erlaubt die Emulation
und das Debugging eines System-on-Chip Designs.
Die Grundlage des Systems besteht aus der Field Programmable Circuit
r
Board
Architektur. Diese Architektur kombiniert eine Prototypingfl¨ache
r
mit einer programmierbaren Verbindungsstruktur, den FPIC
s (Field Pror
grammable Interconnect Component ). FPICs sind elektronisch konfigurierbare bi-direktionale Verbindungsstrukturen und stellen die Verbindungen
zwischen den Prototypingfl¨achen her. Die Prototypingfl¨achen k¨onnen mit
FPGAs und Systemkomponenten wie DSPs, RAM oder Prozessoren best¨
uckt
werden. Dadurch bildet der System Explorer eine rekonfigurierbare Prototypingplattform.
Zum System Explorer geh¨ort auch ein Softwarepaket. Es besteht aus den
TM
TM
TM
Programmen Design Pilot , Explorer 2000 und Expeditor . Der Design
Pilot f¨
uhrt das logische Mapping durch und generiert die Netzlisten. Er bildet
die entworfene Logik und Soft-IPs auf die Ziel-FPGAs ab. Außerdem f¨
uhrt
er eine automatische hierarchische Blockgruppierung und Partitionierung des
Entwurfs durch.
Software-controlled reconfigurable
hardware enables rapid design
changes and extensive visibility.
TM
r
Abbildung 2.15: Aptix
System Explorer
, Quelle [Apt00]
2 STAND DER TECHNIK
Typ
Emulationskapazit¨at
in ASIC Gattern
Blockmemory
Prototypingfl¨ache
max. Anzahl FPGAs
Anzahl Abgreifpunkte
Einsatzzweck
25
MP3CF
2,5 Millionen
MP4CF
3 Millionen
6 MBit
1920 Pins
12
1500
DSP-basierte Designs
mit m¨aßigen Anforderungen an die Verbindungsstruktur zwischen den Komponenten
10 MBit
2880 Pins
20
2000
optimiert f¨
ur Prototypen mit großen internen Bussen und hohen
Anforderungen an die
Verbindungsstruktur
TM
r
Tabelle 2.2: Technische Daten des Aptix
System Explorer
TM
Der Explorer 2000 f¨
uhrt das Mapping des partitionierten Designs auf die
physischen Komponenten des Prototypingsystems aus. Er routet die einzelnen FPGAs und Komponenten untereinander durch die FPICs und konfiguriert anschließend den Prototypen. Nach der Konfiguration f¨
uhrt die Software eine Automatisierung des Hardware-Debugging durch. Der Explorer 2000
routed automatisch Probes4 und konfiguriert den Agilent Logikanalysator
zum Erfassen von Simulationsdaten.
TM
Die Aufgabe des Expeditor besteht darin, eine Schnittstelle zu anderen
Simulatoren und Testwerkzeugen herzustellen. Damit kann eine verteilte Simulation erfolgen.
Dem System Explorer liegt eine blockbasierte Verifikationsmethodik zu Grunde. Diese erlaubt die schnelle Erstellung von Prototypen, ein einfaches Debugging und eine rasche Implementierung von Designver¨anderungen. Der Prototyp wird Block f¨
ur Block nach der Hierarchie des Designs aufgebaut. Da
Logik¨anderungen meist auf eine FPGA begrenzt sind, erm¨oglicht das System
nach einer Korrektur am Design, die einzelne Ersetzung der fehlerbehafteten
¨
FPGA und somit eine schnelle Anderung
des Designs.
Im Entwurfsprozess kann mit Hilfe des System Explorers eine parallele Entwicklung von Software und Hardware erfolgen. Der Prototyp kann benutzt
4
Probes sind Leitungen innerhalb der FPGA, die nach außen gef¨
uhrt werden, um die
Signalwerte auf den Leitungen abgreifen zu k¨onnen.
26
2 STAND DER TECHNIK
werden, um das System-on-Chip in seiner realen Systemumgebung zu emulieren. Es kann begonnen werden, Schnittstellen zu erproben und andere digitale
oder analoge Subsysteme, w¨ahrend die SoC-Entwicklung noch voranschreitet.
Das fr¨
uhe Vorhandensein eines Prototypen erlaubt es, dem Kunden schon
fr¨
uh im Entwurfsprozess eine Demonstration zu bieten und seine Resonanz
in die weitere Entwicklung mit einfließen zu lassen.
Der System Explorer wird in zwei Ausf¨
uhrungen hergestellt. Die Bezeichnungen sind MP3CF und MP4CF. Tabelle 2.2 stellt die technischen Daten der
beiden Systeme gegen¨
uber. Weiterf¨
uhrende Informationen zum Aptix System Explorer sind auf der Homepage des Unternehmens [Apt] sowie in der
Brosch¨
ure zum System Explorer [Apt00] enthalten.
2.4
Fazit
Die vorangehenden Punkte besch¨aftigten sich mit SystemC als neue Entwurfssprache, mit dem Nutzen von Intellectual Properties und der Bedeutung
der Simulation im Hardwareentwurf. Dazu wurden einige Simulationswerkzeuge und -methoden vorgestellt.
SystemC bringt die Voraussetzungen mit, um den Entwurfsprozess von Hardwaresystemen und Hardware/Software-Systemen weiter zu beschleunigen.
Ein Nachteil ist noch die mangelnde Unterst¨
utzung von sprachfremden IPs
u
¨ber der Register-Transfer-Ebene.
Intellectual Properties bilden zuk¨
unftig ein Schl¨
usselkonzept bei der Entwicklung von SoC-Designs. Durch ihren Einsatz k¨onnen die Entwicklungszeit
und -kosten weiter gesenkt werden. Es existieren bereits L¨osungen zum einfachen Handel mit IPs. Jedoch behindern teilweise rechtliche Unklarheiten im
Moment noch den IP-Handel. Aber in absehbarer Zukunft wird sich dieses
Konzept durchsetzen.
Die Simulation ist ein wichtiges Werkzeug im Entwicklungsprozess. Es existieren verscheidene Simulationswerkzeuge, die verschiedene Ans¨atze verfolgen.
Ein Ansatz besteht in einer reinen Simulationssoftware wie Modelsim und
SystemC. Ans¨atze zur Cosimulation verfolgen das Ziel, verschiedene Simulatoren miteinander zu koppeln, um die Simulation von Hardware und Software
parallel ausf¨
uhren zu k¨onnen. Hardware-Akzeleratoren sollen durch Spezialhardware die Simulation großer Designs beschleunigen. Doch sie bieten auch
2 STAND DER TECHNIK
27
die M¨oglichkeit der Kopplung mit Softwaresimulationsl¨osungen. Die vorgestellten Hardware-Akzeleratoren erlauben teilweise die Nutzung von SystemC. Die Unterst¨
utzung beginnt jedoch erst auf Register-Transfer-Ebene.
In h¨oheren Abstraktionsebenen fehlt diese Unterst¨
utzung noch.
28
2 STAND DER TECHNIK
3 DIE METHODE DER ADAPTIERUNG
3
29
Die Methode der Adaptierung
Diese Kapitel beschreibt die Adaptierung eines Hardware-Akzelerators an die
SystemC-Verhaltenssimulation. Der erste Teil beinhaltet die Herleitung des
Hardware/Software-Interfaces5 und die Analyse seiner Anforderungen. Eine
Realisierung des HW/SW-Interfaces durch einen Interfaceblock wird im zweiten Abschnitt vorgestellt. Anschließend werden Details zur technischen Umsetzung dargestellt. Die Einsatzm¨oglichkeiten des HW/SW-Interfaces zeigt
der letzte Abschnitt dieses Kapitels auf.
3.1
Das Hardware/Software-Interface
Das Ziel dieser Arbeit ist es, ein Verfahren zu entwicklen, welches die Simulation von VHDL-IPs in SystemC, auf einer h¨oheren Abstraktionsebene als der
RT-Ebene, erlaubt. Bisher ist die Einbindung dieser IPs f¨
ur den Entwurf und
somit auch f¨
ur die Simulation erst auf Netzlistenebene m¨oglich. In fr¨
uheren
Entwurfsstadien ist eine Simulation des Gesamtsystems mit diesen IPs jedoch schon sehr hilfreich, um Tests mit dem Systemverhalten durchf¨
uhren
zu k¨onnen und fr¨
uhzeitig Fehler zu entdecken.
Zur Simulation einer VHDL-IP mit SystemC existieren zwei grunds¨atzliche M¨oglichkeiten. Die erste M¨oglichkeit ist die Konvertierung der IP in ein
SystemC-Modul (Abbildung 3.1). Die Konvertierung muss dabei von Hand
erfolgen. Dieser Schritt verursacht zus¨atzliche Arbeit. Das erstellte SystemCModul muss gegen die VHDL-IP verifiziert werden, um sicherzustellen, dass
ihr Verhalten u
¨bereinstimmt. Dieser Prozess bindet Ressourcen und kostet
meist viel Zeit und Geld.
Einen Ansatz aus der Cosimulation vorfolgt die zweite Variante. Dabei findet die Simulation der VHDL-IP in einem VHDL-Simulator und die des
SystemC-Modells in einem SystemC-Simulator statt. Die Kopplung der beiden Simulatoren realisiert eine Software/Software-Schnittstelle (Abbildung
3.2). Anforderungen, die die SW/SW-Schnittstelle erf¨
ullen muss, sind der
5
F¨
ur Interface wird in den folgenden Abschnitten der deutsche Begriff Schnittstelle
verwendet
30
3 DIE METHODE DER ADAPTIERUNG
VHDL-IP
SystemC
Modell der IP
Korrektur
Konvertierung
Verifikation
Test
SystemC
Modell der IP
M1
Übereinstimmung
M2
SystemC-Simulation
Gesamtsimulation
Abbildung 3.1: Adaptierung durch Konvertierung
Austausch von Simulationsdaten und Kontrollsignalen sowie die Synchronisation zwischen den Simulatoren, damit zum richtigen Zeitpunkt die korrekten
Simulationsdaten vorhanden sind.
Allerdings kostet die Ausf¨
uhrung von zwei Simulatoren auf einem Rechner
viel Rechenleistung. Die Folge ist eine geringere Simulationsgeschwindigkeit. Da kontinuierlich Daten zwischen den Simulatoren ausgetauscht werden m¨
ussen, spielt nicht nur die Ausf¨
uhrungszeit der beiden Simulatoren
eine große Rolle sondern auch die Zeit, die die Kommunikation zwischen diesen beansprucht.
Der Vorteil dieser Variante liegt darin, dass die IP nicht von Hand konver-
SW/SW
Interface
M1
VHDL-IP
M2
VHDL-Simulation
SystemC-Simulation
Gesamtsimulation
Abbildung 3.2: Adaptierung eines Simulators
3 DIE METHODE DER ADAPTIERUNG
IO
...
IO
IO
IO
SM
IO
SM
...
CLB
...
SM
CLB
IO
2
...
IO
IO
allgemeine Leitungen
IO
lange Leitungen
CLB konfigurierbarer Logikblock
IO
IO
IO
kurze Leitungen
SM
CLB
IO
IO
CLB
...
IO
hierarchisches Verbindungssystem
IO
...
IO
IO
...
IO
31
1
...
IO
IO
IO
SM Switchmatrix
IO
IO
IO
programmierbare IO-Blöcke
1
Bondinselring
2
Zellenfeld
Abbildung 3.3: Schematischer Aufbau eines SRAM-basierten FPGA
tiert werden muss. Dieses Kriterium ist wichtig, weil dadurch die Zeit f¨
ur
Tests und Verifizierung eingespart wird. Um die Simulation zu beschleunigen, wird, zus¨atzlich zum Cosimulationsansatz, der Ansatz von HardwareAkzeleratoren eingebracht. Das heißt, dass die IP in Hardware emuliert wird,
was eine schnellere Ausf¨
uhrung der IP erlaubt, und mit dem SystemC-Simulator
gekoppelt wird.
Der Einsatz von kommerziellen Hardware-Akzeleratorsystemen ist durch ihre
hohen Kosten hier nicht praktikabel. Eine L¨osung f¨
ur dieses Problem w¨are eine g¨
unstigere handels¨
ubliche Hardware, die schnell konfiguriert werden kann.
Mit dieser Hardware sollte der Anwender auch in der Lage sein, gr¨oßere Schaltungen schnell zu realisieren.
Diese Voraussetzungen erf¨
ullen SRAM-basierte Field Programable Gate Arrays (FPGA). FPGAs sind programmierbare Hardwarebausteine und geh¨oren
zur Gruppe der anwenderprogrammierbaren Schaltungen. Den grunds¨atzlichen Aufbau von FPGAs stellt Abbildung 3.3 dar. Sie bestehen im wesentlichen aus konfigurierbaren Logikbl¨ocken, konfigurierbaren IO-Bl¨ocken
und einer konfigurierbaren hierarchischen Verbindungstruktur. Mit Hilfe von
FPGAs k¨onnen kombinatorische und sequentielle digitale Schaltungen realisiert werden. Mehr Informationen zu FPGAs bieten [Wan98] und die Homepages von FPGA-Herstellern [Alt, Atm, Lat, Xilc].
Um jedoch die FPGA nutzen zu k¨onnen, ist die Synthesef¨ahigkeit der IP
32
3 DIE METHODE DER ADAPTIERUNG
HW/SW
Interface
M1
VHDL-IP
M2
IP-Emulation
auf FPGA (HW)
SystemC - Simulation
auf PC (SW)
Gesamtsimulation
Abbildung 3.4: Allgemeines Hardware/Software-Interface
M1
M2
VHDL-IP
SW-IF
SystemC - Simulation
auf PC (SW)
HW/SW
HW-IF
Interface
IP-Emulation
auf FPGA (HW)
Gesamtsimulation
Abbildung 3.5: Genaueres Modell des Hardware/Software-Interface
unabdingbar. Durch diese Einschr¨ankung entf¨allt die Verwendung von HardIPs (vgl. Abschnitt 2.2). Sie sind bereits synthetisiert und mit Layout und
Timing versehen. Soft-IPs dagegen sind synthetisierbar.
Durch die Nutzung der FPGA muss im Folgenden auf der Hardwareseite von
Emulation statt von Simulation gesprochen werden. Emulation ist das funktionelle Nachbilden eines Systems durch ein anderes. Die Implementierung
der IP ist nun kein Modell mehr, wie f¨
ur eine Simulation, sondern ist eine
Nachbildung der realen digitalen Schaltung mit Hilfe eines FPGAs.
Eine Hardware/Software-Schnittstelle tritt nun an die Stelle der Software/Software-Schnittstelle (Abbildung 3.4), um die SystemC-Simulation
mit der IP-Emulation zu koppeln. Doch wie soll die Kopplung erfolgen und
welche Anforderungen werden damit an die Hardware/Software-Schnittstelle
gestellt?
Die Kopplung der SystemC-Simulation erfolgt u
¨ber eine SW/SW-Schnittstelle.
Auf der Hardwareseite befindet sich eine HW/HW-Schnittstelle, um die Ver-
3 DIE METHODE DER ADAPTIERUNG
33
bindung mit der IP herzustellen. Abbildung 3.5 stellt diese genauere Betrachtung der HW/SW-Schnittstelle dar. Dies erm¨oglicht es, die eigentliche Grenze
zwischen Hardware und Software f¨
ur die SystemC-Simulation sowie f¨
ur die
IP-Emulation unsichtbar zu machen. Welchen Anforderungen die HW/SWSchnittstelle gen¨
ugen muss, um diese Art der Verbindung herzustellen, wird
im folgenden Abschnitt analysiert.
3.1.1
Anforderungsanalyse fu
¨ r das HW/SWInterface
Die Anforderungen an die HW/SW-Schnittstelle sind zun¨achst die gleichen
wie bei einer SW/SW-Schnittstelle:
• Austausch von Simulationsdaten und Kontrollsignalen erm¨oglichen
• Synchronisation zwischen Simulation und Emulation gestatten
• Nutzung der IP ohne diese zu ver¨andern
Zun¨achst soll die Anforderung des Datenaustausch n¨aher betrachtet werden.
Er geschiet u
¨ber zwei Schnittstellen. Zum Einen u
¨ber die Schnittstelle von IP
und HW/SW-Schnittstelle. Diese HW/HW-Schnittstelle h¨angt allein von der
¨
IP ab. Da keine Anderungen
an der IP vorgenommen werden sollen, bilden
die Ein- und Ausgangssignale der IP die einzige Kommunikationsm¨oglichkeit.
Das hat zur Folge, dass die HW/HW-Schnittstelle genau durch die Eing¨ange
und Ausg¨ange der IP realisiert wird.
Die andere Schnittstelle befindet sich auf der Softwareseite. Dort muss die
SystemC-Simulation mit der HW/SW-Schnittstelle verbunden werden. Prinzipiell ist es bei dieser SW/SW-Schnittstelle m¨oglich, sie um Kontrollsignale
zu erweitern. Das Minimum bilden aber auch hier die Ein- und Ausg¨ange
der IP, da sonst Simulationsdaten verloren gehen w¨
urden. Der Nachteil bei
einer Einf¨
uhrung zus¨atzlicher Signale liegt darin, dass der Simulationskern
ver¨andert werden m¨
usste, um die Signale zu erzeugen. Eine bessere Variante, die den Simulationskern unbeeinflusst l¨asst, besteht darin, das HW/SWInterface f¨
ur den Simulationskern unsichtbar zu halten und nur die Ein- und
Ausg¨ange der IP f¨
ur die Simulation bereitzustellen. Daraus ergibt sich eine
weitere Anforderung an die HW/SW-Schnittstelle. Sie muss intern Kontrollsignale erzeugen und auswerten k¨onnen, um den Transport der Simulationsdaten sicherzustellen.
34
3 DIE METHODE DER ADAPTIERUNG
Ein weiteres Problem, welches sich aus dem Datentransport durch die HW/SW¨
Schnittstelle ergibt, ist die Uberwindung
der Grenze zwischen Hardware und
Software. Dies kann durch Standardschnittstellen am PC erfolgen. Dabei
ist es notwendig, dass diese Schnittstelle die Kommunikation vom PC zur
FPGA und umgekehrt beherrscht, da die Simulationsdaten in beide Richtungen ausgetauscht werden m¨
ussen. Standardschnittstellen besitzen feste
Parameter hinsichtlich der Daten, die sie in einem Kommunikationszyklus
u
¨bermitteln k¨onnen. Da unterschiedliche IPs unterschiedliche Schnittstellenbreiten besitzen, kann keine Aussage getroffen werden, ob die gesamten Simulationsdaten in einem Kommunikationszyklus u
¨bertragbar sind. Deshalb
sollte die HW/SW-Schnittstelle in der Lage sein, die Simulationsdaten intern
zu serialisieren, sie vollst¨andig und ohne Verlust u
¨ber die HW/SW-Grenze
zu transportieren und auf der anderen Seite wieder richtig zu parallelisieren.
Das heißt, innerhalb der HW/SW-Schnittstelle muss eine Datentransformation gestattet sein.
Nachdem die Anforderungen an den Datenaustausch herausgearbeitet sind,
stellt sich nun das Problem der Synchronisation zwischen der SystemCSimulation und der IP-Emulation. Die SystemC-Simulation ist zyklusbasiert (vgl. Abschnitt 2.3.1). Hier dient das Taktsignal als Ausl¨osesignal f¨
ur
die Neuberechnung der Signale des im Test befindlichen Designs. Da keine
¨
Anderungen
am Simulationskern vorgenommen werden sollen, findet dieses
Ausl¨osesignal auch bei der Emulation Verwendung. Das heißt, dass die IP
u
¨ber das Taktsignal der SystemC-Simulation gesteuert wird. Eine MasterSlave-Simulation ist die Folge, bei der die SystemC-Simulation den Master darstellt, da sie das steuernde Signal generiert. Die Emulation dagegen
nimmt, durch die Reaktion auf das Mastersignal, die Rolle des Slave an.
Jedoch wirft die Synchronisation u
¨ber das Taktsignal wiederum ein Problem
auf. Es besteht darin, dass das Taktsignal durch die HW/SW-Schnittstelle
und u
¨ber die darin enthaltene HW/SW-Grenze transportiert werden muss.
Es muss garantiert werden, dass alle Eingangssignale korrekt anliegen, bevor
¨
das Taktsignal angelegt wird. Durch eine reine Ubertragung
des Taktsignals
ist dies nur schwer m¨oglich.
Eine L¨osung besteht darin, das Taktsignal auf der Softwareseite zu analysie¨
ren. Bei der aktiven Taktflanke wird dann zuerst die Ubertragung
der Simulationsdaten ausgef¨
uhrt, dann ein Kontrollsignal zur Takterzeugung auf der
Hardwareseite generiert. Die HW/SW-Schnittstelle generiert f¨
ur die Emulation nun genau einen Takt und gibt eine R¨
uckmeldung an den Softwareteil
nach dessen Beendigung. Am Ende werden die Ausgangsdaten der Emulation zur Simulation u
¨bertragen, welche weiter fortschreiten kann. Abbildung
3 DIE METHODE DER ADAPTIERUNG
35
Initialisierung der Simulation
Generierung der Simulationsdaten des aktuellen
Simulationsschrittes (incl. Taktsignal)
Anlegen der Simulationsdaten an das HW/SW-IF
nein
Simulation
fertig?
ja
Analyse des Taktsignals
Ende
nein
aktive
Taktflanke?
ja
Anlegen der Simulationsdaten an die IP-Emulation
Erzeugen des Taktsignals für die IP
Emulation schreitet einen Takt voran
fertig?
nein
ja
Lesen der Ausgabewerte der IP
Rückgabe der Simulationsdaten der IP an den
System-C-Simulator
Abbildung 3.6: Ablauf der Synchronisation durch das HW/SW-Interface
3.6 stellt diese Art der Synchronisation im Rahmen der Simulation dar. Zur
Umsetzung dieser L¨osung ben¨otigt die HW/SW-Schnittstelle einen Mechanismus, der es erlaubt, Eingangssignale zu analysieren und interne Kontrollsignale sowie Ausgangssignale zu generieren. Es muss also m¨oglich sein, in
der HW/SW-Schnittstelle eine Steuerung zu integrieren.
Die letze Anforderung stellt die Nutzung der IP dar, ohne sie zu ver¨andern.
Diese Anforderung wurde durch die vorangegangen Maßnahmen erf¨
ullt. Eine
¨
Anderung
der Schnittstelle oder der Funktionalit¨at der IP fand nicht statt.
Zusammenfassend sollen hier noch einmal die Anforderungen an die HW/SWSchnittstelle dargestellt werden. Die folgenden Anforderungen ergab die durchgef¨
uhrte Analyse. Die HW/SW-Schnittstelle muss
36
3 DIE METHODE DER ADAPTIERUNG
1. zwei Komponenten kommunizieren lassen, ohne dass an den Kompo¨
nenten Anderungen
durchgef¨
uhrt werden m¨
ussen.
2. den bidirektionalen Datentransport zwischen den Komponenten sicherstellen.
3. die HW/SW-Grenze intern u
¨berwinden.
4. die M¨oglichkeit bieten, Daten intern zu transformieren.
5. die Integration einer Steuerung erlauben.
3.2
Der Interfaceblock als HW/SWInterface
Zur Realisierung der HW/SW-Schnittstelle ben¨otigt man ein Schnittstellenkonstrukt, dass die im vorangegangen Abschnitt herausgestellten Anforderungen im Wesentlichen erf¨
ullt. Falls das Konstrukt nicht allen Anforderungen gen¨
ugt, sollte es so flexibel und erweiterbar sein, dass es sich auf die
neuen Bedingungen leicht anpassen l¨asst. Ein Schnittstellenkonstrukt, dass
einen Großteil der gestellten Anforderungen erf¨
ullen kann, ist der Interfaceblock, der im folgenden Abschnitt kurz vorgestellt wird.
3.2.1
Das Modell des Interfaceblocks
Ein Interfaceblock (IFB) dient als Schnittstelle zwischen inkompatiblen Kommunikationskomponenten. Diese Kommunikationskomponenten k¨onnen komplexe Strukturen (z.B. Bussysteme) oder funktionale Komponenten (z.B.
Algorithmen) sein. Diese werden in der IFB-Terminologie entsprechend als
Medium beziehungsweise Task bezeichnet. In einem Interfaceblock k¨onnen
Daten zwischen Sender und Empf¨anger transformiert werden. Dadurch ist
ein Einsatz als Adapter zwischen physisch inkompatiblen bzw. semantisch
inkompatiblen Kommunikationskomponenten m¨oglich.
Der Interfaceblock ist modular aufgebaut. Er besteht, wie Bild 3.7 zeigt, aus
einer Controlunit (CU), zwei Protokollhandlern (PH) und einem Sequenzhandler (SH). Jeder der Handler besitzt zus¨atzlich mindestens einen Modus,
der die eigentliche Funktionalit¨at implementiert.
3 DIE METHODE DER ADAPTIERUNG
37
CU
FSM
T
A
S
status
PHIN
FSM
data
handshake
SH
FSM
K
P1
P2
S1
T
controls
S2
status
S3
PH OUT
FSM
A
S
K
P1
P2
Abbildung 3.7: Makrostruktur des Interfaceblock
Die Controlunit u
¨bernimmt die Steuerungsaufgaben innerhalb des Interfaceblocks. Sie koordiniert und kontrolliert die Funktion der Protokollhandler
und des Sequenzhandlers. Außerdem bestimmt sie den jeweils aktiven Modus
eines Handlers. Sie steuert die Handler u
¨ber Kontrollsignale und erh¨alt deren
aktuellen Zustand durch Statussignale.
Die Protokollhandler sind die externen Schnittstellen des Interfaceblocks. Die
eigentliche Kommunikation mit den verbundenen Tasks und Medien erfolgt
hier. Basierend auf seinen Modi verarbeitet der Protokollhandler die Protokolle der angeschlossenen Kommunikationskomponenten. Die Kommunikation beinhaltet sowohl das Senden als auch das Empfangen von Daten.
Das Bindeglied zwischen den Protokollhandlern stellt der Sequenzhandler
dar. In ihm werden die eingehenden Nutzdaten konform zum ausgehenden
Protokoll transformiert. Die Transformation folgt einer Abbildungsvorschrift,
die die Sequenzhandlermodi implementieren. Die Transformation ist nicht
¨
nur auf strukturelle Anderungen
der Daten beschr¨ankt, sondern erm¨oglicht
¨
auch eine semantische Anderung.
Weitere Informationen zur Grundidee des Interfaceblocks, zur Beschreibungsform eines Interfaceblocks durch das Interface Synthese (IFS) Format, zur
technischen Umsetzung und zum Stand der aktuellen Entwicklungen sind in
[Ihm01], [HVI01], [IVH02a], [IVH02b], [IBJK+ 03], [IVH03], [Fic03], [Fla03]
und [IH04] enthalten.
38
3.2.2
3 DIE METHODE DER ADAPTIERUNG
Analyse der Leistung des Interfaceblocks
Um den Interfaceblock als HW/SW-Schnittstelle einsetzen zu k¨onnen, ist
zun¨achst der Nachweis erforderlich, dass der Interfaceblock auch die gestellten Anforderungen (vgl. Abschnitt 3.1.1) theoretisch erf¨
ullen kann.
Die erste Anforderung bestand darin, zwei Komponenten kommunizieren zu
¨
lassen, ohne an den Komponenten Anderungen
durchzuf¨
uhren. Der Interfaceblock erf¨
ullt die Funktion eines Adapters. Ein Adapter ist nach [Wika]
ein Ger¨at, dass zur Verbindung verschiedener mechanischer oder elektrischer
Ger¨ate dient, deren Anschl¨
usse wegen unterschiedlicher Formate oder Normen nicht zueinander passen. In dem vorliegenden Fall sind die zu verbindenden Ger¨ate“ die SystemC-Simulation und die IP-Emulation. Die Anschl¨
usse
”
stellen die Schnittstellen dar, die in Software bzw. in Hardware vorliegen.
Dadurch ist eine direkte Verbindung nicht m¨oglich. Zur Verbindung wird die
Eigenschaft des IFBs als Adapter genutzt. Somit ist die Verbindung jedenfalls
theoretisch m¨oglich.
Die n¨achste Anforderung umfasst den bidirektionalen Datentransport zwischen den Komponenten. Der IFB dient nach dem Modell als Schnittstelle
zwischen Kommunikationskomponenten. Eine Schnittstelle (Interface) ist ein
Teil eines Systems, das dem Austausch von Informationen, Energie oder Materie mit anderen Systemen dient [Wikb]. Nach der Definition beherrscht eine
Schnittstelle den Austausch von Informationen, die im vorliegenden Fall die
Simulationsdaten sind. Da der IFB eine Schnittstelle ist und Daten senden
und empfangen kann, erf¨
ullt er auch diese gestellte Anforderung.
Die Integration einer Steuerung in den IFB erfolgt durch die Controlunit. Sie
erf¨
ullt innerhalb des IFBs Steuerungs- und Kontrollaufgaben. Sie kontrolliert
die Handler, indem sie Steuerungssignale an diese u
¨bermittelt und Statussignale der Handler auswertet. Somit ist sie der zentrale Punkt im IFB, von
dem aus eine Steuerung arbeiten kann.
Weiterhin soll die HW/SW-Schnittstelle eine interne Datentransformation
zulassen. Das kann in den Modi der Handler geschehen. Sie implementieren
die Funktionalit¨at zur Daten¨
ubertragung. Die Modi k¨onnen also auch mit
Algorithmen versehen sein, die Daten transformieren.
Die transformierten Daten m¨
ussen nun noch durch den IFB transportiert
werden k¨onnen. Innerhalb des IFBs findet Kommunikation zwischen der Controlunit und Protokollhandlern bzw. Sequenzhandler statt. Außerdem kommunizieren die Protokollhandler mit dem Sequenzhandler, um den Datentransport durch den IFB zu realisieren. Kommunikation, also der Austausch
3 DIE METHODE DER ADAPTIERUNG
39
von Daten, l¨auft nach einem Protokoll ab, damit der Sender und Empf¨anger
sich gegenseitig verstehen. Da das Modell des IFBs das interne Kommunikationsprotokoll nicht festlegt, ist die Verwendung eines Protokolls m¨oglich,
das den Transport der transformierten Daten erm¨oglicht.
¨
Zur Uberwindung
der HW/SW-Grenze innerhalb des IFB soll die freie Auswahl eines Protokolls dienen. Ein Protokoll wird u
¨ber eine Schnittstelle u
¨bertragen. Die Benutzung einer Schnittstelle, die Hardware und Software physisch verbindet, bringt die L¨osung dieses Problems. Der IFB ist aber bisher
nur f¨
ur reine Hardwareanwendungen konzipiert. Aus diesem Grund muss gepr¨
uft werden, ob sich das Modell dahingehend erweitern l¨asst, dass es die
Einbindung einer physischen HW/SW-Schnittstelle gestattet.
3.2.3
Erweiterung des Interfaceblocks
Zur Feststellung der Erweiterbarkeit des IFBs wird der IFB schrittweise zwischen der SystemC-Simulation und der IP-Emulation aufgebaut. Die Ausgangssituation stellt die Verbindung eines Softwaretasks (SystemC-Simulation) mit einem Hardwaretask (IP-Emulation) dar. Die Verbindung soll mit
Hilfe eines Interfaceblocks erfolgen. Abbildung 3.8 veranschaulicht die Ausgangssituation.
Zun¨achst richtet sich die Betrachtung auf den Hardwaretask, da dem Interfaceblock eine Hardwareanwendung zugrunde liegt. Die Verbindung zwischen
dem Interfacebock und der Intellectual Property wird durch einen Protokollhandler bewerkstelligt (Abbildung 3.9). Er wird im Folgenden als PHHW-out
bezeichnet, da er den hardwareseitigen Ausgang des Interfaceblock bildet.
CU
FSM
status
SystemC
Simulation
PHIN
FSM
data
handshake
controls
SH
FSM
PHOUT
FSM
SW
IP
Emulation
HW
P1
P2
S1
S2
S3
P1
P2
Abbildung 3.8: Verbindung eines SW-Task und eines HW-Task durch einen
Interfaceblock
40
3 DIE METHODE DER ADAPTIERUNG
CU
FSM
Control
status
SystemC
Simulation
PHIN
FSM
controls
SH
FSM
PHHW-out
SW
IP
Emulation
HW
P1
Abbildung 3.9: Die
ProtokollhandlerHW-out
P2
S1
S2
S3
Hardwareschnittstelle
Memory
des
Interfaceblocks,
der
Die Funktion, die die Schnittstelle PHHW-out ↔ IP-Emulation erf¨
ullen muss,
ist das Anlegen der Triggerdaten an die IP und das kontrollierte Abgreifen
der Tracedaten von der IP w¨ahrend eines Emulationszyklus. Zur Sicherstellung der Datenkonsistenz, also dass die Daten nur aus dem gerade ablaufenden Emulationszyklus stammen, muss dieser Vorgang u
¨ber Kontrollsignale
gesteuert werden. Die Daten, die u
¨ber die Schnittstelle transportiert werden, m¨
ussen bis zu ihrer Verarbeitung verf¨
ugbar sein. Aus diesem Grund
erfolgt eine Zwischenspeicherung der Daten im IFB. Die Speicherung findet
im Modus des PHHW-out statt, da die Modi der Handler diese Funktionalit¨at
bereitstellen k¨onnen.
Die Verbindung von SystemC-Simulation und Interfaceblock realisiert wiederum ein Protokollhandler. Dieser Protkollhandler hat die Aufgabe, die
Kommunikation mit der SystemC-Simulation auf Softwareseite sicherzustellen. Im Folgenden wird er als PHSW bezeichnet (Abbildung 3.10). Neu im
IFB-Modell ist, dass der Protokollhandler eine SW-Schnittstelle darstellt.
An der Aufgabe der Schnittstelle ¨andert sich nichts. Die Funktionalit¨at wird
in Software jedoch durch Funktionen bestimmt, die Algorithmen implementieren und nicht durch kombinatorische Logik und endliche Automaten. Die
Daten¨
ubergabe findet bei Funktionen u
¨ber Parameter und nicht durch das
Anlegen eines elektrischen Pegels statt. Das stellt aber kein Hinderniss dar.
Eine Funktion kann ebenso Parameter auswerten und auch R¨
uckgabewerte
erzeugen. Außerdem erlaubt Software die Implementierung von umfangreichen Funktionen. Es spricht also nichts dagegen, dem Interfaceblock eine
SW-Schnittstelle in Form eines Softwareprotokollhandlers zu geben. Die Modi liegen ebenfalls in Software und sind durch Funktionen implementiert, die
vom PHSW aufgerufen werden.
3 DIE METHODE DER ADAPTIERUNG
41
CU
FSM
Control
Control
SystemC
Simulation
status
controls
SH
FSM
PHSW
PHHW-out
SW
HW
SW
Function
SW
Function
Abbildung 3.10: Die
ProtokollhandlerSW
S1
S2
S3
Softwareschnittstelle
CU
FSM
PHSW
Memory
des
Interafceblocks,
der
Control
Control
Control
SystemC
Simulation
IP
Emulation
status
physical
HW/SW-IF
controls
SHHW
PHHW-out
SW
IP
Emulation
HW
SW
Function
SW
Function
Datatransformation
Memory
Abbildung 3.11: Die physische HW/SW-Schnittstelle im Interfaceblock
Nun stellt sich die Frage, an welche Stelle die physische HW/SW-Schnittstelle
platziert wird. Es gibt dabei die M¨oglichkeiten, sie zwischen PHSW und SH
oder SH und PHHW-out anzusiedeln. Um einen Großteil des IFB-Modells beizubehalten, wird die physische HW/SW-Schnittstelle als Schnittstelle von
PHSW und SH genutzt (Abbildung 3.11). Da der Sequenzhandler in Hardware liegt, wird er weiterhin als SHHW bezeichnet. In Abschnitt 3.1.1 wurde bereits festgestellt, dass wahrscheinlich eine Transformation der Daten, die u
¨ber
die physische HW/SW-Schnittstelle transportiert werden, notwendig ist. Die
Aufgabe des Sequenzhandlermodus besteht nun darin, die empfangenen und
die zu sendenden Daten vom bzw. zum PHSW in ein protokollkonformes Format umzuwandeln.
Zur Kontrolle der Abl¨aufe innerhalb des IFB kommt die Controlunit zum
Einsatz. Sie hat die Aufgabe, die Handler zu steuern und zu u
¨berwachen.
Bei der Verwendung des IFBs als HW/SW-Schnittstelle, muss der PHHW-out ,
42
3 DIE METHODE DER ADAPTIERUNG
CU
FSM
status
SystemC
Simulation
PHSW
physical
HW/SW-IF
control
SHHW
PHHW-out
SW
IP
Emulation
HW
SW
Function
Datatransformation
SW
Function
Memory
Abbildung 3.12: Controlunit zur Steuerung von Hardware und Software
CU-Kommunikation
?
CUSW
SystemC
Simulation
PHSW
CU HW
status
physical
HW/SW-IF
control
SHHW
PHHW-out
SW
IP
Emulation
HW
SW
Function
SW
Function
Datatransformation
Memory
Abbildung 3.13: Teilung der Controlunit in Hardware- und Softwareteil
der SHHW aber auch der PHSW von der Controlunit gesteuert werden. Das
erfordert, dass die Controlunit Software als auch Hardware ansteuern kann
(Abbildung 3.12).
Die physische Trennung von Hardware- und Softwareseite des IFBs, gestaltet
die Steuerung durch eine einzige Controlunit schwierig. Aus diesem Grund
erfolgt eine Teilung der Controlunit in einen Softwareteil (CUSW ) und einen
Hardwareteil (CUHW ), wie Abbildung 3.13 zeigt. Der Vorteil liegt nun darin, dass die jeweilige Controlunit ihren Teil direkt kontrollieren kann, ohne Steuersignale u
¨ber die HW/SW-Grenze zu schicken und damit gr¨oßere
Verz¨ogerungszeiten im Kontrollfluss zu verursachen.
Ein Problem, welches durch die Teilung auftritt, ist die Kommunikation zwischen den Controlunits. Zur geregelten Steuerung des IFBs und zur Synchronisation zwischen Hardware- und Softwareteil ist eine Kommunikation
3 DIE METHODE DER ADAPTIERUNG
CU HW
CUSW
status
SystemC
Simulation
PHSW
43
physical
HW/SW-IF
control
PHHW-in
SHHW
Controlseperation
Datatransformation
PHHW-out
SW
IP
Emulation
HW
SW
Function
SW
Function
Memory
Abbildung 3.14: Controlunit in Software und Hardwareteil geteilt
zwischen CUSW und CUHW notwendig. Als Hinderniss ist dabei die HW/SWGrenze zu u
¨berwinden. Dies kann auf zwei Arten erfolgen. Zum Einen u
¨ber
eine zweite physische HW/SW-Schnittstelle, die allein f¨
ur den Transport
und Austausch von Kontroll- und Statussignalen zwischen den Controlunits zust¨andig ist. Die L¨osung bedeutet einen h¨ohere Aufwand, in Bezug auf
die Bereitstellung von Hardware. Außerdem muss eine zweite Schnittstelle in
Software als auch in Hardware implementiert werden.
Die zweite M¨oglichkeit besteht darin, die Kommunikation u
¨ber die physische HW/SW-Schnittstelle zu bew¨altigen, u
¨ber die auch die Simulationsdaten ausgetauscht werden. Der Vorteil dieser Variante ist die Nutzung der
vorhandenen physischen Schnittstelle ohne zus¨atzlichen Hardwareaufwand.
Allerdings ben¨otigt man jetzt ein zus¨atzliches Protokoll, dass u
¨ber dem Protokoll der HW/SW-Schnittstelle angesiedelt ist, um eine Unterscheidung zwischen Simulationsdaten und Controlunitdaten zu erm¨oglichen. Dies bringt die
Einf¨
uhrung eines weiteren Protokollhandlers auf der Hardwareseite des IFBs
mit sich (Abbildung 3.14). Er wird im Folgenden als PHHW-in bezeichnet.
Diese Maßnahme ist notwendig, da der Sequenzhandler laut Definition nur
¨
f¨
ur die Anderung
von Daten zust¨andig ist. Die Verarbeitung von Protokollen
ist dem Protokollhandler vorbehalten.
Die CU-Kommunikation k¨onnte also wie folgt ablaufen. Die CUSW will ein
Kontrollsignal an die CUHW schicken. Dazu leitet sie das Signal an den PHSW
weiter, welcher es in das Protokoll zur Datenunterscheidung umwandelt und
es mittels des normalen HW/SW-Protokoll an den Hardwareteil des IFBs
sendet. Die Stelle im Hardwareteil, an dem die Daten empfangen werden, ist
der PHHW-in . Er pr¨
uft, ob die empfangenen Daten f¨
ur die Simulation oder
f¨
ur die Controlunit bestimmt sind. Die Kontrollsignale werden an die CUHW
weitergeleitet. Sie kann die Signale auswerten und eine Antwort an die CUSW
44
3 DIE METHODE DER ADAPTIERUNG
u
ucksenden.
¨ber den gleichen Weg zur¨
Als Ergebnis liegt jetzt ein erweiterter Interfaceblock vor. Das heißt, dass das
Modell des Interfaceblocks dahingehend erweiterbar ist, um damit auch eine
HW/SW-Schnittstelle zu realisieren. Das Modell des Interfaceblocks ist also
nicht auf reine Hardwareanwendungen begrenzt. Um dieses Ergebnis weiter
zu untermauern, folgt den bisher theoretischen Betrachtungen, eine m¨ogliche
technischen Umsetzung dieses Modells am Beispiel des Simulationsinterfaceblocks.
3.3
Technische Umsetzung der Adaptierung durch einen Simulationsinterfaceblock
Dieser Abschnitt stellt eine M¨oglichkeit der technischen Umsetzung eines
erweiterten Interfaceblocks dar. Da die Erweiterung speziell f¨
ur die Kopplung von SystemC-Simulation und IP-Emulation zugeschnitten ist, wird der
erweiterte Interfaceblock im weiteren Verlauf dieser Arbeit als Simulationsinterfaceblock (SimIFB) bezeichnet.
3.3.1
Die hardwareseitige Implementierungsplattform
Als Implementierungsplattform f¨
ur den Hardwareteil und die Emulation der
Intellectual Property kommt das Digilent 2E Development Board (Abbildung
3.15) zum Einsatz. Es ist eine Entwicklungsplatine, die mit einem Xilinx
Spartan2E FPGA-Chip versehen ist. Die genaue Bezeichnung des FPGAChips lautet XC2S200E-PQ208. Mit dem FPGA k¨onnen bis zu 200 000 Gatter¨aquivalente nachgebildet werden. Die Entwicklungsplatine verf¨
ugt außerdem u
¨ber mehrere Extensionheader sowie u
¨ber eine serielle, eine parallele
und eine JTAG-Schnittstelle.
Mehr Informationen zur Entwicklungsplatine bietet das dazugeh¨orige Handbuch [Dig02]. Erl¨auterungen zum Xilinx Spartan 2E FPGA enth¨alt das Datenblatt [Xil03].
3 DIE METHODE DER ADAPTIERUNG
45
Abbildung 3.15: Digilent 2E Developmentboard mit Xilinx Spartan 2E
FPGA, Quelle [Dig]
3.3.2
Umsetzung des HW/SW-Interfaces
Als physische Hardware/Software-Schnittstelle kommen unter Nutzung des
Digilent 2E nur dessen Schnittstellen in Frage. Dass heißt, eine Verbindung
ist u
¨ber den seriellen, den parallelen, den JTAG-Port oder u
¨ber den Extensionheader m¨oglich.
In Abschnitt 3.1.1 wurde die Verwendung von Standardschnittstellen eines
PCs angedacht. Ein PC stellt standardm¨aßig nur die serielle und die parallele Schnittstelle bereit. Somit entf¨allt die Verwendung von JTAG-Port und
Extensionheader.
Die Wahl der Schnittstelle h¨angt nun von der Leistung der Schnittstelle
ab. Tabelle 3.1 stellt die serielle und die parallele Schnittstelle einander gegen¨
uber. Das wichtigste Leistungsmerkmal f¨
ur die Verbindung der SystemC¨
Simulation und der IP-Emulation stellt die Ubertragunsgeschwindigkeit dar.
Deshalb findet die parallele Schnittstelle f¨
ur die HW/SW-Schnittstelle Verwendung.
Die Kommunikation u
¨ber die parallele Schnittstelle findet u
¨ber das EPPProtokoll (Enhanced Parallel Port) statt. Das EPP-Protokoll ist im IEEEStandard 1284 definiert. Die Nutzung des EPP-Protokolls bringt einige Eigenschaften mit sich, die f¨
ur die HW/SW-Schnittstelle und deren Umsetzung
von Bedeutung sind.
46
3 DIE METHODE DER ADAPTIERUNG
Merkmal
¨
Ubertragunsart
¨
Ubertragungsmodi
Synchronisation
maximale
Geschwindigkeit
Anzahl der Datenbits pro Zyklus
Fehlererkennung
serielle Schnittstelle parallele Schnittstelnach RS-232
le nach IEEE 1284
(EPP)
seriell
parallel
asynchron
synchron
senden
Daten senden
Adressen senden
empfangen
Daten lesen
Adressen lesen
Signalflanke
Handshake
115 200 Bit/s
2 MByte/s
= 14 400 Byte/s
8
8
Parit¨at
-
Tabelle 3.1: Vergleich von serieller Schnittstelle nach RS-232 und paralleler
Schnittstelle nach IEEE 1284
Zum Einen ist das Protokoll ein Master-Slave-Protokoll. Dass heißt, die Kommunikation kann nur von einem Kommunikationspartner initiiert werden. Im
Abschnitt 3.1.1 wurde festgestellt, dass es sich bei der vorliegenden Verbindung von SystemC-Simulation und IP-Emulation um eine Form der MasterSlave-Cosimulation handelt. Somit stellt diese Eigenschaft des Protokolls kein
Hinderniss dar. Den Master der HW/SW-Schnittstelle bildet die Softwareseite, also der PC auf dem die SystemC-Simulation abl¨auft. Die Hardwareseite
des Systems (Hardwareseite des IFBs und IP-Emulation) stellt den Slave dar.
Somit existiert auch innerhalb des IFB eine Master-Slave-Beziehung zwischen
den Controlunits. Doch dazu mehr im Abschnitt 3.3.7.
Eine weitere Eigenschaft des EPP-Protokolls, die f¨
ur die Trennung von Datenfluss und Steuerfluss u
¨ber die HW/SW-Schnittstelle von Bedeutung ist,
¨
bilden die vier verschiedenen Ubertragungsmodi.
Mit Hilfe des Protokolls ist
der Master in der Lage, Daten und Adressen zu schreiben bzw. zu lesen. Die
Modi werden durch unterschiedliche Formen des Handshakes realisiert. Zur
Veranschaulichung stellt Abbildung 3.16 den Protokollautomaten des EPPProtokoll auf der Slaveseite dar. Ausf¨
uhrlichere Informationen zur parallelen
Schnittstele finden sich in [Axe97], [Pea04] und [War].
¨
bedeuten f¨
ur die HW/SW-SchnittDie unterschiedlichen Ubertragungsmodi
3 DIE METHODE DER ADAPTIERUNG
DataWcycle
Writecycle
0
nWrite = 0
Init
nWait = 0
nWait = 0
ata
ob
Str
nA
dd
rS
tro
be
=
nWait = 0
DWGet
nDataStrobe = 1
AddressWcycle
0
nWait = 0
nWait = 1
AWGet
nAddrStrobe = 1
nWait = 1
nWrite = 1
e
rit
nW
=
nD
0
e=
47
CycleEnd
nWait = 1
DRPut
e
rit
nW
DataRcycle
=
1
Readcycle
nWait = 0
ata
nD
Str
=
obe
nA
dd
rS
tro
be
=
0
0
nWait = 0
nDataStrobe = 1
ARPut
AddressRcycle
nWait = 0
nWait = 1
nAddrStrobe = 1
nWait = 1
nWrite = 1
Abbildung 3.16: Protokollautomat des EPP-Protokoll
stelle, dass f¨
ur die Kommunikation eine Adressbreite von 8 Bit zur Verf¨
ugung
steht. Mit jeder Adresse k¨onnen 8 Bit Daten adressiert werden. Mit 8 Bit
lassen sich 28 = 256 verschiedene Adressen darstellen. Da jeder Adresse 8 Bit
Daten zugewiesen werden k¨onnen, ergeben sich daraus 256 · 8 Bit = 2048 Bit
Daten, die adressiert geschrieben und 2048 Bit Daten, die adressiert gelesen
werden k¨onnen. Mit Hilfe dieses Mechanismus ist es m¨oglich, die Daten mit
einer Semantik zu versehen.
Auf dieser Basis setzt das Protokoll zur Datenunterscheidung auf. Es dient
dazu, die Simulationsdaten von den Kontrollsignalen der Kommunikation
zwischen den Controlunitteilen zu trennen. Allerdings wird hier nicht die
gesamte Leistung der EPP-Schnittstelle genutzt. Adressen werden hier nicht
doppelt belegt. Dass heißt, mit einer Adresse kann entweder geschrieben oder
gelesen werden. Das Protokoll zur Datenunterscheidung beruht auf einer Teilung des Adressraumes. Die ersten 16 Adressen (00h6 bis 0Fh) dienen zur
Kommunikation der Controlunits. Diese haben somit 16 · 8 Bit = 128 Bit
f¨
ur Kontrollsignale zur Verf¨
ugung. F¨
ur den Austausch von Simulationsdaten stehen die Adressen 10h bis FFh zur Verf¨
ugung. Die ersten Adressen ab
6
Hexadezimale Zahlendarstellung
48
3 DIE METHODE DER ADAPTIERUNG
10h stehen den Eing¨angen der IP zur Verf¨
ugung und sind somit schreibbare
Adressen. Im Anschluss daran folgen die lesbaren Adressen. Die erste lesbare Adresse (FRA, first readable address) berechnet sich aus der Formel
der IP−1
e. Somit ergibt sich f¨
ur die maximale
FRA = 10h + d Anzahl Eingangsbits
8
Anzahl von Ein- und Ausg¨angen der IP (256 − 16) · 8 = 1920.
3.3.3
Der PHSW
Die Aufgaben des Protokollhandlers der Softwareseite lauten wie folgt:
• Schnittstelle zur SystemC-Simulation bereitstellen
• Schnittstelle zum Parallelport des PCs implementieren
• Simulationsdaten senden
• Simulationsdaten lesen
• Kommunikation der CUSW und CUHW erlauben
Eine Anforderung an den Simulationsinterfaceblock besteht nach Abschnitt
3.1.1 darin, der SystemC-Simulation eine SW-Schnittstelle bereitzustellen,
sc_out< >
Epp_IF.h
Parallele
Schnittstelle
lokale
Variablen PH SW
Dlportio.h / .lib
sc_in< >
Init_EPP
Write_EPP
Read_EPP
CUSW
physical
HW/SW-IF
PHSW -Modus
WriteSimData
PHSW -Modus
ReadSimData
Abbildung 3.17: Detailierter Aufbau des PHSW
3 DIE METHODE DER ADAPTIERUNG
Funktion
Init EPP
Write EPP
Read EPP
Parameter
→BADDR
→BADDR
→Adresse
→Datenbyte
→BADDR
→Adresse
←Datenbyte
49
Aufgabe
Initialisierung der Schnittstelle
Schreiben des Datenbyte
auf die angegebene
Adresse
Lesen des Datenbytes
von der angegebenen
Adresse
Tabelle 3.2: Grundfunktionen zum Zugriff auf die parallele PC-Schnittstelle
(BADDR = Basisadresse des Parallelports u
¨ber den die Kommunikation
stattfinden soll; → Eingangsparameter, ← R¨
uckgabeparameter)
bei der der Simulationskern nicht ver¨andert werden muss. Aus diesem Grund
wird der PHSW als SystemC-Modul implementiert. Als Schnittstelle kommen
die SystemC-Ports sc in<> und sc out<> zum Einsatz. Die Eing¨ange und
Ausg¨ange der IP bestimmen die Breite und Anzahl der Ports. Lokale Variablen nehmen die Werte der Ports f¨
ur die weitere Verarbeitung auf (Abbildung
3.17).
Der Zugriff auf den Parallelport des PCs wird u
¨ber die Bibliothek dlportio.lib hergestellt. Diese Bibliothek wurde nicht in dieser Arbeit entwickelt,
sondern als bereits fertige L¨osung von der Website www.driverlinx.com [Scib]
bezogen. Das Programm port95nt.exe [Scia] von der Website muss auf dem
Rechner installiert sein, um die Bibliothek nutzen zu k¨onnen.
Auf die Funktionen der Bibliothek bauen die drei Funktionen Init EPP, Write EPP und Read EPP auf. Ihre Parameter und Aufgaben f¨
uhrt Tabelle 3.2
auf. Nur u
ber
diese
Funktionen
kann
auf
die
parallele
Schnittstelle
zugegriffen
¨
werden. Diesen Weg nutzen alle Funktionen der Softwareseite des IFB, die
auf die Schnittstelle zugreifen m¨
ussen. Das betrifft die PHSW -Modi und die
CUSW . Der Zugriff u
¨ber fest definierte Funktionen bringt den Vorteil, dass die
Bibliothek dlportio.lib auch ausgetauscht werden kann und nur diese Funktionen angepasst werden m¨
ussen, falls eine andere Art des Schnittstellenzugriffs
implementiert werden soll.
Den Transport der Simulationsdaten u
¨bernehmen die Modi des PHSW . Den
Modus zum Schreiben realisiert die Funktion WriteSimData. Den f¨
ur das Le¨
sen zust¨andigen Modus bildet die Funktion ReadSimData. Die Ubergabeparameter sind bei beiden Funktionen gleich. Sie bestehen aus der Basisadres-
50
3 DIE METHODE DER ADAPTIERUNG
Mapping der Eingänge auf lokale Variablen
Resetsignal aktiv?
nein
ja
Schreibmodus im IFBHW setzen
Zähler setzen
lokale Variablen an Emulation senden
Reset der Emulation ausführen
Lesemodus setzen
Emulationsergebnisse in lokale Variablen lesen
Taktsignal aktiv?
nein
ja
Schreibmodus im IFBHW setzen
Zähler setzen
lokale Variablen an Emulation senden
Emulation getaktet ausführen
Lesemodus setzen
Emulationsergebnisse in lokale Variablen lesen
Mapping der lokalen Variablen auf die Ausgänge
Abbildung 3.18: Ablaufplan zur Umsetzung des PHSW
se des Parallelports, einem Zeiger auf ein Feld, dass die Simulationsdaten
enth¨alt bzw. aufnimmt und einem Wert f¨
ur die Gr¨oße des Feldes in Byte.
Den Ablauf eines Funktionszyklus des PHSW stellt Abbildung 3.18 dar. Am
¨
Anfang erfolgt das Ubertragen
der Eing¨ange auf lokale Variablen. Sie dienen als Zwischenspeicher, um die Daten auf die Breite der Eing¨ange der IP
zu konvertieren. Anschließend wird gepr¨
uft, ob das asynchrone Resetsignal
aktiv ist. Es besitzt Vorrang vor dem Taktsignal, da auch bei Registern das
asynchrone Resetsignal die h¨ohere Priorit¨at hat. Ist das Signal aktiv, dann
setzt die CUSW -Funktion SetWriteMode die CUHW in den Schreibmodus. Nun
¨
beginnt das Setzen der Z¨ahler und das Ubertragen
der Simulationsdaten.
Die Ausf¨
uhrung des asynchronen Reset f¨
ur die IP-Emulation schließt sich
an. Nachdem dieser Schritt beendet ist, setzt die Funktion SetReadMode die
CUHW in den Lesemodus. Das Auslesen der Emulationsergebnisse erfolgt in
lokale Variablen, die zum Schluss auf die Ausg¨ange u
¨bertragen werden.
3 DIE METHODE DER ADAPTIERUNG
51
Ist das asynchrone Resetsignal nicht aktiv, so findet die Pr¨
ufung auf Aktivit¨at
des Taktsignals statt. Die einzelnen Schritte sind denen der Resetausf¨
uhrung
gleich. Der einzige Unterschied besteht darin, dass nach dem Schreiben der
Simulationsdaten kein Reset durchgef¨
uhrt wird, sondern das Taktsignal, entsprechend der gesetzten Z¨ahlerwerte, an die IP-Emulation angelegt wird.
3.3.4
Der PHHW-in
Der hardwareseitige Protokollhandler (Abbildung 3.19), der die Schnittstelle
zur physischen HW/SW-Schnittstelle bildet, hat folgende Aufgaben:
• Kommunikation u
¨ber die parallele Schnittstelle realisieren
• Trennung von Simulationsdaten und CU-Kommunikation
F¨
ur die Kommunikation u
¨ber die parallele Schnittstelle implementiert der
Modus des PHHW-in den Protokollautomaten f¨
ur die Slave-Seite des EPPProtokolls. Abbildung 3.16 stellt den Protokollautomaten dar. Es werden 4
CUHW
physical
HW/SW-IF
Parallele
Schnittstelle
status
control
Handlercontrol
FSM
Adresse
Daten
PHHW-in
Daten
PHHW-in Modus 00h..0Fh
sonst
Adresse
EPPProtokoll- Daten
automat Daten
CU-Komm
Extraktion
Abbildung 3.19: Detailierter Aufbau des PHHW-in
52
3 DIE METHODE DER ADAPTIERUNG
¨
EPP-Ubertragungsarten
durch den Protokollautomaten implementiert. Dazu z¨ahlen das byteweise Lesen von Adressen, Schreiben von Adressen, Lesen
von Daten und Schreiben von Daten. F¨
ur die vorliegenden Aufgaben wird
jedoch die Funktion des Lesens von Adressen nicht ben¨otigt. Der Protokollautomat stellt in Registern die empfangene Adresse und die empfangenen
Daten bereit. Ein weiteres Register speichert Daten zwischen, die von der
Softwareseite abgerufen werden.
Die empfangene Adresse ist Grundlage f¨
ur die zweite Aufgabe des PHHW-in ,
die Trennung von Simulationsdaten und CU-Kommunikation. Die CU-Kommunikation findet u
¨ber die Adressen 00h bis 10h statt. Dieser Adressraum
ist wiederum in einen schreibbaren (00h bis 07h) und einen lesbaren Teil
(08h bis 10h) unterteilt. Es stehen also 8 Adressen zum Lesen und 8 zum
Schreiben bereit. Die genaue Belegung und Funktion der Adressen ist im
Abschnitt 3.3.7 beschrieben. Alle Adressen, die gr¨oßer als 10h sind, werden
unver¨andert an den SHHW weitergegeben. Die Auswertung dieser Adressen
ist nicht Aufgabe der PHHW-in .
Der endliche Automat Handlercontrol (Abbildung 3.19) dient allein zur internen Kontrolle des Handlers und zum Starten eines Modus. Den Datentransport durch den IFB beeinflusst er nicht.
3.3.5
Der SHHW
Die Aufgabe des Sequenzhandlers im Hardwareteil des Simulationsinterfaceblocks liegt in der korrekten Verteilung der Simulationsdaten. Durch die
HW/SW-Schnittstelle liegen die Daten in Form von Tupel (Adresse, Datenbyte) vor. Anhand der Adresse muss nun zuerst eine Unterscheidung getroffen
werden, ob es sich um eine Schreibadresse oder eine Leseadresse handelt.
ni − 1
−1
Schreibadressen: 10h
. . . 10h +
8
l m
ni − 1
ni − 1
no
Leseadressen: 10h +
. . . 10h +
+
−1
8
8
8
ni . . . Anzahl Eingangsbits der emulierten IP mit Taktsignal
no . . . Anzahl Ausgangsbits der emulierten IP
(3.1)
(3.2)
3 DIE METHODE DER ADAPTIERUNG
53
CUHW
status
Adresse
Daten
Daten
control
Handlercontrol
FSM
Enable
Daten
SHHW
Daten
SH HW Modus
Datacontrol
Schreibadressen
Leseadressen
Abbildung 3.20: Detailierter Aufbau des SHHW . Die Werte der Schreibadressen bilden den Bereich nach Formel 3.1, die Leseadressen nach Formel 3.2
Den Bereich der Schreibadressen gibt Formel 3.1 an. Er ist abh¨angig von der
Anzahl der Eingangsleitungen ni der emulierten IP. Da das Taktsignal gesondert behandelt wird, muss es von den Eingangsleitungen abgezogen werden.
Die niedrigste Adresse, die u
¨berhaupt Daten transportieren kann, stellt die
10h dar.
Die Leseadressen schließen sich an den Bereich der Schreibadressen an. Sie
sind zus¨atzlich abh¨angig von der Anzahl der Ausgangsleitungen der emulierten IP. Den Adressraum gibt Formel 3.2 an.
Nach der Dekodierung der Adresse werden die Daten zugeordnet. F¨
ur die
Schreibadressen kommt dazu ein Demultiplexer zum Einsatz, da das Datenbyte je nach Adresse auf unterschiedliche Leitungen gelegt werden muss.
Außerdem werden Enablesignale erzeugt, die zur Kommunikation mit dem
PHHW-out dienen. F¨
ur die Abfrage von Leseadressen kommt ein Multiplexer
zum Einsatz. Er legt die Daten vom PHHW-out , die der aktuellen Adresse
entsprechen, auf die Datenleitung zum PHHW-in .
3.3.6
Der PHHW-out
Die Aufgabe des Protokollhandlers der Hardwareseite, der die Schnittstelle
zur IP-Emulation bildet, besteht darin, einen Speicher f¨
ur die Simulationsdaten bereitzustellen. Zu speichern sind sowohl die anzulegenden Daten als
54
3 DIE METHODE DER ADAPTIERUNG
CUHW
status
Enable
Daten
Daten
control
Handlercontrol
FSM
PHHW-out
ni
no
IP
Emulation
HW
PHHW-outModus
FF-Register to IP
FF-Register from IP
Abbildung 3.21: Detailierter Aufbau des SHHW-out
auch die Emulationsergebnisse. Zus¨atzlich muss der PHHW-out noch einen Mechanismus enthalten, mit dem eine kontrolliert Ausl¨osung des Taktsignals f¨
ur
die Emulation m¨oglich ist.
F¨
ur jedes Eingangs- sowie Ausgangssignal der emulierten IP wird ein eigenst¨andiger Speicher ben¨otigt. Deshalb kommen Flipflops als Speicher zum
Einsatz. Da die IP ni Eing¨ange und no Ausg¨ange besitzt, muss der Modus
des PHHW-out ni + no Flipflops zur Speicherung der Simulationsdaten bereitstellen.
Um eine Steuerung der Datenspeicherung zu erlauben, werden die Flipflops
mit Enable-Signalen gesteuert. Die Flipflops mit den Eingangsdaten der IP
werden durch den SHHW gesteuert. Die Flipflops, die die Ausgangswerte der
IP u
¨bernehmen, durch ein Kontrollsignal von der CUHW , da diese die genaue
G¨
ultigkeit der Daten kennt.
Unter den ni Flipflops f¨
ur die Eingangssignale der IP befindet sich auch ein
Flipflop f¨
ur das Taktsignal. Es wird mittels eines Kontrollsignals von der
CUHW gesetzt oder gel¨oscht, da die CUHW die Taktsteuerung implementiert.
3.3.7
Die Controlunit
Die Controlunit (Abbildung 3.22) besteht aus einem Hardware- (CUHW ) und
einem Softwareteil (CUSW ), die beide zusammenarbeiten. Sie kommunizieren
3 DIE METHODE DER ADAPTIERUNG
CUSW
CUsw.h
Definitionen
55
CUHW
Autoreset
CUsw.cpp
SetWriteMode
SetReadMode
SetWaitMode
SetCycleEnd
SetStartSim
SetDUTreset
SetResetIFB
init_Interface
SetLDIVCounter
condition_to_start_simulation SetHDIVCounter
test_environment_id
SetCycleCounter
GetStatus1
GetStatus2
GetLDIVCounter
GetHDIVCounter
GetZyklenCounter
IFB-Control FSM
Kontroll- und
Statusregister
Zähler
Abbildung 3.22: Detailierter Aufbau der Controlunits
miteinander u
¨ber die HW/SW-Schnittstelle mit Hilfe von PHSW und PHHW-in .
Die Grundlagen der Kommunikation wurden bereits in den Abschitten 3.3.3
und 3.3.4 erl¨autert.
In den Abschnitten 3.1.1 und 3.2.3 wurde herausgearbeitet, dass zwischen
der SystemC-Simulation und der IP-Emulation eine Master-Slave-Beziehung
besteht. Diese Beziehung wird auf den IFB u
¨bertragen, so dass der Softwareteil, also die CUSW , die Rolle des Masters annimmt und der Hardwareteil,
also die CUHW , die Rolle des Slave.
Zun¨achst soll der Hardwareteil der Controlunit n¨aher betrachtet werden. Er
besteht aus einem Automaten zur Kontrolle des Interfaceblocks, der zus¨atzlich Kontrollregister, Statusregister und Z¨ahler beinhaltet, und eine Kompo¨
nente Autoreset. Uber
die Kontrollregister erh¨alt der Automat Steuersignale
von der CUSW . Die Statusregister erlauben der CUSW , den aktuellen Zustand
des Hardwareteils abzufragen. Die Funktion der Kontroll- und Statusregister,
die sie erf¨
ullen, sowie die Adresse, u
uhren
¨ber die sie angesprochen werden, f¨
Tabelle 3.3 und 3.4 auf.
Das Zustandsdiagramm der endlichen Automaten stellt Abbildung 3.23 dar.
¨
Aus Gr¨
unden der Ubersichtlichkeit
sind die Ausgaben der Zust¨ande in Tabelle 3.5 aufgef¨
uhrt. Zu Beginn f¨
uhren die Zust¨ande Start PHin, Start SH und
Start PHout das Starten der Handlerautomaten durch. Anschließend wartet
der Automat im Zustand Waiting auf Signale der CUSW .
Von diesem Zustand aus erreicht der Automat durch Setzen des Signals cwrite bzw. cread die Zust¨ande DWrite bzw. DRead. In diesen Zust¨anden sollten
56
3 DIE METHODE DER ADAPTIERUNG
Adresse
00 h
01 h
02 h
03 h
04 h
05 h
06 h
07 h
08 h
09 h
0A h
0B h
0C h
0D h
0E h
0F h
w/r
w
w
w
w
w
w
w
w
r
r
r
r
r
r
r
r
Funktion
Neutrale Adresse
Kontrollregister
LDIV Z¨ahler
HDIV Z¨ahler
Zyklenz¨ahler High-Byte
Zyklenz¨ahler Low-Byte
keine
keine
Statusregister1
Statusregister2
LDIV Z¨ahlerwert
HDIV Z¨ahlerwert
Zyklenz¨ahlerwert High-Byte
Zyklenz¨ahlerwert Low-Byte
keine
Environment ID
Tabelle 3.3: Die Register der hardwareseitigen Controlunit. (w - schreibbar,
r - lesbar)
die Simulationsdaten geschrieben bzw. gelesen werden. Dies ist nicht zwingend notwendig. Um jedoch ein versehentliches Starten der Emulation zu
verhindern, sollten diese Funktionen in den Zust¨anden ausgef¨
uhrt werden.
In den Zustand NoAction geht der Automat, falls das Startsignal gesetzt ist,
aber noch kein Wert f¨
ur die Anzahl der Simulationszyklen im Zyklenz¨ahler
eingetragen ist. Dies verhindert, dass ein Emulationszyklus durchlaufen wird
ohne eine Angabe der Zyklenanzahl.
Der Zustand DUTreset f¨
uhrt einen asynchronen Reset der IP-Emulation
durch. Da der asynchrone Reset dem Taktsignal u
¨bergeordnet und von ihm
unabh¨angig ist, wird die Emulation dabei ohne Taktsignal ausgef¨
uhrt. Die
Speicherung der Ausgabedaten der Emulation erfolgt dabei wie in einem normalen Taktzyklus.
Beim Start der Emulation durch das Signal cstart wechselt der Automat
in den Zustand DPrepare falls der Zyklenz¨ahler einen Wert ungleich Null
enth¨alt. Der Zustand dient der Vorbereitung auf die Emulation. Es werden
die Flipflops zur Aufnahme der Emulationsdaten im PHHW-out -Modus freigegeben und die Z¨ahler LDIV und HDIV geladen. Anschließend wechselt
3 DIE METHODE DER ADAPTIERUNG
cwrite
cread
Statusregister1
Statusregister2
-
-
-
-
-
zero hdiv swrite
zero ldiv
Kontrollregister
sread
cstart
0
zero cycles sready
-
1
cnext
-
2
swork
3
cdutreset
4
snext
5
phout runs
6
sh runs
7
phin runs creset
Bit
57
Tabelle 3.4: Belegung der Kontroll- und Statusregister der CUHW
der Automat in den Zustand Clk gen1, in dem die Taktgenerierung beginnt.
Der Zustand Clk gen1 erzeugt den Highpegel in positiver Logik w¨ahrend der
Zustand Clk gen0 den Lowpegel generiert. Die Dauer der generierten Pegel
bestimmten die Werte der Z¨ahler HDIV und LDIV. Mit Hilfe der Z¨ahler
ist es m¨oglich, die IP-Emulation wahlweise mit einem symmetrischen oder
einem asymmetrischen Taktsignal zu betreiben. Die Frequenz, mit der die
IF B
. Die
IP emuliert wird, berechnet sich nach der Formel fIP = HDIVf+LDIV
+2
Herleitung der Formel beschreibt Anhang A. Um die gew¨
unschte Anzahl an
Taktperioden zu erzeugen, werden die Zust¨ande Clk gen1 und Clk gen0 so
oft nacheinander abgearbeitet, bis der Zyklenz¨ahler den Wert 0 erreicht hat.
Nach Abschluss der Taktgenerierung wechselt der Automat in den Zustand
End Cycle. Dieser Zustand sperrt die Flipflops des PHHW-out -Modus wieder,
damit die aufgenommenen Emulationsdaten nicht verf¨alscht werden k¨onnen.
Der Automat verweilt in diesem Zustand, bis das Signal cnext oder cread
gesetzt wird.
Das Signal mit der obersten Priorit¨at ist creset. Es bringt den Automaten
in den Zustand DoReset. Er l¨ost ein Signal f¨
ur die Komponente Autoreset
aus. Das Signal veranlasst die Komponente, einen asynchrone Reset f¨
ur die
Hardwareseite des Interfaceblocks auszul¨osen. Somit ist es m¨oglich, den Interfaceblock durch ein Signal der Softwareseite r¨
uckzusetzen.
Der Softwareteil der Controlunit setzt sich aus einem Definitionsteil und einem Funktionsteil zusammen. Die Definitionen werden in der Datei CUsw.h
58
3 DIE METHODE DER ADAPTIERUNG
Init
DoReset
always at creset = 1
NoAction
Start_PHin
ResetDUT
phin_runs = 1
zero_counter_zyklen = 1
cstart = 1
cdutreset = 1
cnext = 1
Start_SH
sh_runs = 1
cnext = 1
Waiting
Start_PHout
cread = 1
phout_runs = 1
zero_counter_ldiv = 1
zero_counter_zyklen = 1
cread = 1
cwrite = 1
cwrite = 0
zero_counter_zyklen = 0
cstart = 1
DWrite
End_Cycle
Clk_gen0
cread = 0
cwrite = 1
DRead
DPrepare
zero_
counter_
hdiv = 1
Clk_gen1
zero_
counter_
ldiv = 0
zero_
counter_
zyklen = 0
zero_
counter_
hdiv = 0
Abbildung 3.23: FSM der Controlunit. Die Ausgaben der Zust¨ande sind in
Tabelle 3.5 zu finden.
getroffen. Sie dienen zum Festlegen der Adressen der Kontroll- und Statusregister des Hardwareteils, sowie der Festlegung von vordefinierten Werten, mit
denen zum Beispiel die Kontrollregister gesetzt und die Statusregister ausgewertet werden k¨onnen. Diese Definitionen stehen der gesamten Softwareseite
des Interfaceblocks zur Verf¨
ugung.
Die Funktionen der CUSW sind in Tabelle 3.6 zusammengefasst. Sie teilen
sich wie folgt in drei Gruppen:
• Funktionen zum Schreiben in die Kontrollregister
• Funktionen zum Abruf der Statusregister
• Hilfsfunktionen
Die Funktionen zum Schreiben in die Kontrollregister erm¨oglichen es, Funktionen im Hardwareteil des Interfaceblocks auszul¨osen. Der Automat kann
in verschiedene Zust¨ande versetzt werden, die Emulation gestartet oder der
Interfaceblock zur¨
uckgesetzt werden. Außerdem erlauben die Funktionen das
Setzen der Z¨ahler HDIV, LDIV und das Taktzyklenz¨ahlers.
Start PHin
Start SH
Start PHout
Waiting
DWrite
DRead
DPrepare
Clk gen1
Clk gen0
NoAction
End Cycle
DoReset
ResetDUT
Signal
phin start
phin stop
sh start
sh stop
phout start
phout stop
load counter zyklen
inclk0 counter zyklen
inclk1 counter zyklen
load counter hdiv
go counter hdiv
load counter ldiv
go counter ldiv
cstart reset
sread
swrite
sready
swork
snext
ffreg out en
ffreg in en
setsimclock
activate reset loc
59
Init
Zustand
3 DIE METHODE DER ADAPTIERUNG
0
1
0
1
0
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
0
0
1
0
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
0
0
1
0
1
0
0
0
1
0
0
0
0
0
0
0
0
0
0
0
0
0
1
0
0
1
0
1
0
0
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
0
0
1
0
1
0
0
0
0
0
1
0
1
0
0
0
0
0
0
0
0
0
0
0
1
0
1
1
0
1
0
0
0
1
0
1
1
1
0
0
0
0
0
0
0
0
1
0
1
0
0
1
1
0
0
0
0
0
1
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
0
0
0
0
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
1
1
0
0
0
1
0
1
0
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
0
1
1
0
0
Tabelle 3.5: Die Ausgaben des Clockcontrolautomaten in seinen Zust¨anden
Der Abruf von Statusregistern dient der CUSW zur Information u
¨ber den Zustand der CUHW . Außerdem k¨onnen die aktuellen Werte der Z¨ahler abgerufen
werden.
Die Hilfsfunktionen haben die Aufgabe, die Arbeit des Softwareteils des Interfaceblocks zu unterst¨
utzen. So sind Funktionen zur Initialisierung der parallelen Schnittstelle, zum Testen von Signalen auf eine bestimmte Bedingung
vorhanden. Außerdem eine Funktion, die vor der Aufnahme der Kommunikation mit der Hardwareseite sicherstellen soll, dass sich der richtige Interfaceblock auf dem FPGA befindet.
60
3 DIE METHODE DER ADAPTIERUNG
Funktionsname
SetWriteMode
SetReadMode
SetWaitMode
SetCycleEnd
SetStartSim
SetDUTreset
Aufgabe
Setzt cwrite-Bit in CUHW
Setzt cread-Bit in CUHW
Setzt Kontrollregister auf 00h
Setzt cnext-Bit in CUHW
Setzt cstart-Bit in CUHW
Setzt Bit f¨
ur asynchronen Reset
der IP in CUHW
SetResetIFB
Setzt creset-Bit in CUHW
und l¨ost damit Reset des IFB aus
SetLDIVCounter
Setzt den Z¨ahlen LDIV in CUHW
SetHDIVCounter
Setzt den Z¨ahler HDIV in CUHW
SetCycleCounter
Setzt den Zyklenz¨ahler in CUHW
GetStatus1
Liest erstes Statusbyte von CUHW
GetStatus2
Liest zweites Statusbyte von CUHW
GetLDIVCounter
Liest Wert des LDIV-Z¨ahler
GetHDIVCounter
Liest Wert des HDIV-Z¨ahler
GetZyklenCounter Liest Wert des Zyklenz¨ahlers
condition to
Pr¨
uft, ob ein Signal einen bestimmten
start simulation
Wert hat
init Interface
initialisiert die parallele Schnittstelle
test environment id pr¨
uft, ob sich auf dem FPGA
der richtige IFB befindet
Tabelle 3.6: Funktionen der CUSW
3.4
Anwendungsm¨
oglichkeiten
Der Haupteinsatzzweck dieses Hardware/Software-Interfaces ist die gekoppelte Simulation einer SystemC-Verhaltensbeschreibung und einer synthesef¨ahigen VHDL-IP.
Eine weitere Anwendung liegt in der Simulation eines Prototypen auf einem FPGA unter Verwendung eines SystemC-Testbenches. Dies stellt den
Haupteinsatzzweck ohne weitere SystemC-Module dar. Die einzigen Module sind dabei der Testbench, die Mainfunktion und das Koppelmodul des
Interfaceblocks. Durch die Verwendung von SystemC k¨onnen die Simulationsdaten des ausgef¨
uhrten Designs in Tracefiles aufgezeichnet werden und
erlauben so ein einfaches Hardwaredebugging.
3 DIE METHODE DER ADAPTIERUNG
61
Unter Benutzung eines FPGA, das dynamische Rekonfiguration erlaubt, k¨onnen
auch dynamisch rekonfigurierbare Designs emuliert werden. Diese Anwendung erlaubt den Test dieser Designs und wiederum die Aufzeichnung von
Testdaten in einem Tracefile oder durch den Nutzer unter Verwendung von
C/C++ Operationen.
Weiterhin ist vorstellbar, dass mit Hilfe eines Simulationsinterfaceblocks rechenzeitintensive Teile der Designbeschreibung auf ein FPGA ausgelagert
werden. Die ben¨otigte Rechenleistung nimmt ab und eine Beschleunigung
der Simulation kann erreicht werden.
62
3 DIE METHODE DER ADAPTIERUNG
4 DER SIMULATIONSINTERFACEBLOCK-GENERATOR
4
63
Der SimulationsinterfaceblockGenerator
Dieses Kapitel stellt das Programm Simulationsinterfaceblock-Generator vor. Seine Entwicklung fand im Rahmen dieser Arbeit statt.
Zun¨achst werden die Gr¨
unde f¨
ur die Implementierung des Programms beschrieben. Der sich anschließende Abschnitt beschreibt die Merkmale und
die M¨oglichkeiten des Programms. Danach wird die Arbeitsweise vorgestellt.
Am Ende dieses Kapitels wird auf die Benutzung des Programms eingegangen und Verbesserungsm¨oglichkeiten aufgezeigt.
4.1
Motivation
Der Simulationsinterfaceblock verbindet eine IP-Emulation mit einer SystemCSimulation. Die Parameter des Interfaceblocks h¨angen immer von den Eing¨angen und Ausg¨angen der emulierten IP ab. Aus diesem Grund muss der
Simulationsinterfaceblock f¨
ur jede IP neu erstellt werden.
Ein Ziel der Kopplung von Emulation und Simulation durch einen Interfaceblock liegt darin, Zeit bei der Simulationsvorbereitung einzusparen. Die
Erstellung eines Simulationsinterfaceblocks kann aber auch viel Zeit in Anspruch nehmen. Die manuelle Erstellung des Simulationsinterfaceblocks erh¨oht
zudem die Wahrscheinlichkeit, dass sich Fehler im Design einschleichen.
Um die menschlichen Fehler einzugrenzen und die Zeit f¨
ur die manuelle Erstellung einzusparen, soll hier im Folgenden eine automatische L¨osung vorgestellt werden. Die L¨osung besteht im Programm SimulationsinterfaceblockGenerator und wurde im Rahmen dieser Arbeit entwickelt.
4.2
Arbeitssweise
Dieser Abschnitt stellt die Arbeitsweise des Simulationsinterfaceblock-Generators vor. Zun¨achst erfolgt die Vorstellung der Eingaben f¨
ur das Programm
64
4 DER SIMULATIONSINTERFACEBLOCK-GENERATOR
externe Tools
VHDL-IP
Templates
Nutzereingaben
SimIFB
Generator
SimIFBHW
Konfigurationsdatei für FPGA
SimIFBHW
Sources
SimIFBSW
Sources
Abbildung 4.1: Eingaben und Ausgaben des SimIFB-Generators
und die gew¨
unschten Ausgaben. Anschließend wird die interne Datenstruktur, auf der das Programm arbeitet, erkl¨art, bevor der Ablauf des Programms
beschrieben wird.
4.2.1
Eingaben und Ausgaben
F¨
ur die Entwicklung eines Programmes sind als erstes die Eingaben und
Ausgaben zu betrachten (Abbildung 4.1). Als Eingaben stehen dem Simulationsinterfaceblock-Generator die VHDL-IP, die emuliert werden soll und
Templates zur Verf¨
ugung. Zus¨atzlich k¨onnen vom Benutzer noch einige Parameter w¨ahrend des Programmlaufs festgelegt werden.
Nach dem Programmlauf sollen sowohl der Softwareteil also auch der Hardwareteil des Simulationsinterfaceblocks zur Verf¨
ugung stehen. Der Softwareteil besteht aus C/C++-Quelldateien, die in ein SystemC-Design eingebunden werden. Der Hardwareteil beinhaltet als erste Ausgabe die VHDLQuelldateien des Simulationsinterfaceblock und die daran angebundene IP.
Aus diesen Quelldateien erfolgt, unter Nutzung von externen Tools zur Synthese, Platzierung und Trassierung, die Generierung der Konfigurationsdatei
f¨
ur das FPGA.
4.2.2
Die internen Datenstrukturen
Ein Programm ben¨otigt zur Speicherung und Verarbeitung von Daten eine
Datenstruktur. Die Hauptdatenstruktur im Simulationsinterfaceblock-Generator ist die ENTITY STRUCTUR. Sie nutzt die Datenstrukturen PORT LIST
und GENERIC LIST. Zur Unterst¨
utzung bestimmter Operationen existieren
4 DER SIMULATIONSINTERFACEBLOCK-GENERATOR
65
ENTITY STRUCTUR
Datentyp
Variablenname
char*
filename
char*
component name
int
compname position
GERNERIC LIST* generics
PORT LIST*
ports
int
data width to dut
int
hs width to dut
int
data width from dut
int
byte to dut
int
byte from dut
unsigned char
id
int
hdiv counter
int
ldiv counter
int
cycle counter
int
epp port addr
int
fpga prog after gen
Tabelle 4.1: Aufbau der Datenstruktur ENTITY STRUCTUR
des Weiteren die Datenstrukturen WORD LIST und FILELIST. Die genaue Beschreibung der Datenstrukturen erfolgt in den sich anschließenden Abschnitten.
4.2.2.1
Die Datenstruktur ENTITY STRUCTUR
Die grundlegende Datenstruktur im Simulationsinterfaceblock-Generator ist
die ENTITY STRUCTURE. Sie speichert alle Daten, die f¨
ur die Erstellung des
Simulationsinterfaceblocks notwendig sind. Die Daten bestehen aus Analyseergebnissen der VHDL-IP und darauf aufbauender Berechnungen, sowie
aus Parametern, die vom Nutzer zur Laufzeit des Programms festgelegt werden. Außerdem existieren einige Funktionen, die eine einfache Arbeit mit der
Datenstruktur erlauben.
Zun¨achst soll die Funktion der Variablen der Datenstruktur, die Tabelle 4.1
auff¨
uhrt, vorgestellt werden. Die Variable filename speichert den Namen der
Quelldatei, die den Toplevel der VHDL-IP darstellt. Den Namen der VHDLEntity dieser Datei enth¨alt component name und die Position innerhalb der
Datei compname position.
66
4 DER SIMULATIONSINTERFACEBLOCK-GENERATOR
Funktion
make entitystructur
Aufgabe
Erzeugt ein neues Element vom Typ
ENTITY STRUCTUR
init entitystructur
Initialisiert die Datenstruktur vom Typ
ENTITY STRUCTUR
reserve wordspace ename Reserviert Speicherplatz f¨
ur die Variable
component name
reserve wordspace fname Reserviert Speicherplatz f¨
ur die Variable
filename
check entity for clock
Durchsucht die Ports der Entity nach einem Taktsignal und legt eines an, falls die
Suche fehlschl¨agt.
¨
Tabelle 4.2: Uberblick
zu den Funktionen zur Datenstruktur ENTITY STRUCTUR
Die Zeiger generics und ports verweisen auf die Datenstrukturen GENERIC LIST
bzw. PORT LIST. Sie dienen zum Erfassen der Generics und Ports der Entity.
Ihre genaue Funktion beschreiben Abschnitt 4.2.2.3 bzw. Abschnitt 4.2.2.2.
Die Variablen data width to dut und data width from dut geben die ben¨otigte Anzahl Signale an, um Daten zur und von der IP zu transportieren.
Byte to dut und byte from dut stellen die Werte auf ein volles Byte gerundet
dar. Die Variable hs width to dut gibt die Breite der Handshakesignale an,
die der SHHW zum Zugriff auf den Speicher im PHHW-out ben¨otigt.
In id wird eine 8 Bit lange Identifikationsnummer gespeichert. Ein Zufallsgenerator erzeugt sie. Sie dient zur Identifikation des Hardwareteils des Simulationsinterfaceblocks durch den Softwareteil um sicherzustellen, dass die
richtigen Teilst¨
ucke miteinander arbeiten.
Die Variablen hdiv counter, ldiv counter und cycle counter speichern die
Werte, auf die w¨ahrend der sp¨ateren Simulation die Z¨ahler des Hardwareteils eingestellt werden. Die Funktion der Z¨ahler wurde bereits im Abschnitt
3.3.7 erl¨autert.
Epp port addr enth¨alt die Adresse, u
¨ber die die parallele Schnittstelle des
ausf¨
uhrenden PCs angesprochen wird. Der Wert in fpga prog after gen gibt
an, ob der Simulationsinterfaceblock-Generator das FPGA nach der Generierung des Simulationsinterfaceblocks sofort konfigurieren soll.
4 DER SIMULATIONSINTERFACEBLOCK-GENERATOR
67
Zur Datenstruktur ENTITY STRUCTUR geh¨oren neben den Variablen auch einige Funktionen, die Tabelle 4.2 auff¨
uhrt. Sie dienen zur einfacheren Arbeit
mit der Datenstruktur.
4.2.2.2
Die Datenstruktur PORT LIST
Zur Speicherung der Struktur der durch den Simulationsinterfaceblock-Generator analysierten VHDL-Entity der IP, dient die Datenstruktur PORT LIST.
Sie wird durch eine doppelt verkettete lineare Liste gebildet. Tabelle 4.3 stellt
die Variablen eines Elementes der Liste dar. Die Verkettung der einzelnen
Elemente realisieren die Zeiger prev und next.
Eine VHDL-Entity besteht aus Ports, die die Schnittstelle der jeweiligen
Komponente definieren. F¨
ur jeden Port existiert in der Liste ein Element.
Die Variable port name gibt den Namen des Ports an. Port position speichert
die Position des Ports in der VHDL-Datei. Die Richtung des Ports, also ob
es sich um einen Eingang, Ausgang, einen bidirektionalen Port oder einen
Buffer handelt, gibt port direction an.
Ein Port besitzt eine Breite port width. Die Grenzen des Ports bestimmen
PORT LIST
Datentyp
char*
int
unsigned char
unsigned int
unsigned int
unsigned int
unsigned char
unsigned int
unsigned int
unsigned char
unsigned char
unsigned char
struct port list*
struct port list*
Variablenname
port name
port position
port direction
port width
port high
port low
port align
map from
map to
special
active
sign
prev
next
Tabelle 4.3: Aufbau der Datenstruktur PORT LIST
68
4 DER SIMULATIONSINTERFACEBLOCK-GENERATOR
Funktion
make port
Aufgabe
Erzeugt ein neues Element vom Typ
PORT LIST
init portlist
Initialisiert die Datenstruktur
insert port
F¨
ugt ein Element in eine bestehende Liste
ein
reserve wordspace
Reserviert Speicherplatz f¨
ur die Variable
port name
sort portlist width
Sortiert die Liste absteigend nach der
Breite der Ports port width
sort portlist direction Sortiert die Liste nach der Richtung der
Ports port direction
¨
Tabelle 4.4: Uberblick
zu den Funktionen zur Datenstruktur PORT LIST
port high und port low. Die Ausrichtung des Ports, dass heißt to“ oder
”
downto“ falls er ein Vektor ist, speichert die Variable port align.
”
Nach der Entityanalyse berechnet das Programm noch Werte zur Abbildung der Signale innerhalb des Interfaceblocks. Die Variablen map from und
map to nehmen diese auf. Spezielle Attribute eines Ports, wie Takt- oder
Resetsignal, legt die Variable special fest. In diesem Zusammenhang bestimmt active die aktive Taktflanke dieses Signals. Ob der Port im erstellten
SystemC-Modul vorzeichenbehaftet ist oder kein Vorzeichen besitzt, beeinflusst die Varibale sign.
Neben den Variablen erleichtern einige Funktionen die Arbeit mit der Datenstruktur. Ihre Aufgaben stellt Tabelle 4.4 dar.
4.2.2.3
Die Datenstruktur GENERIC LIST
Die Datenstruktur GENERIC LIST wurde eingef¨
uhrt, um generische Parameter in der VHDL-Entity zu unterst¨
utzen. Allerdings existiert bis jetzt nur
die Definition der Datenstruktur. Tabelle 4.5 f¨
uhrt die enthaltenen Variablen auf. Eine doppelt verkettete lineare Liste realisert die Datenstruktur
¨ahnlich wie die Liste der Ports (vgl. Abschnitt 4.2.2.2). Die Nutzung von
VHDL-Generics ist im Simulationsinterfaceblock-Generator noch nicht implementiert. Aus diesem Grund wird an dieser Stelle auf eine ausf¨
uhrlichere
Beschreibung verzichtet.
4 DER SIMULATIONSINTERFACEBLOCK-GENERATOR
69
GENERIC LIST
Datentyp
Variablenname
char*
generic name
int
generic value
struct generic list* prev
struct generic list* next
Tabelle 4.5: Aufbau der Datenstruktur GENERIC LIST
4.2.2.4
Die Datenstruktur WORD LIST
Die Datenstruktur WORD LIST hat die Aufgabe, das Parsen und Analysieren
der VHDL-Entity der IP zu unterst¨
utzen. Dies geschieht, indem mit Hilfe der
Datenstruktur die einzelnen syntaktischen Elemente der Entity wortweise gespeichert werden. Sie ist durch eine doppelt verkettete lineare Liste realisert,
deren Elemente die Variablen aus Tabelle 4.6 enthalten.
Die Verkettung der Liste wird durch die Zeiger prev und next hergestellt.
Einzelne Worte speichert die Variable word. Die Position des Wortes in der
VHDL-Datei beinhaltet die Variable position.
Zur Datenstruktur geh¨oren die Funktionen make word, insert word und reserve wordspace, deren Aufgaben Tabelle 4.7 beschreibt.
WORD LIST
Datentyp
Variablenname
char*
word
int
position
struct word list* prev
struct word list* next
Tabelle 4.6: Aufbau der Datenstruktur WORD LIST
Funktion
make word
insert word
reserve wordspace
Aufgabe
Erzeugt ein neues Element vom Typ WORD LIST
F¨
ugt ein Element in eine bestehende Liste ein
Reserviert Speicherplatz f¨
ur die Variable word
¨
Tabelle 4.7: Uberblick
zu den Funktionen zur Datenstruktur WORD LIST
70
4 DER SIMULATIONSINTERFACEBLOCK-GENERATOR
FILELIST
Datentyp
char*
int
struct filelist*
Variablenname
filename
processed
next
Tabelle 4.8: Aufbau der Datenstruktur FILELIST
Funktion
Aufgabe
filelist new
Erzeugt ein neues Element vom Typ FILELIST
filelist addfile F¨
ugt einen Dateinamen in die Liste ein, falls dieser
noch nicht in der Liste vorhanden ist
filelist free
Gibt den Speicherplatz f¨
ur die Liste wieder frei
¨
Tabelle 4.9: Uberblick
zu den Funktionen zur Datenstruktur FILELIST
4.2.2.5
Die Datenstruktur FILELIST
Die Aufgabe der Datenstruktur FILELIST besteht darin, eine Liste von Dateinamen zu speichern. Sie findet Verwendung beim Kopieren der IP und der
darin deklarierten Komponenten in das neue Zielverzeichnis.
Die Datenstruktur ist eine einfach verkettete lineare Liste, bei der die Verkettung durch den Zeiger next erreicht wird. Außerdem kann sie in jedem
Element der Liste einen Dateinamen (filename) und den Bearbeitungsstatus
dieser Datei (processed ) speichern. Tabelle 4.8 gibt den Aufbau der Datenstruktur wieder.
Die Funktionen zur Arbeit mit der Datenstruktur f¨
uhrt Tabelle 4.9 auf. Darin
ist auch die Aufgabe der Funktionen dargestellt.
4.2.3
Der Programmablauf
Der erste Schritt, den der Simulationsinterfaceblock-Generator im Programmablauf durchf¨
uhrt, ist die Analyse der VHDL-IP. Bevor jedoch die Analyse
durchgef¨
uhrt werden kann, muss die Quelldatei aufbereitet werden. Der erste Arbeitsgang liest die Quelldatei der VHDL-IP in den Speicher. Anschließend entfernt die Funktion vhdl remove comments die Kommentare aus dem
Quelltext. Die Formatierungszeichen, wie z.B. Zeilenumbr¨
uche, Tabulatoren
4 DER SIMULATIONSINTERFACEBLOCK-GENERATOR
71
und mehrfache Leerzeichen, entfernt die Funktion string remove multispace.
Um ein einfacheres Parsen des Quelltextes zu erm¨oglichen, wandelt die Funktion string tolowercase den Text in Kleinbuchstaben um. Am Ende der Vorbereitung sucht vhdl entity borders die Grenzen der Entity im Text. Es wird
hierbei davon ausgegangen, dass der Quelltext nur eine VHDL-Entity beschreibt oder die erste Entity im Text das Toplevel der IP darstellt. Ihre
Position bestimmt der Anfang des Schl¨
usselwortes entity und das Ende die
Position des Schl¨
usselwortes end. Anhand dieser Grenzen l¨ost die Funktion
string extract die Entity aus dem Text heraus, indem sie den Bereich an den
Beginn des Textes schreibt und den Rest mit Leerzeichen auff¨
ullt.
Sind alle vorbereitenden Arbeiten durchgef¨
uhrt, startet durch die Funktion
vhdl parse entity die Analyse der Entity. Sie beginnt mit einem syntaktischen
Trennen des Textes mit Hilfe der Funktion vhdl seperate syntax. Das bedeutet, dass syntaktische Elemente im Text durch ein Leerzeichen voneinander
getrennt werden. Zu den syntaktischen Elementen z¨ahlen zum Beispiel die
Schl¨
usselw¨orter entity, port und is, aber auch Zeichenketten f¨
ur Namen, sowie Begrenzungszeichen, wie Semikolon und Klammern. Nach der Trennung
kommt die Datenstruktur WORD LIST zum Einsatz, in der die syntaktischen
Elemente wortweise gespeichert werden.
Auf dieser Datenstruktur erfolgt das eigentliche Parsen der Entity. Die Syntax, auf die der Parser aufbaut, stellt das Syntaxdiagramm in Abbildung
4.2 dar. Das Syntaxdiagramm gibt nicht die vollst¨andige Syntax f¨
ur eine
VHDL-Entity wieder. Es ist nur auf die in diesem Zusammenhang ben¨otigten
syntaktischen Konstrukte reduziert. Andere m¨ogliche Konstrukte wie Attribute werden durch den Parser ignoriert. Auch die Auswertung von Generics
vernachl¨assigt der Parser, da ihre Verwendung im SimulationsinterfaceblockGenerator bis jetzt noch nicht implementiert ist.
Der Parser stellt zun¨achst den Namen der Entity fest und speichert ihn in
der Datenstruktur ENTITY STRUCTURE. Anschließend baut er eine Liste der
gefundenen Ports und ihrer Parameter mit der Datenstruktur PORT LIST
auf. Wurden alle Ports analysiert, pr¨
uft die Funktion vhdl complete entity
die Liste der Ports auf Vollst¨andigkeit. Fehlen Informationen zu einem Port,
so erg¨anzt diese die Funktion. Die Namen der Ports k¨onnen durch die Umwandlung des Quelltextes in Kleinbuchstaben jedoch verf¨alscht sein. Um zu
gew¨ahrleisten, dass die Groß- und Kleinschreibung der Portnamen erhalten
bleibt, ersetzt die Funktion vhdl replace names nach dem Parsevorgang die
Namen in der Portliste durch ihre Originale aus der Quelldatei. Nach dem
Parsevorgang steht nun eine Liste der Ports der IP bereit, in der alle aus der
Entity gewonnenen Informationen gespeichert sind.
72
4 DER SIMULATIONSINTERFACEBLOCK-GENERATOR
Entity-Deklaration
:
Entity-Kopf
Entity-Kopf
:
entity
Entity-Körper
:
Entity-Ende
:
Generic-Deklaration
:
Entity-Körper
Entity-Ende
Component-Name
Generic-Deklaration
end
is
Port-Deklaration
Component-Name
generic
(
;
Generic-Konstante
)
;
;
Port-Deklaration
:
port
(
Port-Signal
)
;
;
Port-Signal
:
signal
Port-Name
:
Port-Richtung
Port-Typ
;
Port-Typ
:
std_logic
std_logic_
vector
Port-Richtung
:
(
PortLow
PortAusrichtung
Port-Ausrichtung
:
inout
to
downto
buffer
:
)
in
out
Component-Name
PortHigh
Port-Low
:
ganze Zahl
Port-High
:
ganze Zahl
Zeichenkette
Abbildung 4.2: Syntaxdiagramm einer VHDL-Entity nach dem der Parser
des Simulationsinterfaceblock-Generators arbeitet
An dieser Stelle ben¨otigt der Simulationsinterfaceblock-Generator noch ein
paar Informationen vom Benutzer. Er muss das Taktsignal sowie das asynchrone Resetsignal und deren aktive Signalflanken festlegen. Diese Informationen dienen sp¨ater dem Simulationsinterfaceblock zur Ausl¨osung des
Transportes der Simulationsdaten. Um die Kompatibilit¨at mit dem SystemCDesign zu gew¨ahrleisten, in das der Simulationsinterfaceblock eingebunden
werden soll, kann der Benutzer festlegen, ob Vektoren vorzeichenbehaftet sind
oder nicht. Der Wert des Zyklenz¨ahlers, die Adresse der parallelen Schnittstelle und ob die FPGA durch den Simulationsinterfaceblock-Generator konfiguriert werden soll, sind weitere vom Benutzer einzustellende Parameter.
Nach dem Sammeln aller ben¨otigten Informationen erfolgt eine Sortierung
4 DER SIMULATIONSINTERFACEBLOCK-GENERATOR
73
Analysierte und
berechnete Daten
Templates für
HW- und SW-Teil
Quelldateigenerierung
Quelldateien für
HW- und SW-Teil
SimIFB-Generator
Abbildung 4.3: Erzeugung der Quelldateien des Simulationsinterfaceblocks
aus Templates
der Portliste. Zuerst sortiert die Funktion sort portlist width die Ports absteigend nach ihrer Breite. Im Anschluss sortiert sort portlist direction sie nach
ihrer Richtung. Die Sortierung dient zur Vorbereitung f¨
ur das Signalmapping.
Das Signalmapping bildet die Ports mit Hilfe der Funktion map entity signals
auf interne Signale des Simulationsinterfaceblocks ab. Außerdem wird gepr¨
uft, ob die Abbildung zul¨assig ist, dass heißt, dass nicht mehr Signale
durch den Simulationsinterfaceblock transportiert werden m¨
ussen, als die
HW/SW-Schnittstelle zul¨asst. F¨
ur solch einen Fall bricht das Programm mit
einer Fehlermeldung ab.
War das Mapping erfolgreich, startet die Generierungsphase der Quelltexte. Die Generierung erfolgt aus Templates, was schematisch Abbildung 4.3
darstellt. Diese Templates enthalten bereits große St¨
ucken an Quellcode, da
viele Teile f¨
ur den Simulationsinterfaceblock immer gleich sind. Codest¨
ucke,
die speziell angepasst werden m¨
ussen, ersetzt im Template eine Marke. Diese
Marken werden w¨ahrend der Generierung durch einen aus den vorhandenen
Daten berechneten Wert oder ein anhand dieser Daten generiertes Codest¨
uck
ersetzt. Anschließend erfolgt die Speicherung des fertigen Quelltextes im Zielverzeichnis.
Die Generierungsphase besteht aus drei Teilabschnitten. Der erste Schritt
startet durch Aufruf der Funktion generate HWpart. Er erzeugt alle notwendigen VHDL-Quelldateien des Simulationsinterfaceblocks . Außerdem instanziiert er den Simulationsinterfaceblock und die VHDL-IP unter einem Toplevel, um diese sp¨ater gemeinsam zu synthetisieren. W¨ahrend der Bearbeitung
einer Quelldatei wird diese auch in eine Projektdatei eingetragen, die alle
Dateien zusammenfasst. Sie bildet die Informationsgrundlage f¨
ur die sp¨atere
Synthese. F¨
ur die Synthetisierung m¨
ussen auch alle in der IP instanziierten
Komponenten mit zu den VHDL-Quelldateien kopiert werden. Deshalb sucht
74
4 DER SIMULATIONSINTERFACEBLOCK-GENERATOR
die Funktion generate dut alle instanziierten Komponenten und sammelt sie
mit Hilfe der Datenstruktur FILELIST. Anschließend kopiert sie die Funktion
zu den anderen VHDL-Quellen und f¨
ugt sie zur Projektdatei hinzu. Die Voraussetzung, dass diese Funktion ihren Zweck erf¨
ullt, besteht darin, dass sich
die instanziierten Komponenten im gleichen Verzeichnis wie der Quelltext
der IP befinden und ihr Dateiname mit dem Namen ihrer Komponentendeklaration plus der Dateierweiterung .vhd u
¨bereinstimmt.
Nach der Erzeugung der VHDL-Quellen steht die Generierung von Skripten an. Diese Skripte bauen auf externen Programmen auf. Sie dienen der
¨
Synthese (xst), der Ubersetzung
(ngdbuild), dem Mapping (map), der Platzierung und Trassierung (par), der Bitstromgenerierung (bitgen), der FPGAKonfigurierung (impact) und der Timinganalyse (trce) der erzeugten VHDLQuellen. Die externen Programme sind in der Xilinx Entwicklungsumgebung
ISE [Xilb] enthalten. Da in dieser Arbeit nur Xilinx FPGAs zur Verf¨
ugung
standen, beschr¨ankt sich der Simulationsinterfaceblock-Generator auf die
Nutzung der Xilinx-Tools. Eine ausf¨
uhrliche Beschreibung der Tools ist in
[Xila] und [Xild] zu finden. Eine Erweiterung des Programms ist aber durchaus denkbar.
Nach der Generierung der Skripte erfolgt ihre Ausf¨
uhrung durch die Funktion
execute hwscripts. Am Ende der Skriptsphase analysiert die Funktion analyze timing das Logfile des Timinganalyseskriptes. Es sucht nach der gr¨oßten
Verz¨ogerungszeit und berechnet daraus die Werte f¨
ur die LDIV- und HDIVZ¨ahler. Dies dient dazu, dass die Emulation mit dem richtigen Takt ausgef¨
uhrt wird, damit die Emulationsergebnisse auch solang abgegriffen werden, bis an den Ausg¨angen der IP ein korrektes Ergebnis anliegt. Die LDIVund HDIV-Z¨ahler ben¨otigt die dritte Generierungsphase, um alle Quelldateien des Softwareteils erstellen zu k¨onnen.
Die dritte Generierungsphase erzeugt den Softwareteil, also die C/C++ Quellund Headerdateien des Simulationsinterfaceblocks . Sie startet durch Aufruf der Funktion generate SWpart. Der erste Schritt generiert das SystemCModul, welches die Schnittstelle des Simulationsinterfaceblocks zur SystemCSimulation bereitstellt. Dieses Modul tr¨agt den Namen der Entity der VHDLIP. Die Headerdatei bildet die Schnittstelle, die Quelldatei realisiert die Funktionalit¨at des PHSW . Beide Dateien werden komplett durch den Simulationsinterfaceblock-Generator erstellt und nicht aus Templates. Alle anderen
Dateien des Softwareteils generiert das Programm wiederum aus Templates.
W¨ahrend des Programmlaufs schreibt der Simulationsinterfaceblock-Generator Informationen f¨
ur den Benutzer zu den einzelnen Operationen sowie
4 DER SIMULATIONSINTERFACEBLOCK-GENERATOR
75
aufgetretene Fehler in ein Logfile. Nach den Generierungsphasen ist das Programm abgeschlossen und die erzeugten Daten k¨onnen verwendet werden.
Mehr Informationen zur Verwendung der Daten bietet der Abschnitt 4.3.
4.3
Benutzung des Programms
Dieser Abschnitt erkl¨art die Benutzung des SimulationsinterfaceblockGenerator . Er gibt Hinweise zum Aufbau des Programms und zu den einzelnen Phasen, die w¨ahrend der Ausf¨
uhrung durchschritten werden. Außerdem enth¨alt dieser Abschnitt Informationen zu den Nutzereingaben, die das
¨
Programm in den einzelnen Phasen erwartet. Am Ende wird ein Uberblick
u
¨ber die vom Programm erzeugten Daten gegeben.
4.3.1
Programmstart und -aufbau
Abbildung 4.4: Ansicht des Simulationsinterfaceblock-Generators nach dem
Programmstart
Das Programm Simulationsinterfaceblock-Generator startet durch den Aufruf der Datei simifb generator.exe. Es erscheint ein Fenster auf dem Bildschirm, das Abbildung 4.4 darstellt. Die linke Seite des Fensters zeigt durch
76
4 DER SIMULATIONSINTERFACEBLOCK-GENERATOR
Grafiken die aktuelle Bearbeitungsphase an. In der Mitte des Fensters liegt
der Bereich f¨
ur die Eingaben des Benutzers. In den einzelnen Feldern des
Nutzerbereichs existiert jeweils ein Hilfe -Button, um Informationen zu den
entsprechenden Eingabefeldern zu erhalten. Der rechte Teil enth¨alt ein Statusfeld, in dem Informationen vom Programm ausgegeben werden. Darunter
befinden sich die Button zum Starten der Generierung, zum Anzeigen des
Logfiles und zum Verlassen des Programms.
4.3.2
Die Analyse der Quelldatei
Die erste Eingabe, die der Nutzer durchzuf¨
uhren hat, ist die Auswahl der
VHDL-IP f¨
ur die ein Simulationsinterfaceblock erstellt werden soll. Dies erfolgt im Bereich Analyseparameter unter dem Punkt Quelldatei. Mit einem
Klick auf den oberen Durchsuchen. . . -Button ¨offnet sich ein Dialogfeld, in
dem die Datei ausgew¨ahlt werden kann. Das Feld neben dem Button zeigt
nach der Auswahl die Datei und ihr Verzeichnis an.
Die zweite Eingabe betrifft das Zielverzeichnis, in dem die generierten Dateien
gespeichert werden sollen. Der entsprechende Dialog kann u
¨ber den zweiten
Durchsuchen. . . -Button erreicht werden. Den Pfad stellt das nebenstehende
Textfeld nach der Auswahl dar.
Nach der Auswahl beider Parameter ist die Analysefunktion anw¨ahlbar (Abbildung 4.5). Durch Klicken des Button Analyse starten beginnt das Programm die VHDL-IP zu analysieren und ihre interne Datenstruktur aus der
Entity der VHDL-IP aufzubauen.
Abbildung 4.5: Ansicht des Feldes Analyseparameter
4 DER SIMULATIONSINTERFACEBLOCK-GENERATOR
4.3.3
77
Festlegung von Signalparametern
Es werden zwei weitere Felder nach Beendigung der Analyse sichtbar. Zum
Einen das Feld Auswahl des Taktsignals und zum Anderen das Feld Auswahl
des asynchronen Resetsignals. Abbildung 4.6 zeigt das Programm in diesem
Programmabschnitt.
Abbildung 4.6: Der Simulationsinterfaceblock-Generator nach der Analysephase
Die in diesem Abschnitt erschienenen Felder dienen zur Auswahl des Taktsignals und des asynchronen Resetsignals aus den Eing¨angen der VHDL-IP.
Auf Grund dieser Informationen erzeugt der Simulationsinterfaceblock-Generator die Sensitivit¨atsliste des SystemC-Moduls. Es existiert jeweils f¨
ur
Takt- und Resetsignal die Option, dass diese Signale in der VHDL-IP nicht
vorhanden sind. Zur Darstellung dieses Sachverhaltes kann der Listeneintrag
Kein Takt“ bzw. Kein asynchroner Reset“ ausgew¨ahlt werden. Ist ein Si”
”
gnal ausgew¨ahlt, so muss der Benutzer zus¨atzlich dessen aktive Taktflanke
festgelegen. Ein Klick auf den jeweiligen Ok -Button beendet die Eingabe
¨
der Signalparameter und l¨asst keine Anderung
an den Einstellungen mehr
zu. Abbildung 4.7 stellt eine detailierte Ansicht der Felder zur Auswahl des
Takt- und des asynchronen Resetsignals dar. Fehler bei der Eingabe zeigt
das Statusfeld an.
78
4 DER SIMULATIONSINTERFACEBLOCK-GENERATOR
Abbildung 4.7: Ansicht der Felder zur Einstellung der Signalparameter
4.3.4
Weitere Parameter
Nun ¨offnet sich das letze Feld mit Benutzereingaben (Abbildung 4.8). In
diesem Abschnitt k¨onnen einige zus¨atzliche Parameter eingestellt werden.
Auf der linken Seite des Feldes k¨onnen semantische Einstellungen zu den
Vektoren vorgenommen werden. Alle Signale, die als Vektor in der Entity
der VHDL-IP eingetragen sind, k¨onnen n¨aher spezifiziert werden. Der Nutzer kann die Auswahl treffen, ob der Vektor mit einem Vorzeichen behaftet
Abbildung 4.8: Der Simulationsinterfaceblock-Generator nach der Einstellung der Signalparameter
4 DER SIMULATIONSINTERFACEBLOCK-GENERATOR
79
Abbildung 4.9: Detailierte Ansicht des Feldes zur Einstellung der Vektorsemantik und von zus¨atzlichen Parametern
sein soll oder nicht. Dies erleichtert die sp¨atere Integration des generierten
SystemC-Moduls in das SystemC-Design.
Rechts neben der Einstellung der Vektorsemantik befindet sich als erstes die
Angabe der Taktzyklenanzahl, die die IP-Emulation in einem SystemC-Simulationstakt durchl¨auft. Voreingestellt ist der Wert 1. Der maximal m¨ogliche
Wert betr¨agt 65 536. Dieser Parameter kann dazu genutzt werden, um den
Emulationstakt auf ein vielfaches des SystemC-Designtaktes einzustellen.
Im zweiten Parameterfeld ist die Auswahl der Adresse der parallelen Schnittstelle m¨oglich. Zul¨assige Werte sind die Standardadressen 278h, 378h und
3BCh der Schnittstelle. Diese Adresse muss f¨
ur den PC eingestellt werden, auf
dem die SystemC-Simulation ablaufen wird. Es besteht jedoch die M¨oglichkeit, diesen Parameter nach der Generierung von Hand zu ¨andern. Die Erkl¨arung folgt im Abschnitt 4.3.6.
Die Checkbox legt fest, ob die FPGA nach der Generierungsphase sofort
konfiguriert werden soll, oder ob der Benutzer dies sp¨ater selbst durchf¨
uhren
m¨ochte. Um die sp¨atere Konfigurierung der FPGA einfacher zu gestalten,
wird das Skript zur Konfiguration do program.bat immer erstellt und kann
vom Benutzer dazu verwendet werden.
Eine Hilfestellung zu den Parametern kann u
¨ber den Button Hilfe abgerufen
werden. Abbildung 4.9 zeigt das Feld mit eingestellten Parametern.
80
4 DER SIMULATIONSINTERFACEBLOCK-GENERATOR
4.3.5
Die Generierung
Der Button Generierung des SimulationsIFB starten l¨ost die Erstellung des
Simulationsinterfaceblocks aus. Als Erstes erfolgt die Generierung der Quelldateien des Hardwareteils (Abbildung 4.10). In diesem Schritt werden alle
VHDL-Quelldateien erzeugt, die zur Synthese des Hardwareteils des Interfaceblocks und der Emulation der IP notwendig sind. Darunter fallen alle
Dateien im Ausgabeverzeichnis Hardware/Src sowei die Projektdatei f¨
ur die
sp¨atere Synthese.
Abbildung 4.10: Der Simulationsinterfaceblock-Generator bei der Generierung des Hardwareteils
¨
Anschließend erstellt das Programm die Skripte f¨
ur die Synthese, das Ubersetzen, das Mapping, die Platzierung und Trassierung, die Generierung des
Bitstroms und die Konfiguration des FPGAs. Diese Phase stellt Abbildung
4.11 dar. Die Ausf¨
uhrung der Skripte schließt sich an die Generierung an.
Zur erfolgreichen Ausf¨
uhrung der Skripte ist es notwendig, dass die Entwicklungsumgebung Xilinx ISE auf dem Rechner installiert ist, der den Simulationsinterfaceblock-Generator ausf¨
uhrt. Im derzeitigen Zustand unterst¨
utzt
der Simulationsinterfaceblock-Generator zur Ausf¨
uhrung der Emulation nur
das Digilab 2E Development Board [Dig02] mit der darauf befindlichen Xilinx
Spartan2E FPGA. Zur Unterst¨
utzung anderer FPGAs und Synthesewerkzeuge kann der Simulationsinterfaceblock-Generator sp¨ater erweitert werden.
4 DER SIMULATIONSINTERFACEBLOCK-GENERATOR
81
Abbildung 4.11: Der Simulationsinterfaceblock-Generator bei der Generierung der Skripte
Die Generierung des Softwareteils des Simulationsinterfaceblocks schließt sich
an die Skriptausf¨
uhrung an (Abbildung 4.12). Sie baut teilweise auf die Synthese des Hardwareteils, speziell auf die Timinganalyse, auf. In dieser Phase
erstellt der Simulationsinterfaceblock-Generator das SystemC-Modul aus den
analysierten Daten der Entity der VHDL-IP und den Eingaben des Nutzers.
Das SystemC-Modul tr¨agt den Namen der Entity der VHDL-IP. Zu diesem
Modul geh¨oren noch weitere Bibliotheken, die aus Templates erstellt werden.
In den Templates tr¨agt der Simulationsinterfaceblock-Generator nur einige
Parameter, wie zum Beispiel die Gr¨oße der Simulationsdaten, ein. Nach dem
fehlerfreien Abschluss der Generierung ist der Programmlauf beendet.
Das Statusfenster zeigt an, ob Fehler bei den einzelnen Schritten aufgetreten sind. Dies kann der Fall sein, wenn das Programm die Templates nicht
fand oder die Ausf¨
uhrung der Skripte fehlschlug. Im letzeren Fall muss der
Benutzer sicherstellen, dass das Verzeichnis mit den Xilinxtools in der Pfadumgebung des Betriebssystems vorhanden und die Xilinx Umgebungsvariable
gesetzt ist. Tritt trotzdem ein Fehler bei der Synthese auf, so sollte die VHDLDatei der IP auf m¨ogliche syntaktische Fehler u
uft werden. Dar¨
uber, in
¨berpr¨
welchem Abschnitt der Synthese der Fehler auftrat, geben die Logdateien des
Syntheseprozesses Auskunft.
82
4 DER SIMULATIONSINTERFACEBLOCK-GENERATOR
Abbildung 4.12: Der Simulationsinterfaceblock-Generator bei der Generierung des Softwareteils
4.3.6
¨
Uberblick
u
¨ ber die generierten Dateien
¨
Dieser Abschnitt soll einen Uberblick
u
¨ber die generierten Daten des Simulationsinterfaceblock-Generators geben. Die Verzeichnisstrukur stellt Abbildung 4.13 dar. Im Zielverzeichnis befinden sich zun¨achst die Unterverzeichnisse Hardware und Software sowie zwei Dateien. Die Datei simifb-gen.log ist
das Logfile des Simulationsinterfaceblock-Generators und enth¨alt die Statusausgaben und Fehlermeldungen, die w¨ahrend des Programmlaufs auftraten.
Es kann auch u
¨ber den Button Logfile anzeigen aus dem Programm heraus eingesehen werden. Die ausf¨
uhrbare Datei exec scripts.bat erm¨oglicht es,
den Implementierungsvorgang des Hardwareteils zu wiederholen, da sie alle
ausgef¨
uhrten Skripte aufruft.
Im Verzeichnis Hardware befinden sich alle Dateien, die zur Erstellung des
Hardwareteils des Simulationsinterfaceblocks notwendig sind. Die Aufgaben
der darin enthaltenen Dateien f¨
uhrt Tabelle 4.10 auf. Neben den Dateien
verf¨
ugt das Verzeichnis u
¨ber Unterverzeichnisse. Sie dienen der geordneten
Speicherung der Implementierungsdaten des Hardwareteils des Simulationsinterfaceblocks.
4 DER SIMULATIONSINTERFACEBLOCK-GENERATOR
83
¨
Abbildung 4.13: Uberblick
u
¨ber die Verzeichnisstruktur der generierten Daten
Im Folgenden sind die Unterverzeichnisse und eine kurze Beschreibung der
enthaltenen Daten aufgef¨
uhrt:
Bit: Verzeichnis mit den Ausgaben der Bitfile-Generierung. Die Datei mit
der Endung bit dient zur Konfiguration des FPGA.
Log: Dieses Verzeichnis enth¨alt die Statusausgaben der ausgef¨
uhrten Skripte. Dabei steht der erste Teil des Dateinamen f¨
ur die ausgef¨
uhrte Datei
(z.B. xst.log f¨
ur die Synthese mit xst.exe).
Map: Verzeichnis, dass die Daten aus dem Technologiemapping des Designs
enth¨alt.
Ngdbuild: In diesem Verzeichnis befinden sich die Dateien, die durch die
¨
Ubersetzung
des Syntheseergebnisses erstellt wurden.
Par: Die Ergebnisse der Platzierung und Trassierung enth¨alt dieses Verzeichnis.
Src: Die VHDL-Quelldateien des Hardwareteils, die vom Simulationsinterfaceblock-Generator erstellt wurden, speichert dieses Verzeichnis.
Trce: Dieses Verzeichnis sammelt die Ausgabedaten der Timinganalyse.
Xst: Die, durch die Synthese erstellten Daten, fasst das Verzeichnis xst zusammen.
84
4 DER SIMULATIONSINTERFACEBLOCK-GENERATOR
Dateiname
sim environment hw.prj
make.bat
do xst.bat
xst script
do ngdbuild.bat
do map.bat
do par.bat
do bitgen.bat
do program.bat
program script.cmd
do trce.bat
Aufgabe
Projektdatei f¨
ur die Synthese
Skript zur Ausf¨
uhrung aller Implementierungsskripte
Skript zum Starten der Synthese
Hilfsdatei mit Parametern f¨
ur die Synthese
¨
Skript zum Ausf¨
uhren des Ubersetzungsvorgangs
Skript f¨
ur das Mapping des Desings
Skript zum Ausf¨
uhren der Platzierung und Trassierung
Skript zur Erstellung der Konfigurationsdatei f¨
ur das
FPGA
Skript zum Starten der FPGA-Konfiguration durch das
Programm Impact
Hilfsskript f¨
ur Impact
Skript zum Durchf¨
uhren der Timinganalyse
¨
Tabelle 4.10: Uberblick
zu den Dateien im Verzeichnis Hardware
Das Verzeichnis Software enth¨alt alle Quelldateien, die f¨
ur die Einbindung
des Simulationsinterfaceblocks in eine SystemC-Simulation n¨otig sind. Das
SystemC-Modul, welches die Schnittstelle zur SystemC-Simulation bildet,
tr¨agt den Namen der Entity der VHDL-IP und die Dateiendung .h. Darin ist
die Schnittstelle definiert. Die Funktionalit¨at stellt die gleichnamige Datei
mit der Endung .cpp bereit. Alle anderen Dateien im Verzeichnis Software enthalten Funktionen, die von diesen Dateien genutzt werden. Dabei ist
besonders die Datei CUsw.h zu erw¨ahnen. Sie definiert alle wichtigen Parameter f¨
ur den Softwareteil des Simulationsinterfaceblocks . Dazu z¨ahlen die
Adresse der parallelen Schnittstelle, die Gr¨oße der Simulationsdaten, sowie
die Adressen der Kontroll- und Statusregister des Hardwareteils des Simulationsinterfaceblocks .
Die Einbindung der Dateien des Softwareteils in ein bestehendes Design sollte aus dem generierten Verzeichnis erfolgen. Dazu muss beim Aufruf des
C/C++-Compilers das Softwareverzeichnis als zus¨atzlicher Pfad f¨
ur Includedateien angegeben werden. F¨
ur den Linker ist als Bibliothek die Datei dlportio.lib sowie das Softwareverzeichnis als weiteres Bibliotheksverzeichnis mit
anzugeben. Das hat den Vorteil, dass die Ausgaben des Simulationsinterfaceblock-Generators in einem Verzeichnis gesammelt bleiben. Dies verringert die
Gefahr, dass ein Hardwareteil auf das FPGA geladen wird, der nicht zum benutzen Softwareteil geh¨ort und dadurch falsche Simulationsergebnisse erzielt
werden.
4 DER SIMULATIONSINTERFACEBLOCK-GENERATOR
4.4
85
Verbesserungsmo
¨glichkeiten und
Fazit
Um die Einsatzm¨oglichkeiten des Simulationsinterfaceblock-Generators zu
verbessern, sind einige Erweiterungen im Programm denkbar. In der gegenw¨artigen Version verarbeitet der Simulationsinterfaceblock-Generator nur
Ports von VHDL-Entities mit den Richtungen in oder out. Zur Unterst¨
utzung
einer gr¨oßeren Anzahl von VHDL-IPs k¨onnte das Programm f¨
ur die Verarbeitung von bidirektionalen Ports (Richtung inout) erweitert werden. Mit der
Analysem¨oglichkeit von VHDL-Generics wird das Konzept von generischen
Portbreiten umgesetzt. Damit ist auch eine Unterst¨
utzung von parametrisierbaren IPs denkbar.
Die Menge der unterst¨
utzen IPs kann weiter steigen, indem Mechanismen
in das Programm eingebaut werden, die andere Hardwarebeschreibungssprachen, wie zum Beispiel Verilog, analysieren k¨onnen. Somit wird eine Adaptierung von IPs in verschiedenen Hardwarebeschreibungssprachen erreicht und
das Programm gewinnt an Flexibilit¨at.
Die vorliegenden Version des Simulationsinterfaceblock-Generators schr¨ankt
die hardwareseitige Implementierungsplattform noch auf das Digilab 2E Developmentboard ein. Um diese Restriktion aufzuheben, muss das Programm
f¨
ur die Unterst¨
utzung anderer FPGA-Typen und -Boards erweitert werden.
Damit einher geht die Nutzung von unterschiedlichen Entwicklungsumgebungen und Tools zur Synthese und Implementierung. Da andere FPGABoards auch andere phyische Schnittstellen besitzen k¨onnen, ist zudem eine
¨
Unterst¨
utzung anderer physischer HW/SW-Schnittstellen zur Uberwindung
der HW/SW-Grenze denkbar.
Der Simulationsinterfaceblock-Generator wurde entwickelt, um eine VHDLIP mittels eines Simulationsinterfaceblocks an eine SystemC-Simulation automatisch zu koppeln. Das Programm nimmt dem Nutzer die manuelle Adaptierung der IP-Emlation an die SystemC-Verhaltenssimulation ab, indem
es automatisch eine HW/SW-Schnittstelle zwischen beiden Tasks erzeugt.
Dadurch sinkt die Zahl der m¨oglichen Fehler, die bei einer manuellen Adaptierung auftreten k¨onnen und der Zeitaufwand f¨
ur die Adaptierung verringert
sich stark. Das Programm implementiert die Grundfunktionalit¨at der Adaptierung und zeigt, dass eine automatische L¨osung praktikabel ist.
86
4 DER SIMULATIONSINTERFACEBLOCK-GENERATOR
5 DEMONSTRATOR
5
87
Demonstrator
Diese Kapitel besch¨aftigt sich mit dem Demonstrator zu den in dieser Arbeit
gewonnenen Erkenntnissen. Im ersten Teil dieses Kapitels wird der allgemeine
Nutzen eines Demonstrators herausgestellt. Der zweite Abschnitt besch¨aftigt
sich mit dem Aufbau und der Funktionsweise des verwendeten Demonstrators. Anschließend erfolgt die Vorstellung der Ergebnisse, die mit seiner Hilfe
gewonnen wurden. Es folgen einige Betrachtungen zur Simulationszeit des
originalen SystemC-Designs und des modifizierten Designs mit der HW/SWSchnittstelle. Das Ende des Kapitels fasst die Ergebnisse zusammen und zieht
daraus Schlussfolgerungen.
5.1
Bedeutung eines Demonstrators
Ein Demonstrator dient dazu, die erarbeiteten theoretischen Konzepte im
praktischen Einsatz zu erproben und zu validieren. Mit seiner Hilfe k¨onnen
Schwachstellen und Fehler im theoretischen Modell aufgedeckt und korrigiert
werden. Außerdem kann die Praxisrelevanz der Konzepte gezeigt werden.
Liegt nur ein theoretisches Modell vor, so besteht die M¨oglichkeit, dass es sich
nicht oder nur schwer in die Praxis umsetzen l¨asst. Unter Umst¨anden bildet
dies eine H¨
urde f¨
ur einen praktischen Einsatz des Modells. Auf der anderen
Seite kann eine rein praktische Implementierung eventuell nicht allgemein
modelliert werden und bleibt damit auf eine spezielle Anwendung beschr¨ankt.
5.2
Aufbau und Funktionsweise
Zur Demonstration des Konzeptes der HW/SW-Schnittstelle und des, im
Rahmen dieser Arbeit, erstellten Programms Simulationsinterfaceblock-Generator sollte ein Beispiel gew¨ahlt werden, welches die praktische Relevanz
der Ergebnisse dieser Arbeit wiederspiegelt. Aus diesem Grund soll nach
M¨oglichkeit auf ein bereits bestehendes Design zur¨
uckgegriffen werden und
keine reine Selbstentwicklung Verwendung finden.
Als Grundlage des Demonstrators dient ein SystemC-Design aus den Beispielen zur SystemC-Version 2.0.1. Diese Version ist auf der SystemC-Website
88
5 DEMONSTRATOR
Fetch
Decode
Integer
Execution
Floatingpoint
Execution
Instruction-Cache
Data-Cache
MMXlike
Execution
Abbildung 5.1: Aufbau des Designs RISC-CPU
[Opea] frei verf¨
ugbar. Das Beispiel beschreibt ein einfaches Design einer
r
RISC-CPU in SystemC. Es wurde von Synopsys
[Syn] entwickelt, um die
F¨ahigkeiten von SystemC bei der HW/SW-Partitionierung zu veranschaulichen. Außerdem kann es als Instruction-set Simulator eingesetzt werden.
Das Design findet sich nach dem Entpacken des heruntergeladenen SystemCPaketes im Verzeichnis /systemc-2.0.1/examples/systemc/risc cpu. Es beinhaltet zus¨atzlich Programme f¨
ur die CPU zum Testen der Funktionalit¨at.
Ein Assembler ist außerdem beigef¨
ugt, um selbst Programme zu entwickeln.
Den Aufbau der beschriebenen RISC-CPU stellt Abbildung 5.1 dar. Das Design der RISC-CPU setzt sich zusammen aus einem Instructioncache, einem
Datencache, einer Fetcheinheit, die die Instruktionen aus dem Instructioncache liest, einer Decodiereinheit zum Umwandeln der Instruktionen in CPUOperationen und jeweils einer Ausf¨
uhrungseinheit f¨
ur Ganzzahlen, Fließkommazahlen und MMX-Berechnungen. Im Folgenden wird dieses SystemCDesign der RISC-CPU als originale RISC-CPU bezeichnet.
Im vorliegenden Szenario (Abbildung 5.2) soll die Ausf¨
uhrungseinheit f¨
ur
ganze Zahlen durch eine VHDL-IP ersetzt werden, die die gleiche Funktionalit¨at bereitstellt. Die anderen Teile des SystemC-Designs, das heißt die
Beschreibung des Prozessors und das verwendete Testprogramm bleiben unver¨andert. Dieses Design wird im Folgenden als modifizierte RISC-CPU bezeichnet. Die VHDL-IP dient als Eingabe f¨
ur das Programm Simulationsinterfaceblock-Generator. Er generiert daraus die Hardware- und die Softwareseite des Simulationsinterfaceblocks und die Emulation f¨
ur diese VHDL-IP.
Die genaue Funktionsweise der Generierung beschreibt Kapitel 4. Die Implementierung von Hardware-Simulationsinterfaceblock und IP-Emulation dient
zur Konfiguration eines Digilab 2E Development Boards. Der Softwareteil
5 DEMONSTRATOR
Opcode
0000
0001
0010
0011
0100
0101
0110
0111
1000
1001
1010
1011
1100
1101
1110
1111
89
Funktion
Verarbeitungsbreite
a + b + carry
32 Bit
a - b - carry
32 Bit
a+b
32 Bit
a-b
32 Bit
a*b
32 Bit
a/b
16 Bit
a nand b
32 Bit
a and b
32 Bit
a or b
32 Bit
a xor b
32 Bit
not a
32 Bit
a << b
32 Bit
a >> b
32 Bit
a mod b
16 Bit
-
Tabelle 5.1: Funktionen der entwickelten Integer-Executionunit
wird anstelle der Integer-Executionunit in das SystemC-Design eingebunden. Ein C++-Compiler erstellt daraus das Simulationsprogramm, welches
ein PC, der u
¨ber die parallele Schnittstelle mit dem FPGA-Board verbunden
ist, ausf¨
uhrt.
Das Design der VHDL-IP wurde im Rahmen dieser Arbeit selbst entworfen. Es bildet alle Funktionen nach, die auch die SystemC-Beschreibung der
Einheit enth¨alt. Sie sind in Tabelle 5.1 aufgef¨
uhrt. Nur der Dividierer unterliegt einer Einschr¨ankung in der Verarbeitungsbreite. Dieser Kompromiss
musste getroffen werden, da die verwendete Emulationsplattform, das Digilab
2E Developmentboard, nur u
¨ber eine Xilinx Spartan2e FPGA (XC2S200EPQ208) verf¨
ugt. Ihre Kapazit¨at reicht nicht aus, um die Ausf¨
uhrungseinheit
mit einem 32 Bit Paralleldividierer zu emulieren. Deshalb wurde die Verarbeitungsbreite der Division und der damit verbundenen Modulo-Brechnung
auf 16 Bit gesenkt.
Diese Einschr¨ankung stellt f¨
ur den vorliegenden Demonstrator jedoch kein
Hindernis dar, da im Testprogramm keine Division ausgef¨
uhrt wird, die eine h¨ohere Verarbeitungsbreite als 16 Bit beansprucht. Außerdem dient der
Demonstrator dem Zweck, die Einsatzf¨ahigkeit und korrekte Funktion des
90
5 DEMONSTRATOR
VHDL-IP
Integer
Execution-Unit
Fetch
SimIFBGenerator
SimIFBSW
Decode
Floatingpoint
Execution
InstructionCache
Data-Cache
MMXlike
Execution
Testprogramm
SimIFBHW &
IP-Emulation
C/C++ Compiler
parallele
Schnittstelle
PC
Abbildung 5.2: Aufbau des Demonstrators
Konzeptes des Simulationsinterfaceblocks und des SimulationsinterfaceblockGenerators nachzuweisen und nicht die der VHDL-IP. Im Fall des Simulationsinterfaceblocks bedeutet es den korrekten Austausch der Daten u
¨ber die
HW/SW-Schnittstelle und die erfolgreiche Kopplung der SystemC-Simulation
mit der IP-Emulation. F¨
ur den Simulationsinterfaceblock-Generator heißt
korrekte Funktion, dass der Simulationsinterfaceblock in Abh¨angigkeit von
der VHDL-IP so erstellt wird, dass er seine Aufgabe erfolgreich erf¨
ullen kann.
5.3
Nachweis der Funktion
Um den Nachweis zu erbringen, dass der Simulationsinterfaceblock seine Aufgabe erf¨
ullt, sollen die Simulationsergebnisse der originalen und der modifizierten RISC-CPU miteinander verglichen werden. Dazu ist zun¨achst die Erstellung der Simulation der originalen RISC-CPU erforderlich. Dies geschieht
einfach durch das Kompilieren und Linken der einzelnen SystemC-Module.
¨
Als Ubersetzungsund Linkprogramm kommt Microsoft Visual C++ 6.0
5 DEMONSTRATOR
sc_in<bool>
sc_in<bool>
sc_in<int>
sc_in<bool>
sc_in<int>
sc_in<bool>
sc_in<signed int>
sc_in<signed int>
sc_in<bool>
sc_in<bool>
sc_in<unsigned>
sc_out<bool>
sc_out<bool>
sc_out<bool>
sc_out<signed int>
sc_out<bool>
sc_out<unsigned>
sc_in_clk
91
reset;
in_valid;
opcode;
negate;
add1;
shift_sel;
dina;
dinb;
forward_A;
forward_B;
dest;
C;
V;
Z;
dout;
out_valid;
destout;
CLK;
Abbildung 5.3: Schnittstellendefinition der originalen Integer-Executionunit.
Der Datentyp bool gibt einfache Signale an. Int, signed int und unsigned
geben Vektoren an.
zum Einsatz. Hinweise zur Nutzung von SystemC in dieser Entwicklungsumgebung beschreibt Anhang B.
Die Erstellung der modifizierten RISC-CPU l¨auft nach Abbildung 5.2 ab.
Zun¨achst wird das Programm Simulationsinterfaceblock-Generator gestartet. Ihm dient als Eingabe die VHDL-IP der Integer-Executionunit. Das
Programm analysiert sie. Anschließend erfolgt die Festlegung der Signalparameter. Das Taktsignal clk und das asynchrone Resetsignal rst sind dabei
high-aktiv. Die Datentypen der Vektoren werden entsprechend den Datentypen der originalen Ausf¨
uhrungseinheit (Abbildung 5.3) festgelegt. Abbildung
5.4 zeigt die Einstellungen im Programm. Die Generierung des Simulationsinterfaceblocks f¨
ur die VHDL-IP der Integer-Executionunit stellt den letzen
Schritt der Programmausf¨
uhrung dar.
Der Hardwareteil des Simulationsinterfaceblocks und die Implementierung
der VHDL-IP befinden sich nun auf dem FPGA-Board. Sie sind bereit f¨
ur die
Ausf¨
uhrung. Um die Simulation der originalen und der modifizierten RISCCPU besser vergleichen zu k¨onnen, wird im Softwareteil des Simulationsinterfaceblocks Quellcode, zur Ausgabe der Simulationsdaten auf dem Bild-
92
5 DEMONSTRATOR
Abbildung 5.4: Festlegung der Datentypen im Simulationsinterfaceblock-Generator
schirm, manuell hinzugef¨
ugt. Dies erfolgt in der generierten Datei exec.cpp.
Als Quelle dient hier die Datei exec.cpp der originalen RISC-CPU. Die anderen generierten Dateien bleiben unver¨andert.
Aus dem Design der originalen RISC-CPU wird die Integer-Executionunit
¨
entfernt und durch das generierte Modul ersetzt. Zur Ubersetzung
des Gesamtdesigns muss noch die Datei dlportio.lib zu den verwendeten Bibliotheken hinzugef¨
ugt werden. Außerdem ist als zus¨atzlicher Includepfad das Verzeichnis mit den generierten Quelldateien einzutragen. Nach der Durchf¨
uhrung
¨
dieser Schritte erfolgt das Ubersetzen
und Linken der modifizierten RISCCPU. Auch hierbei kommt Microsoft Visual C++ 6.0 zum Einsatz.
Die Ausf¨
uhrung der Simulationen erzeugt deren Simulationsergebnisse, die
auf dem Bildschirm ausgegeben werden. Die Ergebnisse sind in Anhang C
auszugsweise gegen¨
ubergestellt. Ihre Gegen¨
uberstellung zeigt, dass die Simulation der originalen und die der modifizierten RISC-CPU zu gleichen
Simulationszeiten die gleichen Eingabe- und Ausgabedaten besitzen. Damit
ist nachgewiesen, dass das Verhalten der beiden Designs u
¨bereinstimmt.
Nachdem sichergestellt ist, dass beide Designs u
¨ber das gleiche Verhalten
verf¨
ugen, soll der Nachweis erfolgen, dass der Simulationsinterfaceblock seine
Aufgaben korrekt erf¨
ullt. Seine Aufgaben lauten nach Abschnitt 3.1.1 wie
folgt:
1. zwei Komponenten kommunizieren lassen, ohne dass an den Kompo¨
nenten Anderungen
durchgef¨
uhrt werden m¨
ussen.
2. den bidirektionalen Datentransport zwischen den Komponenten sicherstellen.
5 DEMONSTRATOR
93
3. die HW/SW-Grenze intern u
¨berwinden.
4. die M¨oglichkeit bieten, Daten intern zu transformieren.
5. die Integration einer Steuerung erlauben.
Am Demonstrator wurde gezeigt, dass die Simulationsdaten erfolgreich zwischen der SystemC-Simulation und der IP-Emulation in beide Richtungen
ausgetauscht werden. Das zeigt, dass der Datentransport bidirektional u
¨ber
die HW/SW-Grenze m¨oglich ist. Somit sind die Aufgaben 2 und 3 erf¨
ullt. Da
die Simulationsdaten f¨
ur den Transport durch den Simulationsinterfaceblock
intern umgewandelt werden und der Transport erfolgreich verl¨auft, ist auch
die korrekte Erf¨
ullung der 4. Aufgabe nachgewiesen. Die interne Steuerung,
die Aufgabe 5 als Inhalt hat, arbeitet nach der Spezifikation, da sie den Datenaustausch steuert und dieser erfolgreich verl¨auft. Zum Nachweis der 1.
Aufgabe m¨
ussen die kommunizierenden Tasks n¨aher betrachtet werden. Das
SystemC-Design bliebt, bis auf die Ersetzung der Integer-Executionunit, unver¨andert. Auch an der VHDL-Beschreibung der IP erfolgten keine Ver¨anderungen. Da beide Komponenten durch den Simulationsinterfaceblock erfolgreich miteinander kommunizieren, gilt auch die 1. Aufgabe als erf¨
ullt.
Den Simulationsinterfaceblock erzeugte der Simulationsinterfaceblock-Generator. Der Nachweis, dass der Simulationsinterfaceblock die ihm gestellten
Aufgaben erfolgreich verrichtet, zeigt somit, dass er korrekt generiert wurde.
Die Aufgabe, die die automatische Adaptierung der IP-Emulation auf dem
FPGA mit der SystemC-Verhaltenssimulation durch einen Simulationsinterfaceblock beinhaltet, erf¨
ullt der Simulationsinterfaceblock-Generator somit
korrekt.
5.4
Betrachtungen zur Simulationszeit
Bei der Simulation spielt die ben¨otigte Zeit eine große Rolle. Deshalb soll an
dieser Stelle die Simulationszeit der originalen und der modifizierten RISCCPU betrachtet werden.
Zu erwarten ist, dass die Zeit, welche die Simulation der modifizierten RISCCPU beansprucht, gr¨oßer ist, als die Simulationszeit der originalen RISCCPU. Die Vermutung begr¨
undet sich darauf, dass bei der Simulation der
modifizierten RISC-CPU zus¨atzlich Zeit f¨
ur die Kommunikation zwischen
94
5 DEMONSTRATOR
SystemC-Simulation und IP-Emulation, sowie f¨
ur die interne Kommunikation
des Simulationsinterfaceblocks aufgewendet werden muss.
Daraus folgt, dass die Geschwindigkeit der physischen HW/SW-Schnittstelle
einen wesentlichen Faktor f¨
ur die Simulationszeit darstellt. Die Untersuchung
ihrer Geschwindigkeit stellt sich deshalb als erste Aufgabe (Abschnitt 5.4.1).
Anschließend wird die Simulationszeit, unter Ber¨
ucksichtigung der gewonnenen Erkenntnisse zur HW/SW-Schnittstelle, betrachtet.
5.4.1
Geschwindigkeit der parallelen Schnittstelle
¨
F¨
ur die Messung der Ubertragungsgeschwindigkeit
der parallelen Schnittstelle mit dem EPP-Protokoll wurde im Rahmen dieser Arbeit eine Messeinrichtung entwickelt. Sie setzt sich aus dem Softwareprogramm Speedtest sw
und dem VHDL-Design f¨
ur das Digilab 2E Developmentboard Speedtest hw
zusammen. Beide Teile sind auf der beiliegenden CD-ROM zu finden (siehe
Anhang D).
Das Programm Speedtest sw hat die Aufgabe, fortlaufend Daten u
¨ber die
parallele Schnittstelle zu schreiben oder zu lesen. F¨
ur den Programmaufruf
m¨
ussen zwei Parameter angegeben werden. Zu Einem der Arbeitsmodus und
zum Anderen die Adresse der parallelen Schnittstelle im PC. Das Programm
besitzt sechs verschiedene Modi, die jeweils eine andere Form der Daten¨
ubertragung durch das EPP-Protokoll ausf¨
uhren. Ihre Funktionen sind in Tabelle
5.2 aufgef¨
uhrt. Die Modi 5 und 6 realisieren ein abwechselndes Schreiben
Modus
m1
m2
m3
m4
m5
m6
Funktion
Datenbyte schreiben
Adressbyte schreiben
Datenbyte lesen
Adressbyte lesen
Adressbyte schreiben, Datenbyte schreiben
Adressbyte schreiben, Datenbyte lesen
¨
Tabelle 5.2: Die Modi der Software zur Messung der Ubertragungsgeschwindigkeit der parallelen Schnittstelle im EPP-Modus
5 DEMONSTRATOR
95
Addr
Data
Daten
Handshake
EPP
FSM
Wertegenerator
Addr
Data
M
U
X
Start
32 Bit Bytezähler
Ansteuerlogik
Stopuhr
Abbildung 5.5: Aufbau der Hardware zur Geschwindigkeitsmessung
eines Adressbytes und Schreiben bzw. Lesen eines Datenbytes. Diese Formen der Daten¨
ubertragung sind f¨
ur den Simulationsinterfaceblock besonders
wichtig, da bei ihm jedem Datenbyte auch eine Adresse zugeordnet ist.
¨
Den Aufbau des Hardwareteils zeigt Abbildung 5.5. Zur Messung der Ubertragungsgeschwindigkeit des EPP-Protokolls dienen ein 32 Bit-Z¨ahler und eine Stopuhr. Beide werden u
¨ber ein gemeinsames Startsignal aktiviert. Der
¨
Bytez¨ahler reagiert auf das Signal nWait des EPP-Protokolls. In jedem Ubertragungszyklus ¨andert das Signal zweimal seinen Wert, einmal von high zu
¨
low und einmal umgekehrt. In jedem Ubertragunszyklus
wird dabei genau
ein Byte u
¨bertragen. Die Stopuhr beginnt die Zeitmessung, sobald der Bytez¨ahler einen Wert ungleich Null annimmt. Sie kann bis zu 1 000 Sekunden
z¨ahlen. Ihre Genauigkeit h¨angt von der eingesetzten Taktfrequenz ab. Im
vorliegenden Fall liegt eine Taktung mit 50 Mhz vor. Daraus ergibt sich eine
maximale Genauigkeit von 20 ns.
Zur Ausgabe der Daten dient eine 7-Segmentanzeige. Die Auswahl der Daten
u
¨bernimmt ein Multiplexer. Es k¨onnen die ausgehenden sowie die eingehenden Adressen und Daten angezeigt werden. Jedoch f¨allt ihnen f¨
ur die Messung
keine Bedeutung zu. Die wichtigen Daten bilden die Anzahl der u
¨bertragenen Bytes und die daf¨
ur ben¨otigte Zeit. Auch sie k¨onnen auf der Anzeige
ausgegeben werden. Das Ausgabeformat ist hexadezimal.
Die Messungen der Geschwindigkeit erfolgen f¨
ur die Modi 5 und 6. Modus
5 schreibt abwechselnd ein Adressbyte und ein Datenbyte auf die parallele
96
5 DEMONSTRATOR
Modus
m5
m6
u
¨bertragene Byte
18 860 504
18 892 543
18 976 578
19 450 840
19 517 029
19 529 100
s
ms
µs
ns
Byte/s
Durchschnittsgeschwindigkeit
30
30
30
30
30
30
543
530
660
323
355
454
789
303
073
718
897
054
500
600
340
040
920
240
617 460
618 813 618 404 Byte/s
618 940
641 440
642 940 641 881 Byte/s
641 264
Tabelle 5.3: Ermittelte Geschwindigkeiten der parallelen Schnittstelle
Schnittstelle. Er nutzt dazu die Funktion Write EPP, die auch f¨
ur die Daten¨
ubertragung im Simulationsinterfaceblock zum Einsatz kommt. Modus 6
schreibt ein Adressbyte und liest ein Datenbyte. Er verwendet die Funktion
Read EPP. Tabelle 5.3 stellt die Ergebnisse der Messungen dar.
¨
Die Ubertragungsgeschwindigkeit,
die f¨
ur die parallelen Schnittstelle mit dem
EPP-Protokoll angegeben ist, betr¨agt nach [Pea04] zwischen 500 kByte/s und
¨
2 MByte/s. Dies ergibt eine Zeit von 2 000 ns bis 500 ns f¨
ur die Ubertragung
eines Bytes. In dieser Messung lag der Wert f¨
ur reine Schreiboperationen bei
durchschnittlich 618 404 Byte/s (1617 ns/Byte). Bei gemischten Schreib-Lese¨
Operationen erreichte die Schnittstelle eine Ubertragungsgeschwindigkeit
von
durchschnittlich 641 881 Byte/s (1558 ns/Byte). Die Werte siedeln sich zwar
im unteren Bereich der theoretisch angegebenen Geschwindigkeit an, liegen
aber im spezifizierten Bereich.
5.4.2
Vergleich der Simulationszeiten
Um eine vergleichende Messung durchzuf¨
uhren, m¨
ussen die gleichen Ausgangsbedingungen f¨
ur beide Simulationen geschaffen werden. Sie werden auf
dem gleichen PC (Pentium4 mit 2,4 Ghz, 512 MB RAM, Betriebssystem Windows XP Professional) ausgef¨
uhrt. F¨
ur beide Simulationen kommt der gleiche Testbench zum Einsatz. Außerdem wird in den Modulen exec.cpp der
Code zur Bildschirmausgabe auskommentiert. Das generierte Modul der modifizierten RISC-CPU wird in jedem Simulationsschritt einmal vollst¨andig
abgearbeitet. Die Ausf¨
uhrung des Originalmodul hingegen findet Abschnittsweise mit Hilfe von wait()-Anweisungen statt. Aus diesem Grund gibt das
generierte Modul mehr Daten auf dem Bildschirm aus. Da Ausgabeopera-
5 DEMONSTRATOR
97
Simulation Zeit durchschnittliche Zeit
originale
0,313 s
RISC-CPU
0,344 s
0,328 s
0,328 s
modifizierte 0,391 s
RISC-CPU
0,359 s
0,385 s
0,406 s
Tabelle 5.4: Gemessene Simulationszeiten der originalen und der modifizierten RISC-CPU. Es wurden je 3 Messungen durchgef¨
uhrt und der Mittelwert
daraus gebildet.
tionen auf der Standardausgabe aber viel Zeit beanspruchen, k¨onnen sie die
Messergebnisse stark verf¨alschen.
Die Zeitmessung f¨
ur beide Simulationen erfolgt durch das Programm timedrun.exe, das im Rahmen dieser Arbeit erstellt wurde. Es f¨
uhrt zwei Skripte
uhrt, welches alle
aus. Als erstes wird das Skript copy simulation.bat ausgef¨
f¨
ur die Simulation ben¨otigten Dateien in das aktuelle Verzeichnis kopiert. F¨
ur
die Ausf¨
uhrung des zweiten Skriptes run.bat wird die Zeit gestoppt. Dieses
Skript dient dazu, die Simulation aufzurufen und die Ausgaben in eine Datei umzuleiten. Die ben¨otigte Zeit wird der Datei time taken by run.log als
letzter Eintrag angef¨
ugt.
Die Ergebnisse der Messung stellt Tabelle 5.4 dar. Die Simulation der originalen RISC-CPU ben¨otigte eine durchschnittliche Zeit von 328 Millisekunden.
Die Simulationszeit der modifizierten RISC-CPU liegt mit durchschnittlich
385 Millisekunden etwas dar¨
uber. Nun stellt sich die Frage, wodurch die um
57 Millisekunden gr¨oßere Simulationszeit zu erkl¨aren ist.
Einen Unterschied zwischen der originalen und der modifizierten RISC-CPU
stellt die Kommunikation u
¨ber die HW/SW-Schnittstelle dar. Zun¨achst soll
das Kommunikationsaufkommen und die daf¨
ur ben¨otigte Zeit untersucht werden. Tabelle 5.5 enth¨alt die Befehle, die in einem Simulationsschritt abgearbeitet werden. Befehle, die in Schleifen ausgef¨
uhrt werden, sind mit Sternen
gekennzeichnet. Die Anzahl der Schleifendurchl¨aufe soll zun¨achst betrachtet
werden, bevor wieder auf die Kommunikationszeit eingegangen wird.
Die erste Schleife dient zum sicheren Starten der IP-Emulation und besteht
aus den Funktionen SetStartSim und GetStatus1. Sie wird in jedem Fall einmal durchlaufen. Im Normalfall endet die Schleife sofort nach dem ersten
98
5 DEMONSTRATOR
Funktion
GetStatus1
SetWriteMode
SetLDIVCounter
SetHDIVCounter
SetCycleCounter
WriteSimData
SetWaitMode
SetStartSim*
GetStatus1*
GetStatus1**
SetCycleEnd
SetReadMode
ReadSimData
SetWaitMode
Kategorie
Anzahl Bytes
(write/read) (write/read)
read
1/3
write
2/0
write
2/0
write
2/0
write
4/0
write
20/0
write
2/0
write
2/0
read
1/3
read
1/3
write
2/0
write
2/0
read
6/18
write
2/0
Tabelle 5.5: Das Datenaufkommen des generierten Moduls. Die Kategorie
gibt an, ob es sich um eine Schreib- oder einen Lesefunktion handelt. Sterne
hinter Funktionen bedeuten, dass sie in einer Schleife ausgef¨
uhrt werden.
¨
Durchlauf. Dies folgt aus der Ubertragungszeit,
die f¨
ur ein Byte notwendig
¨
ist. Nach Abschnitt 5.4.1 betr¨agt die theoretisch k¨
urzeste Zeit zur Ubertragung eines Bytes u
¨ber die parallele Schnittstelle 500 ns. Der Simulationsinterfaceblock ist mit 50 Mhz getaktet und besitzt demnach eine Taktperiode
von 20 ns. Bevor die Funktion GetStatus1 das Statusbyte liest, schreibt sie
eine Adresse. Das heißt vom Ende der Funktion SetStartSim bis zum Lesen
des Statusbyte vergehen mindestens 500 ns. Der Automat hat mindestens
500 : 20 = 25 Taktperioden Zeit, um den Zustandswechsel auszuf¨
uhren. Betrachtete man den Aufbau des Automaten in Abbildung 3.23 auf Seite 58
ben¨otigt er einen Takt f¨
ur den Zustandswechsel. Hinzu kommen jeweils ein
Takt f¨
ur die Wert¨
ubernahme durch die Kontrollregister und Statusregister.
Dies zeigt, dass die Schleife unter normalen Bedingungen nur einmal Durchlaufen wird.
Zur Betrachtung der zweiten Schleife muss die Ausf¨
uhrungszeit eines IPEmulationstaktes mit herangezogen werden. Die Frequenz der IP-Emulation
berechnet sich nach Formel A.14 in Anhang A. Sie lautet
fIP =
fIFB
HDIV + LDIV + 2
5 DEMONSTRATOR
99
Die berechneten Werte des Simulationsinterfaceblock-Generators f¨
ur HDIV
und LDIV eingesetzt, ergibt sich die Frequenz der IP-Emulation von
fIP =
50 Mhz
= 3, 571 Mhz.
6+6+2
Damit betr¨agt die Zeit f¨
ur eine Taktperiode 280 ns. Die Emulation startet
sofort nach dem erfolgreichen Setzen des Startsignals durch SetStartSim. Anschließend wird die Funktion GetStatus1 ausgef¨
uhrt, die das Starten u
¨berpr¨
uft. Sie ben¨otigt einen Schreibvorgang und drei Lesevorg¨ange. Drei Lesevorg¨ange wurden aus Gr¨
unden der Fehlerkorrektur eingef¨
uhrt, da bei der
Schnittstelle vereinzelt Lesefehler auftraten. Die drei empfangenen Bytes werden miteinander verglichen und das Byte zur¨
uchgegeben, welches am h¨aufigsten auftritt. Die Funktion besitzt damit eine Ausf¨
uhrungszeit von mindestens
4 · 500 ns = 2000 ns. Das bedeutet, dass die zweite Schleife startet, wenn die
IP-Emulation schon abgeschlossen ist. Damit ben¨otigt auch sie nur einen
Durchlauf.
Nach der Untersuchung der Schleifendurchl¨aufe soll wieder auf die Kommunikationszeit eingegangen werden. Schreibvorg¨ange im Simulationsinterfaceblock sind definiert als Schreiben eines Adressbytes und Schreiben eines
Datenbytes. In jedem Simulationschritt m¨
ussen damit mindestens 36 Bytes
u
¨bertragen werden. Ein Lesevorgang umfasst das Schreiben eines Adressbytes und Lesen von drei Datenbytes aus Gr¨
unden der Fehlerkorrektur. Die
Lesevorg¨ange besitzen somit ein Kommunikationsaufkommen von 40 Bytes
je Simulationsschritt. Die vorliegende Simulation besteht, nach den Simulationsausgaben in der Datei risc cpu.log (siehe Anhang D), aus 278 Schritten
¨
inklusive der Initialisierung. Als Ubertragungsgeschwindigkeit
werden die gemessenen Werte aus Tabelle 5.3 herangezogen. F¨
ur die Kommunikationszeit
ergibt sich
40 Byte
36 Byte
· 278 +
· 278 = 0, 0335 s = 33, 5 ms
618404 Byte/s
641881 Byte/s
Damit l¨asst sich ein Teil der 57 Millisekunden Zeitunterschied zwischen der
Simulation der originalen und der modifizierten RISC-CPU erkl¨aren.
Ein weitere Faktor, der die h¨ohere Simulationszeit erkl¨aren kann, ist das
Signalmapping in der Datei exec.cpp. In jedem Simulationsschritt m¨
ussen
die Eingangssignale bitweise auf das Feld f¨
ur die Simulationsdaten abgebildet
werden. Eine Abbildung der empfangenen Daten von der IP-Emulation auf
die lokalen Variablen findet in jedem Simulationsschritt statt. Dies kostet
zus¨atzlich Zeit.
100
5 DEMONSTRATOR
Im Vergleich zum generierten Modul hat das originale Modul sehr wenig Anweisungen auszuf¨
uhren. Aus diesem Grund besitzt es einen Vorteil hinsichtlich der Simulationszeit. Es ist wahrscheinlich, dass der jetzige Geschwindigkeitsvorteil der Originaldesigns mit zunehmender Komplexit¨at der SystemCBeschreibung verloren gehen w¨
urde. In diesem Fall kann der Simulationsinterfaceblock auch zur Beschleunigung der SystemC-Simulation eingesetzt
werden.
Bei der Durchf¨
uhrung der Messung ist nicht vorhersagbar, ob der Simulation
u
ugung steht.
¨ber die gesamte Laufzeit die komplette CPU-Leistung zur Verf¨
Auf dem simulierenden PC werden weitere Prozesse des Betriebssystems ausgef¨
uhrt. Falls das Betriebssystem w¨ahrend der Ausf¨
uhrung dem Simulator
kurz den Prozessor entzieht, kommen Umschaltzeiten zwischen den Prozessen zur Simulationszeit hinzu. Damit erkl¨aren sich auch die Schwankungen
bei den Messergebnissen der Simulationszeit.
Die Betrachtungen zeigen, dass die Simulationsgeschwindigkeit bei der Nutzung eines Simulationsinterfaceblocks stark von der Anzahl der ausgetauschten Daten zwischen SystemC-Simulation und IP-Emulation abh¨angt. Die
HW/SW-Schnittstelle kann hier die Simulation ausbremsen. Das FPGA ist
im vorliegenden Beispiel leistungsf¨ahig genug, um nicht geschwindigkeitsmindernd zu wirken. Zur Erh¨ohung der Simulationsgeschwindigkeit ist der Ein¨
satz einer physischen HW/SW-Schnittstelle denkbar, die eine h¨ohere Ubertragungsgeschwindigkeit als die parallele Schnittstelle erlaubt. In diesem Zusammenhang sollte dann auch die Leistungsf¨ahigkeit der FPGA neu untersucht werden und gegebenenfalls ein schnelleres Modell eingesetzt werden,
um ein Gleichgewicht zwischen Schnittstellengeschwindigkeit und FPGALeistung zu erreichen.
5.5
Schlussfolgerungen
Am vorgestellten Demonstrator wurde nachgewiesen, dass das Modell des Simulationsinterfaceblocks leistungsf¨ahig genug ist, um die ihm gestellten Aufgaben korrekt zu erf¨
ullen. Der Simulationsinterfaceblock wurde erfolgreich
eingesetzt, um eine SystemC-Simulation mit einer IP-Emulation u
¨ber eine
¨
HW/SW-Schnittstelle zu verbinden ohne dabei Anderungen an den Komponenten vorzunehmen.
In diesem Zusammenhang erfolgte außerdem der Nachweis, dass der Simulationsinterfaceblock-Generator erfolgreich arbeitet. Das Programm erstellte den
5 DEMONSTRATOR
101
Simulationsinterfaceblock auf Basis einer Analyse der VHDL-IP und Nutzereingaben. Dieser automatisch generierte Simulationsinterfaceblock erf¨
ullte
die Aufgabe der Verbindung von SystemC-Simulation und IP-Emulation zur
Zufriedenheit.
Der Einsatz eines bereits bestehenden SystemC-Designs als Teil des Demonstrators zeigt, dass die Leistung des Simulationsinterfaceblocks und des Simulationsinterfaceblock-Generators ausreicht, um auch im praktischen Einsatz
Verwendung zu finden.
102
5 DEMONSTRATOR
6 ZUSAMMENFASSUNG UND AUSBLICK
6
103
Zusammenfassung und Ausblick
Diese Kapitel bildet den Abschluss der Arbeit. Es fasst die Konzepte und
Ergebnisse dieser Arbeit zusammen und erl¨autert daran die erfolgreiche Bearbeitung der Aufgabenstellung. Anschließend wird ein Ausblick auf M¨oglichkeiten der Weiterentwicklung geboten.
6.1
Zusammenfassung der Arbeit
Diese Arbeit untergliedert sich in zwei Aufgaben. Die erste Aufgabe bestand
in der Untersuchung eines Co-Simulationsansatzes. Dieser Ansatz zielt darauf ab, eine synthesef¨ahige VHDL-Komponente auf einem FPGA zu emulieren und die Emulation mit einer SystemC-Simulation zu koppeln. Die zweite
Aufgabe ist eng mit der Ersten verkn¨
upft. Dabei sollte aufbauend auf den Betrachtungen des Co-Simulationsansatzes ein Verfahren entwicklet werden, das
eine automatische Adaptierung von SystemC-Simulation und IP-Emulation
erlaubt.
Der erste Teil dieser Arbeit bot eine Einf¨
uhrung in die Problematik und
stellte die Aufgabenstellung vor. Anschließend erfolgte die Betrachtung des
aktuellen Standes der Techniken mit denen diese Arbeit verkn¨
ufpt ist. Daran
schloss sich die Vorstellung von SystemC als Entwurfssystem und die Begutachtung seiner derzeitige Leistungsf¨ahigkeit an. Der Begriff der Intellectual
Properties wurde erkl¨art und das IPQ-Projekt kurz vorgestellt, mit dessen
Hilfe bestehende Probleme bei der IP-Nutzung u
¨berwunden werden sollen.
Zuletzt wurde auf den Begriff Simulation eingegangen und verschiedene Simulationsverfahren und -konzepte vorgestellt.
Das dritte Kapitel betrachtete den Co-Simulationsansatz. Dabei wurde herausgearbeitet, dass eine Hardware/Software-Schnittstelle ben¨otigt wird, um
die SystemC-Simulation mit der IP-Emulation zu koppeln. In diesem Zusammenhang erfolgte die Herausstellung der Aufgaben der HW/SW-Schnittstelle
sowie der von ihr zu erbringenden Leistungen. F¨
ur eine m¨ogliche Umsetzung
der HW/SW-Schnittstelle fand das Modell des Interfaceblocks Verwendung.
104
6 ZUSAMMENFASSUNG UND AUSBLICK
Dazu wurde zun¨achst desses Leistungsf¨ahigkeit analysiert, um sicherzustellen, dass es in der Lage ist, die Aufgaben zu erf¨
ullen. Da das vorliegende
Modell des Interfaceblocks eine Aufgabe nicht abdecken konnte, erfolgte eine
Erweiterung das Konzept. Das Ergebnis bestand in einem erweiterten Interfaceblock, der die Hardware/Software-Grenze u
¨berwinden kann. Um den
erweiterten Interfaceblock f¨
ur die Co-Simulation einsetzen zu k¨onnen, wurden Untersuchungen zur praktischen Umsetzung durchgef¨
uhrt. Das Ergebnis
bestand im Simulationsinterfaceblock, der eine M¨oglichkeit der praktischen
Realisierung des erweiterten Interfaceblocks darstellt. Zum Abschluss des
Kapitels wurden noch die verschiedenen Einsatzm¨oglichkeiten des Simulationsinterfaceblocks vorgestellt.
Das vierte Kapitel besch¨aftigte sich mit einer L¨osung, die eine automatische
Erstellung eines Simulationsinterfaceblocks erlaubt. Das Ergebnis bildet das
Prorgamm Simulationsinterfaceblock-Generator. Es wurde detailiert auf die
interne Arbeitsweise des Programms eingegangen, um eine gute Grundlage f¨
ur Weiterentwicklungen des Programms zu bieten. F¨
ur die Anwendung
des Programms zur Generierung von Simulationsinterfacebl¨ocken wurde ein
Handbuch verfasst, um Benutzer einen schnellen Einstieg zu gew¨ahren. Abschließend erfolgte die Vorstellung von M¨oglichkeiten der Weiterentwicklung
zur Unterst¨
utzung eines breiteren Spektrums von Implementierungsplattformen und Intellectual Properties.
Der Demonstrator, u
unfte Kapitel handelt, diente dem Erproben
¨ber den das f¨
und Validieren der Konzepte aus Kapitel drei und des Programm aus Kapitel vier. Es wurde der Aufbau und die Funktionsweise des Demonstrators
vorgestellt. Anschließend wurde der Nachweis der korrekten Funktion durch
die Ausf¨
uhrung des Demonstrators und dem Vergleich mit dem Ursprungsdesign erbracht. Da ben¨otigte Zeit einer Simulation ein wichtiges Kriterium
bei der Wahl der Simulationsart darstellt, schlossen sich dem Nachweis der
Funktion Untersuchungen zur Simulationsgeschwindigkeit an. In diesem Zusammenhang wurde eine Messeinrichtung entwickelt, die die Geschwindigkeit
der parallelen Schnittstelle ermittelte. Die Untersuchungen ergaben, dass die
Simulationsgeschwindigkeit stark von der Geschwindigkeit der physischen
HW/SW-Schnittstelle abh¨angt. Das Ergebnis des Demonstrators bestand
darin, dass die erarbeiteten Konzepte dieser Arbeit ihre Aufgaben korrekt
erf¨
ullten und erfolgreich in der Praxis eingesetzt werden konnten. Auch das
Prorgamm Simulationsinterfaceblock-Generator erf¨
ullte seinen Zweck und erlaubt die automatische Adaptierung einer IP-Emulation und einer SystemCSimulation. Anhand des Demonstrators wurde gezeigt, dass die gestellten
Aufgaben dieser Arbeit erfolgreich gel¨ost wurden.
6 ZUSAMMENFASSUNG UND AUSBLICK
6.2
105
Ausblick fu
¨ r den erweiterten Interfaceblock
Abgeleitet vom Konzept des erweiterten Interfaceblocks wurde in dieser Arbeit die Implementierung eines Simulationsinterfaceblocks durchgef¨
uhrt. Er
dient zur Kopplung einer SystemC-Simulation auf einem PC und einer IPEmulation auf einem FPGA. Im Bezug auf die Cosimulation k¨onnten weiterer
Arbeiten folgende Themen untersuchen:
• Unter Nutzung eines Simulationsinterfaceblocks k¨onnte ein Tool f¨
ur das
Hardwaredebugging implementiert werden. Dies bietet die M¨oglichkeit,
das Verhalten eines Hardwaredesigns als Implementierung auf einem
FPGA zu untersuchen.
• Ein weiteres Feld f¨
ur Untersuchungen liegt in der Emulation von dynamisch rekonfigurierbaren Designs. Dabei kann die Kopplung mit einer
SystemC-Simulation erfolgen, um dynamisch rekonfigurierbare Teile eines gr¨oßeren Designs zu untersuchen oder ein Hardwaredebugging des
dynamisch rekonfigurierbaren Designs durchzuf¨
uhren.
Um die Einsatzm¨oglichkeiten des allgemeinen Konzeptes des erweiterten Interfaceblocks zu erweitern, k¨onnten Untersuchungen auf den folgenden Gebieten behilflich sein:
• Ein Gebiet von Untersuchung k¨onnte der Einsatz als Schnittstelle zwischen Anwendungsprogrammen und Spezialhardware sein. Der Einsatz
von Spezialhardware beschleunigt dabei bestimmte Funktionen, deren
Ausf¨
uhrung in Software zu langsam ist, um eine Steigerung der Programmperformance zu erreichen.
• Weiterhin k¨onnte das Konzept des erweiterten Interfaceblocks in das
bestehende Interface Synthese (IFS)-Format aufgenommen werden und
damit auch die M¨oglichkeit einer automatischen Generierung eines erweiterten Interfaceblock als HW/SW-Schnittstelle entstehen.
106
6.3
6 ZUSAMMENFASSUNG UND AUSBLICK
Ausblick fu
¨ r den Simulationsinterfaceblock-Generator
Die Entwicklung des Simulationsinterfaceblock-Generators im Rahmen dieser Arbeit fand speziell f¨
ur die automatische Adaptierung von SystemCSimulation und VHDL-IP-Emulation statt. Um ein gr¨oßeres Einsatzfeld des
Programms zu erlangen und damit die praktische Einsatzf¨ahigkeit weiter zu
steigern, sind einige Erweiterungen des Programms denkbar:
• In der gegenw¨artigen Version verarbeitet der SimulationsinterfaceblockGenerator nur Ports von VHDL-Entities mit den Richtungen in oder
out. Zur Unterst¨
utzung einer gr¨oßeren Anzahl von VHDL-IPs k¨onnte
das Programm f¨
ur die Verarbeitung von bidirektionalen Ports (Richtung inout) erweitert werden.
• Mit der Analysem¨oglichkeit von VHDL-Generics kann das Konzept von
generischen Portbreiten umgesetzt werden. Damit ist auch eine Unterst¨
utzung von parametrisierbaren IPs denkbar.
• Die Erweiterung des Programms zur Unterst¨
utzung anderer Hardwarebeschreibungssprachen, wie zum Beispiel Verilog, w¨
urde die Einsatzbreite erheblich steigern.
• Eine Unterst¨
utzung unterschiedlicher FPGA-Typen und -Boards bringt
eine gr¨oßere Flexibilit¨at des Programms hinsichtlich der Emulationsplattform mit sich. In diesem Zusammenhang steht die Nutzung von unterschiedlichen Entwicklungsumgebungen und Tools zur Synthese und
Implementierung.
• Andere phyische Hardware/Software-Schnittstellen k¨onnen zum Einen
die Simulationsgeschwindigkeit erh¨ohen. Auf der anderen Seite erh¨oht
sich dadurch ebenfalls die Flexibilit¨at gegen¨
uber unterschiedlichen Implementierungsplattformen.
Anhang A
A
107
Herleitung der Formel zur Berechnung der Taktfrequenz
der IP-Emulation
Zur Herleitung der Formel zur Berechnung der Taktfrequenz der IP-Emulation
sind zun¨achst eine Variablendefinitionen durchzuf¨
uhren. Die verwendeten Variablen definieren sich wie folgt:
fIF B
TIF B
fIP
TIP
tIPH
tIPL
HDIV
LDIV
nH
nL
...
...
...
...
...
...
...
...
...
...
Taktfrequenz des Interfaceblocks
Taktperiode des Interfaceblocks
Taktfrequenz der IP-Emulation
Taktperiode der IP-Emulation
Zeit des Highpegels der Taktperiode der IP-Emulation
Zeit des Lowpegels der Taktperiode der IP-Emulation
Wert des Z¨ahlers HDIV
Wert des Z¨ahlers LDIV
Anzahl der Durchl¨aufe durch den Zustand Clk gen1
Anzahl der Durchl¨aufe durch den Zustand Clk gen0
Der Interfaceblock ist mit der Taktfrquenz fIF B getaktet. Die Taktperiode
ergibt sich aus der Taktfrequenz nach der Formel
T =
1
f
(A.1)
Somit ergibt sich f¨
ur die Taktperiode des Interfaceblocks
TIF B =
1
fIF B
(A.2)
Der endliche Automat in der CUHW generiert den Highpegel als auch den
Lowpegel des Taktsignals f¨
ur die IP-Emulation mindestens einen Takt lang.
Daraus folgt f¨
ur die minimalen Pegelzeiten der Taktperiode der IP-Emulation
tIPH,min = TIF B
tIPL,min = TIF B
(A.3)
108
Anhang A
Die Taktgenerierung erfolgt in den Zust¨anden Clk gen1 und Clk gen0 des
Automaten der CUHW . Die Verweildauer in diesen Zust¨anden geben die Werte
der Z¨ahler HDIV und LDIV an. Aber jeder dieser Zust¨ande wird mindestens
einmal durchlaufen. Die Anzahl der Durchl¨aufe dieser Zust¨ande ergibt sich
aus
nH = HDIV + 1
nL = LDIV + 1
(A.4)
Die Anzahl der Durchl¨aufe bestimmt, f¨
ur welche Zeitspanne der jeweilige
Pegel generiert wird. Die Zeitspanne betr¨agt f¨
ur den jeweiligen Pegel aber
mindestens tIPH,min bzw. tIPL,min . F¨
ur die Gesamtzeit des High- bzw. Lowpegels ergibt sich
tIPH = nH · tIPH,min
tIPH = (HDIV + 1) · tIPH,min
tIPL = nL · tIPL,min
tIPL = (LDIV + 1) · tIPL,min
(A.5)
(A.6)
Aus den Formeln A.3 und A.6 bildet sich
tIPH = (HDIV + 1) · TIF B
tIPL = (LDIV + 1) · TIF B
(A.7)
Die Dauer der Taktperiode f¨
ur die IP-Emulation ergibt sich aus der Zeit des
Highpegels und der Zeit des Lowpegels.
mit A.7:
TIP
TIP
TIP
TIP
= TIPH + TIPL
= (HDIV + 1) · TIF B + (LDIV + 1) · TIF B
= (HDIV + 1 + LDIV + 1) · TIF B
= (HDIV + LDIV + 2) · TIF B
(A.8)
(A.9)
(A.10)
(A.11)
(A.12)
Nach Formel A.1 werden die Taktperioden in Formel A.11 durch Frequenzen
ersetzt
1
1
= (HDIV + LDIV + 2) ·
fIP
fIF B
fIF B
fIP =
HDIV + LDIV + 2
(A.13)
(A.14)
Anhang B
B
109
Hinweise zur Nutzung von
SystemC in Mircrosoft Visual C++ 6.0
Um die SystemC Klassenbibliothek erfolgreich in der C/C++ Entwicklungsumgebung Microsoft Visual C++ 6.0 einsetzen zu k¨onnen, m¨
ussen einige
Einstellungen vorgenommen werden. Sie betreffen den Compiler und den
Linker und sind unter dem Men¨
upunkt Project -> Settings... vorzunehmen.
Die Einstellungen sind im Folgenden aufgef¨
uhrt. Dabei ist als erstes die Registerkarte aufgef¨
uhrt, unter dem sich die Einstellung findet. Es schließt sich
der Unterpunkt und die jeweilige Parameter an. Der Wert, der f¨
ur den Parameter einzutragen ist, steht darunter mit einer Bemerkung in Klammern.
C/C++ -> C++ Language -> Enable Run-Time Type Information (RTTI)
aktiv (Haken eingetragen)
C/C++ -> Preprocessor -> Additional include directories
...\Systemc-2.0.1\src ( Pfad zu systemc.h)
Link -> General -> Object/library modules
systemc.lib (hinzuf¨
ugen zu vorhandenen Bibliotheken)
Link -> Input -> Additional library path
...\Systemc-2.0.1\msvc60\systemc\Debug
(Pfad zur Datei systemc.lib)
Weitere Hinweise zur Arbeit mit SystemC enth¨alt das Handbuch [Opeb].
110
Anhang B
Anhang C
C
111
Gegenu
¨ berstellung der Simulationsdaten
Die Simulationsergebnisse der originalen und modifizierten RISC-CPU werden hier auszugsweise gegen¨
ubergestellt. Bei den Ausgaben der originalen
RISC-CPU wurden die Ausgaben, die keine Simulationsdaten enthielten, ent¨
fernt, um eine bessere Ubersicht
zu gew¨ahrleisten. Zur direkten Gegen¨
uberstellung sind die Simulationsausgaben der modifizierten RISC-CPU ebenfalls gek¨
urzt aufgef¨
uhrt. Die vollst¨andigen Ausgabedaten finden sich auf der
dieser Arbeit beiliegenden CD- ROM. Unter den Verzeichnisssen /Testdesigns/Risc cpu original/Simulation sowie /Testdesigns/Risc cpu simifb/Simulation existiert jeweils eine Datei risc cpu.log, die die Daten enth¨alt. Mehr
zum Inhalt der Verzeichnisse bietet Anhang D, der das Inhaltsverzeichnis der
CD-ROM beinhaltet.
Ausgaben der
|
Ausgaben der
originalen RISC-CPU
|
RISC-CPU mit SimulationsIFB
-------------------------------------|-----------------------------------|
** ALERT ** ID: initialize Archite
| ** ALERT ** ID: initialize Archite
ctural Registers
|
ctural Registers
** ALERT ** BIOS: initialize BIOS
| ** ALERT ** BIOS: initialize BIOS
** ALERT ** DCU: initialize Data
| ** ALERT ** DCU: initialize Data
Cache
|
Cache
----------------------| ----------------------IFU : mem=0xf000001
| IFU : mem=0xf000001
IFU : pc= 1 at CSIM 5 ns
| IFU : pc= 1 at CSIM 5 ns
------------------------------| ------------------------------ID: R0=R0(=0)
| ID: R0=R0(=0)
: at CSIM 7 ns
|
: at CSIM 7 ns
------------------------------| ------------------------------ALU : op= 3 A= 0 B= 0
| ALU : op= 3 A= 0 B= 0
ALU : R= 0-> R0 at CSIM 9 ns
| ALU : R= 0-> R0 at CSIM 9 ns
-----------------------| -----------------------IFU : mem=0xf000002
| IFU : mem=0xf000002
IFU : pc= 2 at CSIM 12 ns
| IFU : pc= 2 at CSIM 12 ns
------------------------------| ------------------------------ID: R0=R0(=0)
| ID: R0=R0(=0)
: at CSIM 14 ns
|
: at CSIM 14 ns
------------------------------| ------------------------------ALU : op= 3 A= 0 B= 0
| ALU : op= 3 A= 0 B= 0
112
ALU : R= 0-> R0 at CSIM 16 ns
-----------------------IFU : mem=0xf000003
IFU : pc= 3 at CSIM 19 ns
------------------------------ID: R0=R0(=0)
: at CSIM 21 ns
------------------------------ALU : op= 3 A= 0 B= 0
ALU : R= 0-> R0 at CSIM 23 ns
-----------------------IFU : mem=0xf000004
IFU : pc= 4 at CSIM 26 ns
------------------------------ID: R0=R0(=0)
: at CSIM 28 ns
------------------------------ALU : op= 3 A= 0 B= 0
ALU : R= 0-> R0 at CSIM 30 ns
------------------------------ICU ALERT: ******AFTER RESET******
ICU ALERT: ***********************
------------------------------ID: R0=0x0(0) fr ALU at CSIM 31 ns
-----------------------IFU : mem=0xf160000a
IFU : pc= 5 at CSIM 33 ns
------------------------------ID: R6=10 at CSIM 35 ns
------------------------------ALU : op= 3 A= 10 B= 0
ALU : R= 10-> R6 at CSIM 37 ns
------------------------------ID: R6=0xa(10) fr ALU at CSIM 38 ns
-----------------------IFU : mem=0x0
IFU : pc= 6 at CSIM 40 ns
------------------------------*******************************
ID: REGISTERS DUMP at CSIM 42 ns
*******************************
REG :=============================
R 0(00000000)
R 1(00000001)
R 2(fff000e2)
R 3(ffffffff)
R 4(00000004)
R 5(00000005)
R 6(0000000a)
R 7(fcf0fdef)
R 8(00000008)
R 9(00000009)
Anhang C
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ALU : R= 0-> R0 at CSIM 16 ns
-----------------------IFU : mem=0xf000003
IFU : pc= 3 at CSIM 19 ns
------------------------------ID: R0=R0(=0)
: at CSIM 21 ns
------------------------------ALU : op= 3 A= 0 B= 0
ALU : R= 0-> R0 at CSIM 23 ns
-----------------------IFU : mem=0xf000004
IFU : pc= 4 at CSIM 26 ns
------------------------------ID: R0=R0(=0)
: at CSIM 28 ns
------------------------------ALU : op= 3 A= 0 B= 0
ALU : R= 0-> R0 at CSIM 30 ns
------------------------------ICU ALERT: ******AFTER RESET******
ICU ALERT: ***********************
------------------------------ID: R0=0x0(0) fr ALU at CSIM 31 ns
-----------------------IFU : mem=0xf160000a
IFU : pc= 5 at CSIM 33 ns
------------------------------ID: R6=10 at CSIM 35 ns
------------------------------ALU : op= 3 A= 10 B= 0
ALU : R= 10-> R6 at CSIM 37 ns
------------------------------ID: R6=0xa(10) fr ALU at CSIM 38 ns
-----------------------IFU : mem=0x0
IFU : pc= 6 at CSIM 40 ns
------------------------------*******************************
ID: REGISTERS DUMP at CSIM 42 ns
*******************************
REG :=============================
R 0(00000000)
R 1(00000001)
R 2(fff000e2)
R 3(ffffffff)
R 4(00000004)
R 5(00000005)
R 6(0000000a)
R 7(fcf0fdef)
R 8(00000008)
R 9(00000009)
Anhang C
R10(00000010)
R11(0000ff31)
R12(0000ff12)
R13(00000013)
R14(00000014)
R15(00000015)
R16(00000016)
R17(00fe0117)
R18(00fe0118)
R19(00fe0119)
R20(00fe0220)
R21(00fe0321)
R22(00fe0322)
R23(00ff0423)
R24(00ff0524)
R25(00ff0625)
R26(00ff0726)
R27(00ff0727)
R28(00f70728)
R29(00000029)
R30(00000030)
R31(00000031)
==================================
-----------------------IFU : mem=0xf160000a
IFU : pc= 7 at CSIM 47 ns
------------------------------ID: R6=10 at CSIM 49 ns
------------------------------ALU : op= 3 A= 10 B= 0
ALU : R= 10-> R6 at CSIM 51 ns
------------------------------ID: R6=0xa(10) fr ALU at CSIM 52 ns
-----------------------IFU : mem=0x0
IFU : pc= 8 at CSIM 54 ns
------------------------------*******************************
ID: REGISTERS DUMP at CSIM 56 ns
*******************************
REG :=============================
R 0(00000000)
R 1(00000001)
R 2(fff000e2)
R 3(ffffffff)
R 4(00000004)
R 5(00000005)
R 6(0000000a)
R 7(fcf0fdef)
R 8(00000008)
R 9(00000009)
R10(00000010)
R11(0000ff31)
R12(0000ff12)
R13(00000013)
R14(00000014)
R15(00000015)
R16(00000016)
R17(00fe0117)
R18(00fe0118)
R19(00fe0119)
R20(00fe0220)
R21(00fe0321)
R22(00fe0322)
R23(00ff0423)
R24(00ff0524)
R25(00ff0625)
R26(00ff0726)
R27(00ff0727)
R28(00f70728)
R29(00000029)
R30(00000030)
R31(00000031)
==================================
113
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
R10(00000010)
R11(0000ff31)
R12(0000ff12)
R13(00000013)
R14(00000014)
R15(00000015)
R16(00000016)
R17(00fe0117)
R18(00fe0118)
R19(00fe0119)
R20(00fe0220)
R21(00fe0321)
R22(00fe0322)
R23(00ff0423)
R24(00ff0524)
R25(00ff0625)
R26(00ff0726)
R27(00ff0727)
R28(00f70728)
R29(00000029)
R30(00000030)
R31(00000031)
==================================
-----------------------IFU : mem=0xf160000a
IFU : pc= 7 at CSIM 47 ns
------------------------------ID: R6=10 at CSIM 49 ns
------------------------------ALU : op= 3 A= 10 B= 0
ALU : R= 10-> R6 at CSIM 51 ns
------------------------------ID: R6=0xa(10) fr ALU at CSIM 52 ns
-----------------------IFU : mem=0x0
IFU : pc= 8 at CSIM 54 ns
------------------------------*******************************
ID: REGISTERS DUMP at CSIM 56 ns
*******************************
REG :=============================
R 0(00000000)
R 1(00000001)
R 2(fff000e2)
R 3(ffffffff)
R 4(00000004)
R 5(00000005)
R 6(0000000a)
R 7(fcf0fdef)
R 8(00000008)
R 9(00000009)
R10(00000010)
R11(0000ff31)
R12(0000ff12)
R13(00000013)
R14(00000014)
R15(00000015)
R16(00000016)
R17(00fe0117)
R18(00fe0118)
R19(00fe0119)
R20(00fe0220)
R21(00fe0321)
R22(00fe0322)
R23(00ff0423)
R24(00ff0524)
R25(00ff0625)
R26(00ff0726)
R27(00ff0727)
R28(00f70728)
R29(00000029)
R30(00000030)
R31(00000031)
==================================
114
-----------------------IFU : mem=0xf160000a
IFU : pc= 9 at CSIM 61 ns
------------------------------ID: R6=10 at CSIM 63 ns
------------------------------ALU : op= 3 A= 10 B= 0
ALU : R= 10-> R6 at CSIM 65 ns
------------------------------ID: R6=0xa(10) fr ALU at CSIM 66 ns
-----------------------IFU : mem=0x0
IFU : pc= a at CSIM 68 ns
------------------------------*******************************
ID: REGISTERS DUMP at CSIM 70 ns
*******************************
REG :=============================
R 0(00000000)
R 1(00000001)
R 2(fff000e2)
R 3(ffffffff)
R 4(00000004)
R 5(00000005)
R 6(0000000a)
R 7(fcf0fdef)
R 8(00000008)
R 9(00000009)
R10(00000010)
R11(0000ff31)
R12(0000ff12)
R13(00000013)
R14(00000014)
R15(00000015)
R16(00000016)
R17(00fe0117)
R18(00fe0118)
R19(00fe0119)
R20(00fe0220)
R21(00fe0321)
R22(00fe0322)
R23(00ff0423)
R24(00ff0524)
R25(00ff0625)
R26(00ff0726)
R27(00ff0727)
R28(00f70728)
R29(00000029)
R30(00000030)
R31(00000031)
==================================
-----------------------IFU : mem=0xf160000a
IFU : pc= b at CSIM 75 ns
------------------------------ID: R6=10 at CSIM 77 ns
------------------------------ALU : op= 3 A= 10 B= 0
ALU : R= 10-> R6 at CSIM 79 ns
------------------------------ID: R6=0xa(10) fr ALU at CSIM 80 ns
------------------------
Anhang C
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
-----------------------IFU : mem=0xf160000a
IFU : pc= 9 at CSIM 61 ns
------------------------------ID: R6=10 at CSIM 63 ns
------------------------------ALU : op= 3 A= 10 B= 0
ALU : R= 10-> R6 at CSIM 65 ns
------------------------------ID: R6=0xa(10) fr ALU at CSIM 66 ns
-----------------------IFU : mem=0x0
IFU : pc= a at CSIM 68 ns
------------------------------*******************************
ID: REGISTERS DUMP at CSIM 70 ns
*******************************
REG :=============================
R 0(00000000)
R 1(00000001)
R 2(fff000e2)
R 3(ffffffff)
R 4(00000004)
R 5(00000005)
R 6(0000000a)
R 7(fcf0fdef)
R 8(00000008)
R 9(00000009)
R10(00000010)
R11(0000ff31)
R12(0000ff12)
R13(00000013)
R14(00000014)
R15(00000015)
R16(00000016)
R17(00fe0117)
R18(00fe0118)
R19(00fe0119)
R20(00fe0220)
R21(00fe0321)
R22(00fe0322)
R23(00ff0423)
R24(00ff0524)
R25(00ff0625)
R26(00ff0726)
R27(00ff0727)
R28(00f70728)
R29(00000029)
R30(00000030)
R31(00000031)
==================================
-----------------------IFU : mem=0xf160000a
IFU : pc= b at CSIM 75 ns
------------------------------ID: R6=10 at CSIM 77 ns
------------------------------ALU : op= 3 A= 10 B= 0
ALU : R= 10-> R6 at CSIM 79 ns
------------------------------ID: R6=0xa(10) fr ALU at CSIM 80 ns
------------------------
Anhang C
IFU : mem=0x0
IFU : pc= c at CSIM 82 ns
------------------------------*******************************
ID: REGISTERS DUMP at CSIM 84 ns
*******************************
REG :=============================
R 0(00000000)
R 1(00000001)
R 2(fff000e2)
R 3(ffffffff)
R 4(00000004)
R 5(00000005)
R 6(0000000a)
R 7(fcf0fdef)
R 8(00000008)
R 9(00000009)
R10(00000010)
R11(0000ff31)
R12(0000ff12)
R13(00000013)
R14(00000014)
R15(00000015)
R16(00000016)
R17(00fe0117)
R18(00fe0118)
R19(00fe0119)
R20(00fe0220)
R21(00fe0321)
R22(00fe0322)
R23(00ff0423)
R24(00ff0524)
R25(00ff0625)
R26(00ff0726)
R27(00ff0727)
R28(00f70728)
R29(00000029)
R30(00000030)
R31(00000031)
==================================
-----------------------IFU : mem=0xf160000a
IFU : pc= d at CSIM 89 ns
------------------------------ID: R6=10 at CSIM 91 ns
------------------------------ALU : op= 3 A= 10 B= 0
ALU : R= 10-> R6 at CSIM 93 ns
------------------------------ID: R6=0xa(10) fr ALU at CSIM 94 ns
-----------------------IFU : mem=0x0
IFU : pc= e at CSIM 96 ns
------------------------------*******************************
ID: REGISTERS DUMP at CSIM 98 ns
*******************************
REG :=============================
R 0(00000000)
R 1(00000001)
R 2(fff000e2)
R 3(ffffffff)
R 4(00000004)
R 5(00000005)
R 6(0000000a)
R 7(fcf0fdef)
115
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
IFU : mem=0x0
IFU : pc= c at CSIM 82 ns
------------------------------*******************************
ID: REGISTERS DUMP at CSIM 84 ns
*******************************
REG :=============================
R 0(00000000)
R 1(00000001)
R 2(fff000e2)
R 3(ffffffff)
R 4(00000004)
R 5(00000005)
R 6(0000000a)
R 7(fcf0fdef)
R 8(00000008)
R 9(00000009)
R10(00000010)
R11(0000ff31)
R12(0000ff12)
R13(00000013)
R14(00000014)
R15(00000015)
R16(00000016)
R17(00fe0117)
R18(00fe0118)
R19(00fe0119)
R20(00fe0220)
R21(00fe0321)
R22(00fe0322)
R23(00ff0423)
R24(00ff0524)
R25(00ff0625)
R26(00ff0726)
R27(00ff0727)
R28(00f70728)
R29(00000029)
R30(00000030)
R31(00000031)
==================================
-----------------------IFU : mem=0xf160000a
IFU : pc= d at CSIM 89 ns
------------------------------ID: R6=10 at CSIM 91 ns
------------------------------ALU : op= 3 A= 10 B= 0
ALU : R= 10-> R6 at CSIM 93 ns
------------------------------ID: R6=0xa(10) fr ALU at CSIM 94 ns
-----------------------IFU : mem=0x0
IFU : pc= e at CSIM 96 ns
------------------------------*******************************
ID: REGISTERS DUMP at CSIM 98 ns
*******************************
REG :=============================
R 0(00000000)
R 1(00000001)
R 2(fff000e2)
R 3(ffffffff)
R 4(00000004)
R 5(00000005)
R 6(0000000a)
R 7(fcf0fdef)
116
R 8(00000008)
R 9(00000009)
R10(00000010)
R11(0000ff31)
R12(0000ff12)
R13(00000013)
R14(00000014)
R15(00000015)
R16(00000016)
R17(00fe0117)
R18(00fe0118)
R19(00fe0119)
R20(00fe0220)
R21(00fe0321)
R22(00fe0322)
R23(00ff0423)
R24(00ff0524)
R25(00ff0625)
R26(00ff0726)
R27(00ff0727)
R28(00f70728)
R29(00000029)
R30(00000030)
R31(00000031)
==================================
|
|
|
|
|
|
|
|
|
|
|
|
|
|
-----------------------|
IFU : mem=0xf160000a
|
IFU : pc= f at CSIM 103 ns
|
------------------------------|
ID: R6=10 at CSIM 105 ns
|
------------------------------|
ALU : op= 3 A= 10 B= 0
|
ALU : R= 10-> R6 at CSIM 107 ns
|
------------------------------|
ID: R6=0xa(10) fr ALU at CSIM 108 ns |
-----------------------|
IFU : mem=0x0
|
IFU : pc= 10 at CSIM 110 ns
|
------------------------------|
|
*******************************
|
ID: REGISTERS DUMP at CSIM 112 ns
|
*******************************
|
REG :=============================
|
R 0(00000000)
R 1(00000001)
|
R 2(fff000e2)
R 3(ffffffff)
|
R 4(00000004)
R 5(00000005)
|
R 6(0000000a)
R 7(fcf0fdef)
|
R 8(00000008)
R 9(00000009)
|
R10(00000010)
R11(0000ff31)
|
R12(0000ff12)
R13(00000013)
|
R14(00000014)
R15(00000015)
|
R16(00000016)
R17(00fe0117)
|
R18(00fe0118)
R19(00fe0119)
|
R20(00fe0220)
R21(00fe0321)
|
R22(00fe0322)
R23(00ff0423)
|
R24(00ff0524)
R25(00ff0625)
|
R26(00ff0726)
R27(00ff0727)
|
R28(00f70728)
R29(00000029)
|
R30(00000030)
R31(00000031)
|
Anhang C
R 8(00000008)
R 9(00000009)
R10(00000010)
R11(0000ff31)
R12(0000ff12)
R13(00000013)
R14(00000014)
R15(00000015)
R16(00000016)
R17(00fe0117)
R18(00fe0118)
R19(00fe0119)
R20(00fe0220)
R21(00fe0321)
R22(00fe0322)
R23(00ff0423)
R24(00ff0524)
R25(00ff0625)
R26(00ff0726)
R27(00ff0727)
R28(00f70728)
R29(00000029)
R30(00000030)
R31(00000031)
==================================
-----------------------IFU : mem=0xf160000a
IFU : pc= f at CSIM 103 ns
------------------------------ID: R6=10 at CSIM 105 ns
------------------------------ALU : op= 3 A= 10 B= 0
ALU : R= 10-> R6 at CSIM 107 ns
------------------------------ID: R6=0xa(10) fr ALU at CSIM 108 ns
-----------------------IFU : mem=0x0
IFU : pc= 10 at CSIM 110 ns
------------------------------*******************************
ID: REGISTERS DUMP at CSIM 112 ns
*******************************
REG :=============================
R 0(00000000)
R 1(00000001)
R 2(fff000e2)
R 3(ffffffff)
R 4(00000004)
R 5(00000005)
R 6(0000000a)
R 7(fcf0fdef)
R 8(00000008)
R 9(00000009)
R10(00000010)
R11(0000ff31)
R12(0000ff12)
R13(00000013)
R14(00000014)
R15(00000015)
R16(00000016)
R17(00fe0117)
R18(00fe0118)
R19(00fe0119)
R20(00fe0220)
R21(00fe0321)
R22(00fe0322)
R23(00ff0423)
R24(00ff0524)
R25(00ff0625)
R26(00ff0726)
R27(00ff0727)
R28(00f70728)
R29(00000029)
R30(00000030)
R31(00000031)
Anhang C
==================================
-----------------------IFU : mem=0xf1500005
IFU : pc= 11 at CSIM 117 ns
------------------------------ID: R5=5 at CSIM 119 ns
------------------------------ALU : op= 3 A= 5 B= 0
ALU : R= 5-> R5 at CSIM 121 ns
------------------------------ID: R5=0x5(5) fr ALU at CSIM 122 ns
-----------------------IFU : mem=0x0
IFU : pc= 12 at CSIM 124 ns
------------------------------*******************************
ID: REGISTERS DUMP at CSIM 126 ns
*******************************
REG :=============================
R 0(00000000)
R 1(00000001)
R 2(fff000e2)
R 3(ffffffff)
R 4(00000004)
R 5(00000005)
R 6(0000000a)
R 7(fcf0fdef)
R 8(00000008)
R 9(00000009)
R10(00000010)
R11(0000ff31)
R12(0000ff12)
R13(00000013)
R14(00000014)
R15(00000015)
R16(00000016)
R17(00fe0117)
R18(00fe0118)
R19(00fe0119)
R20(00fe0220)
R21(00fe0321)
R22(00fe0322)
R23(00ff0423)
R24(00ff0524)
R25(00ff0625)
R26(00ff0726)
R27(00ff0727)
R28(00f70728)
R29(00000029)
R30(00000030)
R31(00000031)
==================================
-----------------------IFU : mem=0xf550000
IFU : pc= 13 at CSIM 131 ns
------------------------------ID: R5=R5(=5)
: at CSIM 133 ns
------------------------------ALU : op= 3 A= 5 B= 0
ALU : R= 5-> R5 at CSIM 135 ns
-------------------------------
117
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
==================================
-----------------------IFU : mem=0xf1500005
IFU : pc= 11 at CSIM 117 ns
------------------------------ID: R5=5 at CSIM 119 ns
------------------------------ALU : op= 3 A= 5 B= 0
ALU : R= 5-> R5 at CSIM 121 ns
------------------------------ID: R5=0x5(5) fr ALU at CSIM 122 ns
-----------------------IFU : mem=0x0
IFU : pc= 12 at CSIM 124 ns
------------------------------*******************************
ID: REGISTERS DUMP at CSIM 126 ns
*******************************
REG :=============================
R 0(00000000)
R 1(00000001)
R 2(fff000e2)
R 3(ffffffff)
R 4(00000004)
R 5(00000005)
R 6(0000000a)
R 7(fcf0fdef)
R 8(00000008)
R 9(00000009)
R10(00000010)
R11(0000ff31)
R12(0000ff12)
R13(00000013)
R14(00000014)
R15(00000015)
R16(00000016)
R17(00fe0117)
R18(00fe0118)
R19(00fe0119)
R20(00fe0220)
R21(00fe0321)
R22(00fe0322)
R23(00ff0423)
R24(00ff0524)
R25(00ff0625)
R26(00ff0726)
R27(00ff0727)
R28(00f70728)
R29(00000029)
R30(00000030)
R31(00000031)
==================================
-----------------------IFU : mem=0xf550000
IFU : pc= 13 at CSIM 131 ns
------------------------------ID: R5=R5(=5)
: at CSIM 133 ns
------------------------------ALU : op= 3 A= 5 B= 0
ALU : R= 5-> R5 at CSIM 135 ns
-------------------------------
118
ID: R5=0x5(5) fr ALU at CSIM 136 ns
-----------------------IFU : mem=0x0
IFU : pc= 14 at CSIM 138 ns
------------------------------*******************************
ID: REGISTERS DUMP at CSIM 140 ns
*******************************
REG :=============================
R 0(00000000)
R 1(00000001)
R 2(fff000e2)
R 3(ffffffff)
R 4(00000004)
R 5(00000005)
R 6(0000000a)
R 7(fcf0fdef)
R 8(00000008)
R 9(00000009)
R10(00000010)
R11(0000ff31)
R12(0000ff12)
R13(00000013)
R14(00000014)
R15(00000015)
R16(00000016)
R17(00fe0117)
R18(00fe0118)
R19(00fe0119)
R20(00fe0220)
R21(00fe0321)
R22(00fe0322)
R23(00ff0423)
R24(00ff0524)
R25(00ff0625)
R26(00ff0726)
R27(00ff0727)
R28(00f70728)
R29(00000029)
R30(00000030)
R31(00000031)
==================================
-----------------------IFU : mem=0xf550000
IFU : pc= 15 at CSIM 145 ns
------------------------------ID: R5=R5(=5)
: at CSIM 147 ns
------------------------------ALU : op= 3 A= 5 B= 0
ALU : R= 5-> R5 at CSIM 149 ns
------------------------------ID: R5=0x5(5) fr ALU at CSIM 150 ns
-----------------------IFU : mem=0x0
IFU : pc= 16 at CSIM 152 ns
------------------------------*******************************
ID: REGISTERS DUMP at CSIM 154 ns
*******************************
REG :=============================
R 0(00000000)
R 1(00000001)
Anhang C
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ID: R5=0x5(5) fr ALU at CSIM 136 ns
-----------------------IFU : mem=0x0
IFU : pc= 14 at CSIM 138 ns
------------------------------*******************************
ID: REGISTERS DUMP at CSIM 140 ns
*******************************
REG :=============================
R 0(00000000)
R 1(00000001)
R 2(fff000e2)
R 3(ffffffff)
R 4(00000004)
R 5(00000005)
R 6(0000000a)
R 7(fcf0fdef)
R 8(00000008)
R 9(00000009)
R10(00000010)
R11(0000ff31)
R12(0000ff12)
R13(00000013)
R14(00000014)
R15(00000015)
R16(00000016)
R17(00fe0117)
R18(00fe0118)
R19(00fe0119)
R20(00fe0220)
R21(00fe0321)
R22(00fe0322)
R23(00ff0423)
R24(00ff0524)
R25(00ff0625)
R26(00ff0726)
R27(00ff0727)
R28(00f70728)
R29(00000029)
R30(00000030)
R31(00000031)
==================================
-----------------------IFU : mem=0xf550000
IFU : pc= 15 at CSIM 145 ns
------------------------------ID: R5=R5(=5)
: at CSIM 147 ns
------------------------------ALU : op= 3 A= 5 B= 0
ALU : R= 5-> R5 at CSIM 149 ns
------------------------------ID: R5=0x5(5) fr ALU at CSIM 150 ns
-----------------------IFU : mem=0x0
IFU : pc= 16 at CSIM 152 ns
------------------------------*******************************
ID: REGISTERS DUMP at CSIM 154 ns
*******************************
REG :=============================
R 0(00000000)
R 1(00000001)
Anhang C
R 2(fff000e2)
R 3(ffffffff)
R 4(00000004)
R 5(00000005)
R 6(0000000a)
R 7(fcf0fdef)
R 8(00000008)
R 9(00000009)
R10(00000010)
R11(0000ff31)
R12(0000ff12)
R13(00000013)
R14(00000014)
R15(00000015)
R16(00000016)
R17(00fe0117)
R18(00fe0118)
R19(00fe0119)
R20(00fe0220)
R21(00fe0321)
R22(00fe0322)
R23(00ff0423)
R24(00ff0524)
R25(00ff0625)
R26(00ff0726)
R27(00ff0727)
R28(00f70728)
R29(00000029)
R30(00000030)
R31(00000031)
==================================
-----------------------IFU : mem=0xf550000
IFU : pc= 17 at CSIM 159 ns
------------------------------ID: R5=R5(=5)
: at CSIM 161 ns
------------------------------ALU : op= 3 A= 5 B= 0
ALU : R= 5-> R5 at CSIM 163 ns
------------------------------ID: R5=0x5(5) fr ALU at CSIM 164 ns
-----------------------IFU : mem=0x0
IFU : pc= 18 at CSIM 166 ns
------------------------------*******************************
ID: REGISTERS DUMP at CSIM 168 ns
*******************************
REG :=============================
R 0(00000000)
R 1(00000001)
R 2(fff000e2)
R 3(ffffffff)
R 4(00000004)
R 5(00000005)
R 6(0000000a)
R 7(fcf0fdef)
R 8(00000008)
R 9(00000009)
R10(00000010)
R11(0000ff31)
R12(0000ff12)
R13(00000013)
R14(00000014)
R15(00000015)
R16(00000016)
R17(00fe0117)
R18(00fe0118)
R19(00fe0119)
R20(00fe0220)
R21(00fe0321)
R22(00fe0322)
R23(00ff0423)
119
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
R 2(fff000e2)
R 3(ffffffff)
R 4(00000004)
R 5(00000005)
R 6(0000000a)
R 7(fcf0fdef)
R 8(00000008)
R 9(00000009)
R10(00000010)
R11(0000ff31)
R12(0000ff12)
R13(00000013)
R14(00000014)
R15(00000015)
R16(00000016)
R17(00fe0117)
R18(00fe0118)
R19(00fe0119)
R20(00fe0220)
R21(00fe0321)
R22(00fe0322)
R23(00ff0423)
R24(00ff0524)
R25(00ff0625)
R26(00ff0726)
R27(00ff0727)
R28(00f70728)
R29(00000029)
R30(00000030)
R31(00000031)
==================================
-----------------------IFU : mem=0xf550000
IFU : pc= 17 at CSIM 159 ns
------------------------------ID: R5=R5(=5)
: at CSIM 161 ns
------------------------------ALU : op= 3 A= 5 B= 0
ALU : R= 5-> R5 at CSIM 163 ns
------------------------------ID: R5=0x5(5) fr ALU at CSIM 164 ns
-----------------------IFU : mem=0x0
IFU : pc= 18 at CSIM 166 ns
------------------------------*******************************
ID: REGISTERS DUMP at CSIM 168 ns
*******************************
REG :=============================
R 0(00000000)
R 1(00000001)
R 2(fff000e2)
R 3(ffffffff)
R 4(00000004)
R 5(00000005)
R 6(0000000a)
R 7(fcf0fdef)
R 8(00000008)
R 9(00000009)
R10(00000010)
R11(0000ff31)
R12(0000ff12)
R13(00000013)
R14(00000014)
R15(00000015)
R16(00000016)
R17(00fe0117)
R18(00fe0118)
R19(00fe0119)
R20(00fe0220)
R21(00fe0321)
R22(00fe0322)
R23(00ff0423)
120
R24(00ff0524)
R25(00ff0625)
R26(00ff0726)
R27(00ff0727)
R28(00f70728)
R29(00000029)
R30(00000030)
R31(00000031)
==================================
-----------------------IFU : mem=0xf550000
IFU : pc= 19 at CSIM 173 ns
------------------------------ID: R5=R5(=5)
: at CSIM 175 ns
------------------------------ALU : op= 3 A= 5 B= 0
ALU : R= 5-> R5 at CSIM 177 ns
------------------------------ID: R5=0x5(5) fr ALU at CSIM 178 ns
-----------------------IFU : mem=0x0
IFU : pc= 1a at CSIM 180 ns
------------------------------*******************************
ID: REGISTERS DUMP at CSIM 182 ns
*******************************
REG :=============================
R 0(00000000)
R 1(00000001)
R 2(fff000e2)
R 3(ffffffff)
R 4(00000004)
R 5(00000005)
R 6(0000000a)
R 7(fcf0fdef)
R 8(00000008)
R 9(00000009)
R10(00000010)
R11(0000ff31)
R12(0000ff12)
R13(00000013)
R14(00000014)
R15(00000015)
R16(00000016)
R17(00fe0117)
R18(00fe0118)
R19(00fe0119)
R20(00fe0220)
R21(00fe0321)
R22(00fe0322)
R23(00ff0423)
R24(00ff0524)
R25(00ff0625)
R26(00ff0726)
R27(00ff0727)
R28(00f70728)
R29(00000029)
R30(00000030)
R31(00000031)
==================================
-----------------------IFU : mem=0xf550000
IFU : pc= 1b at CSIM 187 ns
------------------------------ID: R5=R5(=5)
Anhang C
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
R24(00ff0524)
R25(00ff0625)
R26(00ff0726)
R27(00ff0727)
R28(00f70728)
R29(00000029)
R30(00000030)
R31(00000031)
==================================
-----------------------IFU : mem=0xf550000
IFU : pc= 19 at CSIM 173 ns
------------------------------ID: R5=R5(=5)
: at CSIM 175 ns
------------------------------ALU : op= 3 A= 5 B= 0
ALU : R= 5-> R5 at CSIM 177 ns
------------------------------ID: R5=0x5(5) fr ALU at CSIM 178 ns
-----------------------IFU : mem=0x0
IFU : pc= 1a at CSIM 180 ns
------------------------------*******************************
ID: REGISTERS DUMP at CSIM 182 ns
*******************************
REG :=============================
R 0(00000000)
R 1(00000001)
R 2(fff000e2)
R 3(ffffffff)
R 4(00000004)
R 5(00000005)
R 6(0000000a)
R 7(fcf0fdef)
R 8(00000008)
R 9(00000009)
R10(00000010)
R11(0000ff31)
R12(0000ff12)
R13(00000013)
R14(00000014)
R15(00000015)
R16(00000016)
R17(00fe0117)
R18(00fe0118)
R19(00fe0119)
R20(00fe0220)
R21(00fe0321)
R22(00fe0322)
R23(00ff0423)
R24(00ff0524)
R25(00ff0625)
R26(00ff0726)
R27(00ff0727)
R28(00f70728)
R29(00000029)
R30(00000030)
R31(00000031)
==================================
-----------------------IFU : mem=0xf550000
IFU : pc= 1b at CSIM 187 ns
------------------------------ID: R5=R5(=5)
Anhang C
: at CSIM 189 ns
------------------------------ALU : op= 3 A= 5 B= 0
ALU : R= 5-> R5 at CSIM 191 ns
------------------------------ID: R5=0x5(5) fr ALU at CSIM 192 ns
-----------------------IFU : mem=0x0
IFU : pc= 1c at CSIM 194 ns
------------------------------*******************************
ID: REGISTERS DUMP at CSIM 196 ns
*******************************
REG :=============================
R 0(00000000)
R 1(00000001)
R 2(fff000e2)
R 3(ffffffff)
R 4(00000004)
R 5(00000005)
R 6(0000000a)
R 7(fcf0fdef)
R 8(00000008)
R 9(00000009)
R10(00000010)
R11(0000ff31)
R12(0000ff12)
R13(00000013)
R14(00000014)
R15(00000015)
R16(00000016)
R17(00fe0117)
R18(00fe0118)
R19(00fe0119)
R20(00fe0220)
R21(00fe0321)
R22(00fe0322)
R23(00ff0423)
R24(00ff0524)
R25(00ff0625)
R26(00ff0726)
R27(00ff0727)
R28(00f70728)
R29(00000029)
R30(00000030)
R31(00000031)
==================================
-----------------------IFU : mem=0x2550001
IFU : pc= 1d at CSIM 201 ns
------------------------------ID: R5= R5(=5)+1
: at CSIM 203 ns
------------------------------ALU : op= 3 A= 5 B= 1
ALU : R= 6-> R5 at CSIM 205 ns
------------------------------ID: R5=0x6(6) fr ALU at CSIM 206 ns
-----------------------IFU : mem=0x0
IFU : pc= 1e at CSIM 208 ns
-------------------------------
121
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
: at CSIM 189 ns
------------------------------ALU : op= 3 A= 5 B= 0
ALU : R= 5-> R5 at CSIM 191 ns
------------------------------ID: R5=0x5(5) fr ALU at CSIM 192 ns
-----------------------IFU : mem=0x0
IFU : pc= 1c at CSIM 194 ns
------------------------------*******************************
ID: REGISTERS DUMP at CSIM 196 ns
*******************************
REG :=============================
R 0(00000000)
R 1(00000001)
R 2(fff000e2)
R 3(ffffffff)
R 4(00000004)
R 5(00000005)
R 6(0000000a)
R 7(fcf0fdef)
R 8(00000008)
R 9(00000009)
R10(00000010)
R11(0000ff31)
R12(0000ff12)
R13(00000013)
R14(00000014)
R15(00000015)
R16(00000016)
R17(00fe0117)
R18(00fe0118)
R19(00fe0119)
R20(00fe0220)
R21(00fe0321)
R22(00fe0322)
R23(00ff0423)
R24(00ff0524)
R25(00ff0625)
R26(00ff0726)
R27(00ff0727)
R28(00f70728)
R29(00000029)
R30(00000030)
R31(00000031)
==================================
-----------------------IFU : mem=0x2550001
IFU : pc= 1d at CSIM 201 ns
------------------------------ID: R5= R5(=5)+1
: at CSIM 203 ns
------------------------------ALU : op= 3 A= 5 B= 1
ALU : R= 6-> R5 at CSIM 205 ns
------------------------------ID: R5=0x6(6) fr ALU at CSIM 206 ns
-----------------------IFU : mem=0x0
IFU : pc= 1e at CSIM 208 ns
-------------------------------
122
*******************************
ID: REGISTERS DUMP at CSIM 210 ns
*******************************
REG :=============================
R 0(00000000)
R 1(00000001)
R 2(fff000e2)
R 3(ffffffff)
R 4(00000004)
R 5(00000006)
R 6(0000000a)
R 7(fcf0fdef)
R 8(00000008)
R 9(00000009)
R10(00000010)
R11(0000ff31)
R12(0000ff12)
R13(00000013)
R14(00000014)
R15(00000015)
R16(00000016)
R17(00fe0117)
R18(00fe0118)
R19(00fe0119)
R20(00fe0220)
R21(00fe0321)
R22(00fe0322)
R23(00ff0423)
R24(00ff0524)
R25(00ff0625)
R26(00ff0726)
R27(00ff0727)
R28(00f70728)
R29(00000029)
R30(00000030)
R31(00000031)
==================================
-----------------------IFU : mem=0x1156fffa
IFU : pc= 1f at CSIM 215 ns
------------------------------ID: bne R5(=6), R6(=10), pc+=(-6).
ID: at CSIM 217 ns
------------------------------ALU : op= 3 A= 0 B= 0
ALU : R= 0-> R0 at CSIM 219 ns
------------------------------ID: R0=0x0(0) fr ALU at CSIM 220 ns
-----------------------IFU : mem=0x0
IFU : pc= 20 at CSIM 222 ns
-----------------------IFU ALERT: **BRANCH**
------------------------------*******************************
ID: REGISTERS DUMP at CSIM 224 ns
*******************************
REG :=============================
R 0(00000000)
R 1(00000001)
R 2(fff000e2)
R 3(ffffffff)
R 4(00000004)
R 5(00000006)
R 6(0000000a)
R 7(fcf0fdef)
R 8(00000008)
R 9(00000009)
Anhang C
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
*******************************
ID: REGISTERS DUMP at CSIM 210 ns
*******************************
REG :=============================
R 0(00000000)
R 1(00000001)
R 2(fff000e2)
R 3(ffffffff)
R 4(00000004)
R 5(00000006)
R 6(0000000a)
R 7(fcf0fdef)
R 8(00000008)
R 9(00000009)
R10(00000010)
R11(0000ff31)
R12(0000ff12)
R13(00000013)
R14(00000014)
R15(00000015)
R16(00000016)
R17(00fe0117)
R18(00fe0118)
R19(00fe0119)
R20(00fe0220)
R21(00fe0321)
R22(00fe0322)
R23(00ff0423)
R24(00ff0524)
R25(00ff0625)
R26(00ff0726)
R27(00ff0727)
R28(00f70728)
R29(00000029)
R30(00000030)
R31(00000031)
==================================
-----------------------IFU : mem=0x1156fffa
IFU : pc= 1f at CSIM 215 ns
------------------------------ID: bne R5(=6), R6(=10), pc+=(-6).
ID: at CSIM 217 ns
------------------------------ALU : op= 3 A= 0 B= 0
ALU : R= 0-> R0 at CSIM 219 ns
------------------------------ID: R0=0x0(0) fr ALU at CSIM 220 ns
-----------------------IFU : mem=0x0
IFU : pc= 20 at CSIM 222 ns
-----------------------IFU ALERT: **BRANCH**
------------------------------*******************************
ID: REGISTERS DUMP at CSIM 224 ns
*******************************
REG :=============================
R 0(00000000)
R 1(00000001)
R 2(fff000e2)
R 3(ffffffff)
R 4(00000004)
R 5(00000006)
R 6(0000000a)
R 7(fcf0fdef)
R 8(00000008)
R 9(00000009)
Anhang C
R10(00000010)
R11(0000ff31)
R12(0000ff12)
R13(00000013)
R14(00000014)
R15(00000015)
R16(00000016)
R17(00fe0117)
R18(00fe0118)
R19(00fe0119)
R20(00fe0220)
R21(00fe0321)
R22(00fe0322)
R23(00ff0423)
R24(00ff0524)
R25(00ff0625)
R26(00ff0726)
R27(00ff0727)
R28(00f70728)
R29(00000029)
R30(00000030)
R31(00000031)
==================================
-----------------------IFU : mem=0x0
IFU : pc= 20 at CSIM 229 ns
-----------------------*******************************
ID: REGISTERS DUMP at CSIM 231 ns
*******************************
REG :=============================
R 0(00000000)
R 1(00000001)
R 2(fff000e2)
R 3(ffffffff)
R 4(00000004)
R 5(00000006)
R 6(0000000a)
R 7(fcf0fdef)
R 8(00000008)
R 9(00000009)
R10(00000010)
R11(0000ff31)
R12(0000ff12)
R13(00000013)
R14(00000014)
R15(00000015)
R16(00000016)
R17(00fe0117)
R18(00fe0118)
R19(00fe0119)
R20(00fe0220)
R21(00fe0321)
R22(00fe0322)
R23(00ff0423)
R24(00ff0524)
R25(00ff0625)
R26(00ff0726)
R27(00ff0727)
R28(00f70728)
R29(00000029)
R30(00000030)
R31(00000031)
==================================
IFU ALERT: **BRANCH**
-----------------------IFU : mem=0x0
IFU : pc= 20 at CSIM 237 ns
------------------------------ID: clear branch at CSIM 238 ns
------------------------------*******************************
123
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
R10(00000010)
R11(0000ff31)
R12(0000ff12)
R13(00000013)
R14(00000014)
R15(00000015)
R16(00000016)
R17(00fe0117)
R18(00fe0118)
R19(00fe0119)
R20(00fe0220)
R21(00fe0321)
R22(00fe0322)
R23(00ff0423)
R24(00ff0524)
R25(00ff0625)
R26(00ff0726)
R27(00ff0727)
R28(00f70728)
R29(00000029)
R30(00000030)
R31(00000031)
==================================
-----------------------IFU : mem=0x0
IFU : pc= 20 at CSIM 229 ns
-----------------------*******************************
ID: REGISTERS DUMP at CSIM 231 ns
*******************************
REG :=============================
R 0(00000000)
R 1(00000001)
R 2(fff000e2)
R 3(ffffffff)
R 4(00000004)
R 5(00000006)
R 6(0000000a)
R 7(fcf0fdef)
R 8(00000008)
R 9(00000009)
R10(00000010)
R11(0000ff31)
R12(0000ff12)
R13(00000013)
R14(00000014)
R15(00000015)
R16(00000016)
R17(00fe0117)
R18(00fe0118)
R19(00fe0119)
R20(00fe0220)
R21(00fe0321)
R22(00fe0322)
R23(00ff0423)
R24(00ff0524)
R25(00ff0625)
R26(00ff0726)
R27(00ff0727)
R28(00f70728)
R29(00000029)
R30(00000030)
R31(00000031)
==================================
IFU ALERT: **BRANCH**
-----------------------IFU : mem=0x0
IFU : pc= 20 at CSIM 237 ns
------------------------------ID: clear branch at CSIM 238 ns
------------------------------*******************************
124
ID: REGISTERS DUMP at CSIM 239 ns
*******************************
REG :=============================
R 0(00000000)
R 1(00000001)
R 2(fff000e2)
R 3(ffffffff)
R 4(00000004)
R 5(00000006)
R 6(0000000a)
R 7(fcf0fdef)
R 8(00000008)
R 9(00000009)
R10(00000010)
R11(0000ff31)
R12(0000ff12)
R13(00000013)
R14(00000014)
R15(00000015)
R16(00000016)
R17(00fe0117)
R18(00fe0118)
R19(00fe0119)
R20(00fe0220)
R21(00fe0321)
R22(00fe0322)
R23(00ff0423)
R24(00ff0524)
R25(00ff0625)
R26(00ff0726)
R27(00ff0727)
R28(00f70728)
R29(00000029)
R30(00000030)
R31(00000031)
==================================
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
-----------------------|
IFU : mem=0x1123000
|
IFU : pc= 21 at CSIM 244 ns
|
------------------------------|
ID: R1= R2(=-1048350)+R3(=-1)
|
: at CSIM 246 ns
|
------------------------------|
ALU : op= 3 A= -1048350 B= -1
|
ALU : R= -1048351-> R1 at CSIM 248ns |
------------------------------|
ID: R1=0xfff000e1(-1048351) fr ALU
|
at CSIM 249 ns
|
-----------------------|
IFU : mem=0x0
|
IFU : pc= 22 at CSIM 251 ns
|
------------------------------|
|
*******************************
|
ID: REGISTERS DUMP at CSIM 253 ns
|
*******************************
|
REG :=============================
|
R 0(00000000)
R 1(fff000e1)
|
R 2(fff000e2)
R 3(ffffffff)
|
R 4(00000004)
R 5(00000006)
|
R 6(0000000a)
R 7(fcf0fdef)
|
R 8(00000008)
R 9(00000009)
|
R10(00000010)
R11(0000ff31)
|
R12(0000ff12)
R13(00000013)
|
Anhang C
ID: REGISTERS DUMP at CSIM 239 ns
*******************************
REG :=============================
R 0(00000000)
R 1(00000001)
R 2(fff000e2)
R 3(ffffffff)
R 4(00000004)
R 5(00000006)
R 6(0000000a)
R 7(fcf0fdef)
R 8(00000008)
R 9(00000009)
R10(00000010)
R11(0000ff31)
R12(0000ff12)
R13(00000013)
R14(00000014)
R15(00000015)
R16(00000016)
R17(00fe0117)
R18(00fe0118)
R19(00fe0119)
R20(00fe0220)
R21(00fe0321)
R22(00fe0322)
R23(00ff0423)
R24(00ff0524)
R25(00ff0625)
R26(00ff0726)
R27(00ff0727)
R28(00f70728)
R29(00000029)
R30(00000030)
R31(00000031)
==================================
-----------------------IFU : mem=0x1123000
IFU : pc= 21 at CSIM 244 ns
------------------------------ID: R1= R2(=-1048350)+R3(=-1)
: at CSIM 246 ns
------------------------------ALU : op= 3 A= -1048350 B= -1
ALU : R= -1048351-> R1 at CSIM 248ns
------------------------------ID: R1=0xfff000e1(-1048351) fr ALU
at CSIM 249 ns
-----------------------IFU : mem=0x0
IFU : pc= 22 at CSIM 251 ns
------------------------------*******************************
ID: REGISTERS DUMP at CSIM 253 ns
*******************************
REG :=============================
R 0(00000000)
R 1(fff000e1)
R 2(fff000e2)
R 3(ffffffff)
R 4(00000004)
R 5(00000006)
R 6(0000000a)
R 7(fcf0fdef)
R 8(00000008)
R 9(00000009)
R10(00000010)
R11(0000ff31)
R12(0000ff12)
R13(00000013)
Anhang C
R14(00000014)
R15(00000015)
R16(00000016)
R17(00fe0117)
R18(00fe0118)
R19(00fe0119)
R20(00fe0220)
R21(00fe0321)
R22(00fe0322)
R23(00ff0423)
R24(00ff0524)
R25(00ff0625)
R26(00ff0726)
R27(00ff0727)
R28(00f70728)
R29(00000029)
R30(00000030)
R31(00000031)
==================================
-----------------------IFU : mem=0x1234000
IFU : pc= 23 at CSIM 258 ns
------------------------------ID: R2= R3(=-1)+R4(=4)
: at CSIM 260 ns
------------------------------ALU : op= 3 A= -1 B= 4
ALU : R= 3-> R2 at CSIM 262 ns
------------------------------ID: R2=0x3(3) fr ALU at CSIM 263 ns
-----------------------IFU : mem=0x0
IFU : pc= 24 at CSIM 265 ns
------------------------------*******************************
ID: REGISTERS DUMP at CSIM 267 ns
*******************************
REG :=============================
R 0(00000000)
R 1(fff000e1)
R 2(00000003)
R 3(ffffffff)
R 4(00000004)
R 5(00000006)
R 6(0000000a)
R 7(fcf0fdef)
R 8(00000008)
R 9(00000009)
R10(00000010)
R11(0000ff31)
R12(0000ff12)
R13(00000013)
R14(00000014)
R15(00000015)
R16(00000016)
R17(00fe0117)
R18(00fe0118)
R19(00fe0119)
R20(00fe0220)
R21(00fe0321)
R22(00fe0322)
R23(00ff0423)
R24(00ff0524)
R25(00ff0625)
R26(00ff0726)
R27(00ff0727)
R28(00f70728)
R29(00000029)
R30(00000030)
R31(00000031)
==================================
125
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
R14(00000014)
R15(00000015)
R16(00000016)
R17(00fe0117)
R18(00fe0118)
R19(00fe0119)
R20(00fe0220)
R21(00fe0321)
R22(00fe0322)
R23(00ff0423)
R24(00ff0524)
R25(00ff0625)
R26(00ff0726)
R27(00ff0727)
R28(00f70728)
R29(00000029)
R30(00000030)
R31(00000031)
==================================
-----------------------IFU : mem=0x1234000
IFU : pc= 23 at CSIM 258 ns
------------------------------ID: R2= R3(=-1)+R4(=4)
: at CSIM 260 ns
------------------------------ALU : op= 3 A= -1 B= 4
ALU : R= 3-> R2 at CSIM 262 ns
------------------------------ID: R2=0x3(3) fr ALU at CSIM 263 ns
-----------------------IFU : mem=0x0
IFU : pc= 24 at CSIM 265 ns
------------------------------*******************************
ID: REGISTERS DUMP at CSIM 267 ns
*******************************
REG :=============================
R 0(00000000)
R 1(fff000e1)
R 2(00000003)
R 3(ffffffff)
R 4(00000004)
R 5(00000006)
R 6(0000000a)
R 7(fcf0fdef)
R 8(00000008)
R 9(00000009)
R10(00000010)
R11(0000ff31)
R12(0000ff12)
R13(00000013)
R14(00000014)
R15(00000015)
R16(00000016)
R17(00fe0117)
R18(00fe0118)
R19(00fe0119)
R20(00fe0220)
R21(00fe0321)
R22(00fe0322)
R23(00ff0423)
R24(00ff0524)
R25(00ff0625)
R26(00ff0726)
R27(00ff0727)
R28(00f70728)
R29(00000029)
R30(00000030)
R31(00000031)
==================================
126
-----------------------IFU : mem=0xffffffff
IFU : pc= 25 at CSIM 272 ns
------------------------------ID: - SHUTDOWN - at CSIM 274 ns
ID: - PLEASE WAIT ...... -------------------------------
Anhang C
|
|
|
|
|
|
|
-----------------------IFU : mem=0xffffffff
IFU : pc= 25 at CSIM 272 ns
------------------------------ID: - SHUTDOWN - at CSIM 274 ns
ID: - PLEASE WAIT ...... -------------------------------
Anhang D
D
127
Inhalt der Quellcode-CD
Zur Sammlung und Bereitstellung der Daten, die im Rahmen dieser Arbeit
erstellt wurden, dient eine CD-ROM. Sie liegt dieser Arbeit bei. In diesem
Abschnitt soll der Inhalt der CD-ROM kurz dargestellt werden, um einen
¨
besseren Uberblick
zu gew¨ahrleisten. Die Verzeichnisstruktur gliedert sich
wie folgt:
[+]/
|-[+]Doc
|
|-[+]Bilder
|
|-[+]Programme
|
|-[+]Epp-speedtest
|
|
|-[+]Hardware
|
|
|-[+]Software
|
|
|
|-[+]Simifb-generator
|
|
|-[+]Templates
|
|
|
|-[+]Timedrun
|
|-[+]Sources
|
|-[+]Epp-speedtest
|
|
|-[+]Hardware
|
|
|-[+]Software
|
|
|
|-[+]Simifb-generator
|
|-[+]Timedrun
|
|-[+]Testdesigns
|-[+]Counter_8bit
|
|-[+]Sifbgen-output
|
|-[+]Simulation
|
|-[+]SystemC
|
|-[+]Vhdl
|
|-[+]Risc_cpu_original
|
|-[+]Simulation
|
|-[+]SystemC
|
|-[+]Risc_cpu_simifb
|-[+]Intexecunit
|-[+]Sifbgen-output
|-[+]Simulation
|-[+]SystemC
128
Anhang D
Im Rootverzeichnis befinden sich die Dateien cd-directories.txt und cd-content.txt.
Cd-directories.txt enth¨alt die Verzeichnisstruktur der CD-ROM. In cd-content.txt
sind alle Dateien der CD-ROM mit ihren Verzeichnissen aufgelistet.
D.1
Verzeichnis DOC
Das Verzeichnis DOC beinhaltet diese Arbeit als PDF-Dokument. Im Unterverzeichnis BILDER befinden sich die zu dieser Arbeit erstellten Bilder.
Bilder, die aus anderen Dokumenten oder von Websiten stammen, sind im
Text mit Quellenangaben versehen und nicht im Verzeichnis enthalten. Die
Bilder liegen im EPS-Format vor.
D.2
Verzeichnis PROGRAMME
Im Verzeichnis PROGRAMME befinden sich die Programme, die im Rahmen
dieser Arbeit entstanden. An dieser Stelle sind nur die zur Ausf¨
uhrung notwendigen Dateien vorzufinden. Die Quelltexte liegen im Verzeichnis SOURCES.
■ Programme/Epp-speedtest
Epp-speedtest dient zur Messung der Geschwindigkeit der parallelen Schnittstelle. Die Messeinrichtung besteht aus einer Hardwarekomponente im Unterverzeichnis Hardware und einer Softwarekomponente im Unterverzeichnis Software. Die Hardwarekomponente wird durch eine Konfigurationsdatei
speedtest.bit realisiert. Sie dient zur Konfiguration der Xilinx FPGA Spartan
XC2S200E-PQ208 auf dem Digilab 2E Developmentboard und sollte auch nur
f¨
ur diesen Typ verwendet werden. Die Softwarekomponente bildet das Programm speedtext sw.exe. Die Datei readme.txt enth¨alt eine Anleitung zur
Nutzung der beiden Teile.
■ Programme/Simifb-generator
Simifb generator.exe ist die Datei zum Starten des SimulationsinterfaceblockGenerators. Die Benutzung des Programms ist in Kapitel 4, speziell in Abschnitt 4.3, ausf¨
uhrlich dargestellt. Die Datei readme.txt enth¨alt eine kurze
Anhang D
129
Anleitung zum Starten des Programms. Das Unterverzeichnis TEMPLATES
wird im folgenden Abschnitt beschrieben. Welche Dateien es enthalten muss,
gibt die Datei template-content.txt an.
■ Programme/Simifb-generator/Templates
Im TEMPLATES-Verzeichnis befinden sich die Templates, die zum Erstellen
eines Simulationsinterfaceblocks notwendig sind. Wenn das Verzeichnis um¨
benannt oder verschoben werden muss, dann sind Anderungen
im Quelltext
und ein erneutes Kompilieren des Programms notwendig.
Folgende Dateien m¨
ussen in diesem Verzeichnis enthalten sein, damit der
Simulationsinterfaceblock-Generator seine Arbeit korrekt erf¨
ullen kann:
Softwareteil
| Hardwareteil
------------------------------------------------------------CUsw.cpp.t
| auto_reset.vhd.t
CUsw.h.t
| cu.vhd.t
Dlportio.h.t
| data_splitting_off.vhd.t
DLPORTIO.lib.t
| handlercontrol.vhd.t
EppIFsw.h.t
| ifb.vhd.t
EppIFsw.cpp.t
| phandler_out.vhd.t
epp.vhd.t
| phandler_in.vhd.t
PHsw-Mode-ReadSimData.h.t
| phin_mode_01.vhd.t
PHsw-Mode-WriteSimData.h.t
| phout_mode_01.vhd.t
PHsw-Mode-ReadSimData.cpp.t
| shandler.vhd.t
PHsw-Mode-WriteSimData.cpp.t | sh_mode_01.vhd.t
StdAfx.h.t
| simdata_ctrl.vhd.t
| sim_ctrl.vhd.t
| sim_environment_HW.vhd.t
| sim_environment_hw.ucf.t
|
■ Programme/Timedrun
Das Programm timedrun.exe dient zur Messung der Ausf¨
uhrungszeit eines
Programms. Eine Anleitung zur Nutzung enth¨alt readme.txt. In den Skripten
copy simulation.bat und run.bat k¨onnen Befehle eingetragen werden. Das
erste Skript f¨allt dabei nicht unter die Zeitmessung. Die Messung umfasst
allein die Ausf¨
uhrung von run.bat.
130
D.3
Anhang D
Verzeichnis SOURCES
Das Verzeichnis SOURCES enth¨alt die Quellcodes, die Projektdateien und
die Ausgaben von Kompilation und Implementierung zu den Programmen
im Verzeichnis PROGRAMME.
■ Sources/Epp-speedtest
Im Unterverzeichnis SPEEDTEST HW befindet sich das Projekt, die VHDLQuellcodes und die Implementierungsdaten zum Hardwareteil der Messeinrichtung. Sie wurden mit der Entwicklungsumgebung Xilinx ISE 5 erstellt.
Das Unterverzeichnis SPEEDTEST SW enth¨alt die Projektdatei, die C/C++Quellcodes und die Kompilationsdaten zum Softwareteil der Messeinrichtung.
Ihre Erstellung erfolgte mit Hilfe der C/C++-Entwicklungsumgebung Microsoft Visual C++ 6.
■ Sources/Simifb-generator
Diese Verzeichnis beinhaltet das Projekt f¨
ur den SimulationsinterfaceblockGenerator . Außerdem liegen in diesem Verzeichnis die Quellcodes und die
Kompilationsdaten zum Simulationsinterfaceblock-Generator . Das Projekt
wurde mit der C/C++-Entwicklungsumgebung Microsoft Visual C++ 6 bearbeitet.
■ Sources/Timedrun
In diesem Verzeichnis befindet sich das Projekt zum Erstellen des Programms
zur Messung der Simulationszeit. Es umfasst die Quellcodes und die kompilierten Daten. Erstellt wurde es mit Hilfe der C/C++-Entwicklungsumgebung
Microsoft Visual C++ 6.
D.4
Verzeichnis TESTDESIGNS
Das Verzeichnis TESTDESIGNS enth¨alt Projekte zum Testen der Funktionalit¨at des Simulationsinterfaceblocks und des Simulationsinterfaceblock-Generators. Das Unterverzeichnis RISC CPU SIMIFB beinhaltet dabei den Demonstrator, der in Kapitel 5 vorgestellt wurde.
Anhang D
131
■ Testdesigns/Counter 8bit
Das Unterverzeichnis SIFBGEN-OUTPUT enth¨alt die Ausgaben des Simulationsinterfaceblock-Generators zum VHDL-Design aus dem Unterverzeichnis
VHDL.
In SIMULATION befinden sich die ausf¨
uhrbare Datei sw ifb counter8bit.exe
zur Durchf¨
uhrung der Simulation und das Logfile sw ifb counter8bit.log, das
die Ausgaben der Simulation enth¨alt. Außerdem stehen zur Durchf¨
uhrung einer Zeitmessung die Dateien timedrun.exe, copy simulation.bat und run.bat
zur Verf¨
ugung. Die Datei time taken by run.log enth¨alt die daf¨
ur ben¨otigte
Zeit.
Im Unterverzeichnis SYSTEMC liegt das SystemC-Design, aus dem die Simulation erstellt wurde. Es enth¨alt die Projektdateien, die Quellcodes und
die kompilierten Daten. Das Projekt wurde mit der C/C++-Entwicklungs¨
umgebung Microsoft Visual C++ 6 bearbeitet. Zur erneuten Ubersetzung
m¨
ussen die Einstellungen f¨
ur die Pfade auf die aktuellen Gegebenheiten angepasst werden.
Die VHDL-Quellcodes, die als Eingabe f¨
ur den SimulationsinterfaceblockGenerator dienten, befinden sich im Unterverzeichnis VHDL. Die Dateien
counter 8bit.vhd und shift l16.vhd beschreiben einen 8 Bit-Z¨ahler und ein
16 Bit-Schieberegister.
■ Testdesigns/Risc cpu original
Das Unterverzeichnis SIMULATION beinhaltet die Dateien zur Simulation
der originalen RISC-CPU. Es existieren zwei Versionen der Simulation. Zum
Einen die Version, die f¨
ur die Zeitmessung aus Abschnitt 5.4.2 Verwendung
fand. Bei ihr wurden die Ausgaben des Moduls exec.cpp entfernt. Ihre Dateinamen besitzen den Zusatz timed“. Dazu geh¨oren die folgenden Dateien:
”
risc cpu timed.exe: ausf¨
uhrbare Datei zum Starten der Simulation
risc cpu timed.log: Logfile mit den Ausgaben der Simulation
time taken by run timed.log: Ergebnisse der Zeitmessung
Die zweite Version verf¨
ugt u
¨ber die vollst¨andigen Ausgaben. Folgende Dateien z¨ahlen zu dieser Version:
132
Anhang D
risc cpu.exe: ausf¨
uhrbare Datei zum Starten der Simulation
risc cpu.log: Logfile mit den Ausgaben der Simulation
Des Weiteren befinden sich im Verzeichnis SIMULATION die Dateien zur
Zeitmessung (timedrun.exe, run.bat, copy simulation.bat) sowie die Eingabedaten f¨
ur den Testbench (bios, dcache, icache, register).
Im Unterverzeichnis SYSTEMC befinden sich die Quelltexte des originalen
SystemC-Designs der RISC-CPU, wie es in den Beispielen zu SystemC vorhanden ist. Der einzige Zusatz ist die Projektdatei f¨
ur Microsoft Visual C++
¨
6 und die Kompilation der Quelldateien. Zur erneuten Ubersetzung
m¨
ussen
die Einstellungen f¨
ur die Pfade auf die aktuellen Gegebenheiten angepasst
werden.
■ Testdesigns/Risc cpu simifb
INTEXECUNIT enth¨alt das Xilinx ISE 5-Projekt, in dem die VHDL-Beschreibung der Integer-Executionunit erstellt wurde. Zum Projekt geh¨oren
Quelltexte, Testbenches und Implementierungsdaten.
Das Unterverzeichnis SIFBGEN-OUTPUT enth¨alt die Ausgaben des Simulationsinterfaceblock-Generators. Als Eingaben dienten die VHDL-Quelldateien
aus dem Verzeichnis INTEXECUNIT.
Im Unterverzeichnis SIMULATION befinden sich die Dateien zur Simulation des modifizierten RISC-CPU-Design mit Simulationsinterfaceblock. Es
existieren zwei Versionen der Simulation. Zum Einen die Version, die f¨
ur die
Zeitmessung aus Abschnitt 5.4.2 Verwendung fand. Bei ihr wurden die Ausgaben des generierten Moduls exec.cpp entfernt. Ihre Dateinamen besitzen
den Zusatz timed“. Dazu geh¨oren die folgenden Dateien:
”
risc cpu timed.exe: ausf¨
uhrbare Datei zum Starten der Simulation
risc cpu timed.log: Logfile mit den Ausgaben der Simulation
time taken by run timed.log: Ergebnisse der Zeitmessung
Die zweite Version verf¨
ugt u
¨ber die vollst¨andigen Ausgaben. Folgende Dateien z¨ahlen zu dieser Version:
Anhang D
133
risc cpu.exe: ausf¨
uhrbare Datei zum Starten der Simulation
risc cpu.log: Logfile mit den Ausgaben der Simulation
Des Weiteren befinden sich im Verzeichnis SIMULATION die Dateien zur
Zeitmessung (timedrun.exe, run.bat, copy simulation.bat) sowie die Eingabedaten f¨
ur den Testbench (bios, dcache, icache, register).
Das Unterverzeichnis SYSTEMC enth¨alt das Projekt, die Quelltexte und
die kompilierten Daten f¨
ur die Erstellung der Simulation der modifizierten
RISC-CPU. Das Projekt wurde mit Microsoft Visual C++ 6 bearbeitet. Zur
¨
erneuten Ubersetzung
m¨
ussen die Einstellungen f¨
ur die Pfade auf die aktuellen Gegebenheiten angepasst werden.
134
135
Literatur
[AB96]
Sorin A. Huss Klaus Waldschmidt Andreas Bleck, Michael Goedecke. Praktikum des modernen VLSI-Entwurfs. B. G. Teubner,
Stuttgart, 1996.
[Alt]
Altera Corporation. Altera: Leaders in FPGAs, CPLDs, and
Structured ASICs. http://www.altera.com/. Homepage.
[Apt]
r
Aptix
Corporation. www.aptix.com. Homepage.
[Apt00]
r
Aptix
Corporation. System Explorer - Reconfigurable System
Prototyping for SoC Emulation, 2000. Brosch¨
ure zum System
TM
Explorer .
[Atm]
Atmel
Corporation.
http://www.atmel.com/. Homepage.
[Axe97]
Jan Axelson. Parallel Port Complete. Lakeview Research, Madison, USA, 1997.
[Dem93]
Klaus Dembowski. Computerschnittstellen und Bussysteme.
Markt-und-Technik-Verlag, Haar bei M¨
unchen, 1993.
[Dig]
Digilent Inc. http://www.digilentinc.com. Homepage.
[Dig02]
Digilent Inc. Digilab 2E Reference Manual, 14. April 2002.
www.digilentinc.com.
[Els94]
J¨
urgen Elsing. Schnittstellen-Handbuch: verst¨andliche Erl¨auterung und Benutzung von Centronics, V24, IEC-Bus. IWT Verlag
GmbH, Vaterstetten bei M¨
unchen, 1994. 4. Auflage.
[Fic03]
Oliver Fick. Verschl¨
usselung von Parametern komplexer Schnittstellen f¨
ur eingebettete Systeme auf Basis von XML. Studienarbeit, Universit¨at Paderborn, 2003.
[Fla03]
Marcel Flade. FPGA-basierte Fail-safe-Schnittstellen f¨
ur eingebettete Systeme. Studienarbeit, Technische Universit¨at Chemnitz, 2003.
TM
Atmel
Corporation.
136
[GL94]
Manfred Selz Gunther Lehmann, Bernhard Wunder. Schaltungsdesign mit VHDL - Synthese, Simulation und Dokumentation digitaler Schaltungen. Franzis-Verlag GmbH, Poing, 1994.
[Har02]
Dr. Wolfram Hardt. Integration von Verz¨ogerungszeit-Invarianz
in den Entwurf eingebetteter Systeme. Shaker Verlag, Aachen,
2002.
[Har03]
Prof. Dr. Wolfram Hardt. Hardware-Software Codesign. Vorlesung, Technische Universit¨at Chemnitz, 2003.
[Har04]
Prof. Dr. Wolfram Hardt. Hardware-Software Codesign II. Vorlesung, Technische Universit¨at Chemnitz, 2003/2004.
[HVI01]
Wolfram Hardt, Markus Visarius, and Stefan Ihmor. Rapid prototyping of real-time interfaces. In Field Programmable Logic
(FPL) - Poster Session, Belfast, Northern Ireland, UK, October
2001.
[IBJK+ 03] Stefan Ihmor, Nilson Bastos Jr., Rafael Cardoso Klein, Markus
Visarius, and Wolfram Hardt. Rapid Prototyping of Realtime
Communication - A Case Study: Interacting Robots. June 2003.
[IH04]
Stefan Ihmor and Wolfram Hardt. Runtime Reconfigurable Interfaces - The RTR-IFB Approach. 18th International Parallel
and Distributed Processing Symposium (IPDPS’04) - Workshop
3, April 2004. Santa Fe, New Mexico, USA.
[Ihm01]
Stefan Ihmor. Entwurf von Echtzeitschnittstellen am Beispiel
interagierender Roboter. Diplomarbeit, Universit¨at Paderborn,
2001.
[Int]
Intel Coporation. Intel Research - Silicon - Moore’s Law.
http://www.intel.com/research/silicon/mooreslaw.htm. Homepage.
[ipq]
Projekt IPQ - Home Page. https://www.ip-qualifikation.de.
[IVH02a]
Stefan Ihmor, Markus Visarius, and Wolfram Hardt. A Consistent Design Methodology for Configurable HW/SW-Interfaces in
Embedded Systems. Montreal, Canada, Aug. 2002.
[IVH02b]
Stefan Ihmor, Markus Visarius, and Wolfram Hardt. A Design
Methodology for Application-specific Real-Time Interfaces. In
137
Proc. of the International Conference on Computer Design, Freiburg, Germany, Sept. 2002.
[IVH03]
Stefan Ihmor, Markus Visarius, and Wolfram Hardt. Modeling of
Configurable HW/SW-Interfaces. pages 51 – 60, Feb. 2003.
[Lat]
Lattice Semiconductor Corporation. FPGA, CPLD and SERDES Programmable Logic Devices by Lattice Semiconductor.
http://www.vantis.com/. Homepage.
[Mar02]
Norbet Schuhmann Martin Speitel. Erfahrungen mit Intellectual
Property. www.elektroniknet.de, 2002.
[M¨ad]
Andreas M¨ader. Vhdl kompakt. http://tech-www.informatik.unihamburg.de/vhdl/doc/kurzanleitung/vhdl.pdf.
[Mena]
Mentor Graphics Corp. www.mentor.com. Homepage.
[Menb]
Mentor Graphics Corp. High-Performance System Integration
Verification: VStation. http://www.mentor.com/vstation/. Homepage.
[Menc]
Mentor Graphics Corp.
VStationPRO High-Performance
System
Verification.
http://www.mentor.com/vstation/vstation pro.html. Homepage.
[Mend]
Mentor Graphics Corp.
VStationTBX - High-Performance
Verification Accelerator.
http://www.mentor.com/vstation/vstation tbx.html. Homepage.
[Men03]
Mentor Graphics Corp. VStationPRO High-Performance System
Verification, 2003. Brosch¨
ure zur VStationPro.
[Men04]
Mentor Graphics Corp.
VStationTBX - Datasheet, 2004.
Brosch¨
ure zur VStationTBX.
[Mic04]
Microsoft Corporation.
Geistiges Eigentum - Definition.
http://www.microsoft.com/germany/digitalmentality/definition.mspx, 2004. Homepage.
[M¨
ul02]
Prof. Dr. Dietmar M¨
uller. Entwurfssysteme. Vorlesung, Technische Universit¨at Chemnitz, 2002.
[M¨
ul03]
Prof. Dr. Dietmar M¨
uller. ASIC Entwurf. Vorlesung, Technische
Universit¨at Chemnitz, 2003.
138
[Mod]
Model Technology. www.model.com. Homepage.
[Mod03]
r
Model Technology. ModelSim
LE User’s Manual, Dezember
2003. Version 5.8a.
[Mon00a] Prof. Dr.-Ing. Dieter Monjau. Rechnerorganisation. Vorlesung,
Technische Universit¨at Chemnitz, 2000.
[Mon00b] Prof. Dr.-Ing. Dieter Monjau. VHDL - Einf¨
uhrung. Unterlagen zur Vorlesung Rechnerorganisation, Technische Universit¨at
Chemnitz, 2000.
[Nau99]
Dr. Bernt Naumann. Digitaltechnik. Vorlesung, Technische Universit¨at Chemnitz, 1999.
[Nau01]
Dr. Bernt Naumann. Werkzeuge f¨
ur den Systementwurf. Vorlesung, Technische Universit¨at Chemnitz, 2001.
[Opea]
Open SystemC Initiative.
SystemCTM
http://www.systemc.org. Homepage.
[Opeb]
Open SystemC Initiative. SystemCTM User’s Guide. Version 2.0.
[Ope02]
Open SystemC Initiative.
Functional Specification for
TM
SystemC
2.0, April 2002. Version 2.0-Q.
[Pea04]
Craig Peacock. Beyond Logic. http://www.beyondlogic.org/, Juli
2004. Webseite.
[Ram89]
Fanz-J. Rammig. Systematischer Entwurf digitaler Systeme. B.
G. Teubner, Stuttgart, 1989.
[Scia]
Scientific Software Tools Inc.
http://www.driverlinx.com/DownLoad/DlPortIO.htm. Downloadseite von port95nt.exe.
[Scib]
Scientific Software Tools Inc.
SST sition
Hardware/Software
and
Custom
http://www.driverlinx.com. Homepage.
[Syn]
r
Synopsys Corporate Marketing.
Synopsys
http://www.synopsys.com. Homepage.
[Syn03]
r
Synopsys Inc.
CoCentric
SystemCTM Compiler - RTL
User and Modeling Guide, Juni 2003.
Version U-2003.06,
www.synopsys.com.
Homepage.
Data AcquiApplications.
Homepage.
139
[Tei97]
Dr.-Ing. J¨
urgen Teich. Digitale Hardware/Software-Systeme Synthese und Optimierung. Springer-Verlag Berlin, Heidelberg,
1997.
[Thaa]
Tharas Systems Inc. www.tharas.com. Homepage.
[Thab]
r
Tharas Systems Inc. Hammer
100 Hardware Accelerator for
Verilog, VHDL and Mixed language simulation. Brosch¨
ure zum
r
Hammer
100 System.
[Thi94]
Michael Thieser.
M¨
unchen, 1994.
[VA ]
VA Software Corp.
SystemCTM Open Source Lizenz.
http://www.systemc.org/web/sitedocs/open source licensing.html.
[Ver96]
Verein Deutscher Ingenieure.
VDI 3633 - Simulation von
Logistik-, Materialfluß- und Produktionssystemen - Begriffsdefinition, November 1996.
[VH04]
Markus Visarius and Wolfram Hardt. The IPQ Format –
An Approach to Support IP based Design. In Proc. of the
GI/ITG/GMM-Workshop Methoden und Beschreibungssprachen
zur Modellierung und Verifikation von Schaltungen und Systemen, pages 106 – 115, Kaiserslautern, Germany, Feb. 2004.
PC-Schnittstellen.
Franzis-Verlag GmbH,
[VLH+ 03] M. Visarius, J. Lessmann, W. Hardt, F. Kelso, and W. Thronicke. An XML Format based Integration Infrastructure for IP
based Design. In Proceedings of the 16th Symposium on Integrated
Circuits and Systems Design (SBCCI 2003), pages 119 – 124, S˜ao
Paulo, Brazil, 08. - 10. September 2003. IEEE Computer Society.
[VLKH04] Markus Visarius, Johannes Lessmann, Frank Kelso, and Wolfram
Hardt. Generic integration infrastructure for ip based design processes and tools with a unified xml format. Integration, the VLSI
journal, 37(4):289 – 321, September 2004.
[Vra98]
Hendrikus P.E. Vranken. Design for test and debug in hardware/software systems. Technische Universit¨at Eindhoven, Eindhoven, 1998.
[Wan98]
Markus Wannemacher. Das FPGA-Kochbuch.
Thomson Publishing GmbH, Bonn, 1998.
International
140
[War]
Warp Nine Engineering. Warp Nine Engineering- The IEEE 1284
Experts. http://www.fapo.com/ieee1284.htm. Webseite.
[Wika]
Wikimedia Foundation Inc. Wikipedia - Die freie Enzyklop¨adie.
http://de.wikipedia.org/wiki/Adapter. Definition: Adapter.
[Wikb]
Wikimedia Foundation Inc. Wikipedia - Die freie Enzyklop¨adie.
http://de.wikipedia.org/wiki/Schnittstelle. Definition: Schnittstelle.
[Wor]
World Intellectual Property Organization. WIPO - World Intellectual Property Organization. http://www.wipo.int/. Homepage.
[Xila]
Xilinx Inc.
Development System Reference Guide ISE5.
http://toolbox.xilinx.com/docsan/xilinx5/pdf/docs/dev/dev.pdf.
[Xilb]
Xilinx Inc. Xilinx: Design Tools Center. http://www.xilinx.com/products/design resources/design tool/index.htm. Homepage.
[Xilc]
Xilinx Inc. Xilinx: Programmable Logic Devices, FPGA & CPLD.
http://www.xilinx.com. Homepage.
[Xild]
Xilinx Inc. Xilinx Synthesis Technology (XST) User Guide.
http://toolbox.xilinx.com/docsan/xilinx5/pdf/docs/xst/xst.pdf.
[Xil03]
Xilinx Inc.
Spartan-IIE 1.8V FPGA Family: Complete Data Sheet, 9. Juli 2003.
Version 2.1,
http://direct.xilinx.com/bvdocs/publications/ds077.pdf.
141
Abku
¨ rzungsverzeichnis
ASIC Application-Specific Integrated Circuit
CD Compact Disc
CPU Central Prozessing Unit
CU Controlunit
DSP Digitaler Signalprozessor
EDA Electronic Design Automation
EPP Enhanced Parallel Port
EPS Encapsulated PostScript
FPGA Field Programmable Gate Array
FPIC Field Programmable Interconnect Component
FSM Finite State Machine
HDL Hardware Description Language
HW Hardware
IEEE Institute of Electrical and Electronics Engineers
IF Interface
IFB Interfaceblock
IFS Interface Synthese
I/O Input-Output
IP Intellectual Property
ISS Instruction-set Simulator
MMX Multimedia Extension
OSCI Open SystemC Initiative
142
PDF Portable Document Format
PC Personal Computer
PH Protokollhandler
RAM Random Access Memory
RISC Reduced Instruction Set Computing
ROM Read Only Memory
RT Register-Transfer
RTL Register-Transfer-Level
RTOS Real-Time Operation System
SH Sequenzhandler
SimIFB Simulationsinterfaceblock
SoC System-on-Chip
SRAM Static Random Access Memory
SW Software
VDI Verein Deutscher Ingenieure
VHDL VHSIC Hardware Description Language
VHSIC Very High Speed Integrated Circuit
XML Extensible Markup Language
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement