Übung 3 - Institut für Kommunikationsnetze und Rechnersysteme ...

Universität Stuttgart
Institut für Kommunikationsnetze und Rechnersysteme
Prof. Dr.-Ing. A. Kirstädter
Entwurf digitaler Systeme
Übung 3: Testbench-Modellierung und Fehleranalyse
In dieser Übung soll das Verhalten zweier VHDL-Implementierungen eines Speichers untersucht
werden. Während die eine Implementierung korrekt funktioniert, weist die andere Implementierung
diverse Fehler auf. Ihre Aufgabe besteht darin, eine Testbench zu entwickeln, mit
deren Hilfe Sie durch Simulation alle Fehler der zweiten Implementierung aufdecken können.
Sie können dabei auf einer bestehenden Testbench aufbauen, die im Folgenden näher beschrieben
wird. Die VHDL-Beschreibungen der in den nächsten Abschnitten vorgestellten Komponenten
finden Sie in einem Zip-Archiv eds-ex3-files.zip, das Sie von der Homepage der
Vorlesung herunterladen können. Das Archiv enthält außerdem ein ModelSim-Projekt
(ex3.mpf), das Sie als Grundlage für die Bearbeitung der Aufgaben heranziehen können. Die
Quellen des ModelSim-Projekts sind in zwei Libraries ex3_public und ex3_secret aufgeteilt.
Letztere enthält die Architecture der enthaltenen Komponente Memory nur in kompilierter
Form, während die Modellierung der in der Library ex3_public enthaltenen Komponenten
vollständig einsehbar ist.
clk_res_gen
clk res_n
memory_tester
clk: std_logic
res_n: std_logic
wena: std_logic
address: address_t
wdata: data_t
rdata: data_t
memory
clk: std_logic
wena: std_logic;
address: address_t
wdata: data_t
rdata: data_t
Bild 1: Struktur der Testbench
Testbench memory_tb
Bild 1 zeigt den Aufbau der Testbench (Entity memory_tb). Sie umfasst den zu validierenden
Speicher memory, einen Speichertester memory_tester und eine Komponente clk_res_gen, die
ein Takt- und ein Resetsignal erzeugt. memory_tb liegt in zwei Varianten vor; diese unterscheiden
sich darin, welche Implementierung des Speichers eingebunden wird:
Entwurf digitaler Systeme Übung 3: Testbench-Modellierung und Fehleranalyse - Bl. 1

• Die Architecture memory_tb(struct) instanziiert den fehlerfreien Speicher (Komponente
memory aus Library ex3_public).
• Die Architecture memory_tb(struct_faulty) instanziiert den fehlerbehafteten Speicher
(Komponente memory aus Library ex3_secret).
Die Typen data_t und address_t sind im Package ex3_public.types definiert.
Speicher memory
Die Komponente memory modelliert einen Speicher, der synchron geschrieben und asynchron
gelesen wird:
• Liegt an seinem Write-Enable-Eingang (wena) eine ’1’ an, so wird das am Eingang
wdata anliegende Datum mit der steigenden Taktflanke in die durch address gegebene
Speicherzelle geschrieben.
• Am Ausgang rdata liegt immer der Inhalt der momentan durch address angegebenen
Speicherzelle an.
Speichertester memory_tester
Aufgabe von memory_tester ist es, Schreib- und Lesezugriffe auf den Speicher auszuführen,
um evtl. vorhandene Fehler aufzudecken. Insbesondere sollte der Tester bei jedem Lesezugriff
prüfen, ob das gelesene Datum mit dem zuletzt an die entsprechende Speicherstelle geschriebenen
Datum übereinstimmt.
Die vorgegebene Fassung des Testers ist noch sehr unvollständig. Sie schreibt die Werte 1 und
3 an die Adressen 4 und 10 und liest diese direkt anschließend wieder aus. Eine Überprüfung
der gelesenen Werte findet nicht statt.
Takt- und Resetgenerator clk_res_gen
Die Komponente clk_res_gen erzeugt ein Taktsignal clk mit der Periodendauer 1µs und ein
low-aktives Reset-Signal res_n, das die ersten 3.7µs Simulationszeit aktiv ist.
Entwurf digitaler Systeme Übung 3: Testbench-Modellierung und Fehleranalyse - Bl. 2

Aufgabe 1
Erste Schritte
Im Folgenden soll zunächst die vorgegebene Fassung der Testbench mit dem korrekt funktionierenden
Speicher simuliert werden. In den folgenden Aufgabenteilen werden Sie die Testbench
dann schrittweise erweitern.
Öffnen Sie das ModelSim-Projekt ex3.mpf und compilieren Sie dieses anschließend:
• Entpacken Sie das Archiv eds-ex3-files.zip
• Starten Sie ModelSim
• File >> Open >> Files of Type: Project Files (*.mpf) >> ex3.mpf auswählen >> Open
• Compile >> Compile Order >> Auto Generate
Simulieren Sie die nun die Architecture struct von memory_tb. Vergewissern Sie sich, dass
sich Tester und Speicher wie zuvor beschrieben verhalten.
Wählen Sie dazu im Workspace-Fenster den Tab Library aus und klicken Sie mit der rechten
Maustaste auf den Eintrag work >> memory_tb >> struct. Wählen Sie im erscheinenden Kontext-Menü
den Punkt Simulate aus. Fügen Sie die Testbench-Signale einem Wave-Window
hinzu und simulieren Sie eine Zeitspanne von 10µs.
Im Folgenden soll der Tester erweitert werden.
Frage 1
Frage 2
Frage 3
Ändern Sie den Prozess tester_p in memory_tester(behav) so ab, dass er zunächst
alle Speicherzellen nacheinander einmal mit beliebigen Werten beschreibt
und die Speicherzellen dann nacheinander wieder ausliest.
Überprüfen Sie die korrekte Funktion im Wave-Window.
Hinweis: Benutzen Sie Funktionen aus dem Package ieee.numeric_std.
Erweitern Sie den Tester so, dass er im Fehlerfall eine Meldung ausgibt
(Adresse, gelesener Wert, erwarteter Wert). Benutzen Sie dazu eine assertoder
report-Anweisung.
Hinweis:
Auf Grund der Simulationsmethodik von VHDL ändert sich der Ausgang
rdata des Speichers erst nach einem (infinitesimal) kleinen Zeitraum nachdem
seine Eingangssignale gesetzt wurden. In der Testbench müssen Sie daher
ein wait-statement zwischen dem Setzen von wena/address/wdata und
dem Lesen von rdata einfügen. Beispielsweise könnten Sie bis zur nächsten
negativen Taktflanke warten.
Simulieren Sie nun memory_tb(struct_faulty).
An welchen Adressen meldet Ihr Tester Fehler? Stellen Sie eine Vermutung
an, wie ein solches Fehlermuster zustande kommen kann.
Entwurf digitaler Systeme Übung 3: Testbench-Modellierung und Fehleranalyse - Bl. 3

Aufgabe 2
Pseudozufällige Speicherzugriffe
Nun soll der Tester so abgeändert werden, dass er pseudozufällige Speicherzugriffe ausführt.
Zur Erzeugung der dazu nötigen Pseudozufallszahlenfolge (x i ) soll ein sogenannter linearer
Kongruenzgenerator benutzt werden. Dabei wird das Folgenglied x i+1 aus dem Folgenglied x i
gemäß folgender Vorschrift erzeugt:
x i 1
+
= ( A ⋅ x i
+ B) mod M
Im Folgenden wird A=16807, B=0 und M=2147483647 gewählt.
Frage 1
Frage 2
Frage 3
Fügen Sie der Architecture memory_tester(behav) eine Funktion random hinzu,
der als Argument ein Glied der Folge übergeben wird und die das jeweils
nächste Glied zurückgibt.
In welchem Bereich können die Werte dieser Folge liegen? Berücksichtigen
Sie diese Erkenntnis im Folgenden bei der Wahl des Startwerts x 0 .
Prüfen Sie nun die korrekte Funktion von random. Ergänzen Sie dazu
memory_tester(behav) um einen Prozess, der die Folge x i mit x 0 =1 in der Simulationskonsole
ausgibt.
Zur Vereinfachung der späteren Aufgaben soll nun eine Funktion random entwickelt werden,
die mit Wahrscheinlichkeitswerten (d.h. Zahlen im Bereich ]0,1]) statt Ganzzahlen arbeitet.
Frage 4
Frage 5
Frage 6
Deklarieren Sie einen Typ probability_t zur Modellierung von Wahrscheinlichkeitswerten.
Fügen Sie die neue Funktion random der Architecture hinzu und testen Sie
diese wiederum mit Hilfe eines einfachen Prozesses.
Erweitern Sie den Prozess tester_p nun so, dass er in einer Endlosschleife jeweils
zunächst ein zufälliges Datum an eine zufällig gewählte Speicherstelle
schreibt und dieselbe Speicherstelle im jeweils folgenden Taktzyklus ausliest.
Im Fehlerfall soll wiederum eine Meldung ausgegeben werden.
Nun sollen Schreib- und Lesezugriffe zufällig gemischt werden. Um in diesem Fall noch feststellen
zu können, ob ein gelesenes Datum korrekt ist, soll innerhalb der Architecture
memory_tester(behav) eine Datenstruktur memory_state genutzt werden, in der für jede
Adresse festgehalten wird, ob diese schon beschrieben wurde und wie der zuletzt geschriebene
Wert lautet.
Frage 7
Ergänzen Sie die Architecture memory_tester(behav) um die Datenstruktur
memory_state. Definieren Sie zuvor geeignete Typen.
Aus Modularisierungsgründen sollen drei Prozesse in der Architecture verwendet werden:
• Der Prozess control_p entscheidet in jedem Taktzyklus, ob ein Schreib- oder ein Lesezugriff
stattfinden soll und treibt die Ausgangsports entsprechend. Die Wahrscheinlichkeit
beider Zugriffsarten soll jeweils 50% betragen. Die Folge der Schreibadressen soll sich
von der der Leseadressen unterscheiden.
Entwurf digitaler Systeme Übung 3: Testbench-Modellierung und Fehleranalyse - Bl. 4

• Der Prozess updater_p aktualisiert bei jedem Schreibzugriff memory_state.
• Der Prozess checker_p prüft jeden Lesezugriff und wertet dazu den Inhalt von
memory_state aus. Im Fehlerfall soll wie bisher eine Fehlermeldung über die Simulationskonsole
ausgegeben werden.
Frage 8
Frage 9
Aufgabe 3
Ergänzen Sie die Architecture um die drei Prozesse control_p, updater_p und
checker_p.
Simulieren Sie die Testbench memory_tb(struct_faulty).
Welche weiteren Fehler des Speichers memory aus der Library ex3_secret
finden Sie? Hinweis: Identifizieren Sie zunächst die Fehlermuster, die sich
durch den in Aufgabe 1 identifizierten Fehler nicht erklären lassen. Suchen
Sie dann nach Auffälligkeiten im Zugriffsmuster.
Erzeugung einer Protokolldatei
Nun soll der Tester so ergänzt werden, dass er jeden erfolgten Speicherzugriff in einer Datei
access.log protokolliert (vgl. Bild 2).
[...]
Writing 0010101000000101 to address 1110
Reading 0001111000011011 from address 0010
Writing 1010010111011110 to address 0010
Writing 1000110000000100 to address 0011
Writing 0011111110101111 to address 0110
[...]
Bild 2: Beispielhafte Protokolldatei
Für den Dateizugriff soll das Package std.textio benutzt werden. Den mit dieser Übung ausgeteilten
Unterlagen können Sie entnehmen, wie es verwendet wird.
Frage 1
Ergänzen Sie den Tester um einen Prozess logger_p, der eine Protokolldatei
gemäß Bild 2 erzeugt.
Hinweise:
• Im Package textio gibt es keine write-Prozedur, die einen std_logic_vector direkt ausgeben
kann. Sie können aber eine entsprechende Prozedur leicht selber schreiben. Verzichten
Sie dabei der Einfachheit halber auf die Parameter justified und field.
• Im Package textio ist sowohl eine write-Prozedur deklariert, die als Argument einen
string erwartet, als auch eine Variante, die einen bit_string als Argument erwartet. Da der
Compiler nicht ohne Weiteres string- von bit_string-Literalen unterscheiden kann (Bsp.:
Welchen Typ hat "0011"?), müssen Sie beim Aufruf der write-Prozedur den Typ solcher
Literale explizit qualifizieren:
write(line,string’("Hello World!"));
Entwurf digitaler Systeme Übung 3: Testbench-Modellierung und Fehleranalyse - Bl. 5

Aufgabe 4
Fehlererkennung mittels Parity
Nun soll der bisher benutzte, korrekt funktionierende Speicher memory(behav) so erweitert
werden, dass er zusammen mit jedem Datenwort ein Parity-Bit abspeichert.
Frage 1
Frage 2
Frage 3
Aufgabe 5
Ergänzen Sie die Entity memory um zwei Ports wparity und rparity und erweitern
Sie die Architecture memory(behav) entsprechend.
Ändern Sie den Tester so ab, dass beim Schreiben jeweils die Parity berechnet
und geschrieben und beim Lesen geprüft wird, ob die Parity zu den Daten
passt.
Passen Sie die Testbench memory_tb(struct) an und simulieren Sie das Design.
Modellierung einer fehlerhaften Übertragungsstrecke
Nun soll ein Fall modelliert werden, in dem der Speicher selbst zwar fehlerfrei funktioniert, bei
der Übertragung von Signalen vom oder zum Speicher aber Bits verfälscht werden können.
Dabei soll von folgender Annahme ausgegangen werden: Bei jeder Änderung des Werts von
wdata, rdata und address besteht eine Wahrscheinlichkeit von jeweils 0.1%, dass genau ein
Bit des entsprechenden Wortes invertiert wird.
Modelliert wird dieser fehlerhafte Kanal durch eine Komponente channel, die in der Testbench
memory_tb(struct) zwischen memory_tester und memory(behav) eingefügt wird.
Frage 1
Frage 2
Entwickeln Sie Entity und Architecture der Komponente channel.
Ergänzen Sie das Design so, dass einerseits die Häufigkeit gestörter Zugriffe
und andererseits die Häufigkeit erkannter Fehler registriert wird.
Setzen Sie die Werte in Bezug zueinander und versuchen Sie, ihr Verhältnis
nährungsweise herzuleiten.
Lösungsvorschläge können in Papierform abgegeben oder alternativ per E-Mail an die Adresse
domenic.teuchert@ikr.uni-stuttgart.de geschickt werden.
Bei Fragen und Problemen bei der Durchführung der Übungen wenden Sie sich bitte an Dipl.-
Ing. D. Teuchert (Telefon 685-69003, Zimmer 1.305), an Dipl.-Ing. J. Häussler (Telefon 685-
67991, Zimmer 1.365) oder an Dipl.-Ing. M. Meyer (Telefon 685-67975, Zimmer 1.334).
Entwurf digitaler Systeme Übung 3: Testbench-Modellierung und Fehleranalyse - Bl. 6