Configurable Embedded Systems WS 19/20

Prof. Dr. Sven-Hendrik Voß 10. Dezember 2019

Laborübung 5
Die Bearbeitung der Aufgaben erfolgt in Gruppen zu je max zwei Teilnehmern. Alle
Aufgaben sind schriftlich zu lösen und in einem Protokoll festzuhalten. Alle praktische
Realisierungen sind dem Dozenten im Rahmen der Gruppenrücksprache zu präsentie-
ren. Erfolgreiche Abnahmen werden auf dem Aufgabenblatt schriftlich quittiert. Eine
erfolgreiche Laborteilnahme ist Voraussetzung für die Teilnahme an der Klausur am
Ende des Semesters. Labore werden benotet und gehen zu 30% in die Endnote ein.
Bitte bedenken Sie, dass eine gute Vorbereitung zu den Laborterminen unabdingbar ist.

Übersicht
In diesem Labor werden Sie mal mit einem etwas größeren Projekt arbeiten können.
Ihre erste Aufgabe wird es sein, eine Anwendung zu bauen, welche ein Bild auf einem
Bildschirm anzeigt. In der zweiten Aufgabe soll dieses Bild vorher durch einen Block
bearbeitet werden, welcher einen Teil der JPEG-Kompression emuliert.
Frage: Wie sieht der Datenfluss der 2 Aufgaben aus?
Vorbereitung
Beschäftigen Sie sich mit der DCT und der JPEG-Kompression. Lesen Sie sich den
Quellcode des DCT- und des VGA-Blocks durch und beantworten Sie folgende Fragen:

• Vorbereitung JPEG & DCT:

– Wofür steht DCT, was ist das?

– Wie wird die DCT in JPEG genutzt?
– Warum kann man mithilfe der DCT Speicherplatz für das Bild sparen?
– Wie groß ist der Bildausschnitt, der in der DCT analysiert wird?

• VGA Block:

– Was unterscheidet den VGA Block von dem, den ihr in Aufgabe 3 gebaut
habt?
– Welche Ein- und Ausgänge hat der VGA Block und wofür sind sie da?
(Es muss bei dem AXI Interface nicht jeder einzelne Ein- und Ausgang
benannt werden)
– Wenn man den VGA Block aus Aufgabe 3 auf 12 Bit erweitert, braucht
man etwas mehr als 100 Block-RAM-Blöcke. Wenn man den hier vorgege-
benen Block verwendet, braucht man keinen einziges Blockram Tile. Wie
erreicht man diese Einsparung?

1
 – Warum gibt es 2 RAMs (ram0 und ram1)?
– In welchem Format werden die Daten an den DCT-Block geschickt / Wie
sieht die Unteraufteilung eines 32 Bit Datums aus?

• DCT Block:

– Welche Ein- und Ausgänge hat der VGA Block und wofür sind sie da?
(Es muss bei dem AXI Interface nicht jeder einzelne Ein- und Ausgang
benannt werden)
– Welche mathematische Operation implementiert der DCT-Block?
– Wie groß ist der Bildausschnitt, der in dem DCT-Block analysiert wird?
– In welchem Format werden die Daten an den DCT-Block geschickt / Wie
sieht die Unteraufteilung eines 32 Bit Datums aus?
– Was bewirken die Schalter?
– Wann fängt der DCT Block an, die DCT der Pixel zu berechnen?
– Wie sprechen sich der Block und der Prozessor ab?

Laden Sie sich von der Homepage von Prof. Voß den Ordner Aufgabe 5 runter. In
diesem finden Sie alle Dateien, welche Sie zur Bearbeitung dieses Aufgabenblattes
benötigen. In diesem finden Sie ein TCL-Skript, mit welchem das Vivado-Projekt
bis zur Erstellung des Bitstreams erstellt wird. Des weiteren finden Sie im Ordner
A5 source code alle VHDL-Dateien und die Constraints, welche das Projekt verwen-
det. Als letztes finden Sie hier auch einen Ordner SDK header, in welchem ein Header
File liegt, welches ein 640 x 480 Bild in Form eines Arrays enthält.

Aufgabe 1

Öffnen Sie Vivado und gehen Sie in die TCL Konsole. Dort wechseln Sie mit dem cd -
Befehl in den Ordner Aufgabe 5, den Sie von Prof. Voß Website runtergeladen haben.
Anschließend erstellen Sie das Projekt durch den Befehl source create A5.tcl. Gucken
Sie sich das Block Design an, damit Sie verstehen, welcher Block wie verbunden ist.
In Vivado kann es sein, dass ihr den Fehler The design failed to meet the timing
requirements. Please see the timing summary report for details on the timing violati-
ons. bekommt. Den könnt ihr ignorieren. Ich habe das Design mitsamt dieses Fehlers
getestet und es funktioniert trotzdem.
Öffnen Sie nun das SDK und legen Sie ein neues SDK Projekt an. Anschließend
kopieren Sie aus dem SDK header -Ordner die Datei testimage.h in ihren Ordner mit
den Quelldateien ( das sollte [ Vivado Projektname ].sdk/[ SDK Projektname ]/src
sein ). Nun können Sie anfangen, den C-Code zu implementieren, welcher dafür sorgt,
dass das im Header befindliche Bild auf dem Monitor angezeigt wird.
Wenn man in C ein Programm schreibt, welches Daten in den Speicher schreibt, dann
geht man in der Regel auch davon aus, dass diese Daten in den RAM geschrieben

2
werden. In meinen Tests habe ich aber herausgefunden, dass dies in diesem Fall nicht
passiert. Tatsächlich werden die Daten nur in den Cache geschrieben und erreichen
nie den RAM. Um dem vorzubeugen kann man entweder nach dem Schreiben den
Cache flushen oder ihn von Anfang an komplett disablen. Funktionen dafür findet ihr
in der Headerdatei xil cache.h.
Beim Testen kann es aber auch zu einem weiteren Fehler im SDK kommen, welche
viele von euch auch schonmal beobachtet haben: AP transaction error, DAP status
f0000021. Dieser Fehler kommt vermutlich daher, dass sowohl das SDK das Programm
in den Speicher des PS schreiben möchte ( an Adresse 0x01000000 ) als auch der
VGA Block in regelmäßigen Zeitabständen Daten aus dem Speicher anfordert und
das beides miteinander kollidiert. Sollte ihr den Fehler sehen, dann resettet einfach
das Board ( mit einem der 2 Push Buttons links von den Schaltern oder indem ihr das
Board einmal an- und wieder ausschaltet ). Anschließend ladet wieder den Bitstream
und das Programm auf das ZedBoard. Um diesem Fehler vorzubeugen habe ich es
als wirksam herausgefunden, den FPGA während des Programmstarts im Reset zu
halten. Haltet dazu einfach den mittleren der 5 Push Buttons gedrückt.
Wenn ihr nun das Bild auf dem Bildschirm seht, werdet ihr feststellen, dass es feh-
lerhaft angezeigt wird. Eure Aufgabe besteht nun darin, den Fehler zu finden und zu
beseitigen. Dieser Fehler ist in einem früheren Design auch bei mir aufgetreten und
eine gute Möglichkeit, das Debuggen mithilfe des Integrated Logic Analyzers ( kurz
ILA ) zu üben. In eurem Design befinden sich bereits 2 ILA IPs, welche auch schon
mit allen Debug-Signalen verbunden sind, welche benötigt werden, um diesen Fehler
auffinden zu können.
Die von dem TCL-Skript verbauten ILA IPs sind bereits vollständig konfiguriert. Falls
ihr aber bei einem eigenen Design einen ILA benutzen wollt, lohnt es sich, sich mal
die Möglichkeiten der Konfiguration anzugucken. Geht dazu in Vivado in das Block
Design und macht einen Doppelklick auf den zu konfigurierenden ILA IP. Die wichtig-
sten Einstellungen sind die Auswahl zwischen Native und AXI, sowie die Einstellung
der Sample Data Depth. Mit der ersten Auswahl könnt ihr auswählen, ob ihr euch
einzelne Signale oder ein AXI-Interface angucken wollt. In dem von mir vorgegebenen
Design findet ihr einen ILA, welcher native Signale überwacht und einen für ein AXI
Interface. Wenn ihr einen ILA als Native einstellt, könnt ihr darunter angeben, wie
viele Eingänge er haben soll. In den Reitern oben neben dem Reiter General könnt ihr
von den einzelnen Eingängen die Bitbreite angeben. Mit der Angabe der Sample Da-
ta Depth könnt ihr einstellen, wie viele Sample ihr speichern wollt. Da diese Sample
aber in dem Blockram des FPGAs zwischengespeichert werden und gleichzeitig für
alle Eingänge gelten, sollte man sich hier gut überlegen, wie viele Sample ihr wirklich
braucht. Wenn ihr hier nämlich eine zu große Zahl angebt, dann wird Vivado das erst
in der Implementation auffallen. Weitere Einstellmöglichkeiten sind die Bereitstellung
von Trigger In und Trigger Out Ports, welche in dem von mir vorgegebenen Design
auch genutzt sind. Des weiteren kann man auch Capture Control und Advanced Trig-
ger bereitstellen, mit welchen man noch feinere Bedingungen definieren kann, unter
denen die Daten aufgenommen werden. Für weitere Einstellungen und genauere Be-
schreibungen sei hier auf die von Xilinx bereitgestellte Dokumentation des ILA IPs

3
verwiesen. Diese findet man im Internet, sowie je eine Dokumentation für alle von
Xilinx bereitgestellten IP Cores.
Geht in Vivado im Flow Navigator unten auf Open Hardware Manager. Die zwei
technischen Voraussetzungen, um Signale auf dem Board mit dem ILA aufzunehmen
sind a) dass ein ILA auf dem FPGA konfiguriert ist und b) dass die Clock dieses ILA
läuft. Sollten diese Bedingungen nicht zutreffen, so wird Ihnen im Hardware Manager
oben in einem grünen Streifen der Fehler No Debug Cores found angezeigt. Da in
dem Design definitiv ein ILA synthetisiert ist, muss nur noch sichergestellt werden,
dass die Clock auch läuft. Da die Clock vom Processing System bereitgestellt wird,
muss mindestens ein Mal ein Programm gestartet werden. Wenn man danach das
ZedBoard nicht mehr ausschaltet, läuft die Clock vom PS weiter. Um zu sehen, ob
die Clock läuft, habe ich sie in dem Design auch auf die erste LED gelegt: Leuchtet
diese halbhell, dann läuft die Clock. Wenn ihr den Fehler nun immer noch seht, dann
klickt daneben einfach auf Refresh Device und dann solltet im Hardware Manager
zwei neue Tabs sehen: hw ila 1 und hw ila 2. Der ILA 1 ist der mit dem AXI Signal
und im ILA 2 kann man die Ausgangssignale des VGA Cores sehen.
Unter dem Abschnitt mit dem schwarzen Hintergrund sieht man 2 Fensterabschnit-
te nebeneinander, bei welchem man Einstellungen für den ILA vornehmen kann: in
dem links sind die 2 Tabs Settings und Status zu finden, in dem rechts die Tabs
Trigger Setup und Capture Setup. Bei den Settings kann man den Trigger Mode und
die Trigger Position einstellen. Beim Trigger Mode hat man die Auswahl BASIC,
TRIG IN ONLY oder beide Trigger.
Die Trigger Position ist das Sample, bei dem der Trigger triggert. Im ILA selber ist
etwas wie ein Ringbuffer verbaut, so dass man in den Samples vor dem Trigger die
Waveform ansehen kann, wie sie vor dem Trigger war. Mit der Trigger Position stellt
ihr also ein, wie viel ihr vor oder nach dem Moment sehen wollt, an dem der Trigger
triggert. In dem Tab Status könnt ihr den Status des ILAs sehen, also ob er gerade
nichts tut, auf einen Trigger wartet, ob er gerade dabei ist, Daten aufzunehmen oder
ob er damit fertig ist.
Im Tab Trigger Setup könnt ihr die Triggerbedingungen definieren. Erst, wenn die
Triggerbedingungen erfüllt ist, fängt der ILA an, die Daten aufzunehmen und an
Vivado zu senden, damit ihr die Waveform im Hardware Manager seht. Mit einem
Klick auf das +-Symbol könnt ihr ein Signal ( eine Probe ) auswählen, auf die ihr
triggern wollt. Mit einem Klick auf das Minus-Symbol kann man dieses Signal wie-
der löschen. Darunter könnt ihr den Komparator für das Signal konfigurieren: Ihr
könnt hier einen Vergleichsoperator auswählen, sowie einen Wert einstellen, mit dem
das Signal verglichen werden soll. Verschiedene Eingabemöglichkeiten stellt euch die
Radix-Eingabe zur Verfügung, so dass ihr die Vergleichswerte unter anderem in binär,
hexadezimal und als Ganzzahl eingeben könnt. Mit dem Klick auf das Gattersymbol
in der Leiste, wo auch das Plus- und das Minus-Symbol sind, kann man die globale
Triggerkondition einstellen: Das AND-Gatter definiert zum Beispiel, dass getriggert
werden soll, wenn alle Triggerbedingungen gleichzeitig wahr sind.
Neben der Möglichkeit auf Signale zu triggern gibt es auch noch den TRIG IN Port.

4
Dieser ermöglicht einem, 2 ILA gleichzeitig zu triggern. So kann man zum Beispiel
in dem ILA 2 eine Trigger Bedingung definieren und den ILA 1 gleichzeitig mittrig-
gern. Dazu müsst ihr nur im ILA 1 in dem Reiter Settings den Trigger Mode: auf
TRIG IN ONLY stellen.
Wenn ihr nun die Trigger definiert habt, könnt ihr in dem Waveform-Fenster auf
das Play-Symbol drücken (das blaue, nach rechts zeigende Dreieck), um den ILA zu
starten. Danach wird er in den Status gehen, in welchem er auf den Trigger wartet und
kurz darauf solltet ihr die Waveform zu sehen bekommen, sobald die Triggerbedingung
erfüllt ist. Solltet ihr nach kurzer Zeit keine Waveform sehen, so überprüft am Besten
eure Trigger-Bedingung. Mit dem Symbol neben dem Play-Symbol könnt ihr auch
einmal eine Waveform aufnehmen, ohne auf den Trigger zu warten. Wenn ihr beide
ILAs gleichzeitig triggern wollt, dann startet ihr erst den ILA 1, der den TRIG IN
hat, und anschließend den ILA 2. Sobald der Trigger des ILA 2 triggert, wird dann
automatisch über den Cross Trigger auch der ILA 1 getriggert.
Damit solltet ihr das Handwerkszeug haben, um auf dem Board Signale zu debug-
gen. Spielt ein bisschen mit dem ILA rum, um ein Gefühl dafür zu bekommen, wie
die Signale des VGA Cores aussehen, probiert auch gerne mal verschiedene Trigger-
Bedingungen aus. Am Ende ist der Fehler, den ihr auffindet durch die Modifikation
einer Zeile behebbar.

Aufgabe 2

Zusätzlich zu dem VGA Block, mit dem ihr ja jetzt ein Bild anzeigen könnt, be-
findet sich im Design noch ein DCT Block. Guckt euch an, wie ihr an diesen die
Daten zur Verarbeitung senden könnt und wann und wie ihr die verarbeiteten Daten
wieder abholen könnt. Dann schreibt eine Anwendung, welche das Testbild in einer
Endlosschleife einmal durch den DCT Block bearbeiten lasst und dann anzeigt.

5
Nur vom Dozenten nach erfolgreicher Abnahme auszufüllen!

Gruppenname

Abnahme

Aufgabe 1 Aufgabe 2

Beurteilung

Kriterium Max. Punkte

Themenbearbeitung entsprechend Zielstellung 5

Fundierte Erarbeitung des Lösungsansatzes 5
Qualität der technischen Umsetzung 5
Funktionsfähigkeit der technischen Umsetzung 5
Darstellung von Ergebnissen und Lösungsvorschlägen 5
Bearbeitungszeit 5

Gesamtpunkte für Beurteilungskriterium 30

Note

Index 28,5 27 25,5 24 22,5 21 19,5 18 16,5 15

Note 1,0 1,3 1,7 2,0 2,3 2,7 3,0 3,3 3,7 4,0