Home

Automatische Adaption von Hardware-Acceleratoren für

1. Opcode Funktion Verarbeitungsbreite 0000 0001 a b carry 32 Bit 0010 a b carry 32 Bit 0011 a b 32 Bit 0100 a b 32 Bit 0101 ap 32 Bit 0110 a b 16 Bit 0111 b 32 Bit 1000 a and b 32 Bit 1001 aor b 32 Bit 1010 a xor b 32 Bit 1011 not a 32 Bit 1100 a lt lt b 32 Bit 1101 a gt gt b 32 Bit 1110 a mod b 16 Bit 1111 Tabelle 5 1 Funktionen der entwickelten Integer Executionunit wird anstelle der Integer Executionunit in das SystemC Design eingebun den Ein C Compiler erstellt daraus das Simulationsprogramm welches ein PC der iiber die parallele Schnittstelle mit dem FPGA Board verbunden ist ausf hrt Das Design der VHDL IP wurde im Rahmen dieser Arbeit selbst entwor fen Es bildet alle Funktionen nach die auch die SystemC Beschreibung der Einheit enthalt Sie sind in Tabelle 5 1 aufgef hrt Nur der Dividierer un terliegt einer Einschr nkung in der Verarbeitungsbreite Dieser Kompromiss musste getroffen werden da die verwendete Emulationsplattform das Digilab 2E Developmentboard nur ber eine Xilinx Spartan2e FPGA XC28200E PQ208 verf gt Ihre Kapazit t reicht nicht aus um die Ausf hrungseinheit mit einem 32 Bit Paralleldividierer zu emulieren Deshalb wurde die Verar beitungsbreite der Division und der damit verbundenen Modulo Brechnung auf 16 Bit gesenkt Diese Einschr nkung stellt f r den vorliegenden Demonstrator jedoch kein Hindernis d
2. Inhaltsverzeichnis 1 Einf hrung 1 1 1 2 Aufgabenstellung a edere ace nae ee ee Gliederung der Arbeit a4 sa YU pr E Sg 2 Stand der Technik 2 1 2 2 2 3 2 4 SA G a uice od atari t utat he gs toh Yama ape Se a V Intellectual Properties du eu tpa met Simulati n a a 2 3 1 Simulation mit SystemC rasante 2 3 2 Hardwaresimulation mit ModelSim 2 3 3 HW SW Cosimulation 6 14614 ove dew te Kaas DDR 2 3 4 Hardware Akzeleratoren 2 3 4 1 Tharas Hammer 100 45 ge See Goad 2 3 4 2 Mentor Graphics VStation 2 3 4 3 Aptix System Explorer 3 Die Methode der Adaptierung 3 1 3 2 3 3 Das Hardware Software Interface 31 1 Anforderungsanalyse f r das HW SW Interface Der Interfaceblock als HW SW Interface 3 2 1 Das Modell des Interfaceblocks 3 2 2 Analyse der Leistung des Interfaceblocks 3 2 3 Erweiterung des Interfaceblocks Technische Umsetzung der Adaptierung durch einen Simula tionsinterfacebloeck 21 2242 2 2a QVE ane 3 9 1 Die hardwareseitige Implementierungsplattform 3 3 2 Umsetzung des HW SW Interfaces 2 3 3 3 Ber PHW i ek Gene Lot ex eut 13 15 16 17 20 21 23 24 26 29 29 33 36 36 38 39 IV 4 Hayes 2 8 bok A
3. Tabelle 3 3 Die Register der hardwareseitigen Controlunit w schreibbar r lesbar die Simulationsdaten geschrieben bzw gelesen werden Dies ist nicht zwin gend notwendig Um jedoch ein versehentliches Starten der Emulation zu verhindern sollten diese Funktionen in den Zust nden ausgef hrt werden In den Zustand NoAction geht der Automat falls das Startsignal gesetzt ist aber noch kein Wert f r die Anzahl der Simulationszyklen im Zyklenz hler eingetragen ist Dies verhindert dass ein Emulationszyklus durchlaufen wird ohne eine Angabe der Zyklenanzahl Der Zustand DUTreset f hrt einen asynchronen Reset der IP Emulation durch Da der asynchrone Reset dem Taktsignal bergeordnet und von ihm unabh ngig ist wird die Emulation dabei ohne Taktsignal ausgef hrt Die Speicherung der Ausgabedaten der Emulation erfolgt dabei wie in einem nor malen Taktzyklus Beim Start der Emulation durch das Signal cstart wechselt der Automat in den Zustand DPrepare falls der Zyklenz hler einen Wert ungleich Null enth lt Der Zustand dient der Vorbereitung auf die Emulation Es werden die Flipflops zur Aufnahme der Emulationsdaten im PHyw ou Modus frei gegeben und die Z hler LDIV und HDIV geladen Anschlie end wechselt 3 DIE METHODE DER ADAPTIERUNG 57 Bit 1 c bo oO creset cdutreset gt cnext cstart cwrite cread Kontrollregister phin_runs sh_runs phout runs snext swo
4. Dateiname Aufgabe sim_environment_hw prj Projektdatei f r die Synthese make bat Skript zur Ausf hrung aller Implementierungsskripte do xst bat Skript zum Starten der Synthese xst script Hilfsdatei mit Parametern f r die Synthese do_ngdbuild bat Skript zum Ausfiihren des Ubersetzungsvorgangs do_map bat Skript fiir das Mapping des Desings do_par bat Skript zum Ausfiihren der Platzierung und Trassierung do_bitgen bat Skript zur Erstellung der Konfigurationsdatei fiir das FPGA do_program bat Skript zum Starten der FPGA Konfiguration durch das Programm Impact program script cmd Hilfsskript f r Impact do trce bat Skript zum Durchf hren der Timinganalyse Tabelle 4 10 berblick zu den Dateien im Verzeichnis Hardware Das Verzeichnis Software enthalt alle Quelldateien die f r die Einbindung des Simulationsinterfaceblocks in eine SystemC Simulation n tig sind Das SystemC Modul welches die Schnittstelle zur SystemC Simulation bildet tr gt den Namen der Entity der VHDL IP und die Dateiendung h Darin ist die Schnittstelle definiert Die Funktionalit t stellt die gleichnamige Datei mit der Endung cpp bereit Alle anderen Dateien im Verzeichnis Softwa re enthalten Funktionen die von diesen Dateien genutzt werden Dabei ist besonders die Datei CUsw h zu erw hnen Sie definiert alle wichtigen Para meter f r den Softwareteil des Simulationsinterfaceblocks Dazu z hlen die Adresse der parallelen Schnitt
5. A 3 9 5 DerSHge a em sa Em e AGE Re XR 3 3 6 Der Pings a EA A pr Die Controlunit m 412927 X 3 4 Anwendungsm glichkeiten Der Simulationsinterfaceblock Generator Ale eae ae A ES EU A 4292 Arbeitsswelise 24 4 2 fudge al x2 E dt Ra tS a RS 4 2 1 Eingaben und Ausgaben 4 2 2 Die internen Datenstrukturen 4 2 2 1 Die Datenstruktur ENTITYSTRUCTUR 4 2 2 2 Die Datenstruktur PORT_LIST 4 2 2 3 Die Datenstruktur GENERIC_LIST 4 2 2 4 Die Datenstruktur WORD_LIST 4 2 2 5 Die Datenstruktur FILELIST 1 2 3 Der Programmablauf artnet wire Bu 4 3 Benutzung des Programms 4 2 a a Ka RS 4 3 1 Programmstart und aufbau 4 3 2 Die Analyse der Quelldatei 2 2222 4 3 3 Festlegung von Signalparametern 4 3 4 Weitere Parameter Ka Y oes cs 4 3 5 Die Generierung suec S 4 3 6 berblick ber die generierten Dateien 4 4 Verbesserungsm glichkeiten und Fazit Demonstrator 5 1 Bedeutung eines Demonstrators 5 2 Aufbau und Funktionsweise 5 3 Nachweis der Funktion e 22 28 8 225 ixl 5 4 Betrachtungen zur Simulationszeit e 5 4 1 Geschwindigkeit der parallelen Schnittstelle 63 63 63 64 64 65 67 68 69 0
6. 43 Digilent 2E Developmentboard mit Xilinx Spartan 2E FPGA 45 Protokollautomat des EPP Protokol 4T Detailierter Aufbau des 48 Ablaufplan zur Umsetzung des PHsw 2 22 2 2 50 Detailierter Aufbau des 51 Detailierter Aufbau des SHuw gt 222 53 Detailierter Aufbau des 2 54 Detailierter Aufbau der Controlunits 55 FSM der Controlumit 42 42 22 tah ed Eh 58 Eingaben und Ausgaben des SimIJFB Generators 64 Syntaxdiagramm einer VHDL Entity 72 Erzeugung der Quelldateien des SimIFBs aus Templates 73 Ansicht des Simulationsinterfaceblock Generators nach dem Programmstart ce ot de eod os eae a e T9 Ansicht des Feldes Analyseparameter 76 Der Simulationsinterfaceblock Generator nach der Analysephase 77 Ansicht der Felder zur Einstellung der Signalparameter 78 Der Simulationsinterfaceblock Generator nach der Einstellung der Signalparameter 221 2 2222 ce ir 78 Detailierte Ansicht des Feldes zur Einstellung weiterer Para Der Simulationsinterfaceblock Generator bei der Generierung des HW Teils veo ae mee rei E s 80 Ix 4 11 Der Simulationsinterfaceblock Generator bei der Generierung oals oot e Sd me HE te uke 4 12 Der Simulationsinterfaceblock Generator bei der Generierung a A ect ater er
7. R26 00ff0726 R27 00 0727 R28 00 70728 R29 00000029 R28 00 70728 R29 00000029 R30 00000030 R31 00000031 R30 00000030 R31 00000031 gt 3233 3 2 2222222222 nass feel IFU mem 0x1234000 IFU mem 0x1234000 pc 23 at CSI M 258 ns ID R2 R3 1 RA at CSIM 260 ns op A 1 B 4 4 IFU pc 24 at CSI mem 0x0 M 265 ns ID REGISTERS DUMP at CSIM 267 ns K FK K ok ok KK OK KK REG 0 00000000 2 00000003 4 00000004 6 0000000 8 00000008 R10 00000010 R12 0000ff12 R14 00000014 R16 00000016 R18 00fe0118 R20 00fe0220 R22 00 0322 R24 00ff0524 R26 00ff0726 R28 00 70728 R30 00000030 R 1 000e1 R S ffffffff R 5 00000006 R 7 fcfOfdef R 9 00000009 R11 0000ff31 R13 00000013 R15 00000015 R17 00fe0117 R19 00fe0119 R21 00fe0321 R23 00 0423 R25 00 0625 R27 00 0727 R29 00000029 R31 00000031 IFU 23 at CSI M 258 ns ID R2 R3 1 R4 at CSIM 260 ns opp A 1 B 4 4 IFU pc 24 at CSI mem 0x0 M 265 ns DK KK KK K KK ok ok ok FK OK FK K FK K FK ID REGISTERS DUMP at CSIM 267 ns a a a a a a a
8. 2 fff000e2 4 00000004 6 0000000a 8 00000008 R10 00000010 R12 0000ff12 R14 00000014 R16 00000016 R18 00fe0118 R20 00fe0220 R22 00 0322 R 1 00000001 R S ffffffff R 5 00000005 R 7 fcfOfdef R 9 00000009 R11 0000ff31 R13 00000013 R15 00000015 R17 00fe0117 R19 00fe0119 R21 00fe0321 R23 00 0423 2 fff000e2 4 00000004 6 0000000a 8 00000008 R10 00000010 R12 0000ff12 R14 00000014 R16 00000016 R18 00fe0118 R20 00fe0220 R22 00fe0322 R24 00 0524 R26 00ff0726 R28 00 70728 R30 00000030 R S ffffffff 5 00000005 R 7 fcfOfdef R 9 00000009 R11 0000f f31 R13 00000013 R15 00000015 R17 00fe0117 R19 00fe0119 R21 00fe0321 R23 00 0423 R25 00ff0625 R27 00 0727 R29 00000029 R31 00000031 IFU IFU mem 0xf550000 17 at CSI M 159 ns ID R5 R5 5 at CSIM 161 ns op A 5 B R 5 gt R5 at 0 CSIM 163 ns IFU pc 18 at CSI mem 0x0 M 166 ns FKK OK OK FKK K K K OK OK FK FK FK K FK K FK K FK FK KK K OK K ID REGISTERS DUMP at CSIM 168 ns a a a ae ak a ae ae aka k a k ak ak ak kk I I a ak ak ak ak k ak ak K REG 0 00000000 2 fff000e2 4 00000004 6 0000000 8 00000008 R10 00000010 R12 0000ff12 R14 00000014 R16 00000016 R18 00fe0118 R20 00fe0220 R22 00 0322 R 1 00000001 R S ffffffff R 5 00000005 R 7 fcfOfdef R 9 00000009 R11 0000f
9. R25 00ff0625 R27 00 0727 R29 00000029 R31 00000031 0 00000000 2 fff000e2 4 00000004 6 0000000 8 00000008 10 00000010 R12 0000ff12 R14 00000014 R16 00000016 R18 00fe0118 R20 00fe0220 R22 00 0322 R24 00 0524 R26 00f 0726 R28 00 70728 R30 00000030 R 1 00000001 R S ffffffff R 5 00000005 R 7 fcfOfdef R 9 00000009 R11 0000ff31 R13 00000013 R15 00000015 R17 00fe0117 R19 00fe0119 R21 00fe0321 R23 00ff0423 R25 00ff0625 R27 00 0727 R29 00000029 R31 00000031 117 IFU mem 0xf1500005 IFU pc 11 at CSIM 117 ns ALU op 3 A 5 B 0 ALU R 5 gt R5 at CSIM 121 ns IFU mem 0x0 IFU pc 12 at CSIM 124 ns ID REGISTERS DUMP at CSIM 126 ns DKK 0 00000000 2 fff000e2 4 00000004 6 0000000 8 00000008 R10 00000010 R12 0000ff12 R14 00000014 R16 00000016 R18 00fe0118 R20 00fe0220 R22 00fe0322 R24 00 0524 R26 00ff0726 R28 00 70728 R30 00000030 1 00000001 3 ffffffff 5 00000005 7 fcfOfdef 9 00000009 R11 0000ff31 R13 00000013 R15 00000015 R17 00 0117 R19 00 0119 R21 00 0321 R23 00f 0423 R25 00f 0625 R27 00 0727 R29 00000029 R31 00000031 IFU mem 0xf55000
10. 70 berblick zu den Funktionen zur Datenstruktur FILELIST 70 berblick zu den Dateien im Verzeichnis Hardware 84 Funktionen der entwickelten Integer Executionunit 89 Die Modi der Software zur Geschwindigkeitsmessung 94 Ermittelte Geschwindigkeiten der parallelen Schnittstelle 96 Simulationszeiten der originalen und der modifizierten RISC OPU eue Bee Gas ee ch Bare oh eR beo 97 Das Datenaufkommen des generierten Moduls 98 1 EINFUHRUNG 1 1 Einf hrung Die Entwicklung eines digitalen technischen Systems unterliegt heutzutage hohen Anforderungen hinsichtlich Entwicklungszeit und Entwicklungskosten Der Gewinn den ein Produkt erzielt fallt umso gr fer aus je schneller es auf dem Markt verf gbar ist Das Ziel des Entwicklungsprozesses liegt demzufol ge darin ein Produkt schnell und mit m glichst 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 ngig voneinander erfolgen Somit kann der Entwicklungsaufwand auf mehrere Personen oder Teams verteilt werden und die Entwicklungszeit redu ziert sich durch die Parallelisierung der Entwurfsarbeit Das Gesamtsystem ergibt sich aus der Zusammenf hrung und Kopplung der einzelnen Module Ab
11. Adressen lesen Synchronisation Signalflanke Handshake maximale 115 200 Bit s 2 MByte s Geschwindigkeit 14400 Byte s Anzahl der Da 8 8 tenbits pro Zy klus Fehlererkennung Parit t 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 Kom munikation kann nur von einem Kommunikationspartner initiiert werden Im Abschnitt 3 1 1 wurde festgestellt dass es sich bei der vorliegenden Verbin dung von SystemC Simulation und IP Emulation um eine Form der Master Slave Cosimulation handelt Somit stellt diese Eigenschaft des Protokolls kein Hinderniss dar Den Master der HW SW Schnittstelle bildet die Softwaresei te also der PC auf dem die SystemC Simulation abl uft 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 r die Trennung von Da tenfluss und Steuerfluss ber die HW SW Schnittstelle von Bedeutung ist bilden die vier verschiedenen bertragungsmodi 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 P
12. Hardware simulator Backplane Abbildung 2 10 HW SW Cosimulation mit dem Hardware Modell 2 STAND DER TECHNIK 19 Hardware simulator Backplane Abbildung 2 11 HW SW Cosimulation mit dem compilierten Modell benutzt werden falls der Zielprozessor bereits existiert Zur Ausf hrung der Software findet der Zielprozessor statt eines Simulators Verwendung Damit ist eine Echtzeitausf hrung der Software m glich Die Simulation der Hard warekomponenten findet durch einen Hardwaresimulator statt der mit dem Prozessor gekoppelt ist Beim compilierten Modell kommt der Prozessor des ausf hrenden Rech ners zum Einsatz Abbildung 2 11 Die zu simulierende Software wird in Co de dieses Prozessors transformiert und auf diesem ausgef hrt Eine Schnitt stelle verbindet die Softwareausf hrung mit dem Hardwaresimulator der die Ergebnisse der Hardwarekomponenten berechnet Die h chste Simulationsgeschwindigkeit erzielt unter allen Ans tzen die Hard wareemulation welche Abbildung 2 12 veranschaulicht Dieses Verfahren nutzt programmierbare Hardwarebausteine wie zum Beispiel FPGAs Auf Basis dieser Bausteine werden die entwickelten Hardwarekomponenten im plementiert Die Softwareausf hrung findet auf dieser Implementierung statt Implementierung Hardware simulator Backplane Abbildung 2 12 HW SW Cosimulation mit Hardwareemulation 20 2 STAND DER TECHNIK Die Geschwindigkeit die dieser Ansatz erreicht ka
13. Hardware Software and Custom Applications http www driverlinx com Homepage Synopsys Corporate Marketing Synopsys Homepage http www synopsys com Homepage Synopsys Inc CoCentric SystemC Compiler RTL User and Modeling Guide Juni 2003 Version U 2003 06 WWW Synopsys com 139 Tei97 Thaa Thab Ver96 VH04 VLH 03 VLKH04 Vra98 Wan98 Dr Ing J rgen Teich Digitale Hardware Software Systeme Synthese und Optimierung Springer Verlag Berlin Heidelberg 1997 Tharas Systems Inc www tharas com Homepage Tharas Systems Inc Hammer 100 Hardware Accelerator for Verilog VHDL and Mixed language simulation Brosch re zum Hammer 100 System Michael Thieser PC Schnittstellen Franzis Verlag GmbH M nchen 1994 VA Software Corp SystemCTMOpen Source Li zenz http www systemc org web sitedocs open source licensing html Verein Deutscher Ingenieure VDI 3683 Simulation von Logistik Materialflu und Produktionssystemen Begriffsdefi nition November 1996 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 Syste men pages 106 115 Kaiserslautern Germany Feb 2004 M Visarius J Lessmann W Hardt F Kelso and W Thro nicke An XML Format based Integration Infrastructure for
14. R14 00000014 R15 00000015 R14 00000014 R15 00000015 R16 00000016 R17 00fe0117 R16 00000016 R17 00fe0117 R18 00fe0118 R19 00fe0119 R18 00fe0118 R19 00fe0119 R20 00fe0220 R21 00fe0321 R20 00 0220 R21 00fe0321 R22 00fe0322 R23 00ff0423 R22 00fe0322 R23 00ff0423 R24 00ff0524 R25 00ff0625 R24 00ff0524 R25 00ff0625 R26 00ff0726 R27 00 0727 R26 00ff0726 R27 00 0727 R28 00 70728 R29 00000029 R28 00 70728 R29 00000029 R30 00000030 R31 00000031 R30 00000030 R31 00000031 IFU mem 0xf160000a IFU pc 7 at CSIM 47 ns ALU op 3 A 10 B 0 IFU mem 0x0 IFU pc 8 at CSIM 54 ns DOK KK FKK K FKK ok ok ok K FK 3K K FK K 2K K FK ok ok ok OK OK OK K ID REGISTERS DUMP at CSIM 56 ns k k kk k k ak ak ak ak ok k ak ak K A ak ak k k k k REG 0 00000000 2 fff000e2 4 00000004 6 0000000a 8 00000008 R10 00000010 R12 0000ff12 R14 00000014 R16 00000016 R18 00fe0118 R20 00fe0220 R22 00 0322 R24 00ff0524 R26 00ff0726 R28 00 70728 R30 00000030 R 1 00000001 R S ffffffff R 5 00000005 R 7 fcfOfdef 9 00000009 R11 0000ff31 R13 00000013 R15 00000015 R17 00fe0117 R19 00fe0119 R21 00fe0321 R23 00 0423 R25 00 0625 R27 00 0727 R29 00000029 R31 00000031 IFU mem 0xf160000a IFU pc 7 at CSIM 47 ns ALU 3 A 10 B 0 ALU R 10 gt R6 at
15. Zielverzeichnis Z sitbgen_output Durchsuchen Analyse starten Hilfe 1 Abbildung 4 5 Ansicht des Feldes Analyseparameter 4 DER SIMULATIONSINTERFACEBLOCK GENERATOR TT 4 3 3 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 Anlyse gestartet Analyse edolgiesch bescht Abbildung 4 6 Der Simulationsinterfaceblock Generator nach der Analyse phase Die in diesem Abschnitt erschienenen Felder dienen zur Auswahl des Takt signals und des asynchronen Resetsignals aus den Eing ngen der VHDL IP Auf Grund dieser Informationen erzeugt der Simulationsinterfaceblock Ge nerator die Sensitivit tsliste des SystemC Moduls Es existiert jeweils f r 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 hlt werden Ist ein Si gnal ausgew hlt so muss der Benutzer zus tzlich dessen aktive Taktflanke festgelegen Ein Klick auf den jeweiligen Ok Button beendet die Eingabe der Signalparameter und l sst keine nderung an den Einstellungen mehr zu Abbildung 4 7 stellt eine detailierte Ansicht der Felder zur Auswahl des Takt und des asynchronen R
16. ausf hrbare 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 gt ber die vollst ndigen Ausgaben Folgende Datei en z hlen zu dieser Version Anhang D 133 risc_cpu exe ausfiihrbare 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 Einga bedaten f r den Testbench bios dcache icache register Das Unterverzeichnis SYSTEMC enthalt das Projekt die Quelltexte und die kompilierten Daten f r die Erstellung der Simulation der modifizierten RISC CPU Das Projekt wurde mit Microsoft Visual C 4 6 bearbeitet Zur erneuten bersetzung m ssen die Einstellungen f r die Pfade auf die aktu ellen Gegebenheiten angepasst werden 134 135 Literatur AB96 Alt Apt Apt00 Atm Axe97 Dem93 Dig Dig02 Els94 Fic03 Fla03 Sorin A Huss Klaus Waldschmidt Andreas Bleck Michael Goe decke Praktikum des modernen VLSI Entwurfs B G Teubner Stuttgart 1996 Altera Corporation Altera Leaders in FPGAs CPLDs and Structured ASICs http www altera com Homepage Aptix Corporation www aptix com Homepage Aptix Corporation System Explorer Reconfigurable Syste
17. 0 5 5 6 TT 78 80 82 85 5 4 2 Vergleich der Simulationszeiten 96 5 5 Schl ssfolgerungen 04 2S ae 100 Zusammenfassung und Ausblick 103 6 1 Zusammenfassung der Arbeit 103 6 2 Ausblick f r den erweiterten Interfaceblock 105 6 8 Ausblick f r den Simulationsinterfaceblock Generator 106 Herleitung der Formel zur Berechnung der Taktfrequenz der IP Emulation 107 Hinweise zur Nutzung von SystemC in Mircrosoft Visual C 6 0 109 Gegen berstellung der Simulationsdaten 111 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 Abkiirzungsverzeichnis 141 VI Abbildungsverzeichnis 14 1 2 1 3 1 4 1 5 2 1 2 2 2 3 2 4 2 5 2 6 2 7 2 8 2 9 2 10 2 11 2 12 2 13 2 14 2 15 3 1 3 2 3 3 3 4 3 9 3 6 3 7 Schema eines modularen Designs Aktuelle Methode des Hardwareentwurfsprozesses Y Diagramm nach Gajski 1 2 an hr i wi X Diagramim nach Rammig oar rear P Chart Entwurfsstrukturierung Logo von SystemC pen A ds Oe Reels Gave ea bs fet do as Gegenw rtige und SystemC Designmethodik Darstellung von Moores Gesetz SoC aus IPs und selbstentwickelten Komponenten IPQ als Ko
18. 1 Leseadressen 10h 3 10h E 5 1 3 2 ni Anzahl Eingangsbits der emulierten IP mit Taktsignal no Anzahl Ausgangsbits der emulierten IP 3 DIE METHODE DER ADAPTIERUNG 53 sous Adresse Handler Enable Daten control Daten Daten FSM SHuw Daten Schreibadressen Leseadressen Abbildung 3 20 Detailierter Aufbau des SHyw Die Werte der Schreibadres sen bilden den Bereich nach Formel 3 1 die Leseadressen nach Formel 3 2 Data control Den Bereich der Schreibadressen gibt Formel 3 1 an Er ist abh ngig von der Anzahl der Eingangsleitungen n der emulierten IP Da das Taktsignal geson dert behandelt wird muss es von den Eingangsleitungen abgezogen werden Die niedrigste Adresse die berhaupt Daten transportieren kann stellt die 10h dar Die Leseadressen schlieBen sich an den Bereich der Schreibadressen an Sie sind zus tzlich abh ngig von der Anzahl der Ausgangsleitungen der emulier ten IP Den Adressraum gibt Formel 3 2 an Nach der Dekodierung der Adresse werden die Daten zugeordnet F r die Schreibadressen kommt dazu ein Demultiplexer zum Einsatz da das Da tenbyte je nach Adresse auf unterschiedliche Leitungen gelegt werden muss Auferdem werden Enablesignale erzeugt die zur Kommunikation mit dem PHyw out dienen F r die Abfrage von Leseadressen kommt ein Multiplexer zum Einsatz Er legt die Daten vom PHmgw 4 die der aktuelle
19. 1 10 10 2 Zellenfeld Abbildung 3 3 Schematischer Aufbau eines SRAM basierten FPGA tiert werden muss Dieses Kriterium ist wichtig weil dadurch die Zeit fiir Tests und Verifizierung eingespart wird Um die Simulation zu beschleuni gen wird zus tzlich zum Cosimulationsansatz der Ansatz von Hardware Akzeleratoren eingebracht Das hei t dass die IP in Hardware emuliert wird was eine schnellere Ausf hrung der erlaubt und mit dem SystemC Simulator gekoppelt wird Der Einsatz von kommerziellen Hardware Akzeleratorsystemen ist durch ihre hohen Kosten hier nicht praktikabel Eine L sung f r dieses Problem ware ei g nstigere handels bliche Hardware die schnell konfiguriert werden kann Mit dieser Hardware sollte der Anwender auch in der Lage sein gr fere Schal tungen schnell zu realisieren Diese Voraussetzungen erf llen SRAM basierte Field Programable Gate Ar rays FPGA FPGAs sind programmierbare Hardwarebausteine und geh ren zur Gruppe der anwenderprogrammierbaren Schaltungen Den grunds tz lichen Aufbau von FPGAs stellt Abbildung 3 3 dar Sie bestehen im we sentlichen aus konfigurierbaren Logikbl cken konfigurierbaren IO Bl cken und einer konfigurierbaren hierarchischen Verbindungstruktur Mit Hilfe von FPGAs k nnen kombinatorische und sequentielle digitale Schaltungen reali siert werden Mehr Informationen zu FPGAs bieten Wan98 und die Home pages vo
20. 8 00000008 10 00000010 R12 0000ff12 R14 00000014 R16 00000016 R18 00fe0118 R20 00 0220 R22 00 0322 R24 00f 0524 R26 00f 0726 R28 00f 70728 R30 00000030 R 1 00000001 R S ffffffff R 5 00000005 R 7 fcfOfdef R 9 00000009 R11 0000ff31 R13 00000013 R15 00000015 R17 00fe0117 R19 00fe0119 R21 00fe0321 R23 00 0423 R25 00ff0625 R27 00 0727 R29 00000029 R31 00000031 mem 0xf550000 IFU pc 15 at CSIM 145 ns ID R5 R5 5 at CSIM 147 ns op 3 A 5 B 0 R gt R5 at CSIM 149 ns mem 0x0 IFU pc 16 at CSIM 152 ns K K 2K K K K KK ID REGISTERS DUMP at CSIM 154 ns 2K KK K K K K 2K K K K 2K K K ok K K 2K K K 2K 2K KK K K K R 0 00000000 R 1 00000001 ID R5 0x5 5 fr ALU at CSIM 136 ns IFU mem 0x0 pc 14 at CSIM 138 ns ID REGISTERS DUMP at CSIM 140 ns 3 a a a ae a ae k k k k kk kkk kk k I I A ak A ak k k K REG 0 00000000 2 fff000e2 4 00000004 6 0000000 8 00000008 10 00000010 R12 0000f 12 14 00000014 16 00000016 R18 00fe0118 R20 00 0220 R22 00 0322 R24 00f 0524 R26 00f 0726 R28 00 70728 R30 00000030 R 1 00000001 R S ffffffff R 5 00000005 R 7 fcfOfdef R 9 00000009
21. Abbildung 3 1 Adaptierung durch Konvertierung Austausch von Simulationsdaten und Kontrollsignalen sowie die Synchronisa tion zwischen den Simulatoren damit zum richtigen Zeitpunkt die korrekten Simulationsdaten vorhanden sind Allerdings kostet die Ausf hrung von zwei Simulatoren auf einem Rechner viel Rechenleistung Die Folge ist eine geringere Simulationsgeschwindig keit Da kontinuierlich Daten zwischen den Simulatoren ausgetauscht wer den m ssen spielt nicht nur die Ausf hrungszeit der beiden Simulatoren eine gro e Rolle sondern auch die Zeit die die Kommunikation zwischen die sen beansprucht Der Vorteil dieser Variante liegt darin dass die IP nicht von Hand konver SW SW Interface VHDL Simulation SystemC Simulation Gesamtsimulation Abbildung 3 2 Adaptierung eines Simulators 3 DIE METHODE DER ADAPTIERUNG 3l io 10 Io S hierarchisches Verbindungssystem 10 10 kurze Leitungen 10 l moll allgemeine Leitungen 10 SME SM 10 lange Leitungen CLB CLB 5 SM konfigurierbarer Logikblock 10 CLB CLB 10 SM Switchmatrix 10 H 10 IO programmierbare IO 2 lo 1 Bondinselring
22. Adaptierung von SystemC Simulation und IP Emulation erlaubt Der erste Teil dieser Arbeit bot eine Einf hrung in die Problematik und stellte die Aufgabenstellung vor Anschlie end erfolgte die Betrachtung des aktuellen Standes der Techniken mit denen diese Arbeit verkn fpt ist Daran schloss sich die Vorstellung von SystemC als Entwurfssystem und die Begut achtung seiner derzeitige Leistungsf higkeit an Der Begriff der Intellectual Properties wurde erkl rt und das IPQ Projekt kurz vorgestellt mit dessen Hilfe bestehende Probleme bei der IP Nutzung berwunden werden sollen Zuletzt wurde auf den Begriff Simulation eingegangen und verschiedene Si mulationsverfahren und konzepte vorgestellt Das dritte Kapitel betrachtete den Co Simulationsansatz Dabei wurde her ausgearbeitet dass eine Hardware Software Schnittstelle ben tigt wird um die SystemC Simulation mit der IP Emulation zu koppeln In diesem Zusam menhang erfolgte die Herausstellung der Aufgaben der HW SW Schnittstelle sowie der von ihr zu erbringenden Leistungen F r eine m gliche Umsetzung der HW SW Schnittstelle fand das Modell des Interfaceblocks Verwendung 104 6 ZUSAMMENFASSUNG UND AUSBLICK Dazu wurde zun chst desses Leistungsf higkeit analysiert um sicherzustel len dass es in der Lage ist die Aufgaben zu erf llen Da das vorliegende Modell des Interfaceblocks eine Aufgabe nicht abdecken konnte erfolgte eine Erweiterung das Konzept Das Ergebnis bestand
23. DLPORTIO lib 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 O1 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 PHsw Mode WriteSimData h t phout mode O1 vhd t sim environment hw ucf t Programme Timedrun Das Programm timedrun exe dient zur Messung der Ausf hrungszeit eines Programms Eine Anleitung zur Nutzung enthalt readme txt In den Skripten copy_simulation bat und run bat k nnen Befehle eingetragen werden Das erste Skript fallt dabei nicht unter die Zeitmessung Die Messung umfasst allein die Ausf hrung von run bat 130 Anhang D D 3 Verzeichnis SOURCES Das Verzeichnis SOURCES enthalt 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 VHDL Quellcodes und die Implementierungsdaten zum Hardwareteil der Messein richtung Sie wurden mit der Entwicklungsumgebung Xilinx ISE 5 erstellt Das Unterverzeichnis SPEEDTEST SW enth lt die Projektdatei die C C Quellcodes und die Kompilationsdaten zum Softwareteil der Messeinrichtung Ihre Erstellung erfolgte mit Hilfe der C C Entwicklungsumgebung Micr
24. Dar ber in welchem Abschnitt der Synthese der Fehler auftrat geben die Logdateien des Syntheseprozesses Auskunft 82 4 DER SIMULATIONSINTERFACEBLOCK GENERATOR Genesung gertaitel Sagneimaepng elek Sagnaimapping erlolgreich beendet Hardwereled werd genee Ex sd Fehler aulgeteten Skapie wenden genenert und ausgeht Boendet Es sind keine Fehler aulgetseten Soltvennsted wird generiert Abbildung 4 12 Der Simulationsinterfaceblock Generator bei der Generie rung des Softwareteils 4 3 6 berblick ber die generierten Dateien Dieser Abschnitt soll einen berblick ber die generierten Daten des Simu lationsinterfaceblock Generators geben Die Verzeichnisstrukur stellt Abbil dung 4 13 dar Im Zielverzeichnis befinden sich zun chst die Unterverzeich nisse Hardware und Software sowie zwei Dateien Die Datei simifb gen log ist das Logfile des Simulationsinterfaceblock Generators und enth lt die Status ausgaben und Fehlermeldungen die w hrend des Programmlaufs auftraten Es kann auch ber den Button Logfile anzeigen aus dem Programm her aus eingesehen werden Die ausf hrbare Datei exec scripts bat erm glicht es den Implementierungsvorgang des Hardwareteils zu wiederholen da sie alle ausgef hrten Skripte aufruft Im Verzeichnis Hardware befinden sich alle Dateien die zur Erstellung des Hardwareteils des Simulationsinterfaceblocks notwendig sind Die Aufg
25. Die Software VStationTBX TestBench XPress liefert zus tzlich noch ei ne Verifikationsumgebung f r die Simulation und Emulation Es werden die Sprachen SystemC und System Verilog unterst tzt VHDL kann nur als RT Beschreibung verarbeitet werden VStationTBX erlaubt eine schnelle Kom munikation zwischen der VStationPRO einem Simulator und den Verifikati onsprogrammen auf dem Hostrechner Abbildung 2 14 VStation Pro System von Mentor Graphics Quelle Men03 24 2 STAND DER TECHNIK Weiterfiihrende Informationen zum VStation System finden sich auf der Ho mepage der VStation Menb Produktbeschreibungen zur VStationPRO lie fern Menc und Men03 Mehr Informationen ber den VStationTBX ent halten Mend und Men04 2 3 4 3 Aptix System Explorer Der Aptix System Explorer Abbildung 2 15 ist ein System f r Emulati on 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 Board Architektur Diese Architektur kombiniert eine Prototypingfl che mit einer programmierbaren Verbindungsstruktur den FPIC s Field Pro grammable Interconnect Component FPICs sind elektronisch konfigurier bare bi direktionale Verbindungsstrukturen und stellen die Verbindungen zwischen den Prototypingfl chen her Die Prototypingfl chen k nnen mit FPGAs und Systemkomponenten wie DSPs RAM oder Prozesso
26. Flipflop f r das Taktsignal Es wird mittels eines Kontrollsignals von der CUnw gesetzt oder gel scht da die CUnw die Taktsteuerung implementiert 3 3 7 Die Controlunit Die Controlunit Abbildung 3 22 besteht aus einem Hardware CU oe und einem Softwareteil CUsw die beide zusammenarbeiten Sie kommunizieren 3 DIE METHODE DER ADAPTIERUNG 55 CUsw h Definitionen CUsw cpp SetWriteMode SetReadMode SetWaitMode SetCycleEnd SetStartSim SetDUTreset SetResetIFB SetLDIVCounter SetHDIVCounter SetCycleCounter ns IFB Control FSM Kontroll und Statusregister GetStatus 1 GetStatus2 GetLDIVCounter GetHDIVCounter GetZyklenCounter init_Interface condition_to_start_simulation test_environment_id Abbildung 3 22 Detailierter Aufbau der Controlunits miteinander ber die HW SW Schnittstelle mit Hilfe von PHsw und PHuw in Die Grundlagen der Kommunikation wurden bereits in den Abschitten 3 3 3 und 3 3 4 erl utert 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 bertragen so dass der Softwa reteil also die CUsw die Rolle des Masters annimmt und der Hardwareteil also die CU oa die Rolle des Slave Zun chst soll der Hardwareteil der Controlunit n her betrachtet werden Er besteht aus einem Automaten zur Kontrolle des
27. Frage nach einem einheitlichen Qualit tkriterium f r IPs um bei der Auswahl von IPs einheitliche Vergleichskriterien zu haben Zu den Qualit tsmerkmalen einer IP z hlen unter anderem der Umfang der Doku mentation Skripte zur Logiksynthese Applikationsbeispiele Simulationser gebnisse Testdaten und Verifikationsergebnisse Um bestehende Hindernisse bei der Nutzung und dem Handel von IPs zu bew ltigen wurde das Projekt IPQ ipq ins Leben gerufen Die Zielset zung des Projektes liegt darin eine entscheidende Verbesserungen f r die Qualit tssicherung bei der Anwendung und Entwicklung von IP Modulen zu erzielen Dazu geh ren Spezifikationsmethoden eine intelligente IP Suche Eingangschecks von IPs Verfahren zur IP Anpassung und Beitr ge zur Stan dardisierung Das dabei auftretende Problem lag im Nichtvorhandensein eines einheitlichen Beschreibungsstandards ber Firmengrenzen hinweg Jede Firma benutzt ih re eigenen internen Standard und verzichtet auch ungern auf diese da eine Umstellung mit hohen Kosten verbunden ist Dadurch wird der IP Handel er schwert denn die IPs m ssen nach dem Kauf manuell an den firmeninternen Standard angepasst werden Provider A IP Provider B IP A Provider C Simulation Provider D Synthese Provider E Simulation C D Abbildung 2 5 IPQ soll eine standardisierte Komm
28. Funktionen zur Datenstruktur ENTI TY 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 tig te 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 SHyw zum Zugriff auf den Speicher im PHyw ou ben tigt In id wird eine 8 Bit lange Identifikationsnummer gespeichert Ein Zufalls generator erzeugt sie Sie dient zur Identifikation des Hardwareteils des Si mulationsinterfaceblocks durch den Softwareteil um sicherzustellen dass die richtigen Teilst cke miteinander arbeiten Die Variablen counter ldiv counter und cycle counter speichern die Werte auf die w hrend der sp teren Simulation die Z hler des Hardware teils eingestellt werden Die Funktion der Z hler wurde bereits im Abschnitt 3 3 7 erl utert Epp port addr enthalt die Adresse ber die die parallele Schnittstelle des ausf hrenden PCs angesprochen wird Der Wert in fpga prog after gen gibt an ob der Simulationsinterfaceblock Generator das FPGA nach der Gene rierung des Simulationsinterfaceblocks sofort konfigurieren soll 4 DER SIMULAT
29. ICU ALERT ICU ALERT mem 0xf160000a pc 5 at CSIM 33 ns op 3 A 10 B 0 R 10 gt R6 at CSIM 37 ns mem 0x0 3 a a ae ae kk k k k AC ak ak ak ak k k k ak A ak A ak ak k K ID REGISTERS DUMP at CSIM 42 ns FOR a a ae sk ae ok ok aka A a k ak ak ak ak k ak ak ak ak a ak ak ak ak k K REG 0 00000000 2 fff000e2 4 00000004 6 0000000 8 00000008 R 1 00000001 R S ffffffff R 5 00000005 R 7 fcfOfdef R 9 00000009 ID RO RO 0 at CSIM 21 ns ALU 3 O B 0 ALU R 0 gt RO at CSIM 23 ns IFU mem 0xf000004 IFU pc 4 at CSIM 26 ns ID RO RO 0 at CSIM 28 ns op 3 A 0 B 0 R 0 gt RO at CSIM 30 ns ICU ALERT ICU ALERT mem 0xf160000a pc 5 at CSIM 33 ns ALU op 3 A 10 B 0 R 10 5 R6 at CSIM 37 ns mem 0x0 3 a ae a ae sk ae ae AC k a k a a ak ak ak ak I A A A k ak k K ID REGISTERS DUMP at CSIM 42 ns FORA a a a ae a ak ak ak ak ak ak ak a ak ak k ak k K REG 0 00000000 2 fff000e2 4 00000004 6 0000000 8 00000008 R 1 00000001 R S ffffffff R 5 00000005 R 7 fcfOfdef R 9 00000009 Anhang 113 10 00000010 R11 0000ff31 R10 00000010 R11 0000ff31 R12 0000ff12 R13 00000013 R12 0000ff12 R13 00000013
30. IP based Design In Proceedings of the 16th Symposium on Integrated Circuits and Systems Design SBCCI 2003 pages 119 124 Sao Paulo Brazil 08 10 September 2003 IEEE Computer Society Markus Visarius Johannes Lessmann Frank Kelso and Wolfram Hardt Generic integration infrastructure for ip based design pro cesses and tools with a unified xml format Integration the VLSI journal 31 4 289 321 September 2004 Hendrikus P E Vranken Design for test and debug in hardwa re software systems Technische Universit t Eindhoven Eindho ven 1998 Markus Wannemacher Das FPGA Kochbuch International Thomson Publishing GmbH Bonn 1998 140 War Wika Wikb Wor Xila Xilb Xilc Xild Xil03 Warp Nine Engineering Warp Nine Engineering The IEEE 1284 Experts http www fapo com ieee1284 htm Webseite Wikimedia Foundation Inc Wikipedia Die freie Enzyklop die http de wikipedia org wiki Adapter Definition Adapter Wikimedia Foundation Inc Wikipedia Die freie Enzyklop die http de wikipedia org wiki Schnittstelle Definition Schnitt stelle World Intellectual Property Organization WIPO World Intel lectual Property Organization http www wipo int Homepa ge Xilinx Inc Development System Reference Guide ISE5 http toolbox xilinx com docsan xilinx5 pdf docs dev dev pdf Xilinx Inc Xilinx Design Tools Center http www xilinx com products
31. Men03 Men04 Mic04 M l02 M lo3 Proc of the International Conference on Computer Design Frei burg Germany Sept 2002 Stefan Ihmor Markus Visarius and Wolfram Hardt Modeling of Configurable HW SW Interfaces pages 51 60 Feb 2003 Lattice Semiconductor Corporation FPGA CPLD and SER DES Programmable Logic Devices by Lattice Semiconductor http www vantis com Homepage Norbet Schuhmann Martin Speitel Erfahrungen mit Intellectual Property www elektroniknet de 2002 Andreas M der Vhdl kompakt http tech www informatik uni hamburg de vhdl doc kurzanleitung vhdl pdf Mentor Graphics Corp www mentor com Homepage Mentor Graphics Corp High Performance System Integration Verification VStation http www mentor com vstation Ho mepage Mentor Graphics Corp VStationPRO High Performance System Verification http www mentor com vstation vstation_pro html Homepage Mentor Graphics Corp VStationTBX High Performance Verification Accelerator http www mentor com vstation vstation tbx html Homepage Mentor Graphics Corp VStationPRO High Performance System Verification 2003 Brosch re zur VStationPro Mentor Graphics Corp VStationTBX Datasheet 2004 Brosch re zur VStationTBX Microsoft Corporation Geistiges Eigentum Defi nition http www microsoft com germany digital mentality definition mspx 2004 Homepage Prof Dr Dietmar Miiller Entwu
32. R11 0000ff31 R13 00000013 R15 00000015 R17 00fe0117 R19 00fe0119 R21 00fe0321 R23 00 0423 R25 00 0625 R27 00 0727 R29 00000029 R31 00000031 IFU mem 0xf550000 IFU pc 15 at CSIM 145 ns ID R5 R5 5 at CSIM 147 ns op 3 A 5 B 0 R 5 gt R5 at CSIM 149 ns mem 0x0 IFU pc 16 at CSIM 152 ns KKK K K K K K K K K K K K K K K K K K K K K K K K K K K K K ID REGISTERS DUMP at CSIM 154 ns R 0000000000 R 1000000001 Anhang 119 2 fff000e2 4 00000004 6 0000000 8 00000008 R10 00000010 R12 0000ff12 R14 00000014 R16 00000016 R18 00fe0118 R20 00fe0220 R22 00 0322 R24 00ff0524 R26 00ff0726 R28 00 70728 R30 00000030 R S ffffffff R 5 00000005 R 7 fcfOfdef R 9 00000009 R11 0000ff31 R13 00000013 R15 00000015 R17 00fe0117 R19 00fe0119 R21 00fe0321 R23 00 0423 R25 00 0625 R27 00 0727 R29 00000029 R31 00000031 IFU IFU mem 0xf550000 17 at CSI M 159 ns ID R5 R5 5 at CSIM 161 ns ALU ALU op 3 A 5 B R 5 gt R5 at 0 CSIM 163 ns IFU pc 18 at CSI mem 0x0 M 166 ns ID REGISTERS DUMP at CSIM 168 ns REG 0 00000000
33. Simulationsinterfaceblock Generator auf die Nutzung der Xilinx Tools Eine ausf hrliche Beschreibung der Tools ist in Xila und Xild zu finden Eine Erweiterung des Programms ist aber durch aus denkbar Nach der Generierung der Skripte erfolgt ihre Ausf hrung durch die Funktion execute hwscripts Am Ende der Skriptsphase analysiert die Funktion analy ze timing das Logfile des Timinganalyseskriptes Es sucht nach der gr ten Verz gerungszeit und berechnet daraus die Werte f r die LDIV und HDIV Zahler Dies dient dazu dass die Emulation mit dem richtigen Takt aus gef hrt wird damit die Emulationsergebnisse auch solang abgegriffen wer den bis an den Ausg ngen der IP ein korrektes Ergebnis anliegt Die LDIV und HDIV Z hler ben tigt die dritte Generierungsphase um alle Quelldatei en des Softwareteils erstellen zu k nnen Die dritte Generierungsphase erzeugt den Softwareteil also die C C Quell und Headerdateien des Simulationsinterfaceblocks Sie startet durch Auf ruf der Funktion generate S Wpart Der erste Schritt generiert das SystemC Modul welches die Schnittstelle des Simulationsinterfaceblocks zur SystemC Simulation bereitstellt Dieses Modul tr gt den Namen der Entity der VHDL IP Die Headerdatei bildet die Schnittstelle die Quelldatei realisiert die Funk tionalit t des PHsw Beide Dateien werden komplett durch den Simulati onsinterfaceblock Generator erstellt und nicht aus Templates Alle anderen Dateien des
34. Zur Verbindung wird die Eigenschaft des IFBs als Adapter genutzt Somit ist die Verbindung jedenfalls theoretisch m glich Die n chste Anforderung umfasst den bidirektionalen Datentransport zwi schen 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 Ma terie 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 llt er auch diese gestellte Anforderung Die Integration einer Steuerung in den IFB erfolgt durch die Controlunit Sie erf llt innerhalb des IFBs Steuerungs und Kontrollaufgaben Sie kontrolliert die Handler indem sie Steuerungssignale an diese bermittelt und Statussi gnale 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 t zur Daten bertragung Die Modi k nnen also auch mit Algorithmen versehen sein die Daten transformieren Die transformierten Daten m ssen nun noch durch den IFB transportiert werden k nnen Innerhalb des IFBs findet Kommunikation zwischen der Co
35. aus Als Erstes erfolgt die Generierung der Quell dateien des Hardwareteils Abbildung 4 10 In diesem Schritt werden alle VHDL Quelldateien erzeugt die zur Synthese des Hardwareteils des Inter faceblocks und der Emulation der IP notwendig sind Darunter fallen alle Dateien im Ausgabeverzeichnis Hardware Src sowei die Projektdatei f r die sp tere Synthese gestaitet Stonaimapping elt Sagnaimappeng erfolgreich beendet Hardwaretei werd genee Abbildung 4 10 Der Simulationsinterfaceblock Generator bei der Generie rung des Hardwareteils Anschlie end erstellt das Programm die Skripte f r die Synthese das ber setzen das Mapping die Platzierung und Trassierung die Generierung des Bitstroms und die Konfiguration des FPGAs Diese Phase stellt Abbildung 4 11 dar Die Ausf hrung der Skripte schlie t sich an die Generierung an Zur erfolgreichen Ausf hrung der Skripte ist es notwendig dass die Entwick lungsumgebung Xilinx ISE auf dem Rechner installiert ist der den Simula tionsinterfaceblock Generator ausf hrt Im derzeitigen Zustand unterst tzt der Simulationsinterfaceblock Generator zur Ausf hrung der Emulation nur das Digilab 2E Development Board Dig02 mit der darauf befindlichen Xilinx Spartan2E FPGA Zur Unterst tzung anderer FPGAs und Synthesewerkzeu ge kann der Simulationsinterfaceblock Generator sp ter erweitert werden 4 DER SIMULATIONSINTERFACEBLOCK GENERATOR 81 gen
36. des Simulationsmodells mit steigender zur Implementierung Mit steigendem Detailgrad n hert sich die Genauigkeit des Simulationsmo dells stark dem realen System an Durch die Ber cksichtigung von Verz ge rungszeiten von Gattern und Leitungen sowie dem bergang zu einer vier wertigen Logik entsprechen die Ergebnisse der Simulation den real zu erwar teten Daten des zu implementierenden Systems Der hohe Detailgrad der Simulation wirkt sich jedoch stark auf die Simulati onsgeschwindigkeit aus Durch eine steigende Anzahl zu ber cksichtigender Parameter in einem Simulationsschritt steigt der Simulationsaufwand stark an und die Simulationsgeschwindigkeit verringert sich Tabelle 2 1 stellt die sen 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 Verifi zierung der aktuellen Entwurfsebene besitzen m ssen und dementsprechend das Simulationsmodell auszuw hlen Es existieren eine Vielzahl von Simulatoren und Simulationsmethoden die die Simulation unterschiedlicher Abstraktionsebenen beherrschen Einige Si mulatinsmethoden versuchen zudem dem Zeitverlust der durch genauere Modelle entsteht mit verschiedenen Ans tzen entgegenzuwirken Eine klei ne Auswahl von Simulatoren und Simulationsmeth
37. design resources design tool index htm Homepage Xilinx Inc Xilinx Programmable Logic Devices amp CPLD http www xilinx com Homepage Xilinx Inc Xilinx Synthesis Technology XST User Guide http toolbox xilinx com docsan xilinx5 pdf docs xst xst pdf Xilinx Inc Spartan IIE 1 8V FPGA Family Com plete Data Sheet 9 Juli 2003 Version 2 1 http direct xilinx com bvdocs publications ds077 pdf 141 Abk 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 Memo
38. durch den Simulationsinterfaceblock intern umgewandelt werden und der Transport erfolgreich verl uft ist auch die korrekte Erf llung der 4 Aufgabe nachgewiesen Die interne Steuerung die Aufgabe 5 als Inhalt hat arbeitet nach der Spezifikation da sie den Da tenaustausch steuert und dieser erfolgreich verl uft Zum Nachweis der 1 Aufgabe m ssen die kommunizierenden Tasks n her betrachtet werden Das SystemC Design bliebt bis auf die Ersetzung der Integer Executionunit un ver ndert Auch an der VHDL Beschreibung der IP erfolgten keine Ver nde rungen Da beide Komponenten durch den Simulationsinterfaceblock erfolg reich miteinander kommunizieren gilt auch die 1 Aufgabe als erf llt Den Simulationsinterfaceblock erzeugte der Simulationsinterfaceblock Gene rator 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 Simulationsinter faceblock beinhaltet erf llt der Simulationsinterfaceblock Generator somit korrekt 5 4 Betrachtungen zur Simulationszeit Bei der Simulation spielt die ben tigte Zeit eine gro e Rolle Deshalb soll an dieser Stelle die Simulationszeit der originalen und der modifizierten RISC CPU betrachtet werden Zu erwarten ist dass die Zeit welche die Simulation der modifizierten RISC CPU
39. e 4 13 berblick ber die Verzeichnisstruktur der generierten Daten 5 1 Aufbau des Designs RISC CPU 5 2 Aufbau des Demonstrators 5 3 Schnittstellendefinition der originalen Integer Executionunit 5 4 Festlegung der Datentypen im Simulationsinterfaceblock Ge TET ACOL E Ane kere ae as a ee IE 5 5 Aufbau der Hardware zur Geschwindigkeitsmessung Tabellenverzeichnis 2 1 2 2 3 1 3 2 3 3 3 4 3 5 3 6 4 4 2 4 3 4 4 4 5 4 6 4 7 4 8 4 9 4 10 5 1 5 2 5 3 5 4 5 9 Simulationsaufwand von verschiedenen Entwurfsebenen 14 Technische Daten des Aptix System Explorer 25 Vergleich serielle und parallele Schnittstelle 46 Grundfunktionen zum Zugriff auf die parallele PC Schnittstelle 49 Die Register der hardwareseitigen Controlunit 56 Belegung der Kontroll und Statusregister der CUgw 57 Ausgaben der 59 Funktionen der CUew 2 2 2 2 m mm 60 Aufbau der Datenstruktur ENTITY STRUCTUR 65 Funktionen zur Datenstruktur ENTITY STRUCTUR 66 Aufbau der Datenstruktur PORTLIST 67 berblick zu den Funktionen zur Datenstruktur PORT LIST 68 Aufbau der Datenstruktur GENERIC LIST 69 Aufbau der Datenstruktur WORD LIST 69 berblick zu den Funktionen zur Datenstruktur WORD LIST 69 Aufbau der Datenstruktur FILELIST
40. mem 0x2550001 pc id at CSIM 201 ns ID R5 R5 5 1 at CSIM 203 ns op 3 A 5 B 1 IFU mem 0x0 pc 1e at CSIM 208 ns 129 Anhang ID REGISTERS DUMP at CSIM 210 ns 3 a a kk k IC I A k k ak ak ak ak k ak ak A ak ak ak ak k K REG KK FKK K K FK K K FK K FK K FK FK K FKK FK K FK K FK FK K ID REGISTERS DUMP at CSIM 210 ns FA OAC k a k kkk kk ak k ak ak ak ak ak k ak k K 0 00000000 2 fff000e2 4 00000004 6 0000000 8 00000008 R 1 00000001 R S ffffffff R 5 00000006 R 7 fcfOfdef R 9 00000009 0 00000000 2 fff000e2 4 00000004 6 0000000 8 00000008 R 1 00000001 R S ffffffff R 5 00000006 R 7 fcfOfdef R 9 00000009 10 00000010 R11 0000ff31 R10 00000010 R11 0000ff31 R12 0000ff12 R13 00000013 R12 0000ff12 R13 00000013 R14 00000014 R15 00000015 R14 00000014 R15 00000015 R16 00000016 R17 00fe0117 R16 00000016 R17 00fe0117 R18 00fe0118 R19 00fe0119 R18 00fe0118 R19 00fe0119 R20 00 0220 R21 00fe0321 R20 00 0220 R21 00fe0321 R22 00fe0322 R23 00ff0423 R22 00fe0322 R23 00ff0423 R24 00ff0524 R25 00ff0625 R24 00f 0524 R25 00ff0625 R26 00ff0726 R27 00 0727 R26 00ff0726 R27 00 0727 R28 00 70728 R29 00000029 R28 00 70728 R29 00000029 R30
41. nis Software Die Hardwarekomponente wird durch eine Konfigurationsdatei speedtest bit realisiert Sie dient zur Konfiguration der Xilinx FPGA Spartan 25200 208 auf dem Digilab 2E Developmentboard und sollte auch nur f r diesen Typ verwendet werden Die Softwarekomponente bildet das Pro gramm speedtext sw exe Die Datei readme txt enthalt eine Anleitung zur Nutzung der beiden Teile Programme Simifb generator Simifb_generator exe ist die Datei zum Starten des Simulationsinterfaceblock Generators Die Benutzung des Programms ist in Kapitel 4 speziell in Ab schnitt 4 3 ausf hrlich dargestellt Die Datei readme txt enthalt 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 nderungen im Quelltext und ein erneutes Kompilieren des Programms notwendig Folgende Dateien m ssen in diesem Verzeichnis enthalten sein damit der Simulationsinterfaceblock Generator seine Arbeit korrekt erf llen kann Softwareteil Hardwareteil auto reset vhd t cu vhd t data splitting off vhd t handlercontrol vhd t CUsw cpp t CUsw h t Dlportio h t
42. nnen und der Zeitaufwand f r die Adaptierung verringert sich stark Das Programm implementiert die Grundfunktionalit t der Adap tierung und zeigt dass eine automatische L sung praktikabel ist 86 4 DER SIMULATIONSINTERFACEBLOCK GENERATOR 5 DEMONSTRATOR 87 5 Demonstrator Diese Kapitel besch ftigt 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 beschaftigt sich mit dem Aufbau und der Funktionsweise des verwendeten Demonstra tors 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 SW Schnittstelle 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 nnen 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 glichkeit dass es sich nicht oder nur schwer in die Praxis umsetzen l sst Unter Umst nden bildet dies eine H rde f r einen praktischen Einsatz des Modells Au
43. quivalente Der Preis des Simulationssystems liegt zwischen 2 65 und 7 5 US Cent pro Gatterequivalentkapazitat Mehr Informationen zu diesem System bietet die Homepage von Tharas Sys tems Thaa und die Brosch re zum Hammer 100 System Thab 2 STAND DER TECHNIK 23 2 3 4 2 Mentor Graphics VStation Das VStation System von Mentor Graphics Mena gliedert sich in zwei Teile Die Hardwareseite bildet die VStation und das Softwarepaket hei t VStation Das System stellt eine komplette Umgebung bereit die es erm glicht 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 2Mhz Nach au en stellt das System je nach Ausbaustufe zwischen 512 und 4608 I O Verbindungen bereit Der VStationPRO VirtualLogic Compiler erlaubt ein direktes Mapping des Designs von der Register Transfer Ebene auf die FPGAs der VStationPRO ohne zuvor eine Synthese auszufiihren Dadurch werden Signalnamen und die Hierarchie des Designs beibehalten Eine Simulator hnliche Debugumgebung erm glicht es alle Signale des Designs zu berwachen Auch Quellcodedebug ging mit Haltepunkten und das Anzeigen von Waveforms wird unterst tzt
44. 0 IFU 13 at CSIM 131 ns ID R5 R5 5 at CSIM 133 ns ALU op 3 A 5 B 0 IFU mem 0xf1500005 IFU 11 at CSIM 117 ns ALU A 5 B 0 ALU R 5 gt R5 at CSIM 121 ns IFU mem 0x0 IFU 12 at CSIM 124 ns FKK KK FKK K K K FKK ok ok ok FK OK FK K FK K FK K ook ok ok OK KOK OK K ID REGISTERS DUMP at CSIM 126 ns REG 0 00000000 2 fff000e2 4 00000004 6 0000000 8 00000008 R10 00000010 R12 0000ff12 R14 00000014 R16 00000016 R18 00fe0118 R20 00fe0220 R22 00fe0322 R24 00ff0524 R26 00ff0726 R28 00 70728 R30 00000030 R 1 00000001 R S ffffffff 5 00000005 R 7 fcfOfdef R 9 00000009 R11 0000ff31 R13 00000013 R15 00000015 R17 00fe0117 R19 00fe0119 R21 00fe0321 R23 00 0423 R25 00 0625 R27 00 0727 R29 00000029 R31 00000031 IFU mem 0xf550000 IFU pc 13 at CSIM 131 ns ID R5 R5 5 at CSIM 133 ns op 3 A 5 B 0 118 Anhang ID R5 0x5 5 fr ALU at CSIM 136 ns mem 0x0 pc 14 at CSIM 138 ns ID REGISTERS DUMP at CSIM 140 ns 3 a a ae ae ae ae ae k k k A a a ak ak ak ak k k k ak ak A ak A ak ak k K REG 0 00000000 2 fff000e2 4 00000004 6 0000000
45. 0 70728 R29 00000029 R28 00 70728 R29 00000029 R30 00000030 R31 00000031 R30 00000030 R31 00000031 See ees E IFU mem 0xf160000a IFU mem 0xf160000a IFU f at CSIM 103 ns IFU pc f at CSIM 103 ns Sie RE ID R6 10 at CSIM 105 ns ID R6 10 at CSIM 105 ns EE donee ae Eeer ee ALU op 3 A 10 B 0 ALU op 3 A 10 B 0 ALU R 10 gt R6 at CSIM 107 ns ALU R 10 gt R6 at CSIM 107 ns IFU mem 0x0 IFU IFU pc 10 at CSIM 110 ns IFU mem 0x0 10 at CSIM 110 ns K ID REGISTERS DUMP at CSIM 112 ns 3 a a kk k IC I k a a ak ak ak ak ak ak ak A A ak A ak ak k K REG K ID REGISTERS DUMP at CSIM 112 ns 3 a a ae a ae ak ae a aaa k a a a a ak ak ak ak A A ak A k ak k K REG 0 00000000 2 fff000e2 4 00000004 6 0000000 8 00000008 10 00000010 R12 0000ff12 R14 00000014 R16 00000016 R18 00fe0118 R20 00fe0220 R22 00 0322 R24 00f 0524 R26 00f 0726 R28 00 70728 R30 00000030 R 1 00000001 R S ffffffff R 5 00000005 R 7 fcfOfdef R 9 00000009 R11 0000ff31 R13 00000013 R15 00000015 R17 00fe0117 R19 00fe0119 R21 00fe0321 R23 00ff0423
46. 00000000 2 fff000e2 4 00000004 6 0000000 8 00000008 R10 00000010 R12 0000ff12 R14 00000014 R16 00000016 R18 00fe0118 R20 00 0220 R22 00fe0322 R24 00 0524 R26 00ff0726 R28 00 70728 R30 00000030 1 00000001 R S ffffffff 5 00000005 R 7 fcfOfdef R 9 00000009 R11 0000 31 R13 00000013 R15 00000015 R17 00 0117 R19 00 0119 R21 00 0321 R23 00 0423 R25 00 0625 R27 00 0727 R29 00000029 R31 00000031 IFU mem 0xf160000a IFU d at CSIM 89 ns ALU op 3 A 10 B 0 ALU R 10 gt R6 at CSIM 93 ns IFU mem 0x0 IFU e at CSIM 96 ns ID REGISTERS DUMP at CSIM 98 ns ok ok ak ak k k ak ak ak ak ak ak ak ak ak I ke ak ak k k ak k 2K ak ak 0 00000000 2 fff000e2 4 00000004 6 0000000 1 00000001 R S ffffffff 5 00000005 R 7 fcfOfdef IFU mem 0x0 IFU at CSIM 82 ns ID REGISTERS DUMP at CSIM 84 ns a a a ak a a ae k k k a k ak ak ak ak ak k ak I a ak ak ak ak k ak ak ak REG 0 00000000 2 fff000e2 4 00000004 6 0000000 8 00000008 R10 00000010 R12 0000ff12 R14 00000014 R16 00000016 R18 00fe0118 R20 00fe0220 R22 00 0322 R24 00ff0524 R26 00ff0726 R28 00 70728 R30 000
47. 00000030 R31 00000031 R30 00000030 R31 00000031 E oue Se e re Een IFU mem 0x1156fffa IFU mem 0x1156fffa IFU 1f at CSIM 215 ns IFU 1f at CSIM 215 ns NEN I gl ACE Anse a Se ee nt A nca ID bne R5 6 R6 10 pc 6 ID bne R5 6 R6 10 pc 6 ID at CSIM 217 ns ID at CSIM 217 ns Pa Ste EE moon PE EN ALU 3 A 0 B O ALU op 3 A 0 B O ALU R 0 gt RO at CSIM 219 ns ALU R 0 gt RO at CSIM 219 ns IFU mem 0x0 IFU mem 0x0 pc 20 at CSIM 222 ns IFU pc 20 at CSIM 222 ns c ENE Sete eec eee IFU ALERT BRANCH IFU ALERT BRANCH K ID REGISTERS DUMP at CSIM 224 ns 3 a kk k k k k A AC ak ak ak kk ak ak ok ke A ak A ak ak k K ID REGISTERS DUMP at CSIM 224 ns FORA a a a a a ak ak ak ak I A a ak A ak ak k K REG 0 00000000 2 fff000e2 4 00000004 6 0000000 8 00000008 1 00000001 R S ffffffff R 5 00000006 R 7 fcfOfdef R 9 00000009 0 00000000 2 fff000e2 4 00000004 6 0000000 8 00000008 R 1 0000000
48. 00030 1 00000001 R S ffffffff R 5 00000005 R 7 fcfOfdef R 9 00000009 R11 0000ff31 R13 00000013 R15 00000015 R17 00 0117 R19 00fe0119 R21 00fe0321 R23 00 0423 R25 00 0625 R27 00 0727 R29 00000029 R31 00000031 IFU mem 0xf160000a IFU d at CSIM 89 ns ALU 3 A 10 B 0 ALU R 10 gt R6 at 93 ns IFU mem 0x0 IFU e at CSIM 96 ns ID REGISTERS DUMP at CSIM 98 ns a a a ak ak a a ae aka k a k ak ak ak ak ak k ak ak ak ak ak ak ak ak k ak R 0 00000000 2 fff000e2 4 00000004 6 0000000 1 00000001 R S ffffffff 5 00000005 R 7 fcfOfdef REG REG 116 Anhang 8 00000008 R 9 00000009 8 00000008 R 9 00000009 R10 00000010 R11 0000ff31 R10 00000010 R11 0000ff31 R12 0000ff12 R13 00000013 R12 0000ff12 R13 00000013 R14 00000014 R15 00000015 R14 00000014 R15 00000015 R16 00000016 R17 00 0117 R16 00000016 R17 00 0117 R18 00fe0118 R19 00fe0119 18 00 0118 R19 00fe0119 R20 00fe0220 R21 00fe0321 R20 00fe0220 R21 00 0321 R22 00fe0322 R23 00f 0423 R22 00fe0322 R23 00f 0423 R24 00ff0524 R25 00ff0625 R24 00 0524 R25 00 0625 R26 00ff0726 R27 00 0727 R26 00ff0726 R27 00 0727 R28 0
49. 0726 R28 00f70728 R30 00000030 mem 0x2550001 14 at CSIM 201 ns ID R5 R5 5 1 at CSIM 203 ns 3 A 5 B 1 R 6 gt R5 at CSIM 205 ns IFU mem 0x0 pc 1e at CSIM 208 ns k a ak ak ak ak ak k I I A A ak k k k 2K ak ak ID REGISTERS DUMP at CSIM 196 ns a a a ak ok ok ak ak k k k a ae ak ak ak ak k ak ak ak a ak ak ak k ak k ak ak ak REG R 1 00000001 3 ffffffff R 5 00000005 7 fcfOfdef 9 00000009 R11 0000ff31 R13 00000013 R15 00000015 R17 00 0117 R19 00fe0119 R21 00fe0321 R23 00ff0423 R25 00ff0625 R27 00 0727 R29 00000029 R31 00000031 IFU IFU at CSIM 189 ns op A 5 B 0 R 5 gt R5 at CSIM 191 ns 0 00000000 2 fff000e2 4 00000004 6 0000000 8 00000008 R10 00000010 R12 0000ff12 R14 00000014 R16 00000016 R18 00fe0118 R20 00 0220 R22 00fe0322 R24 00 0524 R26 00ff0726 R28 00 70728 R30 00000030 IFU mem 0x0 pc ic at CSIM 194 ns ID REGISTERS DUMP CSIM 196 ns ok ok ok ok ae k k k a ae ak ak ak ak k ak ak ak ak a ak ak ak ak ak ak ak ak REG R 1 00000001 R S ffffffff R 5 00000005 R 7 fcfOfdef R 9 00000009 R11 0000ff31 R13 00000013 R15 00000015 R17 00 0117 R19 00fe0119 R21 00fe0321 R23 00 0423 R25 00 0625 R27 00 0727 R29 00000029 R31 00000031
50. 1 R S ffffffff 5 00000006 R 7 fcfOfdef R 9 00000009 IFU mem 0x0 IFU pc 20 at CSIM 229 ns ID REGISTERS DUMP at CSIM 231 ns REG 0 00000000 2 fff000e2 4 00000004 6 0000000 8 00000008 1 00000001 3 ffffffff 5 00000006 7 fcfOfdef 9 00000009 R10 00000010 R11 0000ff31 R12 0000ff12 R13 00000013 R14 00000014 15 00000015 16 00000016 R17 00fe0117 R18 00fe0118 R19 00fe0119 R20 00fe0220 R21 00fe0321 R22 00 0322 R23 00ff0423 R24 00 0524 R25 00ff0625 R26 00ff0726 R27 00 0727 R28 00 70728 R29 00000029 R30 00000030 R31 00000031 IFU ALERT BRANCH IFU mem 0x0 IFU pc 20 at CSIM 237 ns IFU mem 0x0 IFU 20 at CSIM 229 ns FKK KK KK K K K FKK ok ok ok K OK FKK FK K FK K FK K FK FK KK OK e Anhang C 123 10 00000010 R11 0000ff31 R10 00000010 R11 0000ff31 R12 0000ff12 R13 00000013 R12 0000ff12 R13 00000013 R14 00000014 R15 00000015 R14 00000014 R15 00000015 R16 00000016 R17 00fe0117 R16 00000016 R17 00fe0117 R18 00fe0118 R19 00fe0119 R18 00fe0118 R19 00fe0119 R20 00fe0220 R21 00fe0321 R20 00 0220 R21 00fe0321 R22 00fe0322 R23 00ff0423 R22 00fe0322 R
51. 23 00ff0423 R24 00ff0524 R25 00ff0625 R24 00ff0524 R25 00ff0625 R26 00ff0726 R27 00 0727 R26 00ff0726 R27 00 0727 R28 00 70728 R29 00000029 R28 00 70728 R29 00000029 R30 00000030 R31 00000031 R30 00000030 R31 00000031 ID REGISTERS DUMP at CSIM 231 ns REG 0 00000000 2 fff000e2 4 00000004 6 0000000 8 00000008 R 1 00000001 R S ffffffff R 5 00000006 R 7 fcfOfdef R 9 00000009 IFU mem 0x0 IFU pc 20 at CSIM 237 ns R10 00000010 R11 0000ff31 R12 0000ff12 R13 00000013 R14 00000014 15 00000015 16 00000016 R17 00fe0117 R18 00fe0118 R19 00fe0119 R20 00fe0220 R21 00fe0321 R22 00 0322 R23 00ff0423 R24 00 0524 R25 00f 0625 R26 00ff0726 R27 00 0727 R28 00 70728 R29 00000029 R30 00000030 R31 00000031 IFU ALERT BRANCH 124 Anhang ID REGISTERS DUMP CSIM 239 ns 3 a ok k k k AC ak ak ak ak ak k ak ak ak A ak A ak ak k OK REG ID REGISTERS DUMP at CSIM 239 ns okekokek kk ke okeoke k k ke a kk ae ak ak k ak ak ak ak ak ak A ak k k K 0 00000000 2 fff000e2 4 00000004 6 0000000 8 00000008 R 1 00000001 R S ffffffff R 5 00000006 R 7 fc
52. Beendet Es sind Fehler Skapie wenden garent und 355355 Abbildung 4 11 Der Simulationsinterfaceblock Generator bei der Generie rung der Skripte Die Generierung des Softwareteils des Simulationsinterfaceblocks schlieft sich an die Skriptausf hrung an Abbildung 4 12 Sie baut teilweise auf die Syn these des Hardwareteils speziell auf die Timinganalyse auf In dieser Phase erstellt der Simulationsinterfaceblock Generator das System C Modul aus den analysierten Daten der Entity der VHDL IP und den Eingaben des Nutzers Das SystemC Modul tr gt den Namen der Entity der VHDL IP Zu diesem Modul geh ren noch weitere Bibliotheken die aus Templates erstellt werden In den Templates tr gt der Simulationsinterfaceblock Generator nur einige Parameter wie zum Beispiel die Gr e der Simulationsdaten ein Nach dem fehlerfreien Abschluss der Generierung ist der Programmlauf beendet Das Statusfenster zeigt an ob Fehler bei den einzelnen Schritten aufgetre ten sind Dies kann der Fall sein wenn das Programm die Templates nicht fand oder die Ausf hrung der Skripte fehlschlug Im letzeren Fall muss der Benutzer sicherstellen dass das Verzeichnis mit den Xilinxtools in der Pfad umgebung des Betriebssystems vorhanden und die Xilinx Umgebungsvariable gesetzt ist Tritt trotzdem ein Fehler bei der Synthese auf so sollte die VHDL Datei der IP auf m gliche syntaktische Fehler berpr ft werden
53. CSIM 51 ns IFU mem 0x0 IFU 8 at CSIM 54 ns ID REGISTERS DUMP at CSIM 56 ns a a ak ak k k ak k ak ak ak a ak ak ak ak k ak REG 0 00000000 2 fff000e2 4 00000004 6 0000000 8 00000008 R10 00000010 R12 0000ff12 R14 00000014 R16 00000016 R18 00fe0118 R20 00fe0220 R22 00fe0322 R24 00ff0524 R26 00ff0726 R28 00 70728 R30 00000030 R 1 00000001 R S ffffffff R 5 00000005 R 7 fcfOfdef R 9 00000009 R11 0000f f31 R13 00000013 R15 00000015 R17 00fe0117 R19 00fe0119 R21 00fe0321 R23 00 0423 R25 00ff0625 R27 00 0727 R29 00000029 R31 00000031 114 Anhang de P NE as ee mem 0xf160000a IFU mem 0xf160000a IFU 9 at CSIM 61 ns IFU pc 9 at CSIM 61 ns ALU op 3 A 10 B 0 ALU R 10 gt R6 at CSIM 65 ns IFU mem 0x0 pc a at CSIM 68 ns ID REGISTERS DUMP at CSIM 70 ns OR a ae ae k aka k A A ak ak ak ak ak ak k ak k A ak A ak k k K REG 0 00000000 2 fff000e2 4 00000004 6 0000000 8 00000008 10 00000010 R12 0000ff12 R14 00000014 R16 00000016 R18 00fe0118 R20 00fe0220 R22 00 0322 R24 00f 0524 R26 00f 0726 R28 00 70728 R30 00000030 1 00000001 R
54. Clk gen0 SOS OH DO olol HL Ol lololol o NoAction oo oo oo oo o End Cycle SIO OPO OS DJS Df o DoReset BLO OPO OPO olol ol Kun Kon Kon Kon Ken Kon SO olol ResetDUT SDD A DI olol ol olol DI SP SP ololol ol Init Tabelle 3 5 Die Ausgaben des Clockcontrolautomaten in seinen Zust nden Der Abruf von Statusregistern dient der CUsw zur Information ber den Zu stand der CUpw Au erdem k nnen die aktuellen Werte der Z hler abgerufen werden Die Hilfsfunktionen haben die Aufgabe die Arbeit des Softwareteils des In terfaceblocks zu unterst tzen So sind Funktionen zur Initialisierung der par allelen Schnittstelle zum Testen von Signalen auf eine bestimmte Bedingung vorhanden Au erdem eine Funktion die vor der Aufnahme der Kommuni kation mit der Hardwareseite sicherstellen soll dass sich der richtige Interfa ceblock auf dem FPGA befindet 60 3 DIE METHODE DER ADAPTIERUNG Funktionsname Aufgabe Set WriteMode Setzt cwrite Bit in CUgw SetReadMode Setzt cread Bit in CUgw SetWaitMode Setzt Kontrollregister auf 00h SetCycleEnd Setzt cnext Bit in CUgw SetStartSim Setzt cstart Bit in CUgw SetDU Treset Setzt Bit f r asynchronen Reset der IP in CUmw SetResetIF B Setzt creset Bit in CUgw und l st damit Reset des IFB aus SetLDIV Counter Setzt den Zahlen LDIV in C
55. EEHI Technische Universit t Chemnitz Stra e der Nationen 62 TECHNISCHE UNIVERSIT T 09111 Chemnitz CHEMNITZ Automatische Adaption von Hardware Acceleratoren f r Verhaltenssimulation Diplomarbeit Fakult t f r 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 Dank und Erkl rung Diese Arbeit entstand an der Professur Technische Informatik der Techni schen Universit t Chemnitz Ich m chte hiermit besonders Herrn Prof Dr habil Wolfram Hardt f r das interessante Thema und die engagierte Be treuung w hrend der Anfertigung dieser Arbeit danken Auch f r die Be reitstellung von Rechnern sowie Hard und Software durch die Professur und die Technische Universit t Chemnitz spreche ich an dieser Stelle mei nen Dank aus Ebenfalls sei mir gestattet den Mitarbeitern der Professur speziell Markus Scheithauer f r die Diskussion fachlicher Fragen und hilfrei chen Anregungen zu danken Nicht zuletzt gilt mein Dank Kathrin Kasecker f r das intensive Korrekturlesen dieser Arbeit und meiner Familie f r ihre Unterst tzung Hiermit erkl re ich dass ich die vorliegende Arbeit selbstst ndig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt sowie Zitate kenntlich gemacht habe Chemnitz im September 2004
56. IONSINTERFACEBLOCK GENERATOR 67 Zur Datenstruktur ENTITY STRUCTUR geh ren neben den Variablen auch ei nige Funktionen die Tabelle 4 2 auff hrt Sie dienen zur einfacheren Arbeit mit der Datenstruktur 4 2 2 2 Die Datenstruktur PORT LIST Zur Speicherung der Struktur der durch den Simulationsinterfaceblock Gene rator 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 r 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 Variablenname char port name int port position unsigned char port direction unsigned int port width unsigned int port high unsigned int port low unsigned char port align unsigned int map from unsigned int map to unsigned char special unsigned char active unsigned char sign struct port list prev str
57. Interfaceblocks der zus tz lich Kontrollregister Statusregister und Z hler beinhaltet und eine Kompo nente Autoreset ber die Kontrollregister erhalt 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 llen sowie die Adresse ber die sie angesprochen werden f hren Tabelle 3 3 und 3 4 auf Das Zustandsdiagramm der endlichen Automaten stellt Abbildung 3 23 dar Aus Gr nden der bersichtlichkeit sind die Ausgaben der Zust nde in Tabel le 3 5 aufgef hrt Zu Beginn f hren die Zust nde 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 cwri te bzw cread die Zust nde DWrite bzw DRead In diesen Zust nden sollten 56 3 DIE METHODE DER ADAPTIERUNG Adresse w r Funktion 00 h w Neutrale Adresse 01h w Kontrollregister 02h w LDIV Z hler 03h w Z hler 04h w Zyklenz hler High Byte 05 h w Zyklenz hler Low Byte 06 h w keine 07 h w keine 08 h r Statusregisterl 09 h r Statusregister2 0A h r LDIV Z hlerwert OB h r HDIV Z hlerwert 0C h r Zyklenz hlerwert High Byte OD h r Zyklenz hlerwert Low Byte OE h r keine OF h r Environment ID
58. Jedoch muss dazu eine L sung gefunden werden um die originalen IPs bereits in die Simulation h herer Abstraktionsebenen einzubinden Die Entwicklung einer solchen L sung ist Ziel der vorliegenden Arbeit Spezifikation SW Synthese Betriebssystem Modellierung Entwurfssichten Verifikation HW Sythese Entwurfsebenen Analyse Rapid Prototyping Abbildung 1 5 Die P Chart Entwurfsstrukturierung nach Har02 f r den Entwurf von HW SW Systemen 1 EINFUHRUNG 5 1 1 Aufgabenstellung Der Entwurf von Hardware Software Systemen wurde bisher dadurch er schwert dass eine L cke im Entwurfsprozess zwischen der System Level Beschreibung und der Hardwarebeschreibung existierte Um diese L cke zu schlie en wurde SystemC entwickelt Jedoch ist ein Nachteil dieser Systementwurfsprache dass man bisher ent wickelte Komponenten in VHDL oder Verilog so genannte Intellectual Pro perties erst auf Netzlistenebene SystemC einbinden kann F r die Simu lation von h heren Abstraktionsebenen muss erst ein SystemC Modell der Komponente erstellt werden Das bedeutet zus tzliche Entwicklungsarbeit und damit h here Entwurfskosten In dieser Arbeit soll ein Co Simulationsansatz auf Systemebene untersucht werden Dabei soll die bereits synthesef hige VHDL Komponente auf einem FPGA abgearbeitet werden und mit der Simulation der restlichen SystemC Komponenten gekoppelt werden Der Entwurfsaufwand reduziert sich und das Verhal
59. LDIV an Aber jeder dieser Zust nde wird mindestens einmal durchlaufen Die Anzahl der Durchl ufe dieser Zust nde ergibt sich aus ny 1 ny LDIV 1 A 4 Die Anzahl der Durchl ufe bestimmt f r welche Zeitspanne der jeweilige Pegel generiert wird Die Zeitspanne betragt f r den jeweiligen Pegel aber mindestens 7py min bzw min F r die Gesamtzeit des High bzw Lowpe gels ergibt sich Dr NH UP min trp NL tip min A 5 tipy HDIV 1 DP trp LDIV 1 min 6 Aus den Formeln A 3 und A 6 bildet sich HDIV 1 tre LDIV 1 Trpp A 7 Die Dauer der Taktperiode fiir die P Emulation ergibt sich aus der Zeit des Highpegels und der Zeit des Lowpegels Trp Trp A 8 mit AT Trp HDIV 1 Trea LDIV 1 Tiep A9 T Ee 10 DDIV S2 Trag A 11 A 12 Nach Formel A 1 werden die Taktperioden in Formel A 11 durch Frequenzen ersetzt 1 Fn LDIV 2 13 14 HDIV 4 LDIV 2 Anhang 109 B Hinweise zur Nutzung von SystemC in Mircrosoft Vi sual C 6 0 Um die SystemC Klassenbibliothek erfolgreich der C C Entwicklungs umgebung Microsoft Visual C 6 0 einsetzen zu k nnen m ssen einige Einstellungen vorgenommen werden Sie betreffen den Compiler und den Linker und sind unter dem Men punkt Project gt Settings vorzu nehmen Die Einstellungen s
60. LU ID R1 0xfff000e1 1048351 fr ALU at CSIM 249 ns at CSIM 249 ns Se ene reste ee lcu IFU mem 0x0 IFU mem 0x0 IFU pc 22 at CSIM 251 ns IFU pc 22 at CSIM 251 ns HR HE Hg K KK KK K KK ok OK FK K FK K FK FK K FK ok ok ok OK OK OK OK OK ID REGISTERS DUMP at CSIM 253 ns 3 a kk k ok ke k A a k ak ak ak ak ak ak ak ak k A ak ak ak ak k K REG KK KK K K FK KK FK K FK K FK FK K FK K FK K FK K FK FK K OK K ID REGISTERS DUMP at CSIM 253 ns FORA k k a k kkk k k ak I ak kkk ak k k K 0 00000000 2 fff000e2 4 00000004 6 0000000a 8 00000008 10 00000010 R12 0000ff12 1 fff000e1 R S ffffffff R 5 00000006 R 7 fcfOfdef R 9 00000009 R11 0000ff31 R13 00000013 0 00000000 2 fff000e2 4 00000004 6 0000000 8 00000008 10 00000010 R12 0000ff12 R 1 fff000e1 R S ffffffff R 5 00000006 R 7 fcfOfdef 9 00000009 R11 0000ff31 R13 00000013 Anhang 125 R14 00000014 15 00000015 R14 00000014 R15 00000015 R16 00000016 R17 00 0117 R16 00000016 R17 00 0117 R18 00fe0118 R19 00fe0119 R18 00fe0118 R19 00fe0119 R20 00 0220 R21 00fe0321 R20 00 0220 R21 00 0321 R22 00fe0322 R23 00 0423 R22 00fe0322 R23 00 0423 R24 00f 0524 R25 00ff0625 R24 00f 0524 R25 00 0625 R26 00ff0726 R27 00 0727
61. Liste der gefundenen Ports und ihrer Parameter mit der Datenstruktur PORT LIST auf Wurden alle Ports analysiert pr ft die Funktion vhdl complete entity die Liste der Ports auf Vollst ndigkeit Fehlen Informationen zu einem Port so erg nzt diese die Funktion Die Namen der Ports k nnen durch die Um wandlung des Quelltextes in Kleinbuchstaben jedoch verf lscht sein Um zu gew hrleisten dass die Grof 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 12 4 DER SIMULATIONSINTERFACEBLOCK GENERATOR Entity Deklaration gt Entity Kopf JM Entity K rper 9 Entity Ende Entity Kopf Component Name is gt Entity K rper Generic Deklaration Port Deklaration Entity Ende Cend D Component Name gt gt Generic Deklaration vH e O 0 0 Port Deklaration gt Port Signal 0 gt G gt Port Signal Gignal Port Name Port Richtung gt Port Typ gt Port Typ Port Port Port 0 Low usrichtu
62. P herzustellen Abbildung 3 5 stellt diese genauere Betrach tung der HW SW Schnittstelle dar Dies erm glicht es die eigentliche Grenze zwischen Hardware und Software f r die SystemC Simulation sowie f r die IP Emulation unsichtbar zu machen Welchen Anforderungen die HW SW Schnittstelle gen gen muss um diese Art der Verbindung herzustellen wird im folgenden Abschnitt analysiert 3 1 1 Anforderungsanalyse f r das HW SW Interface Die Anforderungen an die HW SW Schnittstelle sind zun chst die gleichen wie bei einer SW SW Schnittstelle e Austausch von Simulationsdaten und Kontrollsignalen erm glichen e Synchronisation zwischen Simulation und Emulation gestatten e Nutzung der IP ohne diese zu ver ndern Zun chst soll die Anforderung des Datenaustausch n her betrachtet werden Er geschiet ber zwei Schnittstellen Zum Einen ber die Schnittstelle von IP und HW SW Schnittstelle Diese HW HW Schnittstelle h ngt allein von der IP ab Da keine Anderungen an der IP vorgenommen werden sollen bilden die Ein und Ausgangssignale der IP die einzige Kommunikationsm glichkeit Das hat zur Folge dass die HW HW Schnittstelle genau durch die Eing nge und Ausg nge der IP realisiert wird Die andere Schnittstelle befindet sich auf der Softwareseite Dort muss die SystemC Simulation mit der HW SW Schnittstelle verbunden werden Prin zipiell ist es bei dieser SW SW Schnittstelle m glich sie um Kontrollsignale zu erweitern Das Minimu
63. Programme f r die CPU zum Testen der Funktionalitat Ein Assembler ist au erdem beigef gt um selbst Programme zu entwickeln Den Aufbau der beschriebenen RISC CPU stellt Abbildung 5 1 dar Das De sign der RISC CPU setzt sich zusammen aus einem Instructioncache einem Datencache einer Fetcheinheit die die Instruktionen aus dem Instructionca che liest einer Decodiereinheit zum Umwandeln der Instruktionen CPU Operationen und jeweils einer Ausf hrungseinheit f r Ganzzahlen Flie kommazahlen und MMX Berechnungen Im Folgenden wird dieses SystemC Design der RISC CPU als originale RISC CPU bezeichnet Im vorliegenden Szenario Abbildung 5 2 soll die Ausf hrungseinheit f r ganze Zahlen durch eine VHDL IP ersetzt werden die die gleiche Funktio nalit t bereitstellt Die anderen Teile des SystemC Designs das hei t die Beschreibung des Prozessors und das verwendete Testprogramm bleiben un ver ndert Dieses Design wird im Folgenden als modifizierte RISC CPU be zeichnet Die VHDL IP dient als Eingabe f r das Programm Simulations interfaceblock Generator Er generiert daraus die Hardware und die Softwa reseite des Simulationsinterfaceblocks und die Emulation f r diese VHDL IP Die genaue Funktionsweise der Generierung beschreibt Kapitel 4 Die Imple mentierung von Hardware Simulationsinterfaceblock und IP Emulation dient zur Konfiguration eines Digilab 2E Development Boards Der Softwareteil 5 DEMONSTRATOR 89
64. Rahmen die ser Arbeit fand speziell fiir die automatische Adaptierung von SystemC Simulation und VHDL IP Emulation statt Um ein gr eres Einsatzfeld des Programms zu erlangen und damit die praktische Einsatzf higkeit weiter zu steigern sind einige Erweiterungen des Programms denkbar e In der gegenw rtigen Version verarbeitet der Simulationsinterfaceblock Generator nur Ports von VHDL Entities mit den Richtungen in oder out Zur Unterst tzung einer gr Deren Anzahl von VHDL IPs k nnte das Programm f r die Verarbeitung von bidirektionalen Ports Rich tung inout erweitert werden e Mit der Analysem glichkeit von VHDL Generics kann das Konzept von generischen Portbreiten umgesetzt werden Damit ist auch eine Un terst tzung von parametrisierbaren IPs denkbar e Die Erweiterung des Programms zur Unterst tzung anderer Hardwa rebeschreibungssprachen wie zum Beispiel Verilog w rde die Einsatz breite erheblich steigern e Eine Unterst tzung unterschiedlicher FPGA Typen und Boards bringt eine gr ere Flexibilit t des Programms hinsichtlich der Emulations plattform mit sich In diesem Zusammenhang steht die Nutzung von un terschiedlichen Entwicklungsumgebungen und Tools zur Synthese und Implementierung e Andere phyische Hardware Software Schnittstellen k nnen zum Einen die Simulationsgeschwindigkeit erh hen Auf der anderen Seite erh ht sich dadurch ebenfalls die Flexibilit t gegen ber unterschiedlichen Im plementieru
65. S ffffffff R 5 00000005 R 7 fcfOfdef R 9 00000009 R11 0000ff31 R13 00000013 R15 00000015 R17 00fe0117 R19 00fe0119 R21 00fe0321 R23 00 0423 R25 00ff0625 R27 00 0727 R29 00000029 R31 00000031 IFU mem 0xf 60000a IFU pc b at CSIM 75 ns ALU 3 A 10 B 0 ALU R 10 gt R6 at CSIM 79 ns ALU op 3 A 10 B 0 R 10 5 R6 at CSIM 65 ns mem 0x0 a at CSIM 68 ns 3 a a a ae ae ae k k a a ae ae ak ak ak ak A A A ak ak k K ID REGISTERS DUMP at CSIM 70 ns 3 a a ae a sk k k ke a a ae a ak ak ak ak k ak k ak ak ak ak k k K REG 0 00000000 2 fff000e2 4 00000004 6 0000000 8 00000008 10 00000010 R12 0000ff12 R14 00000014 R16 00000016 R18 00fe0118 R20 00fe0220 R22 00 0322 R24 00f 0524 R26 00ff0726 R28 00 70728 R30 00000030 R 1 00000001 R S ffffffff R 5 00000005 R 7 fcfOfdef R 9 00000009 R11 0000ff31 R13 00000013 R15 00000015 R17 00fe0117 R19 00fe0119 R21 00fe0321 R23 00ff0423 R25 00ff0625 R27 00 0727 R29 00000029 R31 00000031 IFU mem 0xf 60000a IFU pc b at CSIM 75 ns ALU op 3 A 10 B 0 ALU R 10 gt R6 at CSIM 79 ns Anhang IFU mem 0x0 IFU at CSIM 82 ns ID REGISTERS DUMP at CSIM 84 ns a a ak ak kkk kk ae ak ak ak ak k I A A A ak k k k REG 0
66. Simulati onsinterfaceblock Generator erfolgreich arbeitet Das Programm erstellte den 5 DEMONSTRATOR 101 Simulationsinterfaceblock auf Basis einer Analyse der VHDL IP und Nut zereingaben Dieser automatisch generierte Simulationsinterfaceblock erfiillte die Aufgabe der Verbindung von SystemC Simulation und IP Emulation zur Zufriedenheit Der Einsatz eines bereits bestehenden SystemC Designs als Teil des Demons trators zeigt dass die Leistung des Simulationsinterfaceblocks und des Simu lationsinterfaceblock Generators ausreicht um auch im praktischen Einsatz Verwendung zu finden 102 5 DEMONSTRATOR 6 ZUSAMMENFASSUNG UND AUSBLICK 103 6 Zusammenfassung und Aus blick Diese Kapitel bildet den Abschluss der Arbeit Es fasst die Konzepte und Ergebnisse dieser Arbeit zusammen und erl utert daran die erfolgreiche Be arbeitung der Aufgabenstellung Anschlie end wird ein Ausblick auf M glich keiten 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 dar auf ab eine synthesef hige VHDL Komponente auf einem FPGA zu emulie ren und die Emulation mit einer SystemC Simulation zu koppeln Die zweite Aufgabe ist eng mit der Ersten verkn pft Dabei sollte aufbauend auf den Be trachtungen des Co Simulationsansatzes ein Verfahren entwicklet werden das eine automatische
67. Simulationsdaten und Controlunitdaten zu erm glichen Dies bringt die Einf hrung eines weiteren Protokollhandlers auf der Hardwareseite des IFBs mit sich Abbildung 3 14 Er wird im Folgenden als PHyw in bezeichnet Diese Ma nahme ist notwendig da der Sequenzhandler laut Definition nur f r die nderung von Daten zust ndig ist Die Verarbeitung von Protokollen ist dem Protokollhandler vorbehalten Die CU Kommunikation k nnte also wie folgt ablaufen Die CUsw will ein Kontrollsignal an die CUgw schicken Dazu leitet sie das Signal an den PHaw 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 PHuw in Er pr ft ob die empfangenen Daten f r die Simulation oder f r die Controlunit bestimmt sind Die Kontrollsignale werden an die CU gw weitergeleitet Sie kann die Signale auswerten und eine Antwort an die CUsw 44 3 DIE METHODE DER ADAPTIERUNG ber den gleichen Weg zur cksenden 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 gliche technischen Ums
68. Softwareteils generiert das Programm wiederum aus Templates Wahrend des Programmlaufs schreibt der Simulationsinterfaceblock Gene rator Informationen f r den Benutzer zu den einzelnen Operationen sowie 4 DER SIMULATIONSINTERFACEBLOCK GENERATOR 75 aufgetretene Fehler in ein Logfile Nach den Generierungsphasen ist das Pro gramm abgeschlossen und die erzeugten Daten verwendet werden Mehr Informationen zur Verwendung der Daten bietet der Abschnitt 4 3 4 3 Benutzung des Programms Dieser Abschnitt erkl rt die Benutzung des Simulationsinterfaceblock Generator Er gibt Hinweise zum Aufbau des Programms und zu den ein zelnen Phasen die w hrend der Ausf hrung durchschritten werden Aufer dem enthalt dieser Abschnitt Informationen zu den Nutzereingaben die das Programm in den einzelnen Phasen erwartet Am Ende wird ein berblick 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 Auf ruf der Datei simifb_generator exe Es erscheint ein Fenster auf dem Bild schirm 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 fiir die Eingaben des Benutzers In den einzeln
69. Systems mit seinen dynamischen Prozessen in einem experimentierbaren Modell um zu Erkenntnissen zu gelangen die auf die Wirklichkeit bertragbar sind Im weiteren Sinne wird unter Simulation das Vorbereiten Durchf hren und Auswerten gezielter Experimente mit einem Simulationsmodell verstanden Mit Hilfe der Simulation kann das zeitliche Ablaufverhalten komplexer Sys teme untersucht werden Die Simulation ist ein wichtiges Werkzeug beim Hardwareentwurf um ein System w hrend des Entwurfsprozesses zu testen und Fehler fr hzeitig zu lokalisieren und zu beseitigen Die Durchf hrung von Simulationen soll den Nachweis erbringen dass der verfeinerte Entwurf noch mit der Spezifikation des Systems bereinstimmt Den Ausgangspunkt einer Hardwaresimulation bildet eine Beschreibung in ei ner Hardwarebeschreibungssprache HDL engl Hardware Description Lan guage Die wichtigsten Sprachen sind VHDL Verilog und SystemC Auf 14 2 STAND DER TECHNIK Entwurfsebene Aufwand relativ Verhalten 1 Register Transfer 10 Gatter Logik 100 Schalterebene 1000 Elektrische Ebene 10000 Geometrie 100 000 1000000 Tabelle 2 1 Simulationsaufwand von verschiedenen Entwurfsebenen Quelle M l02 Basis dieser Beschreibung wird von einem Simulationswerkzeug ein Simula tionsmodell erstellt Ein Simulationsmodell kann unterschiedliche Abstrakti onsebenen eines Systems nachbilden Dabei erh ht sich der Detailgrad
70. THODE DER ADAPTIERUNG 51 Ist das asynchrone Resetsignal nicht aktiv so findet die Pr fung auf Aktivitat des Taktsignals statt Die einzelnen Schritte sind denen der Resetausf hrung gleich Der einzige Unterschied besteht darin dass nach dem Schreiben der Simulationsdaten kein Reset durchgef hrt wird sondern das Taktsignal ent sprechend der gesetzten Z hlerwerte an die IP Emulation angelegt wird 3 3 4 Der DH Der hardwareseitige Protokollhandler Abbildung 3 19 der die Schnittstelle zur physischen HW SW Schnittstelle bildet hat folgende Aufgaben e Kommunikation ber die parallele Schnittstelle realisieren e Trennung von Simulationsdaten und CU Kommunikation F r die Kommunikation ber die parallele Schnittstelle implementiert der Modus des PHyw in den Protokollautomaten f r die Slave Seite des EPP Protokolls Abbildung 3 16 stellt den Protokollautomaten dar Es werden 4 status Handler control Adresse Daten 4 Daten physical HW SW IF Parallele Schnittstelle pl sonst EPP See Protokoll Paten CU Komm automat Daten Extraktion Abbildung 3 19 Detailierter Aufbau des PHyw in 52 3 DIE METHODE DER ADAPTIERUNG EPP bertragungsarten durch den Protokollautomaten implementiert Da zu z hlen das byteweise Lesen von Adressen Schreiben von Adressen Lesen von Daten und Schreiben von Daten F r die vorliegenden Aufgaben wird jedoch die Funktion des Lesens von Adr
71. Umw SetHDIV Counter Setzt den Z hler in CU ou SetCycleCounter Setzt den Zyklenz hler in CU gw GetStatusl Liest erstes Statusbyte von CUyw GetStatus2 Liest zweites Statusbyte von CU ue GetLDIV Counter Liest Wert des LDIV Z hler GetHDIV Counter Liest Wert des HDIV Z hler GetZyklenCounter Liest Wert des Zyklenz hlers condition _to_ Pr ft ob ein Signal einen bestimmten start_simulation Wert hat init_Interface initialisiert die parallele Schnittstelle test environment id pr ft ob sich auf dem FPGA der richtige IFB befindet Tabelle 3 6 Funktionen der CUsw 3 4 Anwendungsm glichkeiten Der Haupteinsatzzweck dieses Hardware Software Interfaces ist die gekop pelte Simulation einer SystemC Verhaltensbeschreibung und einer synthe sef higen VHDL IP Eine weitere Anwendung liegt in der Simulation eines Prototypen auf ei nem FPGA unter Verwendung eines SystemC Testbenches Dies stellt den Haupteinsatzzweck ohne weitere SystemC Module dar Die einzigen Modu le sind dabei der Testbench die Mainfunktion und das Koppelmodul des Interfaceblocks Durch die Verwendung von SystemC die Simulati onsdaten des ausgefiihrten 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 nnen auch dynamisch rekonfigurierbare Designs emu
72. aben der darin enthaltenen Dateien f hrt Tabelle 4 10 auf Neben den Dateien verf gt das Verzeichnis ber Unterverzeichnisse Sie dienen der geordneten Speicherung der Implementierungsdaten des Hardwareteils des Simulations interfaceblocks 4 DER SIMULATIONSINTERFACEBLOCK GENERATOR 83 Abbildung 4 13 berblick ber die Verzeichnisstruktur der generierten Da ten Im Folgenden sind die Unterverzeichnisse und eine kurze Beschreibung der enthaltenen Daten aufgef hrt Bit Verzeichnis mit den Ausgaben der Bitfile Generierung Die Datei mit der Endung bit dient zur Konfiguration des FPGA Log Dieses Verzeichnis enthalt die Statusausgaben der ausgef hrten Skrip te Dabei steht der erste Teil des Dateinamen f r die ausgef hrte Datei z B xst log f r die Synthese mit xst exe Map Verzeichnis dass die Daten aus dem Technologiemapping des Designs enth lt Ngdbuild In diesem Verzeichnis befinden sich die Dateien die durch die Ubersetzung des Syntheseergebnisses erstellt wurden Par Die Ergebnisse der Platzierung und Trassierung enth lt dieses Ver zeichnis Src Die VHDL Quelldateien des Hardwareteils die vom Simulationsinter faceblock 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 zu sammen 84 4 DER SIMULATIONSINTERFACEBLOCK GENERATOR
73. ar da im Testprogramm keine Division ausgef hrt wird die ne h here Verarbeitungsbreite als 16 Bit beansprucht Auferdem dient der Demonstrator dem Zweck die Einsatzf higkeit und korrekte Funktion des 90 5 DEMONSTRATOR VHDL IP Integer Execution Unit Floatingpoint Execution MMxXlike Execution r Fetch Decode J Instruction Cache Testprogramm SimIFByy amp IP Emulation C C Compiler parallele Schnittstelle Data Cache PC Abbildung 5 2 Aufbau des Demonstrators Konzeptes des Simulationsinterfaceblocks und des Simulationsinterfaceblock Generators nachzuweisen und nicht die der VHDL IP Im Fall des Simulati onsinterfaceblocks bedeutet es den korrekten Austausch der Daten ber die HW SW Schnittstelle und die erfolgreiche Kopplung der SystemC Simulation mit der IP Emulation F r den Simulationsinterfaceblock Generator hei t korrekte Funktion dass der Simulationsinterfaceblock in Abh ngigkeit von der VHDL IP so erstellt wird dass er seine Aufgabe erfolgreich erf llen kann 5 3 Nachweis der Funktion Um den Nachweis zu erbringen dass der Simulationsinterfaceblock seine Auf gabe erf llt sollen die Simulationsergebnisse der originalen und der modifi zierten RISC CPU miteinander verglichen werden Dazu ist zun chst Er stellung der Simulation der originalen RISC CPU erf
74. are simulator Backplane Abbildung 2 9 HW SW Cosimulation mit einem Instruction set Simulator Funktionalit t des Prozessors dass hei t die Applikationssoftware f hrt ein Befehlsinterpreter aus Er verf gt ber Information zu den ben tigten Takt zyklen einer Sequenz von Befehlen zwischen zwei I O Operationen auf dem Bus Dieses Modell ist n tzlich um die low level Interaktion der Kommuni kation auf dem Prozessorbus zu simulieren Jedoch ist es unter Umst nden 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 enthalt alle Details eines ereig nisdiskreten Prozessormodells welches die volle Funktionalit t des Prozessors bereitstellt Dieser Cosimulationsansatz verbindet einen Hardwaresimulator auf dem die Hardwarekomponenten simuliert werden und den 155 der die Ausf hrung der Software bernimmt Die Heterogene Cosimulation verfolgt die Kopplung von Hardware und Software Entwicklungstools Dies erlaubt die schnelle Ausf hrung von Soft ware Anwendungscode auf einer simulierten Hardware Die Cosimulation ver schiedener Hardwarekomponenten und der Software l uft in einem heteroge nen Netzwerk aus PC s oder Workstations Der Ansatz des Hardware Modells wie ihn Abbildung 2 10 zeigt kann Realer Prozessor
75. aten zwischen Sender und Empfanger transformiert werden Dadurch ist ein Einsatz als Adapter zwischen physisch inkompatiblen bzw semantisch inkompatiblen Kommunikationskomponenten m glich Der Interfaceblock ist modular aufgebaut Er besteht wie Bild 3 7 zeigt aus einer Controlunit CU zwei Protokollhandlern PH und einem Sequenz handler SH Jeder der Handler besitzt zus tzlich mindestens einen Modus der die eigentliche Funktionalit t implementiert 3 DIE METHODE DER ADAPTIERUNG 37 Abbildung 3 7 Makrostruktur des Interfaceblock Die Controlunit bernimmt die Steuerungsaufgaben innerhalb des Interfa ceblocks 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 ber Kontrollsignale und erh lt 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 Proto kolle der angeschlossenen Kommunikationskomponenten Die Kommunikati on 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 Abbildun
76. ationsvorbereitung einzusparen Die Erstellung eines Simulationsinterfaceblocks kann aber auch viel Zeit in An spruch nehmen Die manuelle Erstellung des Simulationsinterfaceblocks erh ht zudem die Wahrscheinlichkeit dass sich Fehler im Design einschleichen Um die menschlichen Fehler einzugrenzen und die Zeit f r die manuelle Er stellung einzusparen soll hier im Folgenden eine automatische L sung vorge stellt werden Die L sung besteht im Programm Simulationsinterfaceblock Generator und wurde im Rahmen dieser Arbeit entwickelt 4 2 Arbeitssweise Dieser Abschnitt stellt die Arbeitsweise des Simulationsinterfaceblock Gene rators vor Zun chst erfolgt die Vorstellung der Eingaben f r das Programm 64 4 DER SIMULATIONSINTERFACEBLOCK GENERATOR SimIFByw Konfigurations datei f r FPGA Nutzereingaben Abbildung 4 1 Eingaben und Ausgaben des SimIFB Generators und die gew nschten Ausgaben Anschlie end wird die interne Datenstruk tur auf der das Programm arbeitet erkl rt bevor der Ablauf des Programms beschrieben wird 4 2 1 Eingaben und Ausgaben F r die Entwicklung eines Programmes sind als erstes die Eingaben und Ausgaben zu betrachten Abbildung 4 1 Als Eingaben stehen dem Simu lationsinterfaceblock Generator die VHDL IP die emuliert werden soll und Templates zur Verf gung Zus tzlich k nnen vom Benutzer noch einige Pa rameter w hrend des Programmlaufs festgelegt werden Nach dem Programml
77. auf sollen sowohl der Softwareteil also auch der Hard wareteil des Simulationsinterfaceblocks zur Verf gung stehen Der Softwa reteil besteht aus C C Quelldateien die in ein SystemC Design einge bunden werden Der Hardwareteil beinhaltet als erste Ausgabe die VHDL Quelldateien des Simulationsinterfaceblock und die daran angebundene IP Aus diesen Quelldateien erfolgt unter Nutzung von externen Tools zur Syn these Platzierung und Trassierung die Generierung der Konfigurationsdatei f r das FPGA 4 2 2 Die internen Datenstrukturen Ein Programm ben tigt zur Speicherung und Verarbeitung von Daten eine Datenstruktur Die Hauptdatenstruktur im Simulationsinterfaceblock Gene rator ist die ENTITY_STRUCTUR Sie nutzt die Datenstrukturen PORT_LIST und GENERIC_LIST Zur Unterst tzung 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 Be schreibung der Datenstruk
78. beansprucht gr er ist als die Simulationszeit der originalen RISC CPU Die Vermutung begr ndet sich darauf dass bei der Simulation der modifizierten RISC CPU zus tzlich Zeit f r die Kommunikation zwischen 94 5 DEMONSTRATOR SystemC Simulation und IP Emulation sowie fiir die interne Kommunikation des Simulationsinterfaceblocks aufgewendet werden muss Daraus folgt dass die Geschwindigkeit der physischen HW SW Schnittstelle einen wesentlichen Faktor f r die Simulationszeit darstellt Die Untersuchung ihrer Geschwindigkeit stellt sich deshalb als erste Aufgabe Abschnitt 5 4 1 Anschlie end wird die Simulationszeit unter Ber cksichtigung der gewonne nen Erkenntnisse zur HW SW Schnittstelle betrachtet 5 4 1 Geschwindigkeit der parallelen Schnitt stelle F r die Messung der bertragungsgeschwindigkeit der parallelen Schnittstel le mit dem EPP Protokoll wurde im Rahmen dieser Arbeit eine Messeinrich tung entwickelt Sie setzt sich aus dem Softwareprogramm Speedtest_sw und dem VHDL Design f r 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 ber die parallele Schnittstelle zu schreiben oder zu lesen F r den Programmaufruf m ssen zwei Parameter angegeben werden Zu Einem der Arbeitsmodus und zum Anderen die Adresse der parallelen Schnittstelle im PC Das Programm besitzt sechs ve
79. beschreibungs konstrukte wie zum Beispiel Latches mehrere Takte Gated Clocks und Mo delle mit Signalst rken Alle synthetisierbaren Verilog und VHDL Konstrukte k nnen beschleunigt werden Dar ber hinaus ist es auch m glich Testben ches zu beschleunigen sowie Modelle mit Verz gerungszeiten auszuf hren Zur Software geh rt auch der Runtime Manager Er erleichtert die Laufzeit kontrolle 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 hrung der Simulation auf dem Hammer 100 und einem Software HDL Simulator ebenfalls vollzogen werden Der Debugger kommuniziert mit dem Hardware Trace Buffer um w hrend des Debuggen des Designs einen schnellen Datengewinn aus dem Akzelera tor zu gew hrleisten Das Debugging wird in Hardware ausgef hrt und ist dadurch sehr schnell Auch schrittweises Debugging des Designs ist m glich 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 ber dem schnells ten Software HDL Simulator Die Ausbaustufen des Hammer 100 sind f r 2 4 8 16 und 32 Millionen Gatter quivalente ausglegt Bei einer Zusammen schaltung mehrerer Hammer 100 simuliert das System bis zu 64 96 oder 128 Millionen Gatter
80. bildung 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 rzen den Entwicklungsaufwand f r neue Systeme erheblich da diese Module nicht neu entwickelt werden m ssen Im Idealfall k nnen sie ohne Anderungen in das Design eingebunden werden Ein aktuelles Problem mit dem die Entwickler konfrontiert sind bildet eine L cke im Entwurfsprozess Abbildung 1 2 stellt diesen Sachverhalt dar Die 2 1 EINFUHRUNG C C WW System Level Model Results Manual Conversion VHDL Verilog Refine Rest of Process Abbildung 1 2 Aktuelle Methode des Hardwareentwurfsprozesses Quelle Opeb Entwicklung eines Systems beginnt mit einer Spezifikation auf Systemebene Die dafiir verwendete Sprache ist meist C oder C Die Spezifikation wird schrittweise analysiert und verfeinert Dabei durchl uft Systementwick lung 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 ar beitet Ab einem Verfeinerungsgrad der einer Verhaltensbeschreibung entspricht reichen die bestehenden Beschreibungsm glichkeiten von C C nicht mehr aus und es muss auf eine Hard
81. che Silizium etwa alle 18 Monate verdoppelt Abbildung 2 3 stellt diesen Sach verhalt grafisch dar Dieses Gesetz hat bis heute noch G ltigkeit und wird nach Meinung von Experten auch noch 10 Jahre seine G ltigkeit behalten F r die Hardwareentwickler ergibt sich die Konsequenz dass auf der glei chen Fl che Silizium eine immer gr ere Funktionalit t untergebracht wer den 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 sung ist eine gr ere Zuverl ssigkeit gegen ber 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 ere Spezialisierung der Funk tion Mit einer gr eren F lle an Funktionen sinkt das Anwendungsfeld der Chips Doch je kleiner das Anwendungsfeld desto weniger St ckzahlen wer den vom Chip gebraucht Jedoch m ssen sich mit dem Verkauf des Chips auch 10 2 STAND DER TECHNIK transistors 100 000 000 Pentium 4 Processor Pentium Ill Processor MOORE S LAW d Pentium Il Processor 10 000 000 Pentium Processor 486 DX Processor i 1 000 000 386 Processor lt d m 100 000 i i TE 3 10 000 d 8008 4004 i 1000 1970 1975 1980 1985 1990 1995 2000 Abbildung 2 3 Darstellung
82. die Entity aus dem Text heraus indem sie den Bereich an den Beginn des Textes schreibt und den Rest mit Leerzeichen auff llt Sind alle vorbereitenden Arbeiten durchgef hrt 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 bedeu tet dass syntaktische Elemente im Text durch ein Leerzeichen voneinander getrennt werden Zu den syntaktischen Elementen z hlen zum Beispiel die Schl sselw rter entity port und is aber auch Zeichenketten f r Namen so wie 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 Syn tax auf die der Parser aufbaut stellt das Syntaxdiagramm in Abbildung 4 2 dar Das Syntaxdiagramm gibt nicht die vollst ndige Syntax f r eine VHDL Entity wieder Es ist nur auf die in diesem Zusammenhang ben tigten syntaktischen Konstrukte reduziert Andere m gliche Konstrukte wie Attri bute werden durch den Parser ignoriert Auch die Auswertung von Generics vernachl ssigt der Parser da ihre Verwendung im Simulationsinterfaceblock Generator bis jetzt noch nicht implementiert ist Der Parser stellt zun chst den Namen der Entity fest und speichert ihn in der Datenstruktur ENTITY STRUCTURE Anschlie end baut er eine
83. e Demonstration zu bieten und seine Resonanz in die weitere Entwicklung mit einflie en zu lassen Der System Explorer wird in zwei Ausf hrungen hergestellt Die Bezeichnun gen sind MP3CF und MP4CF Tabelle 2 2 stellt die technischen Daten der beiden Systeme gegen ber Weiterf hrende Informationen zum Aptix Sys tem Explorer sind auf der Homepage des Unternehmens Apt sowie in der Brosch re zum System Explorer Apt00 enthalten 2 4 Fazit Die vorangehenden Punkte besch ftigten sich mit SystemC als neue Ent wurfssprache mit dem Nutzen von Intellectual Properties und der Bedeutung der Simulation im Hardwareentwurf Dazu wurden einige Simulationswerk zeuge und methoden vorgestellt SystemC bringt die Voraussetzungen mit um den Entwurfsprozess von Hard waresystemen und Hardware Software Systemen weiter zu beschleunigen Ein Nachteil ist noch die mangelnde Unterst tzung von sprachfremden IPs ber der Register Transfer Ebene Intellectual Properties bilden zuk nftig ein Schl sselkonzept bei der Ent wicklung von SoC Designs Durch ihren Einsatz k nnen die Entwicklungszeit und kosten weiter gesenkt werden Es existieren bereits L sungen zum einfa chen 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 existie ren verscheidene Simulationswerkzeuge d
84. e ae aka k k k ak ak ak kk k ak k A a ak ak ak k k ak ak K REG 0 00000000 R 2 00000003 R 4 00000004 R 6 0000000a 8 00000008 R10 00000010 R12 0000ff12 R14 00000014 R16 00000016 R18 00fe0118 R20 00fe0220 R22 00 0322 R24 00ff0524 R26 00ff0726 R28 00 70728 R30 00000030 R 1 000e1 R S ffffffff R 5 00000006 R 7 fcfOfdef R 9 00000009 R11 0000ff31 R13 00000013 R15 00000015 R17 00 0117 R19 00fe0119 R21 00fe0321 R23 00 0423 R25 00 0625 R27 00 0727 R29 00000029 R31 00000031 126 Anhang mem Oxffffffff IFU mem Oxffffffff IFU 25 at CSIM 272 ns IFU pc 25 at CSIM 272 ns EE area Se ont ME ID SHUTDOWN at CSIM 274 ns ID SHUTDOWN at CSIM 274 ns ID PLEASE WAIT ID PLEASE WAIT Anhang D 127 D 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 hrleisten Die Verzeichnisstruktur gliedert sich wie folgt Doc Bilder Programme Epp speedtest Hardware Software Simifb generator Templates Timedrun Sources Epp speedtest Hardwa
85. eentwicklung 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 miissen Dadurch entfallt die Entwicklung dieser Teilsysteme im Entwurfsprozess und Entwicklungszeit wird eingespart Die IP kann in verschiedenen Beschreibungen vorliegen Har04 Man unter scheidet zwischen Hard IPs und Soft IPs Hard IPs besitzen ein vorgegebe nes Layout und Timing Sie haben fixe Schnittstellen Die Optimierung der IPs ist in Bezug auf Geschwindigkeit Siliziumfl che und Leistungsaufnahme getroffen Sie sind leicht zu verifizieren au erdem halbleiterhersteller und technologieabhangig 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 gbar Sie sind halbleiterhersteller und technologieunabh ngig konzipiert Soft IPs sind flexibel und zum Teil parametrisierbar Das Konzept der IPs wird als wichtiger Schritt angesehen um die Entwick lungszeiten von Hardware zu verringern Vor allem f r die System on Chip Entwicklung stellt es ein Schl sselkonzept dar 12 2 STAND DER TECHNIK Jedoch gibt es bei der IP Nutzung noch einige Hindernisse Zum Beispiel stellt sich die
86. en Feldern des Nutzerbereichs existiert jeweils ein Hilfe Button um Informationen zu den entsprechenden Eingabefeldern zu erhalten Der rechte Teil enth lt ein Sta tusfeld 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 durchzufiihren hat ist die Auswahl der VHDL IP f r die ein Simulationsinterfaceblock erstellt werden soll Dies er folgt im Bereich Analyseparameter unter dem Punkt Quelldatei Mit einem Klick auf den oberen Durchsuchen Button ffnet sich ein Dialogfeld in dem die Datei ausgew hlt 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 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 hlbar Ab bildung 4 5 Durch Klicken des Button Analyse starten beginnt das Pro gramm die VHDL IP zu analysieren und ihre interne Datenstruktur aus der Entity der VHDL IP aufzubauen Analyseparameter Quelldatei Z diplom sources sitb5 whdl exec exec vhd Durchsuchen
87. entwicklung 2 STAND DER TECHNIK T 2 Stand der Technik Dieses Kapitel besch ftigt sich mit dem aktuellen Stand der Techniken auf die diese Arbeit aufbaut Zun chst erfolgt eine Beschreibung der noch jungen Systementwurfssprache SystemC Der zweite Teil des Abschnittes definiert den Begriff der Intellectual Properties und umrei t deren Bedeutung An schlie end wird auf die Rolle der Simulation bei der Hardwareentwicklung eingegangen und einige Beispiele f r Simulationswerkzeuge darunter auch Hardwareakzeleratoren vorgestellt Das Ende des Kapitels fa t die hier ge wonnen Erkenntnisse zusammen und arbeitet noch einmal kurz die Vor und Nachteile aktueller Techniken heraus 2 1 SystemC SystemC ist eine standardisierte Systementwurfs und Verifikationsspra che Sie wurde im September 1999 eingef hrt und durch die OSCI Open SystemC Initative standardisiert Die OSCI ist ein Konsortium gr e rer 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 Konsor tiums befinden sich auf der Homepage von SystemC Opeal SystemC ist ein eingetragenes Warenzeichen der Open SystemC Initiative Abbildung 2 1 Logo von SystemC Quelle Opea 8 2 STAND DER TECHNIK C C System Level Model SystemC Model Manual Co
88. er Cosimulati onsans tze bieten Vra98 und Har04 2 3 4 Hardware Akzeleratoren Der Nachteil einer HDL Simulationssoftware ist die stark sinkende Simulati onsgeschwindigkeit mit steigendem Detailgrad und steigender Designgr fe Um diesen Nachteil der Simulation zu vermeiden werden Hardwareakzele ratoren eingesetzt Sie emulieren das System auf FPGAs oder simulieren es auf Spezialprozessoren Dadurch steigert sich die Geschwindigkeit der Simu lation 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 Simula tion oder Emulation durchzuf hren und die Simulationsergebnisse zu liefern 2 STAND DER TECHNIK 21 Das Softwarepaket ist daf r zust ndig den ausf hrbaren Code bzw die Kon figurationsdaten fiir den Hardwareakzelerator aus einer HDL Beschreibung zu compilieren bzw zu generieren Auferdem hat es die Aufgabe die Kom munikation zwischen dem Hostrechner und dem HW Akzelerator zu mana gen 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 Den Hardwareakzelerator Hammer 100 stellt die Firma Tharas Systems Thaa her Es ist ein Simulationss
89. er korrekten Funktion durch die Ausf hrung des Demonstrators und dem Vergleich mit dem Ursprungs design erbracht Da ben tigte Zeit einer Simulation ein wichtiges Kriterium bei der Wahl der Simulationsart darstellt schlossen sich dem Nachweis der Funktion Untersuchungen zur Simulationsgeschwindigkeit an In diesem Zu sammenhang 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 ngt Das Ergebnis des Demonstrators bestand darin dass die erarbeiteten Konzepte dieser Arbeit ihre Aufgaben korrekt erf llten und erfolgreich in der Praxis eingesetzt werden konnten Auch das Prorgamm Simulationsinterfaceblock Generator erf llte seinen Zweck und er laubt die automatische Adaptierung einer IP Emulation und einer SystemC Simulation Anhand des Demonstrators wurde gezeigt dass die gestellten Aufgaben dieser Arbeit erfolgreich gel st wurden 6 ZUSAMMENFASSUNG UND AUSBLICK 105 6 2 Ausblick f r den erweiterten In terfaceblock Abgeleitet vom Konzept des erweiterten Interfaceblocks wurde in dieser Ar beit die Implementierung eines Simulationsinterfaceblocks durchgef hrt Er dient zur Kopplung einer SystemC Simulation auf einem PC und einer IP Emulation auf einem FPGA Im Bezug auf die Cosimulation k nnten weiterer Arbeiten folgende Themen untersuchen e Unte
90. eser Protkollhandler hat die Aufgabe die Kommunikation mit der SystemC Simulation auf Softwareseite sicherzustel len 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 ndert sich nichts Die Funktionalit t wird in Software jedoch durch Funktionen bestimmt die Algorithmen implemen tieren und nicht durch kombinatorische Logik und endliche Automaten Die Daten bergabe findet bei Funktionen 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 ckgabewerte erzeugen Au erdem erlaubt Software die Implementierung von umfangrei chen Funktionen Es spricht also nichts dagegen dem Interfaceblock eine SW Schnittstelle in Form eines Softwareprotokollhandlers zu geben Die Mo di liegen ebenfalls in Software und sind durch Funktionen implementiert die vom PHsw aufgerufen werden 3 DIE METHODE DER ADAPTIERUNG 41 Abbildung 3 10 Die Softwareschnittstelle des Interafceblocks der Protokollhandlersw 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 glichkeiten sie zwischen PHsw und SH oder SH und PHgw 44 anzusiedeln Um einen Gro teil des IFB Modells bei zubehalten w
91. esetsignals dar Fehler bei der Eingabe zeigt das Statusfeld an 78 4 DER SIMULATIONSINTERFACEBLOCK GENERATOR Kein Takt addi Pe S Abbildung 4 7 Ansicht der Felder zur Einstellung der Signalparameter 4 3 4 Weitere Parameter Nun ffnet sich das letze Feld mit Benutzereingaben Abbildung 4 8 In diesem Abschnitt k nnen einige zus tzliche Parameter eingestellt werden Auf der linken Seite des Feldes k nnen semantische Einstellungen zu den Vektoren vorgenommen werden Alle Signale die als Vektor in der Entity der VHDL IP eingetragen sind k nnen n her spezifiziert werden Der Nut zer kann die Auswahl treffen ob der Vektor mit einem Vorzeichen behaftet Abbildung 4 8 Der Simulationsinterfaceblock Generator nach der Einstel lung der Signalparameter 4 DER SIMULATIONSINTERFACEBLOCK GENERATOR 79 Semantik der Vektoren und zus tzliche Parameter Portname Br Ri Datentyp 1 Taktzyklen der Emulation F bei einem Simulationstakt opcode 4 in signed aah an 3784 Adresse des Parallelport diria signe dinb 32 i igned SE A 50 dee EPA dout 32 out signed Cidestout 5 out unsigned Hilfe Abbildung 4 9 Detailierte Ansicht des Feldes zur Einstellung der Vektorse mantik und von zus tzlichen Parametern sein soll oder nicht Dies erleichtert die sp tere Integration des generierten SystemC Moduls das SystemC Desig
92. essen nicht ben tigt Der Protokoll automat 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 r die zweite Aufgabe des die Trennung von Simulationsdaten und CU Kommunikation Die CU Kom munikation findet 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 er als 10h sind werden unver ndert an den SHyw weitergegeben Die Auswertung dieser Adressen ist nicht Aufgabe der PHuw in Der endliche Automat Handlercontrol Abbildung 3 19 dient allein zur in ternen Kontrolle des Handlers und zum Starten eines Modus Den Daten transport durch den IFB beeinflusst er nicht 3 3 5 Der SH Die Aufgabe des Sequenzhandlers im Hardwareteil des Simulationsinterfa ceblocks liegt in der korrekten Verteilung der Simulationsdaten Durch die HW SW Schnittstelle liegen die Daten in Form von Tupel Adresse Daten byte vor Anhand der Adresse muss nun zuerst eine Unterscheidung getroffen werden ob es sich um eine Schreibadresse oder eine Leseadresse handelt wat Schreibadressen 10h 10h ES 3 1 LN 1 RN
93. etzt Damit ist auch eine Unterst tzung von parametri sierbaren IPs denkbar Die Menge der unterst tzen IPs kann weiter steigen indem Mechanismen in das Programm eingebaut werden die andere Hardwarebeschreibungsspra chen wie zum Beispiel Verilog analysieren k nnen Somit wird eine Adaptie rung von IPs in verschiedenen Hardwarebeschreibungssprachen erreicht und das Programm gewinnt an Flexibilitat Die vorliegenden Version des Simulationsinterfaceblock Generators schr nkt die hardwareseitige Implementierungsplattform noch auf das Digilab 2E De velopmentboard ein Um diese Restriktion aufzuheben muss das Programm f r die Unterst tzung anderer FPGA Typen und Boards erweitert werden Damit einher geht die Nutzung von unterschiedlichen Entwicklungsumge bungen und Tools zur Synthese und Implementierung Da andere FPGA Boards auch andere phyische Schnittstellen besitzen k nnen ist zudem eine Unterst tzung anderer physischer HW SW Schnittstellen zur berwindung der HW SW Grenze denkbar Der Simulationsinterfaceblock Generator wurde entwickelt um eine VHDL IP mittels eines Simulationsinterfaceblocks an eine SystemC Simulation au tomatisch zu koppeln Das Programm nimmt dem Nutzer die manuelle Ad aptierung 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 glichen Fehler die bei einer manuellen Adap tierung auftreten k
94. etzung dieses Modells am Beispiel des Simulationsinterface blocks 3 3 Technische Umsetzung der Adap tierung durch einen Simulations interfaceblock Dieser Abschnitt stellt eine M glichkeit der technischen Umsetzung eines erweiterten Interfaceblocks dar Da die Erweiterung speziell f r die Kopp lung von SystemC Simulation und IP Emulation zugeschnitten ist wird der erweiterte Interfaceblock im weiteren Verlauf dieser Arbeit als Simulations interfaceblock SimIFB bezeichnet 3 3 1 Die hardwareseitige Implementierungs plattform Als Implementierungsplattform f r 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 FPGA Chips lautet XC2S200E PQ208 Mit dem FPGA k nnen bis zu 200000 Gat ter quivalente nachgebildet werden Die Entwicklungsplatine verf gt au er dem ber mehrere Extensionheader sowie ber eine serielle eine parallele und eine JTAG Schnittstelle Mehr Informationen zur Entwicklungsplatine bietet das dazugeh rige Hand buch Dig02 Erl uterungen zum Xilinx Spartan 2E FPGA enth lt das Da tenblatt Xil03 3 DIE METHODE DER ADAPTIERUNG 45 Toor doce TL e e E Abbildung 3 15 Digilent 2E Developmentboard mit Xilinx Spartan 2E FPGA Quelle Dig 3 3 2 Umsetzung des HW SW Interfaces Als physische Ha
95. f der anderen Seite kann eine rein praktische Implementierung eventuell nicht allgemein modelliert werden und bleibt damit auf eine spezielle Anwendung beschrankt 5 2 Aufbau und Funktionsweise Zur Demonstration des Konzeptes der HW SW Schnittstelle und des im Rahmen dieser Arbeit erstellten Programms Simulationsinterfaceblock Ge nerator sollte ein Beispiel gew hlt werden welches die praktische Relevanz der Ergebnisse dieser Arbeit wiederspiegelt Aus diesem Grund soll nach M glichkeit auf ein bereits bestehendes Design zur ckgegriffen werden und keine reine Selbstentwicklung Verwendung finden Als Grundlage des Demonstrators dient ein SystemC Design aus den Beispie len zur SystemC Version 2 0 1 Diese Version ist auf der SystemC Website 88 5 DEMONSTRATOR Integer Execution Fetch Decode wm Floatingpoint Execution _ MMxXlike Execution Abbildung 5 1 Aufbau des Designs RISC CPU d Instruction Cache Data Cache Opea frei verf gbar Das Beispiel beschreibt ein einfaches Design einer RISC CPU in SystemC Es wurde von Synopsys Syn entwickelt um die F higkeiten von SystemC bei der HW SW Partitionierung zu veranschau lichen Auferdem kann es als Instruction set Simulator eingesetzt werden Das Design findet sich nach dem Entpacken des heruntergeladenen SystemC Paketes im Verzeichnis systemc 2 0 1 examples systemc risc_cpu Es bein haltet zus tzlich
96. f31 R13 00000013 R15 00000015 R17 00fe0117 R19 00fe0119 R21 00fe0321 R23 00 0423 120 Anhang C R24 00 0524 R25 00ff0625 R24 00ff0524 R25 00 0625 R26 00ff0726 R27 00 0727 R26 00ff0726 R27 00 0727 R28 00 70728 R29 00000029 R28 00 70728 R29 00000029 R30 00000030 R31 00000031 R30 00000030 R31 00000031 Ll 2222222222222222222222222 2 2 2 2 gt FTN NEPTIS eee ee IFU mem 0xf550000 IFU mem 0xf550000 IFU pc 19 at CSIM 173 ns IFU pc 19 at CSIM 173 ns dou e Me eee s oL N ee en NEE ID R5 R5 5 ID R5 R5 5 at CSIM 175 ns at CSIM 175 ns M DUE et E SUE 232232222222 C ALU op 3 A 5 B 0 ALU 3 A 5 B 0 ALU R 5 gt R5 at CSIM 177 ns ALU R 5 gt R5 at CSIM 177 ns IFU mem 0x0 IFU IFU 1 at CSIM 180 ns IFU mem 0x0 1 at CSIM 180 ns ID REGISTERS DUMP at CSIM 182 ns 3 a ke sk ok ok ok ok k k ACA ak ak ak ak k ak k ak ke A ak ak ak ak k K REG KKK K KK KK K K FK K K FK K FK K FK FK K FKK FK K FK K FK FK K ID REGISTERS DUMP at CSIM 182 ns 3 a ORC a kk k kkk ak a ak k k k kkk ak ak k K 0 00000000 2 fff000e2 4 00000004 6 0000000 8 00000008 R 1 00000001 R S
97. fOfdef R 9 00000009 0 00000000 2 fff000e2 4 00000004 R 6 0000000 8 00000008 1 00000001 R S ffffffff R 5 00000006 R 7 fcfOfdef R 9 00000009 10 00000010 R11 0000ff31 R10 00000010 R11 0000ff31 R12 0000ff12 R13 00000013 R12 0000f 12 R13 00000013 R14 00000014 R15 00000015 R14 00000014 R15 00000015 R16 00000016 R17 00fe0117 R16 00000016 R17 00fe0117 R18 00fe0118 R19 00fe0119 18 00 0118 R19 00fe0119 R20 00fe0220 R21 00 0321 R20 00 0220 R21 00 0321 R22 00fe0322 R23 00f 0423 R22 00fe0322 R23 00f 0423 R24 00ff0524 R25 00ff0625 R24 00ff0524 R25 00ff0625 R26 O0f 0726 R27 00 0727 R26 00ff0726 R27 00 0727 R28 00 70728 R29 00000029 R28 00 70728 R29 00000029 R30 00000030 R31 00000031 R30 00000030 R31 00000031 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 222222222222 ES 222 Lesen eee n M IFU mem 0x1123000 IFU mem 0x1123000 IFU pc 21 at CSIM 244 ns IFU 21 at CSIM 244 ns EEG DERE IRE IRE EE tain cepe ae ID R1 2 1048350 83 1 ID 1 R2 1048350 R3 1 CSIM 246 ns at CSIM 246 ns aD at SS or a ase nn EE E ALU op 3 A 1048350 B 1 ALU 3 A 1048350 B 1 ALU R 1048351 gt R1 at CSIM 248ns ALU R 1048351 gt R1 at CSIM 248ns ID R1 0xfff000e1 1048351 fr A
98. ffffffff R 5 00000005 R 7 fcfOfdef R 9 00000009 0 00000000 2 fff000e2 4 00000004 6 0000000 8 00000008 R 1 00000001 R S ffffffff 5 00000005 R 7 fcfOfdef R 9 00000009 10 00000010 11 0000 31 10 00000010 R11 0000ff31 R12 0000ff12 R13 00000013 R12 0000ff12 R13 00000013 R14 00000014 R15 00000015 R14 00000014 R15 00000015 R16 00000016 R17 00fe0117 R16 00000016 R17 00fe0117 R18 00fe0118 R19 00fe0119 R18 00fe0118 R19 00fe0119 R20 00 0220 R21 00fe0321 R20 00fe0220 R21 00fe0321 R22 00fe0322 R23 00ff0423 R22 00fe0322 R23 00ff0423 R24 00ff0524 R25 00 0625 R24 00f 0524 R25 00 0625 R26 00f 0726 R27 00 0727 R26 00ff0726 R27 00 0727 R28 00f70728 R29 00000029 R28 00f70728 R29 00000029 R30 00000030 R31 00000031 R30 00000030 R31 00000031 D ae eee eee Sasse E jnre IFU mem 0xf550000 IFU mem 0xf550000 IFU pc 1b at CSIM 187 ns IFU pc 1b at CSIM 187 ns ID R5 R5 5 ID R5 R5 5 Anhang 121 ALU ALU IFU IFU at CSIM 189 ns 3 A 5 B 0 R 5 gt R5 at CSIM 191 ns IFU mem 0x0 pc 1c at CSIM 194 ns 0 00000000 2 fff000e2 4 00000004 6 0000000 8 00000008 R10 00000010 R12 0000ff12 R14 00000014 R16 00000016 R18 00fe0118 R20 00fe0220 R22 00 0322 R24 00ff0524 R26 00ff
99. g enth lt die daf r ben tigte Zeit Im Unterverzeichnis SYSTEMC liegt das SystemC Design aus dem die Si mulation erstellt wurde Es enth lt die Projektdateien die Quellcodes und die kompilierten Daten Das Projekt wurde mit der C C Entwicklungs umgebung Microsoft Visual C 6 bearbeitet Zur erneuten bersetzung m ssen die Einstellungen f r die Pfade auf die aktuellen Gegebenheiten an gepasst werden Die VHDL Quellcodes die als Eingabe f r den Simulationsinterfaceblock Generator dienten befinden sich im Unterverzeichnis VHDL Die Dateien counter_8bit vhd und shift_l16 vhd beschreiben einen 8Bit Z hler 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 r die Zeitmessung aus Abschnitt 5 4 2 Verwendung fand Bei ihr wurden die Ausgaben des Moduls exec cpp entfernt Ihre Da teinamen besitzen den Zusatz _timed Dazu geh ren die folgenden Dateien risc_cpu_timed exe ausf hrbare 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 gt ber die vollst ndigen Ausgaben Folgende Datei en z hlen zu dieser Version 132 Anhang D risc cpu exe ausf hrbare Datei zum Starten der Simulation risc cpu log Logf
100. gefiihrt werden Durchlauf Dies folgt aus der Ubertragungszeit die fiir ein Byte notwendig ist Nach Abschnitt 5 4 1 betr gt die theoretisch k rzeste Zeit zur Ubert ragung eines Bytes ber die parallele Schnittstelle 500 ns Der Simulations interfaceblock ist mit 50 Mhz getaktet und besitzt demnach eine Taktperiode von 20ns 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 500ns Der Automat hat mindestens 500 20 25 Taktperioden Zeit um den Zustandswechsel auszuf hren Be trachtete man den Aufbau des Automaten in Abbildung 3 23 auf Seite 58 ben tigt er einen Takt f r den Zustandswechsel Hinzu kommen jeweils ein Takt f r die Wert bernahme durch die Kontrollregister und Statusregister Dies zeigt dass die Schleife unter normalen Bedingungen nur einmal Durch laufen wird Zur Betrachtung der zweiten Schleife muss die Ausf hrungszeit eines IP Emulationstaktes mit herangezogen werden Die Frequenz der IP Emulation berechnet sich nach Formel A 14 in Anhang A Sie lautet pu LDIV 2 fip 5 DEMONSTRATOR 99 Die berechneten Werte des Simulationsinterfaceblock Generators fiir HDIV und LDIV eingesetzt ergibt sich die Frequenz der IP Emulation von 50 Mhz Sr 2 EE UOS u i fip Damit betr gt die Zeit f r eine Taktperiode 280 ns Die Emulation startet sofort nach dem erfolgreic
101. gend nach ihrer Breite Im Anschluss sortiert sort portlist direction sie nach ihrer Richtung Die Sortierung dient zur Vorbereitung f r das Signalmapping Das Signalmapping bildet die Ports mit Hilfe der Funktion map entity signals auf interne Signale des Simulationsinterfaceblocks ab Au erdem wird ge pr ft ob die Abbildung zul ssig ist dass hei t dass nicht mehr Signale durch den Simulationsinterfaceblock transportiert werden m ssen als die HW SW Schnittstelle zul sst F r solch einen Fall bricht das Programm mit einer Fehlermeldung ab War das Mapping erfolgreich startet die Generierungsphase der Quelltex te Die Generierung erfolgt aus Templates was schematisch Abbildung 4 3 darstellt Diese Templates enthalten bereits gro e St cken an Quellcode da viele Teile f r den Simulationsinterfaceblock immer gleich sind Codest cke die speziell angepasst werden m ssen ersetzt im Template eine Marke Diese Marken werden wahrend der Generierung durch einen aus den vorhandenen Daten berechneten Wert oder ein anhand dieser Daten generiertes Codest ck ersetzt Anschlie end erfolgt die Speicherung des fertigen Quelltextes im Ziel verzeichnis Die Generierungsphase besteht aus drei Teilabschnitten Der erste Schritt startet durch Aufruf der Funktion generate H Wpart Er erzeugt alle notwen digen VHDL Quelldateien des Simulationsinterfaceblocks Au erdem instan ziiert er den Simulationsinterfaceblock und die VHDL IP unter einem Top
102. gr ere Simulationszeit zu erkl ren ist Einen Unterschied zwischen der originalen und der modifizierten RISC CPU stellt die Kommunikation ber die HW SW Schnittstelle dar Zun chst soll das Kommunikationsaufkommen und die daf r ben tigte Zeit untersucht wer den Tabelle 5 5 enth lt die Befehle die in einem Simulationsschritt abgear beitet werden Befehle die in Schleifen ausgef hrt werden sind mit Sternen gekennzeichnet Die Anzahl der Schleifendurchl ufe soll zun chst 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 ein mal durchlaufen Im Normalfall endet die Schleife sofort nach dem ersten 98 5 DEMONSTRATOR Funktion Kategorie Anzahl Bytes write read write read GetStatusl read 1 3 SetWriteMode write 2 0 SetLDIVCounter write 2 0 SetHDIVCounter write 2 0 SetCycleCounter write A 0 WriteSimData write 20 0 SetWaitMode write 2 0 SetStartSim write 2 0 GetStatus1 read 1 3 GetStatus1 read 1 3 SetCycleEnd write 2 0 SetReadMode write 2 0 ReadSimData read 6 18 Set Wait Mode 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 aus
103. gsvorschrift die die Sequenzhandlermodi implementieren Die Transformation ist nicht nur auf strukturelle Anderungen der Daten beschr nkt sondern erm glicht auch eine semantische Anderung Weitere Informationen zur Grundidee des Interfaceblocks zur Beschreibungs form eines Interfaceblocks durch das Interface Synthese IFS Format zur technischen Umsetzung und zum Stand der aktuellen Entwicklungen sind in Ihm01 HVIO1 IVHO2a VH02b IBJK 03 IVHO3 Fic03 Fla03 und IH04 enthalten 38 3 DIE METHODE DER ADAPTIERUNG 3 2 2 Analyse der Leistung des Interfaceblocks Um den Interfaceblock als HW SW Schnittstelle einsetzen zu k nnen ist zun chst der Nachweis erforderlich dass der Interfaceblock auch die gestell ten Anforderungen vgl Abschnitt 3 1 1 theoretisch erf llen kann Die erste Anforderung bestand darin zwei Komponenten kommunizieren zu lassen ohne den Komponenten Anderungen durchzuf hren Der Inter faceblock erf llt die Funktion eines Adapters Ein Adapter ist nach Wika ein Ger t dass zur Verbindung verschiedener mechanischer oder elektrischer Ger te dient deren Anschl sse wegen unterschiedlicher Formate oder Nor men nicht zueinander passen In dem vorliegenden Fall sind die zu verbinden den Gerate die SystemC Simulation und die IP Emulation Die Anschl sse stellen die Schnittstellen dar die in Software bzw in Hardware vorliegen Dadurch ist eine direkte Verbindung nicht m glich
104. hen Setzen des Startsignals durch SetStartSim An schlie end wird die Funktion GetStatus1 ausgef hrt die das Starten ber pr ft Sie ben tigt einen Schreibvorgang und drei Lesevorg nge Drei Le sevorg nge wurden aus Gr nden der Fehlerkorrektur eingef hrt da bei der Schnittstelle vereinzelt Lesefehler auftraten Die drei empfangenen Bytes wer den miteinander verglichen und das Byte zur chgegeben welches am haufigs ten auftritt Die Funktion besitzt damit eine Ausf hrungszeit von mindestens 4 500ns 2000 ns Das bedeutet dass die zweite Schleife startet wenn die IP Emulation schon abgeschlossen ist Damit ben tigt auch sie nur einen Durchlauf Nach der Untersuchung der Schleifendurchl ufe soll wieder auf die Kom munikationszeit eingegangen werden Schreibvorg nge im Simulationsinter faceblock sind definiert als Schreiben eines Adressbytes und Schreiben eines Datenbytes In jedem Simulationschritt m ssen damit mindestens 36 Bytes bertragen werden Ein Lesevorgang umfasst das Schreiben eines Adressby tes und Lesen von drei Datenbytes aus Gr nden der Fehlerkorrektur Die Lesevorg nge besitzen somit ein Kommunikationsaufkommen von 40 Bytes je Simulationsschritt Die vorliegende Simulation besteht nach den Simula tionsausgaben in der Datei risc cpu log siehe Anhang D aus 278 Schritten inklusive der Initialisierung Als bertragungsgeschwindigkeit werden die ge messenen Werte aus Tabelle 5 3 herangezogen F r die Komm
105. ie verschiedene Ans tze verfolgen Ein Ansatz besteht in einer reinen Simulationssoftware wie Modelsim und SystemC Ans tze zur Cosimulation verfolgen das Ziel verschiedene Simula toren miteinander zu koppeln um die Simulation von Hardware und Software parallel ausf hren zu k nnen Hardware Akzeleratoren sollen durch Spezial hardware die Simulation grofer Designs beschleunigen Doch sie bieten auch 2 STAND DER TECHNIK 2 die M glichkeit der Kopplung mit Softwaresimulationsl sungen Die vorge stellten Hardware Akzeleratoren erlauben teilweise die Nutzung von Sys temC Die Unterst tzung beginnt jedoch erst auf Register Transfer Ebene In h heren Abstraktionsebenen fehlt diese Unterst tzung noch 28 2 STAND DER TECHNIK 3 DIE METHODE DER ADAPTIERUNG 29 3 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 Interfaces und die Analyse seiner Anforderungen Eine Realisierung des HW SW Interfaces durch einen Interfaceblock wird im zwei ten Abschnitt vorgestellt Anschlie end werden Details zur technischen Um setzung dargestellt Die Einsatzm glichkeiten 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 Simula tion von VHDL IPs in SystemC auf eine
106. igt die Einstellungen im Programm Die Generierung des Simulations interfaceblocks f r die VHDL IP der Integer Executionunit stellt den letzen Schritt der Programmausf hrung dar Der Hardwareteil des Simulationsinterfaceblocks und die Implementierung der VHDL IP befinden sich nun auf dem FPGA Board Sie sind bereit f r die Ausf hrung Um die Simulation der originalen und der modifizierten RISC CPU besser vergleichen zu k nnen wird im Softwareteil des Simulations interfaceblocks Quellcode zur Ausgabe der Simulationsdaten auf dem Bild 92 5 DEMONSTRATOR Potname Ri Datentyp opcode 4 in signed add 1 in signed dina 32 in signed dinb 32 in signed dest 5 in unsigned dout 22 out signed destout 5 out unsigned Abbildung 5 4 Festlegung der Datentypen im Simulationsinterfaceblock Ge nerator schirm manuell hinzugef gt Dies erfolgt in der generierten Datei exec cpp Als Quelle dient hier die Datei exec cpp der originalen RISC CPU Die an deren generierten Dateien bleiben unver ndert Aus dem Design der originalen RISC CPU wird die Integer Executionunit entfernt und durch das generierte Modul ersetzt Zur Ubersetzung des Ge samtdesigns muss noch die Datei dlportio lib zu den verwendeten Bibliothe ken hinzugef gt werden Au erdem ist als zus tzlicher Includepfad das Ver zeichnis mit den generierten Quelldateien einzutragen Nach der Durchf hrung dieser Schritte erfolgt das bersetzen und Li
107. ile 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 Einga bedaten f r 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 vor handen ist Der einzige Zusatz ist die Projektdatei f r Microsoft Visual C 6 und die Kompilation der Quelldateien Zur erneuten bersetzung m ssen die Einstellungen f r die Pfade auf die aktuellen Gegebenheiten angepasst werden Testdesigns Risc cpu simifb INTEXECUNIT enth lt das Xilinx ISE5 Projekt in dem die VHDL Be schreibung der Integer Executionunit erstellt wurde Zum Projekt geh ren Quelltexte Testbenches und Implementierungsdaten Das Unterverzeichnis SIFBGEN OUTPUT enthalt die Ausgaben des Simula tionsinterfaceblock Generators Als Eingaben dienten die VHDL Quelldateien aus dem Verzeichnis INTEXECUNIT Im Unterverzeichnis SIMULATION befinden sich die Dateien zur Simula tion des modifizierten RISC CPU Design mit Simulationsinterfaceblock Es existieren zwei Versionen der Simulation Zum Einen die Version die f r die Zeitmessung aus Abschnitt 5 4 2 Verwendung fand Bei ihr wurden die Aus gaben des generierten Moduls exec cpp entfernt Ihre Dateinamen besitzen den Zusatz _timed Dazu geh ren die folgenden Dateien risc cpu timed exe
108. iles erfolgen Dazu bie tet die Bibliothek spezielle Funktionen die es auch erlauben die Tracefiles in verschiedenen Formaten zu generieren Formate die unterst tzt werden sind das Integrated Signal Data Base ISDB Format Waveform Intermedia te Format WIF und das Value Change Dump VCD Format Eine andere M glichkeit 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 ModelSim ist eine HDL Simulationssoftware die von der Firma Model Technology Mod entwickelt wurde Model Technology ist eine betriebseige ne Tochtergesellschaft von Mentor Graphics Mena ModelSim unterst tzt die Simulation von VHDL Verilog und SystemC Dabei k nnen Simulati onsmodelle von der Verhaltenssimulation ber Netzlistenmodelle bis hin zur platzierten und trassierten Schaltung mit einem genauen Zeitmodell simuliert werden Den Simulator gibt es f r alle g ngigen Betriebssysteme Model Sim Abbildung 2 7 Logo von ModelSim Quelle Mod Zum Simulator geh rt ein Projektmanager zur Kontrolle der Simulation Zus tzlich bietet er eine integrierte Debugumgebung die es erlaubt auf al le Signale des Designs zuzugreifen Der Verlauf der einzelnen Signale wird mit einem Waveformbetrachter v
109. in einem erweiterten In terfaceblock der die Hardware Software Grenze berwinden kann Um den erweiterten Interfaceblock f r die Co Simulation einsetzen zu k nnen wur den Untersuchungen zur praktischen Umsetzung durchgef hrt Das Ergebnis bestand im Simulationsinterfaceblock der eine M glichkeit der praktischen Realisierung des erweiterten Interfaceblocks darstellt Zum Abschluss des Kapitels wurden noch die verschiedenen Einsatzm glichkeiten des Simulati onsinterfaceblocks vorgestellt Das vierte Kapitel besch ftigte sich mit einer L sung 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 Grundla ge f r Weiterentwicklungen des Programms zu bieten F r die Anwendung des Programms zur Generierung von Simulationsinterfacebl cken wurde ein Handbuch verfasst um Benutzer einen schnellen Einstieg zu gew hren Ab schlieBend erfolgte die Vorstellung von M glichkeiten der Weiterentwicklung zur Unterst tzung eines breiteren Spektrums von Implementierungsplattfor men und Intellectual Properties Der Demonstrator ber den das f nfte Kapitel handelt diente dem Erproben und Validieren der Konzepte aus Kapitel drei und des Programm aus Ka pitel vier Es wurde der Aufbau und die Funktionsweise des Demonstrators vorgestellt Anschlie end wurde der Nachweis d
110. ind im Folgenden aufgef hrt Dabei ist als erstes die Re gisterkarte aufgef hrt unter dem sich die Einstellung findet Es schlieft sich der Unterpunkt und die jeweilige Parameter an Der Wert der f r den Para meter einzutragen ist steht darunter mit einer Bemerkung in Klammern C C gt C Language gt Enable Run Time Type Information aktiv Haken eingetragen C C gt Preprocessor gt Additional include directories MSystemc 2 0 1Nsrc Pfad zu systemc h Link General gt Object library modules systemc lib hinzuf gen zu vorhandenen Bibliotheken Link gt Input gt Additional library path Systemc 2 0 1 msvc60 systemc Debug Pfad zur Datei systemc lib Weitere Hinweise zur Arbeit mit SystemC enth lt das Handbuch Opeb 110 Anhang Anhang 111 Gegen berstellung der Simu lationsdaten Die Simulationsergebnisse der originalen und modifizierten RISC CPU wer den hier auszugsweise gegeniibergestellt Bei den Ausgaben der originalen RISC CPU wurden die Ausgaben die keine Simulationsdaten enthielten ent fernt um eine bessere bersicht zu gew hrleisten Zur direkten Gegen ber stellung sind die Simulationsausgaben der modifizierten RISC CPU eben falls gek rzt aufgef hrt Die vollstandigen Ausgabedaten finden sich auf der dieser Arbeit beiliegenden CD ROM Unter den Verzeichnisssen Testdesi gns Risc_cpu_original Simulation sowie Testdesigns Risc cpu simifb Sim
111. insatz 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 bertragungsgeschwindigkeit die f r die parallelen Schnittstelle mit dem EPP Protokoll angegeben ist betr gt nach 04 zwischen 500 kByte s und 2 Dies ergibt eine Zeit von 2000 ns bis 500ns f r die bertragung eines Bytes In dieser Messung lag der Wert f r reine Schreiboperationen bei durchschnittlich 618 404 Byte s 1617 ns Byte Bei gemischten Schreib Lese Operationen erreichte die Schnittstelle eine bertragungsgeschwindigkeit von durchschnittlich 641881 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 hren m ssen die gleichen Aus gangsbedingungen f r beide Simulationen geschaffen werden Sie werden auf dem gleichen PC Pentium4 mit 2 4 Ghz 512 MB RAM Betriebssystem Win dows XP Professional ausgef hrt F r beide Simulationen kommt der glei che Testbench zum Einsatz Au erdem wird in den Modulen exec cpp der Code zur Bildschirmausgabe auskommentiert Das generierte Modul der mo difizierten RISC CPU wird in jedem Simulationsschritt einmal vollst ndig abgearbeitet Die Ausf hrung des Originalmodul hingegen findet Abschnitts weise mit Hilfe von wait Anweisu
112. ion senden lokale Variablen an Emulation senden Reset der Emulation ausfiihren y e Emulation getaktet ausf hren um Lesemodus setzen Emulationsergebnisse in lokale Variablen lesen y Emulationsergebnisse in lokale Variablen lesen Mapping der lokalen Variablen auf die Ausg nge 4 A Abbildung 3 18 Ablaufplan zur Umsetzung des PHaw se des Parallelports einem Zeiger auf ein Feld dass die Simulationsdaten enth lt bzw aufnimmt und einem Wert f r die Gr e des Feldes in Byte Den Ablauf eines Funktionszyklus des PHgw stellt Abbildung 3 18 dar Am Anfang erfolgt das bertragen der Eing nge auf lokale Variablen Sie die nen als Zwischenspeicher um die Daten auf die Breite der Eing nge der IP zu konvertieren Anschlie end wird gepr ft ob das asynchrone Resetsignal aktiv ist Es besitzt Vorrang vor dem Taktsignal da auch bei Registern das asynchrone Resetsignal die h here Priorit t hat Ist das Signal aktiv dann setzt die CUsw Funktion Set WriteMode die in den Schreibmodus Nun beginnt das Setzen der Z hler und das bertragen der Simulationsdaten Die Ausf hrung des asynchronen Reset f r die IP Emulation schlie t sich an Nachdem dieser Schritt beendet ist setzt die Funktion SetReadMode die CUyw in den Lesemodus Das Auslesen der Emulationsergebnisse erfolgt in lokale Variablen die zum Schluss auf die Ausg nge bertragen werden 3 DIE ME
113. ionen zum Abruf der Statusregister e Hilfsfunktionen Die Funktionen zum Schreiben in die Kontrollregister erm glichen es Funk tionen im Hardwareteil des Interfaceblocks auszul sen Der Automat kann in verschiedene Zust nde versetzt werden die Emulation gestartet oder der Interfaceblock zur ckgesetzt werden Auferdem erlauben die Funktionen das Setzen der Z hler HDIV LDIV und das Taktzyklenz hlers 3 DIE METHODE DER ADAPTIERUNG 59 Zustand Signal phin start phin stop sh start sh stop phout start phout stop load_counter_zyklen inclkO_counter_zyklen inclk1l 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 setsimclock activate reset loc ololol olol olol DID cl DP DID co SP SO olol SO olol CO ra Start_PHin ololololololo olol co DID co SP oO olol SO SO o o Start_SH oO co Start PHout ololol olol olol ol ao ol o Waiting oc co A BH DWrite DRead ol Of Of o o 2 2 2 gt DPrepare o l o l o of ol o ol o o ol ol of ol o o Clk gen1 o o o o o ol o o o o o
114. ird die physische HW SW Schnittstelle als Schnittstelle von PHsw und SH genutzt Abbildung 3 11 Da der Sequenzhandler in Hardwa re liegt wird er weiterhin als SHyw bezeichnet In Abschnitt 3 1 1 wurde be reits festgestellt dass wahrscheinlich eine Transformation der Daten die 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 For mat umzuwandeln Zur Kontrolle der Abl ufe innerhalb des IFB kommt die Controlunit zum Einsatz Sie hat die Aufgabe die Handler zu steuern und zu berwachen Bei der Verwendung des IFBs als HW SW Schnittstelle muss der PHyw out 42 3 DIE METHODE DER ADAPTIERUNG Abbildung 3 12 Controlunit zur Steuerung von Hardware und Software CU Kommunikation control Abbildung 3 13 Teilung der Controlunit in Hardware und Softwareteil der SHyw 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 CUnw wie Abbildung 3 13 zeigt Der Vorteil liegt nun dar in dass die jeweilige Controlunit ihren Teil direkt k
115. isualisiert und kann dadurch genau verfolgt werden Ein Wizard und Templates erlauben dem Benutzer Testbenches schnell zu erstellen ModelSim benutzt als Simulationssprache eine Tcl ba sierte Skriptsprache Dadurch k nnen an den Simulator leicht andere Pro gramme angebunden werden Die Simulation erfolgt auf die folgende Weise Die Hardwarebeschreibung wird zun chst plattformunabh ngig bersetzt Anschlie end erzeugt der Com piler daraus einen maschinenspezifischen Code f r die ausf hrende Maschine der zur Laufzeit optimiert wird Die Ausf hrung des Codes erzeugt die Si mulationsdaten des Modells ModelSim zeichnet die Ausgaben des Codes auf und stellt sie zur Auswertung dem Nutzer zur Verf gung Von ModelSim existieren verschiedene Versionen Die meisten Features stellt die LE Version zur Verf gung Mehr Informationen zum Simulator bietet die Homepage von Model Technology Mod und das Handbuch zu ModelSim Mod03 2 STAND DER TECHNIK 17 2 3 3 HW SW Cosimulation Hardware Software Codesign ist ein Schl sselkonzept um die Entwicklung moderner Hardware Software Systeme zu vereinfachen und zu beschleuni gen Anstatt Hardware und Software getrennt zu entwickeln und beide Berei che im Anschluss m hevoll zusammenzuf gen erlaubt Hardware Software Codesign die Entwicklung beider Bereiche zu parallelisieren Die Cosimula tion von Hardware und Software liefert dabei ein wichtiges Hilfsmittel um das Design zu testen und zu ve
116. ittstelle dargestellt werden Die folgenden Anforderungen ergab die durch gef hrte 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 hrt werden m ssen 2 den bidirektionalen Datentransport zwischen den Komponenten sicher stellen 3 die HW SW Grenze intern berwinden 4 die Moglichkeit bieten Daten intern zu transformieren 5 die Integration einer Steuerung erlauben 3 2 Der Interfaceblock als HW SW Interface Zur Realisierung der HW SW Schnittstelle ben tigt man ein Schnittstellen konstrukt dass die im vorangegangen Abschnitt herausgestellten Anforde rungen im Wesentlichen erf llt Falls das Konstrukt nicht allen Anforderun gen gen gt sollte es so flexibel und erweiterbar sein dass es sich auf die neuen Bedingungen leicht anpassen l sst Ein Schnittstellenkonstrukt dass einen Gro teil der gestellten Anforderungen erf llen kann ist der Interface block der im folgenden Abschnitt kurz vorgestellt wird 3 2 1 Das Modell des Interfaceblocks Ein Interfaceblock IFB dient als Schnittstelle zwischen inkompatiblen Kom munikationskomponenten Diese Kommunikationskomponenten k nnen kom plexe 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 nnen D
117. ktur GENERIC LIST wurde eingef hrt um generische Parame ter in der VHDL Entity zu unterst tzen Allerdings existiert bis jetzt nur die Definition der Datenstruktur Tabelle 4 5 f hrt die enthaltenen Varia blen auf Eine doppelt verkettete lineare Liste realisert die Datenstruktur hnlich wie die Liste der Ports vgl Abschnitt 4 2 2 2 Die Nutzung von VHDL Generics ist im Simulationsinterfaceblock Generator noch nicht im plementiert Aus diesem Grund wird an dieser Stelle auf eine ausf hrlichere 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 unterstiitzen Dies geschieht indem mit Hilfe der Datenstruktur die einzelnen syntaktischen Elemente der Entity wortweise ge speichert 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 ren die Funktionen make word insert word und
118. le vel um diese sp ter gemeinsam zu synthetisieren W hrend der Bearbeitung einer Quelldatei wird diese auch in eine Projektdatei eingetragen die alle Dateien zusammenfasst Sie bildet die Informationsgrundlage f r die sp tere Synthese F r die Synthetisierung m ssen 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 gt sie zur Projektdatei hinzu Die Vor aussetzung dass diese Funktion ihren Zweck erf llt besteht darin dass sich die instanziierten Komponenten im gleichen Verzeichnis wie der Quelltext der IP befinden und ihr Dateiname mit dem Namen ihrer Komponentende klaration plus der Dateierweiterung vhd bereinstimmt Nach der Erzeugung der VHDL Quellen steht die Generierung von Skrip ten an Diese Skripte bauen auf externen Programmen auf Sie dienen der Synthese xst der bersetzung ngdbuild dem Mapping map der Plat zierung und Trassierung par der Bitstromgenerierung bitgen der FPGA Konfigurierung impact und der Timinganalyse trce der erzeugten VHDL Quellen Die externen Programme sind in der Xilinx Entwicklungsumgebung ISE Xilb enthalten Da in dieser Arbeit nur Xilinx FPGAs zur Verf gung standen beschr nkt sich der
119. liert werden Diese Anwen dung 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 re chenzeitintensive Teile der Designbeschreibung auf ein FPGA ausgelagert werden Die ben tigte Rechenleistung nimmt ab und eine Beschleunigung der Simulation kann erreicht werden 62 3 DIE METHODE DER ADAPTIERUNG 4 DER SIMULATIONSINTERFACEBLOCK GENERATOR 63 4 Der Simulationsinterfaceblock Generator Dieses Kapitel stellt das Programm Simulationsinterfaceblock Genera tor vor Seine Entwicklung fand im Rahmen dieser Arbeit statt Zun chst werden die Gr nde f r Implementierung des Programms be schrieben Der sich anschlie ende Abschnitt beschreibt die Merkmale und die M glichkeiten des Programms Danach wird die Arbeitsweise vorgestellt Am Ende dieses Kapitels wird auf die Benutzung des Programms eingegan gen und Verbesserungsm glichkeiten aufgezeigt 4 1 Motivation Der Simulationsinterfaceblock verbindet eine IP Emulation mit einer SystemC Simulation Die Parameter des Interfaceblocks h ngen immer von den Ein g ngen und Ausg ngen der emulierten IP ab Aus diesem Grund muss der Simulationsinterfaceblock f r jede IP neu erstellt werden Ein Ziel der Kopplung von Emulation und Simulation durch einen Interfa ceblock liegt darin Zeit bei der Simul
120. ls ist dies nur schwer m glich Eine L sung besteht darin das Taktsignal auf der Softwareseite zu analysie ren Bei der aktiven Taktflanke wird dann zuerst die bertragung der Simu lationsdaten ausgef hrt dann ein Kontrollsignal zur Takterzeugung auf der Hardwareseite generiert Die HW SW Schnittstelle generiert f r die Emula tion nun genau einen Takt und gibt eine R ckmeldung an den Softwareteil nach dessen Beendigung Am Ende werden die Ausgangsdaten der Emulati on zur Simulation bertragen welche weiter fortschreiten kann Abbildung 3 DIE METHODE DER ADAPTIERUNG 35 imulationsdaten an die IP Emul es Taktsignals f r die ja Ausgabewerte der RE 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 sung ben tigt die HW SW Schnittstelle einen Mecha nismus der es erlaubt Eingangssignale zu analysieren und interne Kontroll signale sowie Ausgangssignale zu generieren Es muss also m glich sein in der HW SW Schnittstelle eine Steuerung zu integrieren Die letze Anforderung stellt die Nutzung der IP dar ohne sie zu ver ndern Diese Anforderung wurde durch die vorangegangen Ma nahmen erf llt Eine Anderung der Schnittstelle oder der Funktionalit t der IP fand nicht statt Zusammenfassend sollen hier noch einmal die Anforderungen an die HW SW Schn
121. m Prototyping for SoC Emulation 2000 Brosch re zum System Explorer Atmel Corporation Atmel Corporation http www atmel com Homepage Jan Axelson Parallel Port Complete Lakeview Research Madi son USA 1997 Klaus Dembowski Computerschnittstellen und Bussysteme Markt und Technik Verlag Haar bei M nchen 1993 Digilent Inc http www digilentinc com Homepage Digilent Inc Digilab 2E Reference Manual 14 April 2002 www digilentinc com J rgen Elsing Schnittstellen Handbuch verst ndliche Erl ute rung und Benutzung von Centronics V24 IEC Bus IWT Verlag GmbH Vaterstetten bei M nchen 1994 4 Auflage Oliver Fick Verschl sselung von Parametern komplexer Schnitt stellen f r eingebettete Systeme auf Basis von XML Studienar beit Universit t Paderborn 2003 Marcel Flade FPGA basierte Fail safe Schnittstellen f r einge bettete Systeme Studienarbeit Technische Universit t Chem nitz 2003 136 GL94 Har02 Har03 Har04 101 IBJK 03 IH04 Ihm01 Int lipq TVHO2a IVH02b Manfred Selz Gunther Lehmann Bernhard Wunder Schaltungs design mit VHDL Synthese Simulation und Dokumentation di gitaler Schaltungen Franzis Verlag GmbH Poing 1994 Dr Wolfram Hardt Integration von Verz gerungszeit Invarianz in den Entwurf eingebetteter Systeme Shaker Verlag Aachen 2002 Prof Dr Wolfram Hardt Hardware Software Codesign Vorle s
122. m bilden aber auch hier die Ein und Ausg nge der IP da sonst Simulationsdaten verloren gehen w rden Der Nachteil bei einer Einf hrung zus tzlicher Signale liegt darin dass der Simulationskern ver ndert werden m sste um die Signale zu erzeugen Eine bessere Varian te die den Simulationskern unbeeinflusst l sst besteht darin das HW SW Interface f r den Simulationskern unsichtbar zu halten und nur die Ein und Ausg nge der IP f r die Simulation bereitzustellen Daraus ergibt sich eine weitere Anforderung an die HW SW Schnittstelle Sie muss intern Kontroll signale erzeugen und auswerten k nnen um den Transport der Simulations daten sicherzustellen 34 3 DIE METHODE DER ADAPTIERUNG Ein weiteres Problem welches sich aus dem Datentransport durch die HW SW Schnittstelle ergibt ist die berwindung 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 Rich tungen ausgetauscht werden m ssen Standardschnittstellen besitzen feste Parameter hinsichtlich der Daten die sie in einem Kommunikationszyklus bermitteln k nnen Da unterschiedliche IPs unterschiedliche Schnittstellen breiten besitzen kann keine Aussage getroffen werden ob die gesamten Si mulationsdaten in einem Kommunikationszyklus bertragbar sind Deshalb sollte die HW SW Schnit
123. 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 Tei lung des Adressraumes Die ersten 16 Adressen 00h bis OFh dienen zur Kommunikation der Controlunits Diese haben somit 16 8Bit 128 Bit f r Kontrollsignale zur Verf gung F r den Austausch von Simulationsda ten stehen die Adressen 10h bis FFh zur Verf gung Die ersten Adressen ab 6Hexadezimale Zahlendarstellung 48 3 DIE METHODE DER ADAPTIERUNG 10h stehen den Eing ngen der IP zur Verf gung und sind somit schreibbare Adressen Im Anschluss daran folgen die lesbaren Adressen Die erste les bare Adresse FRA first readable address berechnet sich aus der Formel FRA 10h Eingangsbits der TP 1 Somit ergibt sich f r die maximale Anzahl von Ein und Ausg ngen der IP 256 16 8 1920 3 3 3 Der PHsw Die Aufgaben des Protokollhandlers der Softwareseite lauten wie folgt e Schnittstelle zur SystemC Simulation bereitstellen Schnittstelle zum Parallelport des PCs implementieren e Simulationsdaten senden e Simulationsdaten lese
124. mmunikation von IP User und IP Serviceprovidern Simulation eines Modells mit SystemC Logo von ModelSim nea od See eh ee ES HW SW Cosimulation mit dem Bus Modell HW SW Cosimulation mit einem 155 HW SW Cosimulation mit dem Hardware Model HW SW Cosimulation mit dem compilierten Modell HW SW Cosimulation mit Hardwareemulation Hammer 100 System von Tharas VStation Pro System von Mentor Graphics Aptix System Explorer eco ichs Adaptierung durch Konvertierung Adaptierung eines Simulators Schematischer Aufbau eines SRAM basierten FPGA Allgemeines Hardware Software Interface Genaueres Modell des Hardware Software Interface Ablauf der Synchronisation durch das HW SW Interface Makrostruktur des Interfaceblock 12 3 8 3 9 3 10 3 11 3 12 3 13 3 14 3 15 3 16 3 17 3 18 3 19 3 20 3 21 3 22 3 23 4 1 4 2 4 3 4 4 4 5 4 6 4 7 4 8 4 9 4 10 Verbindung von SW und HW Task durch einen IFB 39 HW Interface des IFB u 2a a Wan 40 SW Interface des IE B u 0 Desk 41 Physisches HW SW InterfaceimIFB 41 Controlunit zur Steuerung von Hardware und Software 42 Teilung der Controlunit Wer A le ae a EE 42 Controlunit in Software und Hardwareteil geteilt
125. mschaltzeiten zwischen den Prozes sen zur Simulationszeit hinzu Damit erkl ren sich auch die Schwankungen bei den Messergebnissen der Simulationszeit Die Betrachtungen zeigen dass die Simulationsgeschwindigkeit bei der Nut zung eines Simulationsinterfaceblocks stark von der Anzahl der ausgetausch ten Daten zwischen SystemC Simulation und IP Emulation abh ngt Die HW SW Schnittstelle kann hier die Simulation ausbremsen Das FPGA ist im vorliegenden Beispiel leistungsf hig genug um nicht geschwindigkeitsmin dernd zu wirken Zur Erh hung der Simulationsgeschwindigkeit ist der Ein satz einer physischen HW SW Schnittstelle denkbar die eine h here ber tragungsgeschwindigkeit als die parallele Schnittstelle erlaubt In diesem Zu sammenhang sollte dann auch die Leistungsf higkeit der FPGA neu unter sucht werden und gegebenenfalls ein schnelleres Modell eingesetzt werden um ein Gleichgewicht zwischen Schnittstellengeschwindigkeit und FPGA Leistung zu erreichen 5 5 Schlussfolgerungen Am vorgestellten Demonstrator wurde nachgewiesen dass das Modell des Si mulationsinterfaceblocks leistungsf hig genug ist um die ihm gestellten Auf gaben korrekt zu erf llen Der Simulationsinterfaceblock wurde erfolgreich eingesetzt um eine SystemC Simulation mit einer IP Emulation ber eine HW SW Schnittstelle zu verbinden ohne dabei Anderungen an den Kompo nenten vorzunehmen In diesem Zusammenhang erfolgte au erdem der Nachweis dass der
126. n Rechts neben der Einstellung der Vektorsemantik befindet sich als erstes die Angabe der Taktzyklenanzahl die die IP Emulation in einem SystemC Simu lationstakt durchl uft Voreingestellt ist der Wert 1 Der maximal m gliche Wert betr gt 65536 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 Schnitt stelle m glich Zul ssige Werte sind die Standardadressen 278h 378h und 3BCh der Schnittstelle Diese Adresse muss f r den PC eingestellt werden auf dem die SystemC Simulation ablaufen wird Es besteht jedoch die M glich keit diesen Parameter nach der Generierung von Hand zu ndern Die Er kl rung 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 ter selbst durchf hren m chte Um die sp tere 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 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 st die Erstellung des Simulationsinterfaceblocks
127. n trolunit und Protokollhandlern bzw Sequenzhandler statt Au erdem kom munizieren die Protokollhandler mit dem Sequenzhandler um den Daten transport durch den IFB zu realisieren Kommunikation also der Austausch 3 DIE METHODE DER ADAPTIERUNG 39 von Daten l uft nach einem Protokoll ab damit der Sender und Empf nger sich gegenseitig verstehen Da das Modell des IFBs das interne Kommuni kationsprotokoll nicht festlegt ist die Verwendung eines Protokolls m glich das den Transport der transformierten Daten erm glicht Zur berwindung der HW SW Grenze innerhalb des IFB soll die freie Aus wahl eines Protokolls dienen Ein Protokoll wird ber eine Schnittstelle ber tragen Die Benutzung einer Schnittstelle die Hardware und Software phy sisch verbindet bringt die L sung dieses Problems Der IFB ist aber bisher nur f r reine Hardwareanwendungen konzipiert Aus diesem Grund muss ge pr ft werden ob sich das Modell dahingehend erweitern l sst dass es die Einbindung einer physischen HW SW Schnittstelle gestattet 3 2 9 Erweiterung des Interfaceblocks Zur Feststellung der Erweiterbarkeit des IFBs wird der IFB schrittweise zwi schen der SystemC Simulation und der IP Emulation aufgebaut Die Aus gangssituation stellt die Verbindung eines Softwaretasks SystemC Simula tion mit einem Hardwaretask IP Emulation dar Die Verbindung soll mit Hilfe eines Interfaceblocks erfolgen Abbildung 3 8 veranschaulicht die Aus gangssit
128. n e Kommunikation der CUsw und CUpw erlauben Eine Anforderung an den Simulationsinterfaceblock besteht nach Abschnitt 3 1 1 darin der SystemC Simulation eine SW Schnittstelle bereitzustellen Sc Out gt Write EPP Read EPP Init EPP lokale Variablen Parallele Schnittstelle Dlportio h lib Abbildung 3 17 Detailierter Aufbau des PHsw 3 DIE METHODE DER ADAPTIERUNG 49 Funktion Parameter Aufgabe Init EPP BADDR Initialisierung der Schnittstelle Write EPP BADDR Schreiben des Datenbyte Adresse auf die angegebene Datenbyte Adresse Read EPP BADDR Lesen des Datenbytes Adresse von der angegebenen Datenbyte Adresse Tabelle 3 2 Grundfunktionen zum Zugriff auf die parallele PC Schnittstelle BADDR Basisadresse des Parallelports ber den die Kommunikation stattfinden soll Eingangsparameter R ckgabeparameter bei der der Simulationskern nicht ver ndert werden muss Aus diesem Grund wird der PHsw als SystemC Modul implementiert Als Schnittstelle kommen die SystemC Ports sc_in lt gt und sc_out lt gt zum Einsatz Die Eing nge und Ausg nge der IP bestimmen die Breite und Anzahl der Ports Lokale Varia blen nehmen die Werte der Ports f r die weitere Verarbeitung auf Abbildung 3 17 Der Zugriff auf den Parallelport des PCs wird ber die Bibliothek dlpor tio lib hergestellt Diese Bibliothek wurde nicht in dieser A
129. n Adresse entsprechen auf die Datenleitung zum PHyw in 3 3 6 Der DH Die Aufgabe des Protokollhandlers der Hardwareseite der die Schnittstelle zur IP Emulation bildet besteht darin einen Speicher f r die Simulations daten bereitzustellen Zu speichern sind sowohl die anzulegenden Daten als 54 3 DIE METHODE DER ADAPTIERUNG Handler control FSM status Enable Daten IP Emulation Daten HW FF Register to IP FF Register from IP Abbildung 3 21 Detailierter Aufbau des SHyw out auch die Emulationsergebnisse Zus tzlich muss der noch einen Me chanismus enthalten mit dem eine kontrolliert Ausl sung des Taktsignals f r die Emulation m glich ist F r jedes Eingangs sowie Ausgangssignal der emulierten IP wird ein ei genst ndiger Speicher ben tigt Deshalb kommen Flipflops als Speicher zum Einsatz Da die IP n Eing nge und n Ausg nge besitzt muss der Modus des PHiw out n no Flipflops zur Speicherung der Simulationsdaten bereit stellen Um eine Steuerung der Datenspeicherung zu erlauben werden die Flipflops mit Enable Signalen gesteuert Die Flipflops mit den Eingangsdaten der IP werden durch den SHyw gesteuert Die Flipflops die die Ausgangswerte der IP bernehmen durch ein Kontrollsignal von der CU ue da diese die genaue G ltigkeit der Daten kennt Unter den n Flipflops f r die Eingangssignale der IP befindet sich auch ein
130. n FPGA Herstellern Alt Atm Lat Xilc Um jedoch die FPGA nutzen zu k nnen ist die Synthesef higkeit der IP 32 3 DIE METHODE DER ADAPTIERUNG HW SW Interface IP Emulation SystemC Simulation auf FPGA HW auf PC SW Gesamtsimulation SystemC Simulation IP Emulation auf PC SW auf FPGA HW Abbildung 3 5 Genaueres Modell des Hardware Software Interface unabdingbar Durch diese Einschr nkung entf llt die Verwendung von Hard IPs 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 funk tionelle Nachbilden eines Systems durch ein anderes Die Implementierung der IP ist nun kein Modell mehr wie f r eine Simulation sondern ist eine Nachbildung der realen digitalen Schaltung mit Hilfe eines FPGAs Eine Hardware Software Schnittstelle tritt nun an die Stelle der Soft ware 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 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 I
131. n High Port Richtung Cin D Con Port Ausrichtung I Si Component Name 2 Zeichenkette Port Low gt ganze Zahl Port High ganze Zahl 3 Abbildung 4 2 Syntaxdiagramm einer VHDL Entity nach dem der Parser des Simulationsinterfaceblock Generators arbeitet An dieser Stelle ben tigt der Simulationsinterfaceblock Generator noch ein paar Informationen vom Benutzer Er muss das Taktsignal sowie das asyn chrone Resetsignal und deren aktive Signalflanken festlegen Diese Infor mationen dienen sp ter dem Simulationsinterfaceblock zur Ausl sung des Transportes der Simulationsdaten Um die Kompatibilit t mit dem SystemC Design zu gew hrleisten in das der Simulationsinterfaceblock eingebunden werden soll kann der Benutzer festlegen ob Vektoren vorzeichenbehaftet sind oder nicht Der Wert des Zyklenz hlers die Adresse der parallelen Schnitt stelle und ob die FPGA durch den Simulationsinterfaceblock Generator kon figuriert werden soll sind weitere vom Benutzer einzustellende Parameter Nach dem Sammeln aller ben tigten Informationen erfolgt eine Sortierung 4 DER SIMULATIONSINTERFACEBLOCK GENERATOR 73 Analysierte und berechnete Daten ae gt generierung Abbildung 4 3 Erzeugung der Quelldateien des Simulationsinterfaceblocks aus Templates der Portliste Zuerst sortiert die Funktion sort_portlist_width die Ports abstei
132. ngen 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 3135 RISC CPU 0 3445 0 3286 0 328 s modifizierte 0 391s RISC CPU 0 3595 0 3856 0 406 s Tabelle 5 4 Gemessene Simulationszeiten der originalen und der modifizier ten RISC CPU Es wurden je 3 Messungen durchgef hrt und der Mittelwert daraus gebildet tionen auf der Standardausgabe aber viel Zeit beanspruchen k nnen sie die Messergebnisse stark verf lschen Die Zeitmessung f r beide Simulationen erfolgt durch das Programm time drun exe das im Rahmen dieser Arbeit erstellt wurde Es f hrt zwei Skripte aus Als erstes wird das Skript copy simulation bat ausgef hrt welches alle f r die Simulation ben tigten Dateien in das aktuelle Verzeichnis kopiert F r die Ausf hrung des zweiten Skriptes run bat wird die Zeit gestoppt Dieses Skript dient dazu die Simulation aufzurufen und die Ausgaben in eine Da tei umzuleiten Die ben tigte Zeit wird der Datei time taken by run log als letzter Eintrag angef gt Die Ergebnisse der Messung stellt Tabelle 5 4 dar Die Simulation der origina len RISC CPU ben tigte eine durchschnittliche Zeit von 328 Millisekunden Die Simulationszeit der modifizierten RISC CPU liegt mit durchschnittlich 385 Millisekunden etwas dar ber Nun stellt sich die Frage wodurch die um 57 Millisekunden
133. ngsplattformen Anhang 107 A Herleitung der Formel zur Be rechnung der Taktfrequenz der IP Emulation Zur Herleitung der Formel zur Berechnung der Taktfrequenz der IP Emulation sind zun chst eine Variablendefinitionen durchzuf hren Die verwendeten Va riablen definieren sich wie folgt Taktfrequenz des Interfaceblocks Turn Taktperiode des Interfaceblocks fip Taktfrequenz der IP Emulation Taktperiode der IP Emulation trp Zeit des Highpegels der Taktperiode der IP Emulation trp Zeit des Lowpegels der Taktperiode der IP Emulation HDIV Wert des Z hlers HDIV LDIV Wert des Z hlers LDIV ny Anzahl der Durchl ufe durch den Zustand Clk_gen1 nr Anzahl der Durchl ufe durch den Zustand Clk_gen0 Der Interfaceblock ist mit der Taktfrquenz f rg getaktet Die Taktperiode ergibt sich aus der Taktfrequenz nach der Formel 1 pomum A 1 Somit ergibt sich fiir die Taktperiode des Interfaceblocks TirB A 2 Der endliche Automat der generiert den Highpegel als auch den Lowpegel des Taktsignals f r die IP Emulation mindestens einen Takt lang Daraus folgt f r die minimalen Pegelzeiten der Taktperiode der IP Emulation Libo min LIFB UP min LIFB A 3 108 Anhang Die Taktgenerierung erfolgt in den Zust nden Clk_gen1 und Clk gen0 des Automaten der CUgw Die Verweildauer in diesen Zust nden geben die Werte der Zahler HDIV und
134. nken der modifizierten RISC CPU Auch hierbei kommt Microsoft Visual C 6 0 zum Einsatz Die Ausf hrung der Simulationen erzeugt deren Simulationsergebnisse die auf dem Bildschirm ausgegeben werden Die Ergebnisse sind in Anhang C auszugsweise gegen bergestellt Ihre Gegen berstellung zeigt dass die Si mulation 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 bereinstimmt Nachdem sichergestellt ist dass beide Designs ber das gleiche Verhalten verf gen soll der Nachweis erfolgen dass der Simulationsinterfaceblock seine Aufgaben korrekt erf llt Seine Aufgaben lauten nach Abschnitt 3 1 1 wie folgt 1 zwei Komponenten kommunizieren lassen ohne dass an den Kompo nenten Anderungen durchgef hrt werden m ssen 2 den bidirektionalen Datentransport zwischen den Komponenten sicher stellen 5 DEMONSTRATOR 93 3 die HW SW Grenze intern berwinden 4 die M glichkeit bieten Daten intern zu transformieren 5 die Integration einer Steuerung erlauben Am Demonstrator wurde gezeigt dass die Simulationsdaten erfolgreich zwi schen der SystemC Simulation und der IP Emulation in beide Richtungen ausgetauscht werden Das zeigt dass der Datentransport bidirektional ber die HW SW Grenze m glich ist Somit sind die Aufgaben 2 und 3 erf llt Da die Simulationsdaten f r den Transport
135. nn bis zu einem Zehntel der realen Ausf hrungsgeschwindigkeit betragen Bei der Verwendung von mehreren Simulatoren spielt die Schnittstelle zwi schen ihnen eine grofe Rolle Die Schnittstelle stellt in den meisten Fallen den gr ten Engpass dar und ist somit ein wichtiger Faktor f r die resultie rende Simulationsgeschwindigkeit Die Kopplung der Simulatoren kann auf verschiedene Arten erfolgen Die Simulatoren k nnen parallel arbeiten und dabei durch einen Synchro nisationsmechanismus f r 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 Kom munikationsoverhead f r die Schnittstellen Ein anderer Kopplungsansatz besteht in einer Master Slave Simulation Da bei bernimmt ein Simulator die Rolle des Masters und ruft andere Simulato ren auf wenn er Ergebnisse von ihnen ben tigt Bei der Ausf hrung mehrere Simulatoren auf einem Prozessor bringt diese Variante Vorteile Erstens wird jeweils nur ein Simulator ausgef hrt dem die gesamte Prozessorleistung zur Verf gung steht Zus tzlich verringert sich der Kommunikationsoverhead da nur wenige Synchronisationsdaten ausgetauscht werden m ssen Die Hardware Software Cosimulation stellt ein wichtiges Werkzeug dar um die Entwicklung f r zuk nftige Hardware Software Systeme zu beschleuni gen und zu vereinfachen Eine ausf hrlichere Beschreibung d
136. nversion GS VHDL Verilog Results Rest of Process Rest of Process Gegenw rtige Designmethodik SystemC Designmethodik Abbildung 2 2 Gegenw rtige und SystemC Designmethodik Quelle Opeb SystemC ist eine C Klassenbibliothek und nutzt somit die M glichkeit C durch Klassenbibliotheken zu erweitern ohne neue syntaktische Kon strukte hinzuzuf gen Der Entwickler kann somit die ihm vertraute Spra che C 4 und die damit verbundenen Entwicklungswerkzeuge weiterhin ver wenden SystemC wird ber die Open Source Lizenz VA vertrieben Die Bibliothek kann somit kostenlos genutzt werden Der Nutzer enthalt mit der Bibliothek ein kostenloses Entwurfs und Simulationspaket Es enthalt die notwendigen Konstrukte um Systemarchitekturen inklusive Hardwareti ming Nebenl ufigkeit und reaktivem Verhalten zu modellieren die nicht in Standard C enthalten sind Au erdem verf gt die Bibliothek bereits ber einen Simulator mit dem die entworfenen Designs getestet werden k nnen Die Beschreibung des Simulators folgt in Abschnitt 2 3 1 Mit SystemC kann ein Entwickler effektive zyklengenaue Modelle von Softwa realgorithmen Hardwarearchitekturen und Schnittstellen eines System on Chip SoC und System Level Designs beschreiben Au erdem bietet es die M glichkeit eine ausf hrbare Spezifikation zu erstellen Auch Hardware Soft ware Codesign welches in heutigen Systemen eine immer gr fere Bedeutung erlangt wird unterst tzt SystemC unte
137. o soft Visual C4 4 6 Sources Simifb generator Diese Verzeichnis beinhaltet das Projekt f r den Simulationsinterfaceblock Generator Auferdem liegen in diesem Verzeichnis die Quellcodes und die Kompilationsdaten zum Simulationsinterfaceblock Generator Das Projekt wurde mit der C C Entwicklungsumgebung Microsoft Visual C 6 be arbeitet Sources Timedrun In diesem Verzeichnis befindet sich das Projekt zum Erstellen des Programms zur Messung der Simulationszeit Es umfasst die Quellcodes und die kompi lierten Daten Erstellt wurde es mit Hilfe der C C Entwicklungsumgebung Microsoft Visual C 6 0 4 Verzeichnis TESTDESIGNS Das Verzeichnis TESTDESIGNS enthalt Projekte zum Testen der Funktio nalit t des Simulationsinterfaceblocks und des Simulationsinterfaceblock Ge nerators Das Unterverzeichnis RISC_CPU_SIMIFB beinhaltet dabei den De monstrator der in Kapitel 5 vorgestellt wurde Anhang D 131 B Testdesigns Counter_8bit Das Unterverzeichnis SIFBGEN OUTPUT enth lt die Ausgaben des Simula tionsinterfaceblock Generators zum VHDL Design aus dem Unterverzeichnis VHDL In SIMULATION befinden sich die ausf hrbare Datei sw_ifb_counter8bit exe zur Durchf hrung der Simulation und das Logfile sw_ifb_counter8bit log das die Ausgaben der Simulation enth lt Au erdem stehen zur Durchf hrung ei ner Zeitmessung die Dateien timedrun exe copy_simulation bat und run bat zur Verf gung Die Datei time_taken_by_run lo
138. oden sollen die folgenden Abschnitte vorstellen 2 STAND DER TECHNIK 15 2 3 1 Simulation mit SystemC SystemC ist eine C Klassenbibliothek in der auch ein Simulator vorhanden ist Eine ausfiihrliche Beschreibung von SystemC enthalt Abschnitt 2 1 Der Ablauf der Simulation ist in Abbildung 2 6 dargestellt Den Ausgangs punkt stellt das in SystemC beschriebene Modell eines Systems dar Die einzelnen Module des Modells und der Testbench werden von einem C Compiler bersetzt und mit dem Simulationskern aus der Bibliothek zu sammengelinkt Das Ergebnis ist ein ausf hrbares Programm welches die Simulationsergebnisse erzeugt C Compiler Linker SystemC Bibliothek Testbench Ausf hrbares Programm Simulator Simulations ergebnisse Abbildung 2 6 Simulation eines Modells mit SystemC Die SystemC Simulation ist zyklusbasiert Die Aktualisierung von Prozes sen und Signalen erfolgt mit dem bergang des Taktsignals Die Folge ist dass die Genauigkeit der Simulation auf eine Taktperiode beschr nkt ist Die SystemC Bibliothek enth lt zur Simulationssteuerung einen zyklusbasierten Scheduler Er behandelt alle Ereignisse von Signalen und f hrt die Prozesse aus deren Eingangssignale sich ndern Die manuelle Simulationskontrolle ist beschr nkt auf das Starten Stoppen und schrittweises Ausf hren der Si mulation durch SystemC Funktionen Die Ausgabe der Simulationsergebnisse kann in Tracef
139. ontrollieren kann oh ne Steuersignale ber die HW SW Grenze zu schicken und damit gr ere Verz gerungszeiten im Kontrollfluss zu verursachen Ein Problem welches durch die Teilung auftritt ist die Kommunikation zwi schen den Controlunits Zur geregelten Steuerung des IFBs und zur Syn chronisation zwischen Hardware und Softwareteil ist eine Kommunikation 3 DIE METHODE DER ADAPTIERUNG 43 status control physical Abbildung 3 14 Controlunit in Software und Hardwareteil geteilt zwischen CUsw und CUyw notwendig Als Hinderniss ist dabei die HW SW Grenze zu berwinden Dies kann auf zwei Arten erfolgen Zum Einen ber eine zweite physische HW SW Schnittstelle die allein f r den Transport und Austausch von Kontroll und Statussignalen zwischen den Controlu nits zust ndig ist Die L sung bedeutet einen h here 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 glichkeit besteht darin die Kommunikation ber die physi sche HW SW Schnittstelle zu bew ltigen ber die auch die Simulationsda ten ausgetauscht werden Der Vorteil dieser Variante ist die Nutzung der vorhandenen physischen Schnittstelle ohne zus tzlichen Hardwareaufwand Allerdings ben tigt man jetzt ein zus tzliches Protokoll dass ber dem Pro tokoll der HW SW Schnittstelle angesiedelt ist um eine Unterscheidung zwi schen
140. orderlich Dies geschieht einfach durch das Kompilieren und Linken der einzelnen SystemC Module Als bersetzungs und Linkprogramm kommt Microsoft Visual C 6 0 5 DEMONSTRATOR 91 sc_in lt bool gt reset sc_in lt bool gt in_valid sc_in lt int gt opcode sc_in lt bool gt negate sc_in lt int gt addi sc_in lt bool gt shift_sel sc_in lt signed int gt dina sc_in lt signed int gt dinb sc_in lt bool gt forward_A sc_in lt bool gt forward_B sc_in lt unsigned gt dest sc_out lt bool gt GH sc_out lt bool gt V out bool 2 sc_out lt signed int gt dout sc_out lt bool gt out_valid sc_out lt unsigned gt destout SC in clk 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 Entwicklungsum gebung beschreibt Anhang B Die Erstellung der modifizierten RISC CPU lauft nach Abbildung 5 2 ab Zun chst wird das Programm Simulationsinterfaceblock Generator gestar tet Ihm dient als Eingabe die VHDL IP der Integer Executionunit Das Programm analysiert sie Anschlie end erfolgt die Festlegung der Signalpa rameter Das Taktsignal clk und das asynchrone Resetsignal rst sind dabei high aktiv Die Datentypen der Vektoren werden entsprechend den Datenty pen der originalen Ausf hrungseinheit Abbildung 5 3 festgelegt Abbildung 5 4 ze
141. r Nutzung eines Simulationsinterfaceblocks k nnte ein Tool f r das Hardwaredebugging implementiert werden Dies bietet die M glichkeit das Verhalten eines Hardwaredesigns als Implementierung auf einem FPGA zu untersuchen e Ein weiteres Feld f r Untersuchungen liegt in der Emulation von dyna misch rekonfigurierbaren Designs Dabei kann die Kopplung mit einer SystemC Simulation erfolgen um dynamisch rekonfigurierbare Teile ei nes gr eren Designs zu untersuchen oder ein Hardwaredebugging des dynamisch rekonfigurierbaren Designs durchzuf hren Um die Einsatzm glichkeiten des allgemeinen Konzeptes des erweiterten In terfaceblocks zu erweitern k nnten Untersuchungen auf den folgenden Ge bieten behilflich sein e Ein Gebiet von Untersuchung k nnte der Einsatz als Schnittstelle zwi schen Anwendungsprogrammen und Spezialhardware sein Der Einsatz von Spezialhardware beschleunigt dabei bestimmte Funktionen deren Ausf hrung in Software zu langsam ist um eine Steigerung der Pro grammperformance zu erreichen e Weiterhin k nnte das Konzept des erweiterten Interfaceblocks in das bestehende Interface Synthese IFS Format aufgenommen werden und damit auch die M glichkeit einer automatischen Generierung eines er weiterten Interfaceblock als HW SW Schnittstelle entstehen 106 6 ZUSAMMENFASSUNG UND AUSBLICK 6 3 Ausblick f r den Simulationsinter faceblock Generator Die Entwicklung des Simulationsinterfaceblock Generators im
142. r die Hardwareseite des Interfaceblocks auszul sen Somit ist es m glich den In terfaceblock durch ein Signal der Softwareseite r ckzusetzen Der Softwareteil der Controlunit setzt sich aus einem Definitionsteil und ei nem Funktionsteil zusammen Die Definitionen werden in der Datei CUsw h 58 3 DIE METHODE DER ADAPTIERUNG cnext 1 always at creset 1 ResetDUT phin_runs 1 zero_counter_zyklen 1 cstart 1 cdutreset 1 Start_SH sh runs 1 1 Waiting zero counter ldiv 1 zero counter zyklen 1 H Start_PHout cread zero_ counter_ ldiv 0 phout_runs 1 zero_ counter_ zyklen 0 zero_counter_zyklen Zero cstart 1 counter hdiv 1 DWrite cwrite 1 DPrepare Zero counter hdiv 0 Abbildung 3 23 FSM der Controlunit Die Ausgaben der Zust nde sind in Tabelle 3 5 zu finden getroffen Sie dienen zum Festlegen der Adressen der Kontroll und Statusre gister des Hardwareteils sowie der Festlegung von vordefinierten Werten mit denen zum Beispiel die Kontrollregister gesetzt und die Statusregister ausge wertet werden k nnen Diese Definitionen stehen der gesamten Softwareseite des Interfaceblocks zur Verf gung Die Funktionen der CUsw sind in Tabelle 3 6 zusammengefasst Sie teilen sich wie folgt in drei Gruppen e Funktionen zum Schreiben in die Kontrollregister e Funkt
143. r h heren Abstraktionsebene als der RT Ebene erlaubt Bisher ist die Einbindung dieser IPs f r den Entwurf und somit auch f r die Simulation erst auf Netzlistenebene m glich In fr heren Entwurfsstadien ist eine Simulation des Gesamtsystems mit diesen IPs je doch schon sehr hilfreich um Tests mit dem Systemverhalten durchf hren zu k nnen und fr hzeitig Fehler zu entdecken Zur Simulation einer VHDL IP mit SystemC existieren zwei grundsatzli che M glichkeiten Die erste M glichkeit ist die Konvertierung der IP in ein SystemC Modul Abbildung 3 1 Die Konvertierung muss dabei von Hand erfolgen Dieser Schritt verursacht zus tzliche Arbeit Das erstellte SystemC Modul muss gegen die VHDL IP verifiziert werden um sicherzustellen dass ihr Verhalten bereinstimmt Dieser Prozess bindet Ressourcen und kostet meist viel Zeit und Geld Einen Ansatz aus der Cosimulation vorfolgt die zweite Variante Dabei fin det die Simulation der VHDL IP in einem VHDL Simulator und die des SystemC Modells in einem SystemC Simulator statt Die Kopplung der bei den Simulatoren realisiert eine Software Software Schnittstelle Abbildung 3 2 Anforderungen die die SW SW Schnittstelle erf llen muss sind der 5F r Interface wird in den folgenden Abschnitten der deutsche Begriff Schnittstelle verwendet 30 3 DIE METHODE DER ADAPTIERUNG Konvertierung Si Korrektur Ubereinstimmung SystemC Simulation Gesamtsimulation
144. rbeit entwickelt sondern als bereits fertige L sung 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 nnen Auf die Funktionen der Bibliothek bauen die drei Funktionen Init EPP Wri te EPP und Read_EPP auf Ihre Parameter und Aufgaben f hrt Tabelle 3 2 auf Nur 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 ssen Das betrifft die PHsw Modi und die CUsw Der Zugriff ber fest definierte Funktionen bringt den Vorteil dass die Bibliothek dlportio lib auch ausgetauscht werden kann und nur diese Funktio nen angepasst werden m ssen falls eine andere Art des Schnittstellenzugriffs implementiert werden soll Den Transport der Simulationsdaten bernehmen die Modi des PHsw Den Modus zum Schreiben realisiert die Funktion WriteSimData Den f r das Le sen zust ndigen Modus bildet die Funktion ReadSimData Die bergabepa rameter sind bei beiden Funktionen gleich Sie bestehen aus der Basisadres 50 3 DIE METHODE DER ADAPTIERUNG 4 Mapping der Eing nge auf lokale Variablen Resetsignal aktiv Schreibmodus im IFByw setzen Z hler setzen Y x Z hler setzen Taktsignal aktiv m Schreibmodus im IFB setzen lokale Variablen an Emulat
145. rdware Software Schnittstelle kommen unter Nutzung des Digilent 2E nur dessen Schnittstellen in Frage Dass hei t eine Verbindung ist ber den seriellen den parallelen den JTAG Port oder ber den Exten sionheader m glich In Abschnitt 3 1 1 wurde die Verwendung von Standardschnittstellen eines PCs angedacht Ein PC stellt standardm ig nur die serielle und die paral lele Schnittstelle bereit Somit entf llt die Verwendung von JTAG Port und Extensionheader Die Wahl der Schnittstelle h ngt nun von der Leistung der Schnittstelle ab Tabelle 3 1 stellt die serielle und die parallele Schnittstelle einander ge gen ber Das wichtigste Leistungsmerkmal f r die Verbindung der SystemC Simulation und der IP Emulation stellt die bertragunsgeschwindigkeit dar Deshalb findet die parallele Schnittstelle f r die HW SW Schnittstelle Ver wendung Die Kommunikation ber die parallele Schnittstelle findet ber das EPP Protokoll Enhanced Parallel Port statt Das EPP Protokoll ist im IEEE Standard 1284 definiert Die Nutzung des EPP Protokolls bringt einige Ei genschaften mit sich die f r die HW SW Schnittstelle und deren Umsetzung von Bedeutung sind 46 3 DIE METHODE DER ADAPTIERUNG Merkmal serielle Schnittstelle parallele Schnittstel nach RS 232 le nach IEEE 1284 EPP bertragunsart seriell parallel asynchron synchron bertragungs senden Daten senden modi Adressen senden empfangen Daten lesen
146. re Software Simifb generator Timedrun Testdesigns Counter 8bit 18ifbgen output Simulation SystemC Vhd1 Risc cpu original 8imulation 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 lt 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 Un terverzeichnis 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 dieser Stelle sind nur die zur Ausf hrung not wendigen Dateien vorzufinden Die Quelltexte liegen im Verzeichnis SOURCES Programme Epp speedtest Epp speedtest dient zur Messung der Geschwindigkeit der parallelen Schnitt stelle Die Messeinrichtung besteht aus einer Hardwarekomponente im Un terverzeichnis Hardware und einer Softwarekomponente im Unterverzeich
147. re serve 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 Aufgabe make word Erzeugt ein neues Element vom Typ WORD LIST insert word F gt ein Element in eine bestehende Liste ein reserve wordspace Reserviert Speicherplatz f r die Variable word Tabelle 4 7 berblick zu den Funktionen zur Datenstruktur WORD LIST 70 4 DER SIMULATIONSINTERFACEBLOCK GENERATOR RILELIST Datentyp Variablenname filename int processed struct filelist next Tabelle 4 8 Aufbau der Datenstruktur FILELIST Funktion Aufgabe filelist new Erzeugt ein neues Element vom Typ FILELIST filelist_addfile Fiigt einen Dateinamen in die Liste ein falls dieser noch nicht in der Liste vorhanden ist filelist_free Gibt den Speicherplatz fiir 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 Da teinamen 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 Ver kettung durch den Zeiger next er
148. reicht 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 Daten struktur wieder Die Funktionen zur Arbeit mit der Datenstruktur f hrt 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 Programm ablauf durchf hrt ist die Analyse der VHDL IP Bevor jedoch die Analyse durchgef hrt werden kann muss die Quelldatei aufbereitet werden Der ers te Arbeitsgang liest die Quelldatei der VHDL IP in den Speicher Anschlie Bend entfernt die Funktion vhdl_remove_comments die Kommentare aus dem Quelltext Die Formatierungszeichen wie 2 Zeilenumbr che Tabulatoren 4 DER SIMULATIONSINTERFACEBLOCK GENERATOR T1 und mehrfache Leerzeichen entfernt die Funktion string_remove_multispace Um ein einfacheres Parsen des Quelltextes zu erm glichen wandelt die Funk tion string_tolowercase den Text Kleinbuchstaben um Am Ende der Vor bereitung sucht vhdl_entity_borders die Grenzen der Entity im Text Es wird hierbei davon ausgegangen dass der Quelltext nur eine VHDL Entity be schreibt oder die erste Entity im Text das Toplevel der IP darstellt Ihre Position bestimmt der Anfang des Schl sselwortes entity und das Ende die Position des Schl sselwortes end Anhand dieser Grenzen l st die Funktion string_extract
149. ren best ckt werden Dadurch bildet der System Explorer eine rekonfigurierbare Prototy pingplattform Zum System Explorer geh rt auch ein Softwarepaket Es besteht aus den Programmen Design Pilot Explorer 2000 und Expeditor Der Design Pilot f hrt das logische Mapping durch und generiert die Netzlisten Er bildet die entworfene Logik und Soft IPs auf die Ziel FPGAs ab Auferdem f hrt er eine automatische hierarchische Blockgruppierung und Partitionierung des Entwurfs durch wx LCE Abbildung 2 15 Aptix System Explorer Quelle Apt00 2 STAND DER TECHNIK 25 MP4CF Emulationskapazitat 2 5 Millionen 3 Millionen in ASIC Gattern Blockmemory 6 MBit 10 MBit Prototypingflache 1920 Pins 2880 Pins max Anzahl FPGAs 12 20 Anzahl Abgreifpunkte 1500 2000 Einsatzzweck DSP basierte Designs mit m igen Anforde rungen an die Ver bindungsstruktur zwi schen den Komponen optimiert f r Prototy pen mit grofen inter nen Bussen und hohen Anforderungen an die Verbindungsstruktur ten Tabelle 2 2 Technische Daten des Aptix System Explorer Der Explorer 2000 f hrt das Mapping des partitionierten Designs auf die physischen Komponenten des Prototypingsystems aus Er routet die einzel nen FPGAs und Komponenten untereinander durch die FPICs und konfigu riert anschlie end den Prototypen Nach der Konfiguration f hrt die Softwa re eine Automatisier
150. rfsdimensionen vgl Abbil dung 1 5 gew hrleisten Au erdem sollte es die Verwendung von Intellectual Properties auf jeder Verfeinerungsebene f r den Entwurf und den Test des Systems unterst tzen Um diese Anforderungen zu erf llen wurde SystemC Abschnitt 2 1 entwi ckelt SystemC unterst tzt den modularen Entwurfsprozess von der System spezifikation bis zur Register Transfer Ebene Auferdem erlaubt es Hard ware Software Codesign was f r die Entwicklung von HW SW Systemen vorteilhaft ist Die Einbindung von sprachfremden Intellectual Properties ist als Netzliste m glich Eine Netzliste ist eine synthetisierte Register Transfer Beschreibung In h heren Abstraktionsebenen k nnen diese Intellectual Pro perties nicht in ihrer Originalform verwendet werden Zur Simulation eines Systems in diesen Abstraktionsebenen muss ein Modell der IP erstellt wer den Dieser Prozess ist fehleranfallig und kostet Zeit und Geld was den Erfolg des Produktes weniger gut ausfallen lassen kann 4 1 EINFUHRUNG Verhaltenssicht Struktursicht Systemebene Algorithmische Ebene Funktionelle Ebene Gatterebene Schalterebene Elektrische Ebene Physikalische Sicht Testsicht Abbildung 1 4 Das X Diagramm nach Rammig Gegen ber dem Y Diagramm nach Gajski bringt es die Testsicht zus tzlich in jede Entwurf sebene mit ein Die Umgehung der Erstellung eines Modells der Intellectual Property k nnte den Entwurfsprozess weiter beschleunigen
151. rfssysteme Vorlesung Techni sche Universitat Chemnitz 2002 Prof Dr Dietmar Miiller ASIC Entwurf Vorlesung Technische Universitat Chemnitz 2003 138 Mod Mod03 00 Mon Nau99 01 Opea Opeb Ope02 04 Ram89 Scia Scib Model Technology www model com Homepage Model Technology ModelSim LE User s Manual Dezember 2003 Version 5 8a Prof Dr Ing Dieter Monjau Rechnerorganisation Vorlesung Technische Universit t Chemnitz 2000 Prof Dr Ing Dieter Monjau VHDL Einf hrung Unterla gen zur Vorlesung Rechnerorganisation Technische Universit t Chemnitz 2000 Dr Bernt Naumann Digitaltechnik Vorlesung Technische Uni versit t Chemnitz 1999 Dr Bernt Naumann Werkzeuge f r den Systementwurf Vorle sung Technische Universit t Chemnitz 2001 Open SystemC Initiative SystemC Homepage http www systemc org Homepage Open SystemC Initiative SystemC M User s Guide Version 2 0 Open SystemC Initiative Functional Specification for SystemC 2 0 April 2002 Version 2 0 Q Craig Peacock Beyond Logic http www beyondlogic org Juli 2004 Webseite Fanz J Rammig Systematischer Entwurf digitaler Systeme B G Teubner Stuttgart 1989 Scientific Software Tools Inc http www driverlinx com DownLoad DIPortIO htm Downloadseite von port95nt exe Scientific Software Tools Inc SST Data Acqui sition
152. rifizieren Die HW SW Cosimulation verfolgt zwei konkurrierende Ziele Das erste Ziel besteht darin die Simulation mit der gr tm glichen Geschwindigkeit zu be treiben 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 simu liert werden umso geringer ist die Simulationsgeschwindigkeit Aus diesem Grund existieren verschiedene Ans tze zur HW SW Cosimulation die versu chen die Simulationsgeschwindigkeit zu erh hen und dabei m glichst genaue Ergebnisse zu erzielen Der urspr ngliche Ansatz besteht darin einen Hardwaresimulator zu nut zen Die Simulation findet unter Nutzung einer einzigen Simulationsumge bung statt in der sowohl Hardware als auch die darauf ausgef hrte Software simuliert wird Dieser Ansatz bietet eine geringe Simulationsgeschwindigkeit da das simulierte Hardwaremodell einen hohen Detailgrad besitzt Der Vor teil besteht darin dass keine Schnittstellen zu anderen Systemen notwendig sind Zur Beschleunigung der Simulation kann ein Bus Modell verwendet wer den Abbildung 2 8 Ein Bus Modell ist eine Hardwarebeschreibung die nur ein ereignisdiskretes Modell des Bus Interfaces des Prozessors simuliert Die Bus Modell Hardware HDL simulator Backplane Abbildung 2 8 HW SW Cosimulation mit dem Bus Modell 18 2 STAND DER TECHNIK Hardw
153. rk swrite sread Statusregister1 zero cycles sready zero hdiv zero ldiv Statusregister2 Tabelle 3 4 Belegung der Kontroll und Statusregister der CU vw der Automat in den Zustand Clk_gen1 in dem die Taktgenerierung beginnt Der Zustand Clk 1 erzeugt den Highpegel in positiver Logik w hrend der Zustand Clk_genO den Lowpegel generiert Die Dauer der generierten Pegel bestimmten die Werte der Z hler HDIV und LDIV Mit Hilfe der Z hler ist es m glich die IP Emulation wahlweise mit einem symmetrischen oder einem asymmetrischen Taktsignal zu betreiben Die Frequenz mit der die IP emuliert wird berechnet sich nach der Formel f p n Die Herleitung der Formel beschreibt Anhang A Um die gew nschte Anzahl an Taktperioden zu erzeugen werden die Zust nde OI gen und Clk_gen0 so oft nacheinander abgearbeitet bis der Zyklenz hler den Wert 0 erreicht hat Nach Abschluss der Taktgenerierung wechselt der Automat in den Zustand End_Cycle Dieser Zustand sperrt die Flipflops des PHuw ou Modus wieder damit die aufgenommenen Emulationsdaten nicht verf lscht werden k nnen Der Automat verweilt in diesem Zustand bis das Signal cnezt oder cread gesetzt wird Das Signal mit der obersten Priorit t ist creset Es bringt den Automaten in den Zustand DoReset l st ein Signal f r die Komponente Autoreset aus Das Signal veranlasst die Komponente einen asynchrone Reset f
154. rotokollautomaten des EPP Protokoll auf der Slaveseite dar Ausf hrlichere Informationen zur parallelen Schnittstele finden sich in Axe97 04 und War Die unterschiedlichen bertragungsmodi bedeuten f r die HW SW Schnitt 3 DIE METHODE DER ADAPTIERUNG 47 DataWcycle DWGet 20 e a nWait 0 MDataStrobe 1 nwait 1 Writecycle oo ES x 592 Q Y nWait 0 9 A 2 l S Se E og lAddressWcycle AWGet AC o pn nWait 0 PAddrStrobe wett 0 Init SI a L J SES CycleEnd g 2 CA nWait 0 5 E 2 E nWait 1 e lt 9 4 P DataRcycle DRPut ly 2 o KA y nWait 0 nDataStrobe 1 nWait 1 2 62 He e 9 5 Readcycle wor wo EEE a rm nWait 0 X Na 24 Cs 2 SH AddressRcycle ARPut WA 50 E nAddrStrobe 1 nWait 1 E nWfite 1 Vu UE Abbildung 3 16 Protokollautomat des EPP Protokoll stelle dass f r die Kommunikation eine Adressbreite von 8 Bit zur Verf gung steht Mit jeder Adresse k nnen 8 Bit Daten adressiert werden Mit 8 Bit lassen sich 2 256 verschiedene Adressen darstellen Da jeder Adresse 8 Bit Daten zugewiesen werden k nnen ergeben sich daraus 256 8 Bit 2048 Bit Daten die adressiert geschrieben und 2048 Bit Daten die adressiert gelesen werden k nnen Mit Hilfe dieses Mechanismus ist es m glich die Daten
155. rschiedene Modi die jeweils eine andere Form der Daten bert ragung durch das EPP Protokoll ausf hren Ihre Funktionen sind in Tabelle 5 2 aufgef hrt Die Modi 5 und 6 realisieren ein abwechselndes Schreiben Modus Funktion mi Datenbyte schreiben m2 Adressbyte schreiben m3 Datenbyte lesen m4 Adressbyte lesen m5 Adressbyte schreiben Datenbyte schreiben m6 Adressbyte schreiben Datenbyte lesen Tabelle 5 2 Die Modi der Software zur Messung der bertragungsgeschwin digkeit der parallelen Schnittstelle im EPP Modus 5 DEMONSTRATOR 95 32 Bit Bytez hler Stopuhr E Abbildung 5 5 Aufbau der Hardware zur Geschwindigkeitsmessung eines Adressbytes und Schreiben bzw Lesen eines Datenbytes Diese For men der Daten bertragung sind f r 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 ber tragungsgeschwindigkeit des EPP Protokolls dienen ein 32 Bit Z hler und ei ne Stopuhr Beide werden ber ein gemeinsames Startsignal aktiviert Der Bytez hler reagiert auf das Signal n Wait des EPP Protokolls In jedem bert ragungszyklus andert das Signal zweimal seinen Wert einmal von high zu low und einmal umgekehrt In jedem bertragunszyklus wird dabei genau ein Byte bertragen Die Stopuhr beginnt die Zeitmessung sobald der By
156. rst tzt den Systementwurf von der Spezifikation bis zur Register Transfer Ebene Bei bisher verwendeten Beschreibungsm glichkeiten bestand 2 STAND DER TECHNIK 9 eine Liicke im Entwurfsprozess Zum Beispiel stehen in C C keine geeig neten Beschreibungsmittel fiir Hardware zur Verfiigung da Konzepte wie Nebenl ufigkeit und ein Zeitmodell fehlen Deshalb war bisher eine manu elle 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 rtig verwendete Designmethode und die Designmethodik von SystemC gegen ber Als junges Entwurfssystem gibt es allerdings noch Einschr nkungen So ist beim Softwaredesign die Einbindung von Echtzeitbetriebssystemen RTOS noch nicht m glich Eine Verbesserung soll Version 3 von SystemC bringen Als Werkzeuge zur Synthese kommt der CoCentric SystemC Compiler 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 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
157. ry SW Software VDI Verein Deutscher Ingenieure VHDL VHSIC Hardware Description Language VHSIC Very High Speed Integrated Circuit XML Extensible Markup Language
158. stelle die Gr e der Simulationsdaten sowie die Adressen der Kontroll und Statusregister des Hardwareteils des Simula tionsinterfaceblocks Die Einbindung der Dateien des Softwareteils in ein bestehendes Design soll te aus dem generierten Verzeichnis erfolgen Dazu muss beim Aufruf des C C 4 Compilers das Softwareverzeichnis als zus tzlicher Pfad f r Include dateien angegeben werden F r den Linker ist als Bibliothek die Datei dlpor tio lib sowie das Softwareverzeichnis als weiteres Bibliotheksverzeichnis mit anzugeben Das hat den Vorteil dass die Ausgaben des Simulationsinterface block Generators in einem Verzeichnis gesammelt bleiben Dies verringert die Gefahr dass ein Hardwareteil auf das FPGA geladen wird der nicht zum be nutzen Softwareteil geh rt und dadurch falsche Simulationsergebnisse erzielt werden 4 DER SIMULATIONSINTERFACEBLOCK GENERATOR 85 4 4 Verbesserungsm glichkeiten und Fazit Um die Einsatzm glichkeiten des Simulationsinterfaceblock Generators zu verbessern sind einige Erweiterungen im Programm denkbar In der ge genw rtigen Version verarbeitet der Simulationsinterfaceblock Generator nur Ports von VHDL Entities mit den Richtungen in oder out Zur Unterst tzung einer gr eren Anzahl von VHDL IPs k nnte das Programm f r die Verar beitung von bidirektionalen Ports Richtung inout erweitert werden Mit der Analysem glichkeit von VHDL Generics wird das Konzept von generischen Portbreiten umges
159. ten des Systems mit der realen Intellectual Property kann unter sucht werden Zur einfacheren und schnelleren Adaptierung des FPGA an die SystemC Si mulation soll ein automatisiertes Verfahren entwickelt werden Der Vorteil eines automatisierten Verfahrens besteht darin Zeit und Kosten bei der Vor bereitung der Simulation zu sparen 1 2 Gliederung der Arbeit Das Thema dieser Arbeit ist die Automatische Adaption von Hardware Acceleratoren f r Verhaltenssimulation Das erste Kapitel enth lt eine kurze Einf hrung in die Thematik und die Aufgabenstellung Kapitel 2 be schreibt 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 ftigt sich Kapitel 3 Ein allgemeines L sungskonzept wird darin vorgestellt und darauf F r den englischen Begriff Adaption wird im weiteren Verlauf dieser Arbeit der deut sche Begriff Adaptierung verwendet 6 1 EINFUHRUNG aufbauend eine technische Umsetzung geboten Kapitel 4 beschreibt die Au tomatisierung des vorgestellten L sungskonzeptes durch ein im Rahmen die ser Arbeit entwickeltes Programm Der Nachweis ber die korrekte Funktion der erarbeiteten L sungen wird in Kapitel 5 an einem Beispiel durchgef hrt Das 6 Kapitel fasst die Ergebnisse der Arbeit zusammen und gibt einen Aus blick auf Zukunftsperspektiven und M glichkeiten der Weiter
160. tez hler einen Wert ungleich Null annimmt Sie kann bis zu 1000 Sekunden z hlen Ihre Genauigkeit h ngt 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 bernimmt ein Multiplexer Es k nnen die ausgehenden sowie die eingehen den Adressen und Daten angezeigt werden Jedoch fallt ihnen f r die Messung keine Bedeutung zu Die wichtigen Daten bilden die Anzahl der bertrage nen Bytes und die daf r ben tigte Zeit Auch sie k nnen auf der Anzeige ausgegeben werden Das Ausgabeformat ist hexadezimal Die Messungen der Geschwindigkeit erfolgen f r die Modi 5 und 6 Modus 5 schreibt abwechselnd ein Adressbyte und ein Datenbyte auf die parallele 96 5 DEMONSTRATOR Modus bertra s ms us ns Byte s Durchschnitts gene Byte geschwindigkeit 18860504 30 543 789 500 617460 m5 18892543 30 530 303 600 618813 618 404 Byte s 18976578 30 660 073 340 618940 19450840 30 323 718 040 641440 m6 19517029 30 355 897 920 642940 641881 Byte s 19529100 30 454 054 240 641 264 Tabelle 5 3 Ermittelte Geschwindigkeiten der parallelen Schnittstelle Schnittstelle Er nutzt dazu die Funktion Write EPP die auch f r die Da ten bertragung im Simulationsinterfaceblock zum E
161. tstelle in der Lage sein die Simulationsdaten intern zu serialisieren sie vollst ndig und ohne Verlust 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 Datentransforma tion gestattet sein Nachdem die Anforderungen an den Datenaustausch herausgearbeitet sind stellt sich nun das Problem der Synchronisation zwischen der SystemC Simulation und der IP Emulation Die SystemC Simulation ist zyklusba siert vgl Abschnitt 2 3 1 Hier dient das Taktsignal als Ausl sesignal f r die Neuberechnung der Signale des im Test befindlichen Designs Da keine Anderungen am Simulationskern vorgenommen werden sollen findet dieses Ausl sesignal auch bei der Emulation Verwendung Das heift dass die IP ber das Taktsignal der SystemC Simulation gesteuert wird Eine Master Slave Simulation ist die Folge bei der die SystemC Simulation den Mas ter 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 ber das Taktsignal wiederum ein Problem auf Es besteht darin dass das Taktsignal durch die HW SW Schnittstelle und 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 bertragung des Taktsigna
162. turen erfolgt in den sich anschlie enden Abschnit ten 4 2 2 1 Die Datenstruktur ENTITY_STRUCTUR Die grundlegende Datenstruktur im Simulationsinterfaceblock Generator ist die ENTITY_STRUCTURE Sie speichert alle Daten die f r die Erstellung des Simulationsinterfaceblocks notwendig sind Die Daten bestehen aus Analy seergebnissen der VHDL IP und darauf aufbauender Berechnungen sowie aus Parametern die vom Nutzer zur Laufzeit des Programms festgelegt wer den Au erdem existieren einige Funktionen die eine einfache Arbeit mit der Datenstruktur erlauben Zun chst soll die Funktion der Variablen der Datenstruktur die Tabelle 4 1 auff hrt vorgestellt werden Die Variable filename speichert den Namen der Quelldatei die den Toplevel der VHDL IP darstellt Den Namen der VHDL Entity dieser Datei enth lt component_name und die Position innerhalb der Datei compname_position 66 4 DER SIMULATIONSINTERFACEBLOCK GENERATOR Funktion Aufgabe make_entitystructur Erzeugt ein neues Element vom Typ ENTITY STRUCTUR init entitystructur Initialisiert die Datenstruktur vom Typ ENTITY STRUCTUR reserve wordspace ename Reserviert Speicherplatz f r die Variable component name reserve wordspace fname Reserviert Speicherplatz f r die Variable filename check entity for clock Durchsucht die Ports der Entity nach ei nem Taktsignal und legt eines an falls die Suche fehlschlagt Tabelle 4 2 berblick zu den
163. u lation existiert jeweils eine Datei risc cpu log die die Daten enth lt Mehr zum Inhalt der Verzeichnisse bietet Anhang D der das Inhaltsverzeichnis der CD ROM beinhaltet Ausgaben der originalen RISC CPU ALERT ID initialize Archite ctural Registers ALERT BIOS initialize BIOS ALERT DCU initialize Data Cache mem 0xf000001 IFU pc 1 at CSIM 5 ns ID RO RO 0 at CSIM 7 ns ALU op A 0 B 0 ALU R 0 gt RO at CSIM 9 ns IFU mem 0xf000002 IFU 2 at CSIM 12 ns ID RO RO 0 at CSIM 14 ns ALU op 3 A 0 B 0 Ausgaben der RISC CPU mit SimulationsIFB ALERT ID initialize Archite ctural Registers ALERT BIOS initialize BIOS ALERT DCU initialize Data Cache mem 0xf000001 IFU pc 1 at CSIM 5 ns ID RO RO 0 at CSIM 7 ns 3 A 0 B 0 ALU R 0 gt RO at CSIM 9 ns IFU mem 0xf000002 IFU pc 2 at CSIM 12 ns ID RO RO 0 at CSIM 14 ns 112 Anhang ALU R 0 gt RO at CSIM 16 ns ALU R 0 gt RO at CSIM 16 ns Pes ae ae Fer JUL a Tapete eh eos IFU mem 0xf000003 IFU mem 0xf000003 IFU pc 3 at CSIM 19 ns IFU pc 3 at CSIM 19 ns ID RO RO 0 at CSIM 21 ns ALU op 3 A 0 B 0 ALU R 0 gt RO at CSIM 23 ns IFU mem 0xf000004 IFU pc 4 at CSIM 26 ns ID RO RO 0 at CSIM 28 ns op 3 A 0 B 0 R 0 gt RO at CSIM 30 ns
164. uation Zun chst richtet sich die Betrachtung auf den Hardwaretask da dem Interfa ceblock eine Hardwareanwendung zugrunde liegt Die Verbindung zwischen dem Interfacebock und der Intellectual Property wird durch einen Protokoll handler bewerkstelligt Abbildung 3 9 Er wird im Folgenden als PHyw out bezeichnet da er den hardwareseitigen Ausgang des Interfaceblock bildet IP Emulation Abbildung 3 8 Verbindung eines SW Task und eines HW Task durch einen Interfaceblock 40 3 DIE METHODE DER ADAPTIERUNG Emulation Abbildung 3 9 Die Hardwareschnittstelle des Interfaceblocks der Protokollhandleryw out Die Funktion die die Schnittstelle IP Emulation erf llen muss ist das Anlegen der Triggerdaten an die IP und das kontrollierte Abgreifen der Tracedaten von der IP w hrend eines Emulationszyklus Zur Sicherstel lung der Datenkonsistenz also dass die Daten nur aus dem gerade ablaufen den Emulationszyklus stammen muss dieser Vorgang ber Kontrollsignale gesteuert werden Die Daten die ber die Schnittstelle transportiert wer den m ssen bis zu ihrer Verarbeitung verf gbar sein Aus diesem Grund erfolgt eine Zwischenspeicherung der Daten im IFB Die Speicherung findet im Modus des PHyw out statt da die Modi der Handler diese Funktionalit t bereitstellen k nnen Die Verbindung von SystemC Simulation und Interfaceblock realisiert wie derum ein Protokollhandler Di
165. uct port list next Tabelle 4 3 Aufbau der Datenstruktur PORT_LIST 68 4 DER SIMULATIONSINTERFACEBLOCK GENERATOR Funktion Aufgabe make_port Erzeugt ein neues Element vom Typ PORT_LIST init portlist Initialisiert die Datenstruktur insert port F gt ein Element in eine bestehende Liste ein reserve wordspace Reserviert Speicherplatz f r 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 direction Tabelle 4 4 berblick 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 Abbil dung 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 be stimmt active die aktive Taktflanke dieses Signals Ob der Port im erstellten SystemC Modul vorzeichenbehaftet ist oder kein Vorzeichen besitzt beein flusst die Varibale sign Neben den Variablen erleichtern einige Funktionen die Arbeit mit der Da tenstruktur Ihre Aufgaben stellt Tabelle 4 4 dar 4 2 2 3 Die Datenstruktur GENERIC LIST Die Datenstru
166. ung Technische Universit t Chemnitz 2003 Prof Dr Wolfram Hardt Hardware Software Codesign II Vor lesung Technische Universitat Chemnitz 2003 2004 Wolfram Hardt Markus Visarius and Stefan Ihmor Rapid pro totyping of real time interfaces In Field Programmable Logic FPL Poster Session Belfast Northern Ireland UK October 2001 Stefan Ihmor Nilson Bastos Jr Rafael Cardoso Klein Markus Visarius and Wolfram Hardt Rapid Prototyping of Realtime Communication Case Study Interacting Robots June 2003 Stefan Ihmor and Wolfram Hardt Runtime Reconfigurable In terfaces The RTR IFB Approach 18th International Parallel and Distributed Processing Symposium IPDPS 04 Workshop 3 April 2004 Santa Fe New Mexico USA Stefan Ihmor Entwurf von Echtzeitschnittstellen am Beispiel interagierender Roboter Diplomarbeit Universit t Paderborn 2001 Intel Coporation Intel Research Silicon Moore s Law http www intel com research silicon mooreslaw htm Home page Projekt IPQ Home Page https www ip qualifikation de Stefan Ihmor Markus Visarius and Wolfram Hardt A Consis tent Design Methodology for Configurable HW SW Interfaces in Embedded Systems Montreal Canada Aug 2002 Stefan Ihmor Markus Visarius and Wolfram Hardt A Design Methodology for Application specific Real Time Interfaces 137 IVH03 Lat 02 Maid Mena Menb Menc Mend
167. ung des Hardware Debugging durch Der Explorer 2000 routed automatisch Probes und konfiguriert den Agilent Logikanalysator zum Erfassen von Simulationsdaten Die Aufgabe des Expeditor besteht darin eine Schnittstelle zu anderen Simulatoren und Testwerkzeugen herzustellen Damit kann eine verteilte Si mulation erfolgen Dem System Explorer liegt eine blockbasierte Verifikationsmethodik zu Grun de Diese erlaubt die schnelle Erstellung von Prototypen ein einfaches Debug ging und eine rasche Implementierung von Designver nderungen Der Pro totyp wird Block f r Block nach der Hierarchie des Designs aufgebaut Da Logik nderungen meist auf eine FPGA begrenzt sind erm glicht 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 Ent wicklung von Software und Hardware erfolgen Der Prototyp kann benutzt Probes sind Leitungen innerhalb der FPGA die nach au en gef hrt werden um die Signalwerte auf den Leitungen abgreifen zu k nnen 26 2 STAND DER TECHNIK werden um das System on Chip in seiner realen Systemumgebung zu emulie ren Es kann begonnen werden Schnittstellen zu erproben und andere digitale oder analoge Subsysteme w hrend die SoC Entwicklung noch voranschreitet Das fr he Vorhandensein eines Prototypen erlaubt es dem Kunden schon fr h im Entwurfsprozess ein
168. unikation von IP User und verschiedenen IP Serviceprovidern erlauben Quelle VH04 2 STAND DER TECHNIK 13 Zur Losung des Problems musste ein standardisiertes und von den Firmen akzeptiertes Austauschformat gefunden werden Dieses Format musste au er dem die M glichkeit bieten eine firmeninterne Beschreibungen in das stan dardisierte Format zu konvertieren aber auch den Weg vom standardisierten in firmeninterne Formate gew hrleisten Als L sung wurde das IPQ Format entwickelt Es basiert auf XML Schema Auferdem fand die Entwicklung zahlreicher Tools statt die zum Beispiel das Suchen einer IP vereinfachen Weitere Informationen zu diesem Thema bieten VLKHO4 VH04 und VLH 03 Mit Hilfe des IPQ Formates und der dazu entwickelten Tools wird eine stan dardisierte Kommunikationsmoglichkeit von IP Usern und IP Serviceprovidern vgl Abbildung 2 5 geboten Das System ist bereits einsatzf hig Jedoch scheitert sein Einsatz durch teilweise ungekl rte rechtlichen Fragen zum IP Handel und zur IP Nutzung Doch auch f r dieses Problem wird sich eine L sung 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
169. unikationszeit ergibt sich 36 Byte 618404 Byte s 40 Byte 641881 Byte s 278 0 0335s 33 5 ms Damit l sst sich ein Teil der 57 Millisekunden Zeitunterschied zwischen der Simulation der originalen und der modifizierten RISC CPU erkl ren Ein weitere Faktor der die h here Simulationszeit erkl ren kann ist das Signalmapping in der Datei exec cpp In jedem Simulationsschritt m ssen die Eingangssignale bitweise auf das Feld f r 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 tzlich Zeit 100 5 DEMONSTRATOR Im Vergleich zum generierten Modul hat das originale Modul sehr wenig weisungen auszufiihren Aus diesem Grund besitzt es einen Vorteil hinsicht lich der Simulationszeit Es ist wahrscheinlich dass der jetzige Geschwindig keitsvorteil der Originaldesigns mit zunehmender Komplexit t der SystemC Beschreibung verloren gehen w rde In diesem Fall kann der Simulations interfaceblock auch zur Beschleunigung der SystemC Simulation eingesetzt werden Bei der Durchf hrung der Messung ist nicht vorhersagbar ob der Simulation ber die gesamte Laufzeit die komplette CPU Leistung zur Verf gung steht Auf dem simulierenden PC werden weitere Prozesse des Betriebssystems aus gef hrt Falls das Betriebssystem w hrend der Ausf hrung dem Simulator kurz den Prozessor entzieht kommen U
170. von Moores Gesetz Quelle Int die Entwurfskosten amortisieren Damit sich der Entwurf von SoC L sun gen auch weiterhin lohnt m ssen die Entwicklungskosten und die Time to Market sinken Strategien zur Senkung der Entwicklungskosten und der Time to market stel len zum Einen eine weitere Entwurfsautomatisierung und zum Anderen die Wiederverwendung bereits entwickelter Komponenten dar Die Wiederver wendung von Komponenten basiert auf der Nutzung von Intellectual Pro perties Intellectual Properties dt Geistiges Eigentum ist nach der allgemeinen De finition jedes Produkt des menschlichen Intellekts das einzigartig neuar tig und nicht offensichtlich ist Dazu geh ren literarische k nstlerische und wissenschaftliche Arbeiten Leistungen von K nstlern Erfindungen auf al len Gebieten der menschlichen Erkenntnis wissenschaftliche Entdeckungen industrielle Designs eingetragene Waren und Dienstleistungsmarken Han delsnamen und Kennzeichnungen sowie alle weiteren Rechte aus intellektu eller Tatigkeit in den Gebieten der Industrie Wissenschaft Literatur oder Kunst Wor Mar02 Mic04 Time to market gibt die Zeit an die von der Idee bis zur Marktreife eines Produktes vergeht 2 STAND DER TECHNIK 11 Custom IP Design IP Custom Custom Design Design Custom IP Design Abbildung 2 4 Aufbau eines System on Chip aus IPs und selbstentwickelten Komponenten Eine Intellectual Property IP im Sinne der Hardwar
171. warebeschreibungssprache wie zum Beispiel VHDL oder Verilog bergegangen werden Dieser Schritt stellt beim ak tuellen Entwurfsprozess noch ein Hindernis dar da er vom Entwickler von Hand durchgef hrt werden muss Dieser Prozess beansprucht viel Zeit und ist fehleranfallig Nach der Konvertierung muss das Design ausgiebigen Tests unterzogen werden um sicherzustellen dass die Konvertierung mit der Spe zifikation bereinstimmt Dadurch verl ngert sich die Entwicklungszeit und teure Resourcen werden gebunden Wiinschenswert ist nun ein Entwurfssystem das es erlaubt den Entwurf von Hardware ber alle Entwurfsebenen modular und in einer einheitlichen 1 EINFUHRUNG 3 Systemebene Algorithmische Ebene Verhaltenssicht Funktionelle Ebene Struktursicht Gatterebene Integrierter Schaltkreis Subsysteme Busse Systemspezifikation Algorithnien Registertransfers Boolsche Gleichungen Schalten beng Module L itungen Gattet Flipflops Leitungen Transistoren Elektrische Differentialgleichungen 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 hren F r den zunehmend wichtiger werden den Entwurf von eingebetteten Systemen sollte das Entwurfssystem zudem die Unterst tzung der daf r ben tigten Entwu
172. ystem das aus Spezialprozessoren besteht Die Prozessoren berechnen das Simulationsmodell das aus einer Hardware beschreibungssprache 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 CompactPCI Gehause untergebracht wie in Abbildung 2 13 zu sehen ist Die Prozessoren sind speziell daf r gebaut um Hardwarebeschreibungskon strukte zu beschleunigen Alle Prozessoren k nnen miteinander kommunizie ren und in jedem Befehlszyklus gemeinsam Daten benutzen Das Geh use Hammer 100 System Prozessorboard des Hammer 100 Abbildung 2 13 Hammer 100 System von Tharas Quelle Thab 22 2 STAND DER TECHNIK nutzt eine gesch tzte Backplane um eine hohe Prozessorkonnektivit t zu liefern Die Busarchitektur wurde speziell entworfen um den hohen Kom munikationsanforderungen eines hoch parallelen Rechensystems gerecht zu werden Als Hardwarebeschreibungssprachen werden der IEEE Verilog 1364 2001 und der IEEE VHDL 1076 2002 Standard unterstiitzt Der Compiler analysiert eine Hardwarebeschreibungssprache auf syntaktische und semantische Kor rektheit Aus der Beschreibung generiert er optimalen parallelen Code fiir die Spezialprozessoren Der Compiler bersetzt bis zu 50 Millionen RTL Gatter quivalente je Stunde Das Hammer 100 System unterst tzt verschiedene Hardware

Automatische Adaption von Hardware-Acceleratoren für

Contents

Download Pdf Manuals

Related Search

Related Contents

Automatische Adaption von Hardware-Acceleratoren f&uuml;r

Contents

Download Pdf Manuals

Related Search

Related Contents

Automatische Adaption von Hardware-Acceleratoren für