Praktikum Hardware/Software-Codesign mit SystemC · 2006. 5. 29. · Vortrags mit 10 bis 15 Folien...

Technische Universitat BraunschweigAbteilung Entwurf integrierter

Schaltungen (E.I.S.)

Prof. Dr. Ulrich GolzeDipl.-Inform. Wolfgang Klingauf

29. Mai 2006

Praktikum

Hardware/Software-Codesign mit SystemC

Echtzeit-Erkennung von Hand-Gesten

Sommersemester 2006

Einleitung

Herzlich Willkommen beim SystemC-Praktikum an der Abteilung E.I.S.! In diesemPraktikum werden Sie die Systembeschreibungssprache SystemC einsetzen, um einkomplettes Hardware-Software-Codesign eines eingebetteten Systems durchzufuhren. Eshandelt sich dabei um eine Videokamera zur Echtzeit-Erkennung von Handbewegungen,um Gerate beruhrungslos mit Korpergesten zu steuern, etwa Beleuchtung und Jalousienin der Home-Automation.

Angefangen mit einem High-Level-Modell des Gesamtsystems werden wir in diesemPraktikum alle wichtigen Stationen eines modernen System-Level-Designflows besuchenund Einblicke in die jeweiligen Besonderheiten und Herausforderungen bekommen. AmEnde des Praktikums steht eine vollstandige Implementierung von sowohl Hardware alsauch Software auf dem Prototypensystem Xilinx-XUP mit FPGA Virtex-II-Pro.

Dieser Leitfaden ist in drei Teile gegliedert: Der erste beschreibt den Praktikumsablaufmit seinen einzelnen Phasen und Teilaufgaben, der zweite beschreibt die verwendetenTechnologien. Im dritten Abschnitt stellen wir die im Praktikum eingesetzten Werkzeugeund Intellectual-Property-Module (IP) vor und liefern einige Quelltextbeispiele. LesenSie den zweiten und dritten Abschnitt zuerst, da die Praktikumsaufgaben auf dem dortvermittelten Wissen aufbauen.

Bitte lassen Sie uns wissen, wo Probleme auftreten, damit wir fur nachfolgende Jahr-gange Abhilfe schaffen konnen.

3

1 Praktikumsablauf

Wann und Wo?

Fur das Praktikum stehen in der Abteilung E.I.S. in Raum 317 drei Entwicklungsplatzemit Linux-PC, FPGA-Prototypenboard und Videokamera zur Verfugung. Sie konnenden Raum beliebig oft nutzen, dafur erhalt jede Gruppe einen elektronischen Schlus-sel, mit dem Sie auch das Informatikzentrum zu jeder Zeit (sogar nachts. . . ) betretenkonnen. Die Betreuung durch die HiWis findet zu den in der Einfuhrungsveranstaltung(siehe nachste Seite) festgelegten Zeiten statt, jeder Gruppe sind zwei betreute Terminepro Woche zu jeweils 90 Minuten zugeteilt. Die Bearbeitung der Aufgaben erfolgt inDreiergruppen.

Bearbeitung der Aufgaben

Die Praktikumsaufgaben sind in Phasen gegliedert, die aufeinander aufbauen. Falls eszu Beginn noch Verstandnisprobleme zur Aufgabenstellung gibt, fragen Sie uns bittefruhzeitig. Planen Sie zu Beginn jeder Phase, wie Sie die zu erledigende Arbeit auf IhreTeammitglieder aufteilen wollen. Fur die Bearbeitung der Aufgaben selbst existiert einZeitplan, der eingehalten werden sollte.

Abgaben

Am Ende jeder Praktikumsphase mussen ein oder mehrere Dokumente abgegeben wer-den. Diese packen Sie in ein zip-Archiv und kopieren Sie moglichst fristgerecht in denOrdner /opt/cad/scprak/gruppexy . Sie sollten sich selbst darum kummern, Ihre Losungrechtzeitig einem Betreuer vorzufuhren. Denken Sie daran, eine Abgabe besteht nichtnur aus der erfolgreichen Vorfuhrung Ihrer Losung, sondern auch aus kommentierten

Listings, Simulationsausgaben, Screenshots und ggf. weiteren Notizen.

Dokumentation

Zum Abschluss des Praktikums fassen Sie Ihre Ergebnisse in Form eines 15-minutigenVortrags mit 10 bis 15 Folien zusammen. Die Folien sollten mit OpenOffice- oder Po-werPoint erstellt werden.

4

0. Phase: Warming Up1 Woche

Das Kick-Off-Meeting findet am Dienstag, den 18.04.2006 um 10:00 Uhr im Seminarraumder Abteilung E.I.S. (IZ305) statt. Neben der Terminplanung geht es dabei insbeson-dere um die Vorstellung des Motion-Detection-Systems, welches Sie in ein eingebettetesHardware/Software-System umsetzen werden.

In die SystemC-Entwicklungsumgebung VISTA fuhren wir in einem kurzen Crash-Kursein. Hierzu finden Sie außerdem eine Anleitung auf den Praktikumsrechnern unter/opt/cad/vista/Vista Online Documentation.pdf.

Abschließend erhalten Sie pro Gruppe je einen Schlussel fur den Praktikumsraum.

In der ersten Praktikumswoche haben Sie dann Gelegenheit, sich in Ruhe mit demvorliegenden Dokument und dem Spezifikationsmodell zu beschaftigen.1 Kopieren Siesich hierzu das komplette Verzeichnis /opt/cad/scprak/src in Ihr Home-Verzeichnis(/home/gruppexy):

gruppexy@dax:~> cp -r /opt/cad/scprak/src ~

Offnen Sie das Spezifikationsmodell in VISTA, in dem Sie im Menu Project den Menu-punkt Open Project verwenden und dann die von uns bereitgestellte Projektdatei imVerzeichnis src/0 specification model offnen. Schauen Sie sich die Quelltexte an und ma-chen Sie sich mit der Funktionsweise der einzelnen Klassen intensiv vertraut.

Kompilieren Sie das Projekt mit VISTA (Menupunkt Build → Build Project) und startenSie die Bewegungserkennung durch Auswahl des kompilierten Designs im Dateibaum(Design/testbench.cpp) und anschließenden Klick auf Simulation → Simulate. BenutzenSie die Debug-Fahigkeiten von VISTA, um die Funktionsweise des Spezifikationsmodellseingehend zu untersuchen.

Falls mit VISTA oder den Entwicklungsrechnern nicht gleich alles auf Anhieb klappt,wenden Sie sich vertrauensvoll an Ihre HiWis.

Abgabe: Erklaren Sie die Funktionsweise des Spezifikationsmodells Ihrem HiWi.

1Hierzu ein Hinweis: Nutzen Sie die relativ lockere Aufgabenstellung in den ersten Wochen des Prak-

tikums, um sich einen Vorsprung zu verschaffen. Gegen Ende des Semesters stapeln sich erfahrungs-

gemaß die Abgabetermine der verschiedenen Veranstaltungen, die sie besuchen.

5

1. Phase: Komponentenmodell3 Wochen

Ihre Aufgabe in diesem Praktikums ist, ein Hardware/Software-System fur die Echtzeit-Erkennung von Bewegungsablaufen in Live-Videobildern zu entwickeln. Dabei setzenSie einen modernen High-Level-Entwurfsfluss mit der Systembeschreibungs-Sprache Sy-stemC ein, in dem Sie ein von uns zur Verfugung gestelltes High-Level-Modell des Ge-samtsystems schrittweise zu Hardware, Software und Kommunikations-Schnittstellenverfeinern. Am Ende des Praktikums integrieren Sie Ihr Gesamtsystem auf dem FPGA-Prototypensystem XUP und lassen Hardware und Software gemeinsam Bewegungen inVideobildern detektieren.

Wie in der Industrie heute ublich, werden Sie in diesem Praktikum moglichst viele fer-

tige Systemkomponenten – so genannte Intellectual Property – einsetzen, um effizientzum Ziel zu kommen. Dabei setzen Sie das Transaction-Level-Modelling (TLM) ein, umdie Kommunikations-Schnittstellen von dem eigentlichen Verhalten der Systemkompo-nenten zu trennen. Ein Beispiel hierzu zeigt Bild 1.

Bild 1: Zwei System-Varianten mit Transaction-Level-Modelling

Wahrend das Modell in Bild 1a alle Systemkomponenten uber einen gemeinsamenSystembus verbindet, kommen in Bild 1b zwei unterschiedliche Kommunikationsarchi-tekturen zum Einsatz, ein Systembus und ein Network-on-Chip. Beide Systeme erful-len die gleiche Funktion, sind aber sehr unterschiedlich aufgebaut und erreichen da-durch auch unterschiedliche Ausfuhrungsgeschwindigkeiten und benotigen verschiedenviel Platz auf dem Chip.

Im Gegensatz zu Verilog-Designs, bei denen die Kommunikations-Schnittstellen (Inter-faces) auf der hardwarenahen Register-Transfer-Logik-Ebene (RTL) implementiert wer-den, befinden sich die Kommunikations-Ports beim Transaction-Level-Modelling nochauf einer hohen, von der tatsachlichen Hardware-Realisierung unabhangigen Abstrakti-onsebene.

So kann die Zusammenstellung und Simulation der beiden unterschiedlichen Systemmo-delle aus Bild 1 mit SystemC in Minuten erfolgen. Hierzu mussen lediglich alle Moduleim High-Level-Modell mit kompatiblen Kommunikations-Ports ausgestattet sein.

6

Im Praktikum verwenden wir dazu das in Kapitel 2 beschriebene SystemC-High-Level-Protokoll SHIP. SHIP-Ports konnen leicht an verschiedene Kommunikationsarchitektu-ren angeschlossen werden, etwa an einen On-Chip-Bus, oder auch ein Network-on-Chipwie in Bild 1b. Ahnlich zur agilen Softwareentwicklung bewegt man sich bei diesemEntwurfsstil in mehreren Iterationsschritten oder Phasen auf das endgultige Design zu.Dies erlaubt es, Anderungen an der Spezifikation wahrend des gesamten Entwurfsflussesohne großen Aufwand vorzunehmen und in jeder Entwurfsphase verschiedene Realisie-rungsmoglichkeiten auszuloten (Entwurfsraum-Exploration).

Aufgabenstellung: Entwickeln Sie aus dem gegebenen minimalen SystemC-Komponentenmodell im Verzeichnis

/opt/cad/scprak/src/1_component_assembly_model

ein komplettes Komponentenmodell fur das gesamte Motion-Detection-System mit Sy-stemC.

Kapseln Sie die Funktionalitat des Spezifikationsmodells, das sie in Phase 0 betrach-tet haben, sinnvoll in einzelne SystemC-Module, die ausschließlich uber SHIP-Kanale(Abschnitt 2) miteinander kommunizieren. Schreiben Sie eine SystemC-Testbench, diealle Module instanziert und untereinander verbindet. Das Kamerabild und samtlicheBINFrame-Bilder aus den einzelnen Bearbeitungsstufen sollen auf dem Bildschirm dar-gestellt werden. Die Bounding-Box-Funktionalitat aus dem Spezifikationsmodell (Bewe-gungsverfolgung mit Rechtecken im Bild) durfen Sie in dieser Phase vernachlassigen.

Kolloquium: Zu Beginn der zweiten Woche dieser Phase stellen Sie Ihren Entwurf ineinem kurzen Kolloquium vor (Skizze, mundliche Erlauterungen).

Abgabe: Lauffahiges Gesamtsystem als SystemC-TLM-Modell mit Testbench.

7

2. Phase: Kommunikationsarchitektur4 Wochen

Das transaktionsbasierte Komponentenmodell aus Phase 1 soll nun verwendet werden,um verschiedene Realisierungsmoglichkeiten des zu entwickelnden Hardware-Software-Systems gegeneinander abzuwagen. Zielplattform ist das in Abschnitt 5 beschriebenePrototypenboard XUP, welches ein FPGA der Virtex-II-Pro-Familie enthalt. Zwei Kern-fragen mussen geklart werden:

1. Welche Systemkomponenten werden in Hardware und welchein Software realisiert?

2. Welche Kommunikationsarchitektur wird verwendet?

In dieser Praktikumsphase wollen wir uns mit der zweiten Frage beschaftigen. Dazusollen Sie das in Phase 1 entwickelte Komponentenmodell hinsichtlich einer konkre-ten Implementierung fur die Virtex-II-Pro-FPGA-Familie untersuchen. Machen Sie sichdazu mit Kapitel 5 vertraut. Lesen Sie dann Kapitel 3 zur Funktionsweise des On-

Chip Peripheral Bus (OPB). Dieser Bus wird auf Virtex-II-Pro-FPGAs verwendet, umHardwarekomponenten mit dem Systemspeicher und anderen Peripheriekomponentenzu verbinden.

Aufgabenteil 1: Ein Simulationsmodell des On-Chip-Peripheral-Bus

Um das System hinsichtlich einer Anbindung an den OPB zu analysieren, soll ein Bus-Simulationsmodell des OPB entwickelt werden, an das eine variable Anzahl von Master-und Slave-Modulen angeschlossen werden kann. Es soll das in Abschnitt 3 beschriebe-ne Timing-Verhalten des OPB simulieren, um mogliche Kommunikations-Engpasse aufdem On-Chip-Bus schon im High-Level-Entwurf zu erkennen. Als Ergebnis entstehenSystemmodelle wie in Bild 1, mit denen die zu erwartende Performance des Gesamtsy-stems per SystemC-Simulation vorhergesagt werden kann.

Bus-Interface

Der Anschluss von Master-Modulen an das Bus-Simulationsmodell soll uber das in Li-sting 1 gezeigte Interface opb_blocking_if erfolgen. Dieses bietet blockende read- undwrite-Methoden, welche Bus-Mastern den Datenaustausch von 32-Bit-Worten mit Bus-Slaves ermoglichen. Detaillierte Informationen zu diesen Methoden konnen der Dateiopb_blocking_if.h im Verzeichnis ip_lib entnommen werden. Wichtig ist vor allem,dass wir zwischen Einzelwort- und Burst-Transfers unterscheiden. Dies mussen Sie beiIhrer Implementierung berucksichtigen.

Zur Anbindung von Bus-Slaves wird das in Listing 2 gezeigte Interface opb_slave_if

benutzt. Neben den read- und write-Methoden des opb_blocking_if mussen Bus-Slaves die Methoden start_address und end_address implementieren, mit deren Hilfedas Bus-Simulationsmodell herausfinden kann, welcher Slave fur den jeweiligen Buszu-griff zustandig ist (d.h. welcher Slave in dem vom Master angesprochenen Adressraumliegt).

8

Listing 1: opb blocking if.h

class opb_blocking_if : virtual public sc_interface

{

public:

/// Read a 32 bit data word from a slave

virtual bool read(sc_uint <32> &data , unsigned int addr) = 0;

/// Write a 32 bit data word to a slave

virtual bool write(sc_uint <32> data , unsigned int addr) = 0;

/// Do a burst read of arbitrary length data from a slave

virtual bool burst_read(sc_uint <32> *data , unsigned int addr,

unsigned int length) = 0;

/// Do a burst write of arbitrary length data to a slave

virtual bool burst_write(sc_uint <32> *data , unsigned int addr ,


};

Listing 2: opb slave if.h

class opb_slave_if : virtual public opb_blocking_if

{

public:

/// Get the start address of this slave

virtual unsigned int start_address() const = 0;

/// Get the end address of this slave

virtual unsigned int end_address() const = 0;

};

Statten Sie Ihr Bus-Simulationsmodell mit einem Multiport fur den Anschluss von be-liebig vielen Slave-Modulen aus wie in Listing 3. Den Zugriff auf SystemC-Multiportsdemonstriert der Beispielquelltext aus Listing 4.

Bus-Arbitrierung und -Timing

Schreib- und Lesezugriffe verschiedener Master auf die an den Bus angeschlossenen Sla-ves mussen in genau der Reihenfolge abgearbeitet werden, in der sie eintreffen. Dabeimussen die Timing-Eigenschaften des OPB durch wait-Anweisungen widergespiegeltwerden.

Achten Sie darauf, dass immer nur ein Buszugriff zur gleichen Zeit behandelt werdendarf, da es sich bei dem OPB um eine von allen angeschlossenen Modulen gemeinsamgenutzte Kommunikationsverbindung handelt. Speichern Sie hierzu Zugriffswunsche zu-nachst in Form von opb_request-Objekten in einer Warteschlange ab.

Implementieren Sie einen arbiter-Thread, der wartende opb_request-Objekte aus derWarteschlange herausnimmt und in der richtigen Reihenfolge abarbeitet. Die Taktratedes OPB (z.B. 20 MHz) soll bei der Instanzierung Ihres Bus-Functional-Models alsKonstruktorparameter eingestellt werden konnen.

9

Um Ihnen die Arbeit zu erleichtern, stellen wir ein Bus-Grundgerust mit bereits ferti-gen Funktionen zum Verwalten von opb_request-Objekten in einer Warteschlange undmit allen notwendigen Methodenrumpfen in den Dateien opb_bus.h, opb_bus.cpp undopb_request.h im Verzeichnis /opt/cad/scprak/ip lib zur Verfugung. Bauen Sie IhreImplementierung auf dieser Vorlage auf.

Listing 3: Deklaration eines Multiport

#include "systemc.h"

SC_MODULE(opb_bus)

{

public:

// slave multi -port

sc_port<opb_slave_if , 0> slave_port;

// ... here follows the constructor and process declarations ...

};

Listing 4: Zugriff auf Multiport

opb_slave_if *opb_bus::get_slave(unsigned int address)

{

for (int i = 0; i < slave_port.size(); ++i)

{

opb_slave_if *slave = slave_port[i];

if ((slave ->start_address() <= address) &&

(address <= slave ->end_address()))

return slave;

}

return (opb_slave_if *)0;

}

Aufgabenteil 2: Einbindung des OPB-Simulationsmodells

In diesem Aufgabenteil soll das OPB-Simulationsmodell aus Aufgabenteil 1 in Ihr Kom-ponentenmodell aus der letzten Praktikumsphase integriert werden. Hinsichtlich einerspateren Implementierung auf dem XUP-Board werden die folgenden Anforderungendefiniert:

Input-Modul: Das Input-Modul wird als Hardwarekern auf dem FPGA implementiert.Es empfangt fortlaufend Video-Frames von einer angeschlossenen Kamera undschreibt diese uber den OPB als Bus-Master in den Hauptspeicher (DDR-RAM)des XUP.

Display-Modul: Das Display-Modul wird ebenfalls auf dem FPGA realisiert. In seinerersten Version liest es fortlaufend Video-Frames aus dem Hauptspeicher aus undstellt diese mit Hilfe der Klasse yuv_viewer auf einem Bildschirm dar.

10

Integrieren Sie das OPB-Simulationsmodell unter Berucksichtigung der obigen Ent-wurfsentscheidungen in Ihr Komponentenmodell. Verwenden Sie das Modul ddr_ramaus der IP-Bibliothek, welches Sie zur Simulation des Hauptspeichers ebenfalls an IhrBus-Simulationsmodell anschließen. Es implementiert das opb_slave_if-Interface.

Ersetzen Sie den SHIP-Slaveport des Display-Moduls mit einem SHIP-Masterport undeinem passenden SC_THREAD zum Auslesen der Bilddaten aus dem DDR-RAM.

Da das opb_bus-Modul nicht uber SHIP-Kanale angebunden werden kann, ist eine di-rekte Verbindung mit den Modulen aus Ihrem Komponentenmodell nicht moglich. Umdiese trotzdem ohne Programmieraufwand anschließen zu konnen, benotigen wir einenTransaktor. In der IP-Bibliothek fur das Praktikum steht Ihnen der folgende Transaktorzur Verfugung:

shipmaster2opb_transactor: Dieser Transaktor ermoglicht die Verbindung einesSHIP-Masterports mit einem OPB-Masterport. Der Transaktor verwendet dieserialize- und deserialize-Methoden des ship_serializable_if-Interfaces,um die durch den SHIP-Kanal ubertragenen Objekte in einen seriellen Datenstromzu transformieren und vice versa. Diese Methoden werden durch den Datentypyuvframe bereits implementiert!

Detaillierte Beschreibungen zu dem shipmaster2opb_transactor gibt Abschnitt 4. InBild 2 ist das resultierende System skizziert.

Bild 2: Anbindung des OPB-Simulationsmodells uber Transaktoren

11

Aufgabenteil 3: Analyse der Bus-Kommunikation

Das Bus-Simulationsmodell hilft, die Architektur des Gesamtsystems schon auf hoherAbstraktionsebene fur die spatere Realisierung mit unserem Virtex-II-Pro-FPGA vor-zubereiten. Allerdings konnen wir im momentanen Zustand unseres Systems noch nichterkennen, ob die Kommunikation unserer Master- und Slavemodule uber den On-Chip-Peripheral-Bus auch effizient ablauft.

Hierzu wollen wir unser OPB-Simulationsmodell um einige Analysemoglichkeiten erwei-tern. Insbesondere interessieren uns die folgenden Informationen:

• Auslastung des Busses (im Leerlauf / ausgelastet / uberlastet),

• Kommunikationsphase (read, write, burst_read, burst_write).

Mit Hilfe der SystemC-Entwicklungsumgebung VISTA konnen wir diese Daten in Formeines Wave-Diagramms ausgeben lassen. Dazu mussen wir lediglich Signale vom Typsc_signal im opb_bus-Modul anlegen, welche die entsprechenden Informationen ent-halten. Diese konnen wir wahrend der Simulation dann nach Rechtsklick mit der Mausuber den Befehl aquire unserem Wave-Diagramm hinzufugen.

Im Einzelnen werden die folgenden Signale benotigt:

• sc_signal<int> monitor_busload: Aktuelle Anzahl der opb_request-Objektein der Warteschlange.

• sc_signal<int> monitor_read: Ist ungleich ’0’, wahrend der Bus ein read-Kommando abarbeitet.

• sc_signal<int> monitor_write: Ist ungleich ’0’, wahrend der Bus ein write-Kommando bearbeitet.

• sc_signal<int> monitor_burst_read: Ist ungleich ’0’, wahrend der Bus einenburst_read-Befehl ausfuhrt.

• sc_signal<int> monitor_burst_write: Ist ungleich ’0’ wahrend der Bearbei-tung eines burst_write-Kommandos.

So konnen wir uns auf einfache Weise einen grafischen Uberblick zur Auslastungdes On-Chip-Peripheral-Busses verschaffen. Schreiben Sie daruber hinaus die jewei-lige Zieladresse in Signale die monitor_read, monitor_write, usw. So ermoglichtdas Wave-Diagramm auch eine Analyse von Engpassen auf dem Bus, denn an Handder Slave-Adressen lasst sich ermitteln, welche Master-Module bei einer Kollision(monitor_busload ist dann großer als ’1’) gleichzeitig auf den Bus zugreifen .

Erweitern Sie Ihr opb_bus-Modul um die oben genannten Monitor-Signale und erstellenSie ein Wave-Diagramm Ihres Motion-Detection-Systems mit VISTA. Prufen Sie, ob dieabwechselnden Buszugriffe der beiden Master-Module korrekt erkannt werden konnen.

12

Abgabe

Geben Sie nach Bearbeitung aller drei Aufgabenteile ein lauffahiges Gesamtsystem ab,das Videodaten von der Kamera uber das OPB-Simulationsmodell in den Hauptspeicherschreibt. Diese sollen vom Display-Modul ausgelesen und mit Hilfe des YUV-Viewersdargestellt werden. Machen Sie das Kommunikationsverhalten Ihres Systems an Handeines Wave-Diagramms deutlich. Die Motion-Detection-Funktionalitat wird in dieserPraktikumsphase noch nicht in das SystemC-Modell ubertragen.

13

3. Phase: Hardware-Verfeinerung2 Wochen

In der vorherigen Phase haben wir die Zielplattform festgelegt und den Hauptspeicherdes XUP-Boards in das Systemmodell integriert. Nun sollen alle ubrigen Hardware-Komponenten des Motion-Detection-Systems verfeinert werden.

Hierzu legen wir zunachst eine Hardware-Software-Partitionierung fest: Alle Funktionenim Motion-Detection-System, die direkte Manipulationen an den Videodaten durchfuh-ren, werden wir in Hardware realisieren. So konnen wir den Prozessor fur andere Aufga-ben freihalten und eine garantierte Ausfuhrungsgeschwindigkeit (Frames pro Sekunde)gewahrleisten.

Die Bearbeitung der Videodaten ahnelt einer Pipelinestruktur:

Diff → Erosion → Dilation

Also liegt es Nahe, diese Module auch im FPGA uber direkte Punkt-zu-Punkt-Verbindungen zu koppeln. Hierzu konnen wir allerdings keine SHIP-Kanale einsetzenwie im High-Level-Modell. Im Gegensatz zu einer reinen Softwarelosung arbeiten wir inHardware mit getakteter Logik, die nur eine gewisse Anzahl an Rechenoperationen proTakt durchfuhren kann. Deswegen konnen wir nicht ein komplettes BINFrame in einemeinzigen Taktzyklus abarbeiten, die dafur notwendige kombinatorische Logik ware zuaufwendig.

Eine Losung ist die Zwischenspeicherung der BINFrame-Daten, wahrend Sie von einerPipelinestufe zur nachsten weitergegeben werden. Hierzu kommen zwei Moglichkeitenin Frage, die in den Bildern 3 und 4 gegenubergestellt werden. Wahrend in der oberenArchitektur alle Module uber den gemeinsam genutzten OPB an den Hauptspeicherangebunden sind, verwendet die zweite Losung schnelle BRAM-Speicher als Puffer zwi-schen den Berechnungsstufen der Videopipeline.

Die obere Architektur spart Hardware-Ressourcen, da der ohnehin im System vorhan-dene Hauptspeicher optimal ausgenutzt wird. Zugriffe auf diesen sind aber recht lang-sam, und der gemeinsam genutzte Bus wird evtl. zu stark ausgelastet. Die Pipeline-Architektur hingegen verspricht sehr hohe Frameraten, dafur benotigen wir aber eingroßeres FPGA, das die notwendige Menge an BRAM-Speicher auf dem Chip zur Ver-fugung stellt.

Aufgabe: Um beide Varianten miteinander vergleichen zu konnen, sollen Sie Ihr Kom-ponentenmodell in dieser Phase hinsichtlich beider in den Bildern 3 und 4 dargestelltenArchitekturen verfeinern. Schließen Sie fur die linke Variante alle Module uber geeigneteTransaktoren an Ihr Bus-Simulationsmodell an. Hierfur sind lediglich Anderungen imTop-Level-Modul notwendig!

Nutzen Sie fur die Realisierung der BRAM-Variante das SystemC-Modul BRAM aus demVerzeichnis /opt/cad/scprak/iplib, um die BRAM-Speicher in Ihr System zu inte-grieren (eine Beschreibung dieser Module finden Sie in Kapitel 4). Auch hier benotigenSie Transaktoren. Achten Sie darauf, dass diese fur den BRAM-Zugriff fur non-burst -Transfers konfiguriert werden mussen. Dazu steht Ihnen eine modifizierte Variante derbereits bekannten Transaktoren in der Datei shipmaster2opb_transactor_nb.h zurVerfugung.

14

Bild 3: Gemeinsame Nutzung des Hauptspeichers durch alle Systemkomponenten

Bild 4: Gemischte Bus- und Pipeline-Architektur

15

Lassen Sie anschließend die beiden verschiedenen Realisierungen gegeneinander antre-ten. Wie viele Frames pro Sekunden (FPS) konnen Sie maximal erreichen, bei 20 MHz,50 MHz und 100 MHz Systemtakt? (Achtung: Wir meinen naturlich simulierte FPS,d.h. die auf dem Zielsystem zu erwartenden FPS, und nicht die FPS, die Ihr Entwick-lungssystem wahrend der SystemC-Simulation auf dem Bildschirm erreicht).

Analysieren Sie außerdem besonders fur das Bus-basierte Modell, wie haufig Kollisionenauf dem OPB-Bus auftreten, in dem Sie mit VISTA Wave-Diagramme generieren.

Abgabe: Zwei vollstandige SystemC-Modelle fur die beiden beschriebenen Architektu-ren. Welche Performance erreichen Ihre Modelle bei einem Systemtakt von 20 MHz,50 MHz und 100 MHz? Welche Informationen konnen Sie aus Ihren OPB-Wave-Diagrammen gewinnen?

16

4. Phase: Software-Verfeinerung1 Woche

Bisher haben wir uns hauptsachlich mit der Hardware des Motion-Detection-Systemsbeschaftigt. Nun wollen wir uns der Software annehmen. Diese hat die Aufgabe, auf denvon der Hardware vorbereiteten Bilddaten die eigentliche Bewegungserkennung durch-zufuhren. Dazu muss das Ergebnis der letzten Video-Bearbeitungsstufe Dilation aufzusammenhangende Pixelregionen hin untersucht werden. Im ursprunglichen Spezifika-tionsmodell ubernimmt dies die Funktion morph::boundbox.

Im Hardware-Software-System soll diese Funktionalitat durch die Software realisiertwerden. Erstellen Sie hierzu ein neues SC_MODULE(Software), dass uber einen SHIP-Kanal mit dem DISPLAY-Modul in Verbindung steht:

Listing 5: Grundgerust des Software-Moduls

SC_MODULE(Software) {

sc_port<sc_ship_slave_if<BINFrame > > bf_in;

// hier folgen Konstruktor , Methoden , etc.

};

Der SHIP-Kanal am Eingangsport bf_in ubertragt das BINFrame, welches von demDilation-Algorithmus erzeugt wurde, an die Software. Die Software analysiert das erhal-tene Bild und berechnet eine Bounding-Box um den Bildbereich, in dem eine Bewegungerkannt wurde. Durch einen Aufruf der Funktion DISPLAY::drawBoundingBox kann dasberechnete Rechteck anschließend uber das Kamerabild gezeichnet werden.

Abgabe: SystemC-Modelle aus Phase 3 mit jeweils integriertem Software-Modul.

17

Letzte Phase: Hardware/Software-Integration und Test amFPGA-Prototyp2 Wochen

Bisher haben Sie sich ausfuhrlich mit der Frage beschaftigt, wie eine optimale Realisie-rung des Hardware/Software-Systems auf der Virtex-II-Pro-Architektur aussehen konn-te, und Sie haben das Spezifikationsmodell in eine hardwarenahe SystemC-Beschreibungverfeinert. Nun ist der Zeitpunkt gekommen, einen

”echten“ Prototyp des Gesamtsystems

zu erstellen. Dazu setzen wir das moderne Prototypenssytem XUP ein, das in Kapitel 5beschrieben ist.

Eine Logiksynthese Ihres SystemC-Modells fur das Virtex-II-Pro-FPGA mochten wirIhnen allerdings nicht zumuten, da diese bei dem Video-basierten System zur Bewe-gungserkennung einige zusatzliche Erfahrung im Umgang mit dem Zielsystem erfordert,da wir hier nicht nur das FPGA selbst, sondern auch diverse an das FPGA angeschlos-sene externe Hardwarebausteinen wie z.B. die Video-Ein- und -Ausgabe programmierenmussen. Deshalb stellen Ihnen ein fertiges synthetisierbares Hardwaresystem zur Verfu-gung. Es entspricht im Aufbau genau Ihrem Pipeline-Modell mit BRAM-Speicher ausPhase 3.

Samtliche Quellen dieses Systems liegen in Verilog vor, die wir zum Teil aus einemSystemC-Modell (vermutlich ahnlich dem Ihren) generiert haben.

Ihre Aufgabe ist es nun, die Software aus Phase 4 in dieses System zu integrieren, umdas Hardware/Software-Gesamtsystem anschließend auf dem XUP-Prototypensystemmit einer Videokamera als Bildquelle und einem VGA-Monitor als Display testen zukonnen. Lesen Sie dazu unbedingt das Kapitel 5 uber das XUP-Prototypenboard, fallsSie es noch nicht getan haben, und folgen Sie anschließend den Anweisungen in Kapitel 6,um einen Bitstrom fur das FPGA zu synthetisieren und den Prototyp in Betrieb zunehmen.

Auf dem an das XUP angeschlossenen Monitor konnen Sie anschließend das Kamerabildund die verschiedenen BINFrames als Ergebnis der Motion-Pipeline-Stufen in Echtzeitbetrachten. Ubertragen Sie nun Ihr Softwaremodul aus Phase 4 in ein C-Programm, dasauf dem PowerPC-Prozessor des Virtex-II-Pro ausgefuhrt werden kann. Integrieren undKompilieren Sie Ihr Programm mit Hilfe der Anweisungen aus Kapitel 6

Die SystemC-Befehle konnen Sie auf dem Zielsystem nicht mehr benutzen. Stattdessenfugen Sie geeignete Passagen Ihres Quellcodes in das Programm detect_motion.c ein.Dieses Programm enthalt die Methode boundingBox, welche durch einen Hardware-Interrupt jedesmal aufgerufen wird, wenn die Video-Pipeline im FPGA einen neuenFrame abgearbeitet hat. Dies geschieht 50 mal pro Sekunde.

Fur die Kommunikation mit der Hardware stehen Ihnen die folgenden Funktionen zurVerfugung:

void drawBox(Xuint8 x1, Xuint8 y1, Xuint8 x2, Xuint8 y2): Zeichnet ein Rechteckuber das aktuelle Videobild. Die Koordinaten bestimmen die linke obere und dierechte untere Ecke des Rechtecks, wobei der BINFrame-Maßstab zugrunde gelegt

18

wird. D.h. die moglichen X-Koordinaten liegen zwischen 0 und 80, die moglichenY-Koordinaten zwischen 0 und 60. Die Funktion skaliert diese Werte automatischauf die tatsachlich benotigten Koordinaten hoch.

Xuint8 getPixel(Xuint8 x, Xuint8 y): Gibt den Wert des BINFrame-Pixels an der Po-sition (x,y) zuruck. Es handelt dabei jeweils um den letzten BINFrame, der vonder Video-Pipeline ausgegeben wurde. Die Werte werden uber die DSOCM-Schnittstelle des PowerPC-Prozessors aus BRAM-Speicher auf dem FPGA aus-gelesen.

Abgabe: Vollstandiges XPS-Projekt mit Software-basierter Bounding-Box-Generierung. Demonstrieren Sie Ihr Hardware-Software-System auf dem FPGA-BoardXUP.

19

2 Das SystemC High-level Protocol SHIP

Das SystemC High-Level Protocol (SHIP) ist ein leichtgewichtiges Kommunikations-protokoll zur transaktionsbasierten Modellierung von gerichteten Punkt-zu-Punkt-Verbindungen mit SystemC. SHIP wurde speziell fur den Top-Down-Systementwurfmit Transaction-Level-Modeling (TLM) entwickelt und ermoglicht die Beschreibung vonKommunikationsbeziehungen zwischen Systemkomponenten auf einer Abstraktionsebe-ne, die vollig unabhangig von ihrer spateren Realisierung als Hardware oder Softwareist.

Bild 5: SHIP-basiertes Komponentenmodell einer DVB-Set-Top-Box

Bild 5 skizziert eine mit SHIP-Kanalen modellierte DVB-Set-Top-Box. Das dargestellteKomponentenmodell des Systems befindet sich auf einer Abstraktionsebene, die nochnichts uber die spatere Hardware/Software-Partitionierung aussagt. Allerdings wurdebereits eine funktionale Partitionierung sowie eine Orthogonalisierung in die zwei Do-manen Kommunikation und Verhalten vorgenommen. Dies ist die Grundvoraussetzungfur Transaction-Level-Modeling mit SHIP.

Das SHIP-Framework gliedert sich in den SHIP-Channel, das Serializable-Interface

und ein Master- und ein Slave-Interface. Außerdem bietet das Framework verschiedeneWrapper, die SHIP-Kanale mit anderen TLM-Kanalen verbinden, indem sie das SHIP-Protokoll auf das jeweilige andere Protokoll umsetzen. Das im folgenden Abschnitt be-schriebene Serializable-Interface ermoglicht daruber hinaus die direkte Abbildung vonSHIP-Kanalen auf hardwarenahe RTL-Signale durch Transaktoren.

2.1 SHIP-Objekte und das SHIP-Serializable-Interface

Bei der Modellierung mit SHIP werden Systemkomponenten wie in Bild 5 uber SHIP-Kanale miteinander verbunden. Uber diese Kanale konnen beliebige C++-Objektetransportiert werden, die das ship_serializable_if-Interface implementieren. DieseObjekte werden im Folgenden SHIP-Objekte genannt.

Mit Hilfe der in Listing 6 gezeigten Interface-Methoden definiert der Entwickler, welchein einem SHIP-Objekt enthaltenen Daten fur die Kommunikationsbeziehung zwischen

21

zwei Systemkomponenten relevant sind und wie ihre komplexen Datenstrukturen ineinen seriellen Datenstrom (und wieder zuruck) gewandelt werden.

Listing 6: Das SHIP-Serializable-Interface

class ship_serializable_if

{

/// Serialize the content of a SHIP -object

virtual sc_uint <64>* serialize()=0;

/// Deserialize a data stream into a SHIP -object

virtual unsigned int deserialize(sc_uint <64>* values,

unsigned int length)=0;

/// Return the length of the serialized data stream

virtual unsigned int getSerialLength()=0;

};

Durch Aufruf dieser Methoden konnen Wrapper automatisch zwischen den transakti-onsbasierten SHIP-Kanalen und anderen Kommunikationsarchitekturen vermitteln. Umdiese Funktionalitat zu gewahrleisten, muss das ship_serializable_if-Interface vonjedem SHIP-Objekt implementiert werden.

Die Implementierung der serialize-Methode muss samtliche Datenstrukturen desSHIP-Objekts in ein Feld von 64 Bit breiten sc_uint<64> transformieren. Dieseskann anschließend uber jeden beliebigen Kommunikationskanal ubertragen werden. Diedeserialize-Methode ermoglicht den umgekehrten Weg, in dem sie ein empfangenessc_uint<64>-Datenfeld ubergeben bekommt. Ihre Implementierung muss den Inhaltdieses Datenfelds wieder in die SHIP-Objekt-spezifischen Datenstrukturen zuruck trans-formieren.

2.2 Der SHIP-Channel

Bild 6: Strukturmodell und abstrakte Darstellung des SHIP-Channel

Der SHIP-Channel ist ein gerichteter nachrichtenorientierter Kommunikationskanal zurUbertragung von SHIP-Objekten zwischen zwei Systemkomponenten. Der Zugriff aufden Kanal erfolgt mit vier Kommunikationsprimitiven:

send(ship obj data): Die send-Methode sendet ein beliebiges SHIP-Objekt uber denSHIP-Channel an den Kommunikationspartner. Der Methodenaufruf ist blockend,

22

d.h. die Methode kehrt erst zuruck, wenn das SHIP-Objekt vollstandig ubertragenwurde.

recv(ship obj& obj): Mit der recv-Methode wird ein mittels send ubertragenes SHIP-Objekt von der Gegenseite empfangen. Die Methode ist blockend und kehrt erstzuruck, wenn eine vollstandige Transaktion stattgefunden hat.

request(ship obj& data): Mit Hilfe der request-Methode kann die Ubertragung ei-nes SHIP-Objekts vom Kommunikationspartner angefordert werden. Die Methodeblockiert so lange, bis das angeforderte Objekt vollstandig empfangen wurde.

reply(ship obj obj): Der Aufruf der reply-Methode ist die Antwort auf ein request

von der Gegenseite und sendet ein SHIP-Objekt an den Kommunikationspartner,der die Transaktion initiiert hat. Wie send ist diese Methode blockend.

Systemkomponenten, die ausschließlich die Kommunikationsprimitive send und request

verwenden, stellen implizit einen SHIP-Master dar. Werden dagegen ausschließlich dieMethoden recv und reply benutzt, handelt es sich um einen SHIP-Slave. Wenn vomProgrammierer konsequent angewandt, erlaubt dies die automatische Erkennung vonBus-Master- und Bus-Slave-Ports bei einer spateren Kommunikationsverfeinerung durchein Entwurfswerkzeug. Um ihre Master- bzw. Slave-Zugehorigkeit auch in der Implemen-tierung widerzuspiegeln, teilen sich die Kommunikationsprimituve auf zwei Interfacesauf: ship_master_if und ship_slave_if.

Bild 6 zeigt die Struktur des SHIP-Channels mit den beiden Interfaces an den Endpunk-ten und die abstraktere Darstellung durch einen gerichteten Pfeil.

2.3 Der SHIP-Master-Port

Listing 7 demonstriert die Instantiierung von SHIP-Master-Ports. Der Zugriff auf diePorts wird durch den SC_THREAD process_data demonstriert, welcher hier der Ein-fachheit halber direkt im SC_MODULE implementiert wird. Die Methode process_data

fordert kontinuierlich Daten uber den masterport_a an und sendet die empfangenenDaten anschließend an den masterport_b. Beide Ports werden fur die Ubertragung vonObjekten des Typs my_object konfiguriert.

Listing 7: Instantiierung von SHIP-Master-Ports

#include "ship_master_if.h" // SHIP master interface

#include "MyObject.h" // ...implements ship_serializable_if

SC_MODULE(MyMaster)

{

// two ship masterports which transfer MyObjects

sc_port<ship_master_if <MyObject > > masterport_a;

sc_port<ship_master_if <MyObject > > masterport_b;

SC_CTOR(MyMaster) {

SC_THREAD(process_data);

}

23

protected:

// send data to the ship_slave

void process_data() {

MyObject data;

while(true) {

masterport_a->request(data);

masterport_b->send(data);

}

}

};

Das Beispiel zeigt, dass Zugriffe auf SHIP-Master-Ports willkurlich und an beliebi-ger Stelle erfolgen konnen. Aus diesem Grund werden SHIP-Master-Ports als aktive

Ports bezeichnet. SystemC-Module, die ausschließlich SHIP-Master-Ports verwenden,sind SHIP-Master. Um den Quelltext ubersichtlich und wartbar zu gestalten, sollte aufjeden Master-Port nur in einem einzigen SC_THREAD zugegeriffen werden.

2.4 Der SHIP-Slave-Port

Im Gegensatz zu SHIP-Master-Ports ist der SHIP-Slave-Port ein passiver Port. Zugriffenauf einen SHIP-Slave-Port geht immer eine initiierende Aktion des SHIP-Master-Portsam anderen Ende des SHIP-Channels voraus. Der Prozess, der den SHIP-Slave-Portbedient, muss daher stets mit Hilfe der Methode waitEvent auf die Auslosung einesEreignisses durch den Master warten, bevor er selbst auf den SHIP-Channel zugreifendarf. Dies wird in Listing 8 demonstriert.

Listing 8: Instantiierung von SHIP-Slave-Ports

#include "ship_slave_if.h" // SHIP slave interface

#include "Mybject.h" // ... implements ship_serializable_if

SC_MODULE(MySlave)

{

// ship slaveport which transfers instances of class MyObject

sc_port<ship_slave_if<MyObject > > slaveport_a;

SC_CTOR(MySlave) {

SC_THREAD(handle_requests);

}

protected:

// handle master requests

void handle_requests() {

MyObject data;

ship_command comm;

while(true) {

comm = slaveport ->waitEvent(); // wait for action

switch(comm.cmd) { // analyze master command

case SHIP_REQUEST: // master requests data

slaveport ->reply(data);

24

break;

case SHIP_SEND: // master sends data

slaveport ->recv(data);

break;

default:

TRACE("Error. Unknown SHIP command %d\n", comm.cmd);

}

}

}

};

2.5 Implementierungsregeln und Besonderheiten

Obgleich wir das SystemC-High-level-Interface-Protocol SHIP als high-level bezeichnen,ist dessen Implementierung ziemlich low-level. Das Protokoll wurde entwickelt, um Kom-munikationsbeziehungen in TLM-Modellen mit SystemC einfach und dennoch aussage-kraftig auf hochster Abstraktionsebene modellieren zu konnen. Primares Ziel ist hierbeieine maximale Simulationsgeschwindigkeit.

Der SHIP-Channel implementiert keine Maßnahmen zur Fehlererkennung und es exi-stieren keine Timeouts zum Abbruch einer blockenden Kommunikation im Fehler-fall (z.B. Ausbleiben des reply nach einem request). Werden fehlerkorrigieren-de Maßnahmen benotigt, mussen diese durch zusatzliche Protokolle von den SHIP-Kommunikationspartnern selbst implementiert werden.

Auch Implementierungsfehler, die durch unsachgemaße Anwendung des SHIP-Frameworks entstehen, werden nur zu einem gewissen Teil erkannt und abgefangen.Halten Sie sich daher stets an die in den vorherigen Abschnitten erlauterten Implemen-tierungsregeln, um ein Design zu erhalten, dass sich Ihren Vorstellungen entsprechendverhalt.

25

3 On-Chip Peripheral Bus

3.1 IBM CoreConnect

CoreConnect ist eine von IBM entwickelte Busarchitektur fur die Integration vonProzessor-, System- und Peripheriekernen in System-on-Chip-Designs. CoreConnectwurde als skalierbare Architektur entwickelt, die leicht an die Anforderungen kundenspe-zifischer Designs angepasst werden kann und dennoch auf standardisierten Schnittstellenbasiert.

Bild 7: IBM CoreConnect Busarchitektur

Die tragenden Elemente der in Bild 7 dargestellten Architektur sind der Processor Lo-

cal Bus (PLB), der On-Chip Peripheral Bus (OPB) und der Device Control Register

Bus (DCR). Der PLB ist ein High-Performance-Bus mit bis zu 256 Bit Bandbreite undgetrennten Datenbusleitungen fur jeden Bus-Master, was uberlappende Bustransfers er-laubt, aber auch enorme Verdrahtungsressourcen benotigt. Er ist vornehmlich fur dieKopplung von Prozessorkernen mit dem Hauptspeicher gedacht.

Peripheriekomponenten mit geringerem Kommunikationsbedarf werden uber den OPBangebunden. Wie beim PLB handelt es sich um einen vollsynchronen Bus, der allerdingsnur maximal 64 Bit Bandbreite und ein gemeinsam genutztes Medium zur Verfugungstellt. PLB und OPB unterstutzen mehrere Bus-Master und konnen uber eine Bus-Bridge verbunden werden.

3.2 OPB-Architektur

Bild 8 zeigt eine typische physikalische Implementierung des OPB und gibt einen Uber-blick zu den OPB-Signalen. Die von allen Bus-Masters und Bus-Slaves gemeinsam ge-nutzten Daten- und Adressbusleitungen werden verodert und bilden einen verteiltenMultiplexer. Der Zugriff mehrerer Bus-Master wird durch einen Arbiter kontrolliert, derzu allen Bus-Masters Signalleitungen unterhalt.

26

Bild 8: Physikalische Implementierung des OPB

27

3.3 OPB-Operationen

In diesem Abschnitt wird die Arbeitsweise des OPB bei normalen Schreib- und Lese-zugriffen von Bus-Master- auf Bus-Slave-Module erlautert. Wir beschranken uns dabeiauf eine leichtgewichtige OPB-Implementierung mit den folgenden Eigenschaften:

• Daten- und Adressbus sind 32 Bit breit,

• es werden ausschließlich Einzelwort- und Burst-Transfers unterstutzt,

• konkurrierende Zugriffe werden nach dem Round-Robin-Schema bearbeitet.

Den gesamten Prozess eines Buszugriffs von der Anfrage bis zum abgeschlossenen Da-tentransfer nennen wir Transaktion.

3.3.1 Arbitrierung

Der Zugriff auf den OPB wird durch einen Arbiter kontrolliert. Dieser regelt die Bus-Benutzung aller an den OPB angeschlossenen Bus-Master nach dem folgendem Proto-koll:

1. Ein Bus-Master kundigt einen Buszugriff an.

2. Der OPB-Arbiter gewahrt den Zugriff, wenn der Bus frei ist. Melden mehrere Bus-Master gleichzeitig ihr Interesse an, wird nach dem Round-Robin-Schema verfah-ren.

Die Arbitrierung nimmt einen Taktzyklus in Anspruch.

3.3.2 Datenubertragung

Die Datenubertragung uber den On-Chip Peripheral Bus ist in zwei Betriebsmodi mog-lich: Einzelwort-Ubertragung und Burst-Transfer. Bei der Einzelwort-Ubertragung wirdgenau ein 32-Bit-Wort uber den Bus versendet. Burst-Transfers ermoglichen die sequen-tielle Ubertragung von beliebig großen Datenmengen, wobei der Bus uber die gesamteDauer des Transfers durch den initiierenden Bus-Master blockiert ist.

Bild 9 zeigt das Timing einer Einzelwort-Ubertragung. In Takt 2 kundigt der Bus-Master M1 einen Buszugriff an. Nachdem der Arbiter den Buszugriff gewahrt hat, legtM1 in Takt 3 die Zieladresse auf die Adressleitungen. Der angesprochene Bus-Slave S2reagiert innerhalb zwei Taktzyklen und legt in Takt 4 das angeforderte Datum auf die32 Datenleitungen. Im funften Takt wird die Transaktion abgeschlossen. Durch einenlangsameren Slave kann die Transaktion in die Lange gezogen, durch einen schnellerenverkurzt werden.

Da die Arbitrierung fur jede Einzelwort-Ubertragung durchgefuhrt wird, ist der erreich-bare Durchsatz bei großeren Datenmengen recht unbefriedigend. Abhilfe schafft ein Bus-

Lock -Mechanismus, der einen exklusiven Buszugriff erlaubt, so dass Daten kontinuier-lich als Burst ubertragen werden konnen. Das entsprechende Timing-Diagramm zeigtBild 10.

28

Bild 9: OPB Einzelwort-Ubertragung

Bild 10: OPB Burst-Transfer

29

Auch beim Burst-Transfer dauert die Arbitrierung einen Taktzyklus. Anschließend wirddie Zieladresse durch den zugreifenden Bus-Master M1 aber kontinuierlich inkremen-tiert. Der Kommunikationspartner S3 hat in diesem Beispiel eine Latenz von nur einemTaktzyklus, so dass pro Takt ein Datum ubertragen werden kann. Beachten Sie ubrigensden Bus-Master M2, der ebenfalls in Takt 0 um die Gunst des Buszugriffs wirbt, nachdem Round-Robin-Schema aber erst in Takt 5 Beachtung findet.

3.3.3 Fehlerbehandlung

Fehlerhaftes Verhalten von Bus-Slaves im Einzelwort-Betrieb und nicht korrekt beendeteBurst-Transfers konnen zu einem Deadlock auf dem On-Chip Peripheral Bus fuhren. Umdies zu Verhindern, konnen verschiedene Timeout-Mechanismen und eine Begrenzungder maximalen Burst-Lange eingesetzt werden. Entsprechende Verfahren werden in derOPB-Spezifikation ausfuhrlich diskutiert, sollen aber in diesem Praktikum vernachlassigtwerden.

3.3.4 Und daruber hinaus?

Durch die standig steigende Integrationsdichte im System-on-Chip-Bereich wirkt sich dieQualitat der verwendeten Kommunikationsarchitektur immer starker auf die Gesamtper-formance des Systems aus. Aus diesem Grund werden die eingesetzten On-Chip-Bussefortlaufend um neue Fahigkeiten erweitert, die zu immer komplizierten Kommunikati-onsprotokollen fuhren. Der OPB ist hier noch ein eher genugsamer Vertreter. Einigeweiterfuhrende Eigenschaften des OPB, die wir in diesem Praktikum aber nicht weiterbetrachten wollen, sind zum Beispiel:

• Prioritatengesteuertes Scheduling : Bus-Master mit hoherer Prioritat werden vomArbiter bevorzugt behandelt.

• Uberlappende Transfers: Mehrere Bus-Master greifen parallel auf verschiedeneBus-Slaves zu. Dabei werden die Prioritaten in das Scheduling mit einbezogen.

• DMA-Transfers: Von einem DMA-Controller gesteuerte Datenubertragung zwi-schen zwei Bus-Slaves, z.B. von einem Peripheriegerat in den Hauptspeicher (Di-rect Memory Access).

• Dynamic Bus Sizing : Bus-Master und -Slaves konnen unterschiedliche Bandbreitenvon 8, 16, 32 oder 64 Bit implementieren.

30

4 IP-Bibliothek

Dieser Abschnitt enthalt Datenblatter fur Intellectual-Property-Komponenten, die Ihnenfur die Bewaltigung der Praktikumsaufgaben zur Verfugung stehen.

4.1 DDR-RAM

Beschreibung

Das SystemC-Modul ddr_ram ist ein High-Level-Simulationsmodell fur Double-Data-

Rate-Speichermodule. Es simuliert Verhalten und Timing des auf dem ML310 verwen-deten DDR-RAM-Controllers. Ein 32-Bit-Schreibzugriff auf das DDR-RAM dauert inder Regel 7 Taktzyklen, ein 32-Bit-Lesezugriff 11 Taktzyklen. Diese Latenzen leiten sichaus den in Bild 11 und Bild 12 dargestellten Messungen ab.

Schnittstelle

Das ddr_ram-Modul implementiert samtliche Methoden des opb_slave_if-Interfaces:


{

public:





/// Do a burst read from a slave

virtual bool burst_read(sc_uint <32> *data , unsigned int addr,


/// Do a burst write to a slave

virtual bool burst_write(sc_uint <32> *data , unsigned int addr ,






};

Die Adressierung erfolgt mit einem 32-Bit-Wert, so dass maximal 4 GB RAM angespro-chen werden konnen.

Parameter

Bei der Instantiierung des ddr_ram-Moduls konnen die Parameter Speichergroße, Start-adresse und Taktrate konfiguriert werden:

31

Bild 11: OPB-Schreibzugriff auf das DDR-RAM des ML310

Bild 12: OPB-Lesezugriff auf das DDR-RAM des ML31032

ddr ram(sc module name name, uint size, uint clock, uint startaddr):Instantiierung eines DDR-RAM-Simulationsmoduls mit Speichergroße size

in MB, Taktrate clock in MHz und Startadresse startaddr. Die Speichergroßemuss ein Vielfaches von 16 MB sein.

4.2 BlockRAM

Beschreibung

Das SystemC-Modul blockram simuliert das Verhalten von SelectRAM-Blocken derVirtex-II FPGA-Familie auf einer hohen Abstraktionsebene. Diese schnellen RAM-Blocke stehen auf allen Virtex-II-Typen zur Verfugung und bieten je 18 KBit RAM-Speicher, auf den uber eine 32 Bit breite Schnittstelle innerhalb eines Taktzyklusschreibend und lesend zugegriffen werden kann. Bild 13 zeigt die RTL-Schnittstelle derSelectRAM-Blocke. Diese wird durch das SystemC-Modul BRAM zum opb_slave_if-Interface abstrahiert, um einen einfachereren Zugriff auf die Speicherzellen zu ermogli-chen.

Bild 13: RTL-Schnittstelle von Virtex-II Block-SelectRAM

Schnittstelle

Das BRAM-Modul implementiert das opb_slave_if-Interface, wobei nur die Methodenread und write unterstutzt werden. Burst-Transfers (d.h. die Ubertragung von mehrals 32 Bit in einem Zugriff) sind nicht moglich.

Pro BRAM-Instanz konnen maximal 18 KBit SelectRAM angesprochen werden. Bei jedemZugriff werden 32 Bit ubertragen, so dass die Adresse bei sequentiellem Schreiben undLesen nach jedem Zugriff um 4 inkrementiert werden muss.

33

Listing 9: OPB-Schnittstelle des BRAM-Blocks


{

public:









};

Parameter

Bei der Instantiierung des BRAM-Moduls konnen die Parameter Startadresse und Taktratekonfiguriert werden:

blockram(sc module name name, unsigned int clock, unsigned int startaddr):Instantiierung eines Block-SelectRAM-Simulationsmoduls mit 18 KBit Speicher-große, Taktrate clock in MHz und Startadresse startaddr.

4.3 SHIP-Master-to-OPB-Transactor

Beschreibung

Der shipmaster2opb_transactor ist ein spezieller SHIP-Kanal, der einen SHIP-Masterport mit einem OPB-Masterport verbindet (Bild 14). Da hier TLM-Transaktionen auf die RTL-Welt abgebildet werden, wird der Adapter auch als Trans-

aktor bezeichnet. Mit Hilfe des Transaktors kann ein SHIP-Master ohne Anderungenam Quelltext als OPB-Master fungieren. Die hierzu notwendige Datentransformati-on geschieht fur beide Seiten transparent durch Einsatz der ship_serializable_if-Methoden serialize und deserialize.

Da SHIP-Objekte in der Regel mehr als nur 32 Bit Daten enthalten, wird der vonder serialize-Methode ausgegebene Datenstrom als OPB-Burst-Transfer gesendet,um eine moglichst effiziente Datenubertragung zu gewahrleisten. Sollte dies nicht ge-wunscht werden, etwa weil das Zielmodul keine Burst-Transfers unterstutzt (z.B. beider BlockRAM-Implementierung aus dem vorherigen Abschnitt der Fall), kann der mo-difizierte Non-Burst -Transaktor shipmaster2opb_transactor_nb verwendet werden.Dieser implementiert das selbe Interface wie der Burst-Transaktor und wird deshalb imFolgenden nicht separat erwahnt.

34

Schnittstelle

Der shipmaster2opb_transactor implementiert das ship_master_if-Interface. Eskonnen alle C++-Objekte ubertragen werden, die das ship_serializable_if-Interfaceimplementieren.

Listing 10: SHIP-Schnittstelle des shipmaster2opb-Transaktors

template <class T>

class ship_master_if : virtual public sc_interface

{

public:

/// Send a SHIP -object to a slave

virtual void send(T obj ) = 0;

/// Request a SHIP -object from a slave

virtual void request(T& obj) = 0;

};

Bild 14: SHIP-Master-to-OPB-Transactor

Parameter

Bei der Instantiierung des SHIP-Master-to-OPB-Transaktors muss die OPB-Zieladressekonfiguriert werden. Folgender Konstruktor steht zur Verfugung:

shipmaster2opb transactor(sc module name name, unsigned int addr):Konstruktor zur Instantiierung eines SHIP-Master-to-OPB-Slave-Transaktorsmit der OPB-Zieladresse addr. Alle Zugriffe auf den Transaktor werden an dieangegebene OPB-Adresse weitergeleitet.

Beispiel

Listing 11 demonstriert die Anwendung des SHIP-Master-to-OPB-Transactor an einemBeispielsystem. Das resultierende Komponentenmodell zeigt Bild 15.

Listing 11: Beispielanwendung des SHIP-Master-to-OPB-Transactor

#include "systemc.h"

#include "opb_bus.h"

#include "shipmaster2opb_transactor.h"

35

#include "yuvframe.h"

#include "camera.h"

#include "ddr_ram.h"

int sc_main(int argc , char *argv[]) {

// create the OPB bus simulation model

opb_bus *bus = new opb_bus("OPB");

// create a DDR_RAM instance

ddr_ram *ram = new ddr_ram("Memory");

// connect the DDR_RAM to an OPB slave port

bus ->slave_port(ram);

// create a CAMERA instance

camera *cam = new camera("Camera");

// create a SHIP -Master-to-OPB -Transactor channel

// which transports YUVFrame ship -objects

// for OPB slave target address 0x100

shipmaster2opb_transactor <YUVFrame > * transactor =

new shipmaster2opb_transactor <YUVFrame >("SHIP2OPB" , 0x100);

// connect the CAMERA to the OPB by using the transactor

cam ->out_port(transactor);

transactor ->opb_port(transactor);

// start the simulation

sc_start();

return EXIT_SUCCESS;

}

Die Klasse YUVFrame implementiert das ship_serializable_if-Interface und repra-sentiert Objekte, die Einzelbilder im YUV-Farbraum enthalten, wie sie typischerweisevon Videokameras geliefert werden. Das SystemC-Modul camera stellt solche YUVFrame-Objekte an seinem SHIP-Masterport out_port zur Verfugung.

Das Modul opb_bus ist ein Simulationsmodell fur den On-Chip-Peripheral-Bus undimplementiert die Interfaces opb_blocking_if und opb_slave_if. Das Modul ddr_ramsimuliert RAM-Speicher und implementiert das opb_slave_if-Interface.

36

Bild 15: Beispiel zur Anwendung des SHIP-Master-to-OPB-Transactor

37

5 XUP und Virtex-II-Pro

5.1 Die Hardware-Software-Entwicklungsplattform XUP

Bild 16: XUP-Prototypensystem mit Virtex-II-Pro FPGA

Das XUP (Bild 16) ist eine vielseitige Plattform fur die schnelle Prototypen-Entwicklungkomplexer eingebetteter Hardware/Software-Systeme. Das Herz des Systems ist ein re-konfigurierbarer Logikbaustein vom Typ Virtex-II-Pro. Diese FPGA-Serie wurde Ende2002 von der Firma Xilinx auf den Markt gebracht und bietet zum ersten Mal vollstan-dig integrierte Prozessorkerne, hier vom Typ IBM PowerPC 405, die von einem großenrekonfigurierbaren Gate-Array umgeben sind. Auch anspruchsvolle Multi-Processor-on-

Chip-Systeme (MPSoC) mit bis zu 8 Millionen Transistoren und zwei vollwertigen 32-Bit-Prozessoren und konnen auf diese Weise erstmals in einem einzigen FPGA realisiertund mit bis zu 500 MHz Taktrate betrieben werden.

39

Uber den Funktionsumfang des Virtex-II-Pro hinaus bietet das XUP-Prototypensystemeine umfangreiche Ausstattung fur die Entwicklung moderner eingebetteter Multimedia-Systeme. Ein- und Ausgabeschnittstellen umfassen Ethernet, USB, Multi-Gigabit-Transceiver, 256 MB DDR-RAM, CompactFlash, Video Ein- und Ausgabe sowie einenAudio-Controller. Externe Hardware kann uber Erweiterungsstecker an das FPGA ange-schlossen werden. Bild 17 zeigt ein Blockdiagramm der wichtigsten XUP-Komponenten.

Bild 17: XUP Blockdiagramm

In der Abteilung E.I.S. werden das XUP und verwandte Boards intensiv eingesetzt. AlsBetriebssystem verwenden wir u.a. eine fur PowerPC angepasste Linux-Variante.

5.2 Die Virtex-II-Pro FPGA-Familie

Die FPGAs der Virtex-II-Pro-Familie ermoglichen erstmals die Implementierung vonSystem-on-Chip-Designs mit bis zu zwei vollstandig integrierten Prozessorkernen, wo-bei das gesamte System mit bis zu 450 MHz Taktrate betrieben werden kann. Da essich bei den beiden PowerPC-405-CPUs um ausgereifte 32 Bit RISC-Prozessoren han-delt, ist Virtex-II-Pro eine der zur Zeit modernsten, vielseitigsten und interessantestenFPGA-Architekturen fur die Entwicklung komplexer eingebetteter Hardware/Software-Systeme.

Tabelle 1 zeigt die wichtigsten technischen Daten der erhaltlichen Virtex-II-Pro-FPGAs.Bild 18 zeigt ihre generelle Architektur. Wie alle Xilinx-FPGAs basieren auch Virtex-II-Pro-FPGAs auf rekonfigurierbaren Logikblocken, den Complex Logic Blocks (CLB).Diese gliedern sich in vier gleiche Slices und eine Switch-Matrix. Jedes Slice bestehtaus zwei Halften mit je einer programmierbaren Look-Up-Table (LUT), die auch alsSchieberegister (SRL) oder SelectRAM verwendet werden kann, und einem Flip-Flop.Die Konfiguration des FPGA wird in SRAM-Zellen gehalten und kann beliebig oft neuprogrammiert werden.

40

Bild 18: Architektur von Virtex-II-Pro FPGAs

41

Tabelle 1: Virtex-II-Pro FPGA Familienmitglieder

Neben den feingranularen Slices bieten Virtex-II-Pro-FPGAs auch Makroblocke furschnelle 18x18-Bit-Multiplikationen und bis zu 8 Mbit integrierten SRAM-Speicher(Block-SelectRAM ). Fur Verbindungen mit der Außenwelt stehen u.a. RocketIO -Transceiver fur serielle Ubertragungen mit 3,125 GBit/s und maximal 1.104 frei pro-grammierbare I/O-Pins zur Verfugung. Die Entwicklung von Systems-on-Chip mit un-terschiedlichen Clock-Domanen wird durch bis zu 12 digitale Clock-Manager (DCM)unterstutzt.

Bild 19: In das FPGA eingebetteter PowerPC-Prozessor

Wahrend die CLB-Architektur im Vergleich zu alteren FPGA-Familien bis auf einigeFeinheiten gleich geblieben ist, koppeln die integrierten PowerPC-Prozessoren erstmals

42

fest in Silizium gegossenen 32-Bit-CPUs mit rekonfigurierbarer Logik auf einem Chip.Bild 19 skizziert diese Prozessor-Einbettung (sog. immersion). Hervorzuheben ist be-sonders die Moglichkeit, die PowerPC-Kerne direkt mit BlockRAM auf dem FPGA zuverbinden, wodurch eine Datentransferrate von bis zu 8,94 GBit/s zwischen dem Prozes-sor und anwendungsspezifischer Logik moglich sind. In Verbindung mit den 18x18-Bit-Multiplikator-Blocken konnen so Rechengeschwindigkeiten erreicht werden, die bisherder Domane der digitalen Signalprozessoren (DSP) vorbehalten waren.

Fur die Verbindung der PowerPC-Prozessoren mit den anderen Systemkomponenten undinsbesondere dem Hauptspeicher ist der Processor Local Bus (PLB) zustandig. Er istTeil der standardisierten IBM CoreConnect -Architektur, die in Abschnitt 3 beschriebenwird. Auf dem XUP wird der PLB mit 64-Bit Datenbreite und 100 MHz Taktratebetrieben. Somit konnen die Prozessorkerne im Idealfall mit knapp 5,9 GBit/s auf denHauptspeicher zugreifen.

43

6 Einfuhrung in Xilinx Platform Studio 8.1

Nachdem die Verfeinerungen von Hard- und Softwaremodulen in SystemC abgeschlos-sen sind, erfolgt der Ubergang zur Hardware-Software-Integration. Dabei setzen wir dasXUP-Prototypensystem aus Kapitel 5 ein, um die Hardware-Module auf dem Virtex-II-Pro FPGA zu testen und die Software-Module auf den eingebetteten PowerPC-405-Prozessoren laufen zu lassen. Sowohl Hardware als auch Software mussen dazu in eineauf das XUP-System hochladbare Darstellung ubersetzt werden. Fur die Hardware ver-wenden wir hierzu ein Werkzeug zur Logiksynthese, fur die Software einen so genanntenCross-Compiler.

An der Abteilung E.I.S. verwenden wir fur diese Schritte das Tool XPS (Xilinx PlatformStudio). Dieses Kapitel gibt Ihnen einen kurzen Uberblick zu XPS und soll Sie wahrendder Phase 5 des Praktikums begleiten. Wir beschreiben dabei absichtlich nur diejenigenProgrammteile, die Sie fur die Bearbeitung der Praktikumsaufgabe benotigen. Mit denunzahligen weiteren Funktionen von XPS mochten wir Sie hier nicht weiter belastigen. . .

Hinweis: Im Folgenden werden Bilder mit Hilfe farbiger Markierungen erlautert. Ausdiesem Grund empfiehlt es sich, die folgenden Seiten direkt im pdf zu betrachten oderfarbig auszudrucken.

6.1 Der Start

Im Gegensatz zu allen anderen Werkzeugen zum Chip- und Systementwurf arbeitetXPS in der aktuellen Version besser unter Windows als unter Linux. Aus diesem Grundmussen Sie fur die letzte Praktikumsphase Windows XP benutzen, das auf allen Prak-tikumsrechnern neben Linux installiert ist. Sollten Sie Ihren Rechner im Linux-Modusvorfinden, mussen Sie einen Neustart auslosen und Windows im Bootmenu auswahlen.

Loggen Sie sich mit den gleichen Daten ein wie gewohnt. Ihr Heimatverzeichnis,das sie auch unter Linux verwendet haben, konnen Sie als Netzlaufwerk verbinden:\\sauron\homes.

Bild 20: Das Begrußungsfenster von XPS

45

Bevor Sie XPS zum ersten Mal aufrufen, sollten Sie erst einmal eine lokale Kopie desvorbereiteten Projekts fur das Praktikum anlegen. Das Projekt finden Sie im Verzeichniss:\xps_motion. Kopieren Sie sich das gesamte Verzeichnis mit allen Unterverzeichnis-sen. Nun starten Sie XPS uber das Start-Menu.

Nach dem Start offnet sich die XPS-GUI und zeigt das ”Begrußungsfenster”(Bild 20).Dort wahlt man nun Open a recent project und klickt dann auf OK.

Im sich offnenden Datei-Browser wahlt man die Datei system.xps aus dem Verzeichnisder lokalen Projektkopie aus. Daraufhin erscheint das Hauptfenster von XPS mit demkompletten Videosystem (Bild 21).

6.2 Das Hardware-Software-Gesamtsystem

Das auf den ersten Blick vielleicht etwas verwirrend aussehende Fenster zeigt auf einenBlick das gesamte Hardware-Software-System. Um Ihnen die Orientierung etwas zu ver-einfachen haben wir das eigentliche Bild etwas eingefarbt (Bild 21).

Bild 21: Das Hauptfenster von XPS mit geladenem Motion-Detection-Projekt

Rot markiert sind die beiden Prozessoren des Virtex-II-Pro, ppc405_0 und ppc405_1.

Innerhalb des grunen Breiches sehen Sie die Busse des Systems, einschließlich derCoreConnect-Busse PLB, OPB, und DCR sowie einer PLB-2-OPB Bridge.

Alle Module, die zur Kommunikation des Virtex-II-Pro mit der Außenwelt dienen,sind blau markiert. Dazu gehoren der UART-, der JTAG-, der CompactFlash- undder IIC-Controller. Mit Hilfe des UART-Controllers konnen die PowerPC-ProzessorenDaten uber die serielle Schnitstelle empfangen und versenden. Der JTAG-Controllerermoglicht das Programmieren und Debuggen des Virtex-II-Pro von außen uber Ih-ren Entwicklungs-PC. Mit Hilfe des CompactFlash-Controllers konnen Daten auf eineCompactFlash-Karte geschrieben oder davon gelesen werden, und der IIC-Controller

46

wird zur Konfiguration der an das XUP-Board angeschlossenen Videoplatine VDEC-1benutzt.

Die gelb markierten Module stellen den Systemspeicher und notwendige Zusatzmoduledar. Dies sind ein PLB-BRAM-Interface Controller und ein DSOCM-BRAM-Interface-Controller, die es dem PowerPC-Prozessor ermoglichen, uber den Processor-Local-Busbzw. eine On-Chip-Speicherschnittstelle Daten in die angeschlossenen BRAM-Blocke zuschreiben und davon zu lesen. Im orangen Breich findet man alle Module, die zur Takt-und Reset-Signalerzeugung verwendet werden.

Das fur uns wichtigste (und deshalb auch etwas breiter markierte) Modul ist im cy-an Bereich: Das Motion-Detection-System! Im XPS-Projekt wird es video_capture_0

genannt.

6.3 Das Motion-Detection-System

Die genaue Vorstellung aller Module und derer Verbindungen wurde an dieser Stelle zuweit gehen und aus diesem Grund werden wir uns nur auf das Motion-Detection-Systemkonzentrieren. Um die Anschlusse des Moduls zu erkunden, klicken Sie bitte im FeldFilters auf die Checkbox Ports (lila Ellipse in Bild 21). Daraufhin verandert sich dasHauptfenster zu einer Darstellung wie in Bild 22 gezeigt. Sollten die Ports vom MotionDetection System nicht zu sehen sein, expandieren Sie die Modulbeschreibung mit Klickauf das + direkt neben dem Modulnamen video_capture_0.

Auch hier haben wir zur Verdeutlichung die Darstellung in Bild 22 etwas verfremdet.Im roten Bereich finden Sie die Signal, die von der VDEC-1-Videoplatine kommen,namentlich YCrCbin_in, das Signal uber das die YUV-Bilddaten in den Virtex-II-ProChip gelangen, und LLC_CLOCK, der Takt fur die Ubertragung der YUV-Daten.

Grun markiert sind all die Ports, die zur Ansteuerung des an das XUP angeschlossenenVGA-Monitors dienen: R, G und B als Farbwerte, PIXEL_CLOCK als Pixelrate, H_SYNC_Zals horizontales Synchronsignal, V_SYNC_Z als vertikales Synchronsignal, BLANK_Z alsAustastsignal und COMP_SYNC als Sync-on-Green/Composite Synchronisations-Signal.

Der blaue Block enthalt alle Signale, die der Virtex-II-Pro zur VDEC-1-Videoplatine sen-det. Diese sind ein Resetsignal (RESET_VDEC1_Z), ein Aktivierungssignal (VDEC1_OE_Z)und ein Standbysignal (VDEC1_PWRDWN_Z).

Alle gelben Signale sind mit dem BRAM verbunden, das der PowerPC uber seine On-Chip-Memory-Schnittstelle DSOCM auslesen kann. Wie fur RAM ublich, sind dies einAddressbus, ein Datenbus und ein Write-Enable-Signal.

Die lila gefarbten Ports sind alle an den DCR-Bus angeschlossen und ermoglichen denZugriff auf das Motion-Detection-System durch die Software. Die genaue Funktionsweisedes DCR wollen wir an dieser Stelle nicht weiter erlautern, wichtig ist nur, dass die Uber-tragung von 32-Bit-Werten zwischen Software und Motion-Detection-System ermoglicht.In Phase 5 des Praktikums setzen Sie den DCR ein, um die Bounding-Box-Koordinatenan die Hardware zu ubermitteln.

Der cyan gefarbte Bereich in Bild 22 zeigt das Interrupt-Signal, mit dessen Hilfe dasMotion-Detection-System dem PowerPC-Prozessor anzeigt, dass ein neues BINFrame

47

Bild 22: Die Ports des Motion Detection Systems

48

zur Verfugung steht. Das nicht farbig markierte Signal one_shot dient lediglich Debug-zwecken.

6.4 Erzeugen der FPGA-Programmierung

Damit das Virtex-II-Pro-FPGA genau die Funktion erfullt, die das Motion-Detection-System beschreibt, muss das FPGA mit Hilfe der Systembeschreibung konfiguriert wer-den. Dazu muss aus der Systembeschreibung eine FPGA-Konfiguration synthetisiertwerden. Dazu offnet man das Menu Hardware (rosa Elipse in Bild 21; Sie bemerken si-cher, dass die Farben langsam knapp werden...) und klickt auf den Unterpunkt GenerateBitstream.

Nun erzeugt XPS die gewunschte Konfiguration (dies kann durchaus eine Weile dauern).Das Ergebnis ist eine Bitstrom-Datei mit der Endung .bit, die mit Hilfe von ChipScope-Pro (Abschnitt 6.6) zur Programmierung des FPGA benutzt wird.

6.5 Erstellen der Software

Nachdem die Erstellung der Hardware abgeschlossen ist, mussen Sie noch Ihre Soft-waremodule kompilieren. Dazu aktivieren Sie die Registrierkarte Applications (osterlilaEllipse in Bild 21) und expandieren den Unterpunkt Sources durch einen Klick auf das+ direkt daneben. Danach sollte sich der rechte Teil des XPS-Fensters in etwa wie inBild 23 prasentieren.

Bild 23: Applikationsansicht von XPS

Durch Doppelklick auf die Quelle detect_motion.c (in Bild 23 markiert) offnet sie sichim Editor-Fenster die entsprechende Datei.

Nun sollten Sie die Funktion boundingBox mit Leben (im Sinne von Code) fullen (sieheBeschreibung von Praktikumsphase 5) und anschließend kompilieren. Dies geschiehtmit einem Rechtsklick auf den Projektnamen (detect_motion, rote Elipse in Bild 23),woraufhin sich ein Kontextmenu offnet. In diesem wahlt man den Unterpunkt BuildProject aus.

49

Jetzt wird das Projekt kompiliert und anschließend mit den notwendigen Laufzeitbiblio-theken gelinkt. Auch dies kann einen Moment dauern. Wenn alles ohne Fehler durch-gelaufen ist, konnen Hard- und Software auf das XUP-Board (also das Virtex-II-ProFPGA) geladen werden.

6.6 Programmierung des FPGA mit ChipScope Pro

Das Programmieren des XUP-Boards mit dem Motion-Detection-System besteht auszwei Schritten:

1. FPGA-Programmierung,

2. Software-Download und Start.

6.6.1 FPGA-Programmierung

Zur Programmierung des FPGA wird an der Abteilung E.I.S. unter anderem das Pro-gramm Chipscope-Pro eingesetzt, das auch als Logik-Analyzer verwendet werden kann.Nach dem Start von ChipScope erscheint ein Fenster wie in Bild 24 dargestellt. Nun musseine Verbindung zum XUP-Board hergestellt werden. Voraussetzung dafur ist, dass dasBoard eingeschaltet und mit Hilfe des USB-Kabels am Rechner angeschlossen ist.

Ist dies der Fall, klicken Sie im Menu auf JTAG Chain (grune Ellipse in Bild 24) undwahlen darin den Punkt Xilinx Platform USB Cable aus. Im darauf folgenden Fensterkann die Verbindungsgeschwindigkeit konfiguriert werden, die aber standardmaßig auf3 MHz eingestellt ist und so belassen werden sollte. Nach dem Klick auf OK verbindetsich Chipscope mit dem XUP-Board.

Bild 24: Hauptfenster von Chipscope Pro

Bei erfolgreicher Verbindung offnet sich ein Fenster, dass alle vom Entwicklungsrechneransprechbaren Komponenten des XUP-Boards enthalt. Dies sind ein XCF32P-Flash-PROM, ein System-ACE CompactFlash-Controller und (fur Sie am interessantesten)

50

das XC2VP30 Virtex-II-Pro FPGA. Das Fenster kann durch Klick auf OK geschlossenwerden. Jetzt erscheinen alle erkannten Komponenten im JTAG-Chain-Fenster (Bild25).

Bild 25: Das JTAG Chain Fenster nach Verbindung zum XUP Board

Per Rechtsklick auf den Virtex-II-Pro (rote Ellipse in Bild 25) offnet sich ein Kontext-menu, in dem Sie den Punkt Configure... auswahlen. Uber die Schaltflache Select NewFile offnen Sie einen Datei-Browser und wechseln in ihr lokales Projektverzeichnis. Indiesem wahlen Sie den Unterordner Implementation und darin die Datei system.bit perDoppelklick aus.

Nach dem anschließenden Klick auf OK wird der Bitstream in das FPGA geladen undkonfiguriert dieses auf das in XPS beschriebene System. Nachdem der Fortschrittsbalken(unten links in Bild 24) 100% erreicht hat, sollten Sie eine Anderung auf dem Monitorsehen.

Nun konnen Sie damit fortfahren, die Software auf das Board zu laden.

6.6.2 Software-Download und Start

Um den PowerPC-Prozessor im Virtex-II-Pro zu programmieren, verwenden Sie wiederXPS (was Sie wahrend der ChipScope-Prozedur am besten gar nicht geschlossen haben).Dazu offnen Sie in XPS wieder das Projekt (wenn es nicht noch geoffnet ist) und wahlenim Menu Debug (grune Ellipse in Bild 21) den Unterpunkt XMD Debug Options... aus.Im sich offnenden Fenster wahlen Sie aus dem Drop-Down Menu ppc405_1 (achten Sieauf die 1 !) und klicken auf OK (dies muss nur vor dem ersten Start von XMD geschehen).

Dort stellen Sie alles so wie in Bild 26 gezeigt ein. Dadurch wird der Debugger angewie-sen, sich uber das USB-Kabel mit einer Geschwindigkeit von 3MHz mit dem PowerPC-Prozessor 1 des Virtex-II-Pro zu verbinden. Die Einstellungen werden mit einem Klickauf Save gespeichert.

Anschießend wird wieder das Debug Menu geoffnet und diesmal der Unterpunkt LaunchXMD... gewahlt. Auch hier muss wieder im Drop-Down Menu ppc405_1 eingestellt undanschließend mit OK bestatigt werden. Danach verbindet sich XMD mit dem PowerPC1 des Virtex-II-Pro und bei Erfolg erscheint das XMD Fenster wie in Bild 27.

Uber die jetzt etablierte XMD-Verbindung kann der bekannte GDB-Debugger verwendetwerden, um den Instruktionsspeicher des PowerPC zu programmieren und auch dasProgramm zu starten sowie sogar uber die USB-Verbindung zu debuggen.

GDB wird auch uber das Debug Menu und dessen Unterpunkt Lauch Software Debugger...gestartet. Im Hauptfenster von GDB klicken Sie auf die Schaltflache Run (grune Ellipsein Bild 28) und es erscheint das Fenster Target Selection (Bild 29 . Hier konnen die

51

Bild 26: Optionen fur XMD

Bild 27: XMD nach der Verbindung mit dem PowerPC

52

Standardeinstellungen ubernommen werden, jedoch sollten Sie vorerst die Breakpoint -Checkboxen alle deaktivieren (grune Ellipse in Bild 29).

Bild 28: Hauptfenster von GDB

Bild 29: Target Selection Fenster von GDB

Nach einem Klick auf OK ladt GDB Ihre Software auf das XUP-Board und startetsie. Sind keine Breakpoints gesetzt und keine Fehler in Ihrem Programm, sollte nundas Kamerabild auf dem an das XUP-Board angeschlossenen Monitor sichtbar werdenund Ihr Programm ablaufen. Wenn Sie in Ihrer Software Ausgaben uber print oderprintf gemacht haben, mussen Sie noch TeraTerm starten, um diese sehen zu kon-nen (wenn Sie TeraTerm nicht kennen, wenden Sie sich vertrauensvoll an einen HiWi).Das Motion-Detection-System wurde von uns so eingestellt, dass alle print-Ausgabenin Ihrer Software werden automatisch uber die serielle Schnittstelle des Virtex-II-Proausgegeben.

53

Wenn alles geklappt hat und Ihr System reibungslos Bewegungen in Echtzeit erkennt:

Herzlichen Gluckwunsch zum erfolgreichen

Hardware/Software-Codesign mit SystemC und Virtex-II-Pro!

54

Praktikum Hardware/Software-Codesign mit SystemC · 2006. 5. 29. · Vortrags mit 10 bis 15 Folien...

Documents

Transcript of Praktikum Hardware/Software-Codesign mit SystemC · 2006. 5. 29. · Vortrags mit 10 bis 15 Folien...