Forum: FPGA, VHDL & Co. Wie schreibt man eine *richtige* Testbench


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Robert S. (razer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hallo an alle,

ich komme ja ehere aus der Software-Ecke und beginne gerade mit 
digitaler Hardware. Ich arbeite dort mit Test-Driven-Development und 
habe damit beste Erfahrungen. Aus der Software weiß ich, ein gutes Modul 
zu schreiben ist schwer, aber eine gute Testbench dazu ist noch viel 
schwieriger.

Irgendwie fällt mir auf, dass Testbenches mesitens ein wenig 
stiefmütterlich behandelt werden, geschweigedenn man sie überhaupt 
Testbenches nennen kann. Die meisten Testbenches sind meiner Meinung 
nach eher Stimuli-Generatoren ,aber mehr nicht.

Kann Testbenches zeigen, die den Namen Testbench verdient hat?
In der wirklich sauber das Verhalten einer FSM überprüft wird?

Danke im Voraus!
Robert

von Christian R. (supachris)


Bewertung
0 lesenswert
nicht lesenswert
Naja, das ist eine schwierige Sache, denn es kommt auf die Anforderungen 
an. Im Automobil- oder gar Militär- oder Weltraumbereich gibts ganz 
andere Anforderungen an die Testabdeckung als für Messkarten am PC. 
Gerade auch in der SW-Ecke gibts da auch Auswüchse, wo durch einen Test 
sichergestellt wird, dass der Computer richtig 4+5 berechnen kann. Man 
muss da ein gutes Mittelmaß finden. Bei Testbenches kannst du auch alle 
möglichen Sachen über Asserts abprüfen, Stimuli-Daten aus Datei lesen 
und Ergebnisse wieder in Dateien schreiben, den Aufwand kann man 
beliebig hoch treiben. Aber nur um sich an den Zahlen die Modelsim für 
die Code Coverage ausspuckt, aufzugeilen...na ich weiß nicht. Schau dir 
mal die Simulationsmodelle der Speicherhersteller für SDRAM oder Flash 
Speicher an, die haben meist ganz viele Prüfungen. Und was ist gegen 
einen Stimuli-Generator und Ausgabe-Prüfung einzuwenden? Wenn du die 
exakte Funktion einer FSM beweisen willst, musst du ja die FSM in der 
Testbench nochmal beschreiben, wer sagt denn, dass du da nicht den 
selben logischen Fehler einbaust?

von jibi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Man kann das Ganze auch noch weiter treiben, zum Testen eines Rs232 
cores hab ich z.B. gleich eine kleine Anwendung geschrieben, die mir die 
Simulationssignale erzeugt:
1
public List<string> HELPER_generateVHDLTESTBENCHCODE_FOR_RS232INPUT(byte[] bytes)
2
        {
3
            /*
4
              RXDIN <= '0';      -- Startbit
5
              wait for 4333 ns;
6
              RXDIN <= '1';      --Command Byte X63 = read 01100011 -> 11000110
7
              wait for 4333 ns;
8
              RXDIN <= '1';
9
              wait for 4333 ns;
10
              RXDIN <= '0';
11
              wait for 4333 ns;
12
              RXDIN <= '0';
13
              wait for 4333 ns;
14
              RXDIN <= '0';
15
              wait for 4333 ns;
16
              RXDIN <= '1';
17
              wait for 4333 ns;
18
              RXDIN <= '1';
19
              wait for 4333 ns;
20
              RXDIN <= '0';
21
              wait for 4333 ns;
22
             
23
              RXDIN <= '1';      -- Stopbit      
24
              wait for 4333 ns;
25
             */
26
            List<string> vhdlCode = new List<string>();
27
28
            foreach (byte b in bytes)
29
            {
30
                BitArray bits = new BitArray(new byte[] { b });
31
                
32
                //startbit
33
                vhdlCode.Add(" RXDIN <= '0';      -- Startbit" + Environment.NewLine);
34
                vhdlCode.Add(" wait for 4333 ns;" + Environment.NewLine);
35
36
                for (int a = 0; a <= 7; a++)
37
                {
38
                    if (bits[a])
39
                    {
40
                        vhdlCode.Add(" RXDIN <= '1';" + Environment.NewLine);
41
                    }
42
                    else
43
                    {
44
                        vhdlCode.Add(" RXDIN <= '0';" + Environment.NewLine);
45
                    }
46
                    vhdlCode.Add(" wait for 4333 ns;" + Environment.NewLine);
47
                }
48
49
                //stopbit
50
                vhdlCode.Add(" RXDIN <= '1';      -- Stopbit" + Environment.NewLine);
51
                vhdlCode.Add(" wait for 4333 ns;" + Environment.NewLine);
52
53
               
54
55
            }
56
            vhdlCode.Add("wait for 500 us;" + Environment.NewLine);
57
            return vhdlCode;
58
        }

Man muss halt kurz Zeit investieren, ab und zu musst du Dir deine 
Werkzeuge halt selber bauen. Damit lassen sich dann auch komplizierte 
Protokolle einfach simulieren. Nur ein Beispiel dafür das selbst der 
Code für die Simulation nicht von Hand geschrieben werden muss.

Gruß Jonas

von Fpgakuechle K. (fpgakuechle) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Robert S. schrieb:
> Hallo an alle,
>
> ich komme ja ehere aus der Software-Ecke und beginne gerade mit
> digitaler Hardware. Ich arbeite dort mit Test-Driven-Development und
> habe damit beste Erfahrungen. Aus der Software weiß ich, ein gutes Modul
> zu schreiben ist schwer, aber eine gute Testbench dazu ist noch viel
> schwieriger.
>
> Irgendwie fällt mir auf, dass Testbenches mesitens ein wenig
> stiefmütterlich behandelt werden, geschweigedenn man sie überhaupt
> Testbenches nennen kann. Die meisten Testbenches sind meiner Meinung
> nach eher Stimuli-Generatoren ,aber mehr nicht.

Nun hier wird Hardware gebaut und die wird wie Hardware getestet, also 
der FPGA konfiguriert die Testpattern nach Verifikationsplan angelegt 
und der Output mit Referenzwert verglichen. Das ganze nicht nur auf dem 
Tisch bei Raumtemperatur sondern auch im Klimaschrank bei 
Ecktemperaturen.

Die Testbenches in der Simulationsphase sind nicht dem Test in der 
Softwareentwicklung gleichzusetzen. Sie uberprüft die logische Funktion
soweit das man auf die reale Hardware wechseln. In testbenches alle 
zeitlichen Zusammenhänge und asynchronitäten zu testen ist mindestens 
langwierig zuweilen hoffnungslos. Deshalb genügt bei diesem 
Zwischenschritt dem Hardwareentwickler eine Testbench, die der 
Softwerker als unvollständig empfindet.

MfG

von Fpgakuechle K. (fpgakuechle) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
jibi schrieb:

>
1
> public List<string> 
2
> HELPER_generateVHDLTESTBENCHCODE_FOR_RS232INPUT(byte[] bytes)
3
>         {
4
>             /*
5
>               RXDIN <= '0';      -- Startbit
6
>               wait for 4333 ns;
7
>               RXDIN <= '1';      --Command Byte X63 = read 01100011 -> 
8
> 11000110
9
>               wait for 4333 ns;
10
>               RXDIN <= '1';
11
>               wait for 4333 ns;
12
> 
13
>               RXDIN <= '1';      -- Stopbit
14
>               wait for 4333 ns;
15
>              */
16
>             List<string> vhdlCode = new List<string>();
17
> 
18
>             foreach (byte b in bytes)
19
>             {
20
>                 BitArray bits = new BitArray(new byte[] { b });
21
> 
22
>                 //startbit
23
>                 vhdlCode.Add(" RXDIN <= '0';      -- Startbit" + 
24
> Environment.NewLine);
25
>                 vhdlCode.Add(" wait for 4333 ns;" + 
26
> Environment.NewLine);
27
> 
28
>                 for (int a = 0; a <= 7; a++)
29
>                 {
30
>                     if (bits[a])
31
>                     {
32
>                         vhdlCode.Add(" RXDIN <= '1';" + 
33
> Environment.NewLine);
34
35
>                 vhdlCode.Add(" wait for 4333 ns;" + 
36
> Environment.NewLine);
37
> 
38
> 
39
> 
40
>             }
41
>             vhdlCode.Add("wait for 500 us;" + Environment.NewLine);
42
>             return vhdlCode;
43
>         }
44
>



Hm, ich seh grad keinen Sinn darin 50 Zeilen c++ zu tippern um 10 zeilen 
VHDL zu generieren. Was ist daran vorteilhaft?

MfG

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Fpga Kuechle schrieb:
> 50 Zeilen c++ zu tippern um 10 zeilen
> VHDL zu generieren.
Wenn man nur einen Hammer hat, sieht die ganze Welt wie ein Nagel aus...

: Bearbeitet durch Moderator
von Mike (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Lothar Miller schrieb:
> Fpga Kuechle schrieb:
>> 50 Zeilen c++ zu tippern um 10 zeilen
>> VHDL zu generieren.
> Wenn man nur einen Hammer hat, sieht die ganze Welt wie ein Nagel aus...

Hmm, wo schreibt er denn das er nur ein Zeichen simulieren möchte?

> Damit lassen sich dann auch komplizierte
> Protokolle einfach simulieren.

Aber hey, ihr beide macht natürlich niemals Copy&Paste Fehler und könnt 
ASCII im Kopf in den entsprechenden Binärcode übersetzen ;).

von jibi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Moin,

>50 Zeilen c++

Wo? Ist c#.

>Hmm, wo schreibt er denn das er nur ein Zeichen simulieren möchte?

:) Genau. Und man muss sich die Simulation ja nicht anschauen, wenn 
diese seine Ergebnisse wiederrum in eine Datei schreibt. Man generiert 
also eine neue Simulationsdatei, startet diese per batch und polled auf 
das Auftauchen / Datumsänderung der Ausgabedatei. Diese kann man wieder 
weiterverarbeiten und und und...

>Hm, ich seh grad keinen Sinn darin 50 Zeilen c++ zu tippern um 10 zeilen
>VHDL zu generieren. Was ist daran vorteilhaft?

Ach ja: Windowstaste + "calc" eingeben + Enter drücken + "Ascii Tabellen 
Links öffnen + zu sendenen String einzeln in ascii zeichnen umwandeln, 
im Taschenrechner eingeben+ auf binäre ansicht umschalten + rückwärts 
notieren + Vhdl simualations code für jedes bit schreiben + start und 
stopbit nicht vergessen...Du hast ja Hobbys :) Mir macht das kein 
Spass...

Das macht natürlich nicht immer Sinn und nicht alles lässt sich sinnvoll 
automatisieren, das muss mal lernen einzuschätzen.

Schönen Sonntag noch!

Gruß Jonas

von wosnet (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Das Problem bei dem Beispiel ist, dass man sich immer noch die Waveforms 
anschauen muss, um rauszufinden ob das Modul funktioniert.
IMHO ist eine gute Testbench vollkommen automatisch, d.h. es werden alle 
möglichen/sinnvollen Stimuli generiert und für jedes das Ergebnis gleich 
mit dem bekannten und erwarteten Ergebnis geprüft und für jeden Testfall 
"pass" oder "fail" ausgegeben wird. (self-checking testbench).
Gibt auch von Xilinx ein App-Note dazu, allerdings für Verilog (aber ist 
ja fast das Gleiche wie VHDL): 
http://www.xilinx.com/support/documentation/application_notes/xapp199.pdf

von jibi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>Das Problem bei dem Beispiel ist, dass man sich immer noch die Waveforms
>anschauen muss, um rauszufinden ob das Modul funktioniert.

Eben nicht, wenn die States der Signale ausgegeben werden und du sie mit 
dem Sollzustand vergleichst. Einfaches Beispiel: Du willst Koeffizienten 
eines digitalen Filters übertragen. Da das nicht die einzigen Parameter 
sind, gibt es ein kleines Protokoll das die Übertragung steuert. Lass es 
mal 4 Bytes fürn Header + 4 Koeffizienten sein, macht 4 + 4 * 8 = 
36Bytes. 4 Signale im Design sollten nach erfolgreicher Übertragung die 
Koeffizienten gespeichert haben. Man generiert dafür mit meinem kleinen 
Beispielcode die Simulationsdatei, lässt die Simulation per script 
laufen und schaut sich anschließend die Ergebnisse in der ausgegebnen 
Datei an. Das lässt sich wunderbar erweitern und sogar für umfangreicher 
Testreihen erweitern.
Darum geht's hier. Ob die Hardware richtig funktioniert kannst du 
hiermit nur bedingt checken, du verlagerst nur Test's von einer 
funktionierenden Hardware auf den PC. gruß jonas

von jibi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Noch was:
Auf dem "Low-Level" auf dem da getestet wird, kannst du aber z.B den 
Rs232-Core nur den auf grundsächliche und allgemeine Funktion testen. 
Auf dem Level testest du aber keine "High-Level" Protokollfunktion.

von wosnet (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich sehe aber in dem von Dir geposteten Skript weder 
Ausgabe-Anweisungen, noch Monitor-Anweisungen, noch Überprüfungen der 
Signale, die aus dem DUT rauskommen. Daher würde ich um eine kurze 
Erleuchtung bitten, wie ich mit dem C-Skript vermeide, mir Waveforms 
anschauen zu müssen.

von wosnet (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Noch was:
Verilog/VHDL bringen die ganzen Check-Funktionen schon mit, da muss man 
eigentlich kein C-Skript schreiben und nachher Dateien parsen.

von Fpgakuechle K. (fpgakuechle) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
jibi schrieb:
> Moin,
>
>>50 Zeilen c++
>
> Wo? Ist c#.
>
>>Hmm, wo schreibt er denn das er nur ein Zeichen simulieren möchte?
>
> :) Genau. Und man muss sich die Simulation ja nicht anschauen, wenn
> diese seine Ergebnisse wiederrum in eine Datei schreibt. Man generiert
> also eine neue Simulationsdatei, startet diese per batch und polled auf
> das Auftauchen / Datumsänderung der Ausgabedatei. Diese kann man wieder
> weiterverarbeiten und und und...

Ja und dazu braucht man C ? Der VHDL standard hat ein textio-io package, 
damit kann man wunderbar Stimuli einlesen und reports schreiben.
Viele Simulatoren bringen darüber hinaus ein tcl interface mit und damit 
die Verbindung zu tcl-string-verarbeitung etc.

>
>>Hm, ich seh grad keinen Sinn darin 50 Zeilen c++ zu tippern um 10 zeilen
>>VHDL zu generieren. Was ist daran vorteilhaft?
>
> Ach ja: Windowstaste + "calc" eingeben + Enter drücken + "Ascii Tabellen
> Links öffnen + zu sendenen String einzeln in ascii zeichnen umwandeln,
> im Taschenrechner eingeben+ auf binäre ansicht umschalten + rückwärts
> notieren + Vhdl simualations code für jedes bit schreiben + start und
> stopbit nicht vergessen...Du hast ja Hobbys :) Mir macht das kein
> Spass...

Das macht auch keiner, man kann auch in VHDL Unterprogramme, Schleifen 
für stimule verwenden, ascii zu bit konvertieren (wers nicht selber 
schreiben will sucht mit google nach der passenden bibliothek/beispiel 
wie Beitrag "std_logic_vector zu ASCII wandeln" ).

Warum das Rad zum 99 Mal erfinden und warum dann in C???

MfG,

von jibi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>Ich sehe aber in dem von Dir geposteten Skript weder
>Ausgabe-Anweisungen, noch Monitor-Anweisungen, noch Überprüfungen der
>Signale, die aus dem DUT rauskommen. Daher würde ich um eine kurze
>Erleuchtung bitten, wie ich mit dem C-Skript vermeide, mir Waveforms
>anschauen zu müssen.

>Noch was:
>Verilog/VHDL bringen die ganzen Check-Funktionen schon mit, da muss man
>eigentlich kein C-Skript schreiben und nachher Dateien parsen.

Meine Beschreibung und die Funktion als Beispiel deklariert sollte eben 
nur zeigen dass man sich einfache und trotzdem nützliche Testtools 
selber schreiben kann - und damit viel Zeit sparen. Was genau willst du 
jetzt?
Soll ich dir zeigen, wie die Syntax zum Öffnen von Dateien in c# (zum 2. 
mal kein C++ weder C) aussieht? Wie man strings parsed?

Ich zeige eine horizontöffnende Sicht und du laberst nur rum.

Gruß Jonas

von Fpgakuechle K. (fpgakuechle) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
wosnet schrieb:
> Noch was:
> Verilog/VHDL bringen die ganzen Check-Funktionen schon mit, da muss man
> eigentlich kein C-Skript schreiben und nachher Dateien parsen.

Genau in VHDL nennt sich des 'assert' :
http://vhdl.renerta.com/mobile/source/vhd00007.htm

von Fpgakuechle K. (fpgakuechle) Benutzerseite


Bewertung
-1 lesenswert
nicht lesenswert
jibi schrieb:
>>Ich sehe aber in dem von Dir geposteten Skript weder

> Ich zeige eine horizontöffnende Sicht und du laberst nur rum.

PLONK - Dont feed the troll

von jibi (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Das ich nicht lache, dir ist doch nicht mal bewusst was das "don't feed 
the troll" aussagen soll. Ist mir jetzt auch egal.
>Wenn man nur einen Hammer hat, sieht die ganze Welt wie ein Nagel aus...

von jibi (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
>Die Testbenches in der Simulationsphase sind nicht dem Test in der
>Softwareentwicklung gleichzusetzen. Sie uberprüft die logische Funktion
<soweit das man auf die reale Hardware wechseln. In testbenches alle
>zeitlichen Zusammenhänge und asynchronitäten zu testen ist mindestens
>langwierig zuweilen hoffnungslos. Deshalb genügt bei diesem
>Zwischenschritt dem Hardwareentwickler eine Testbench, die der
>Softwerker als unvollständig empfindet.

Hier beschreibst du doch den Einsatzzweck solcher Tools selbst ganz 
genau.
Mehr als auf PC-Seite möglichst viel testen zu können, kann doch gar 
nicht das Ziel sein. Und wenn du jetzt noch verstehen würdest auf 
welchem Level die von mir angesprochenen Tests laufen (nämlich 
Applikation Level) dann würdest du auch endlich dahinter steigen um was 
es mir von Anfang an geht, was ich zeigen wollte und würdest nicht darum 
krakeelen.

gruß Jonas

von wosnet (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> Ich zeige eine horizontöffnende Sicht und du laberst nur rum.

Entschuldige mein "Gelaber". Ich habe hier nur den Hinweis auf 
"self-checking" testbenches gegeben.

> Was genau willst du jetzt?

Der TO ist neu in digitalem Entwurf und fragte, wie man Testbenches 
schreiben kann. Du zeigtest ein Beispiel und hast behauptet, man kann 
damit ohne Waveforms anzuschauen automatisch auf Korrektheit prüfen. Ich 
kann das so leider nicht nachvollziehen. Eventuell gibst Du mal ein 
Beispiel Deiner Methode, das auch nachvollziehbar ist?

von berndl (Gast)


Bewertung
0 lesenswert
nicht lesenswert
jibi schrieb:
>>Ich sehe aber in dem von Dir geposteten Skript weder
>>Ausgabe-Anweisungen, noch Monitor-Anweisungen, noch Überprüfungen der
>>Signale, die aus dem DUT rauskommen. Daher würde ich um eine kurze
>>Erleuchtung bitten, wie ich mit dem C-Skript vermeide, mir Waveforms
>>anschauen zu müssen.
>
>>Noch was:
>>Verilog/VHDL bringen die ganzen Check-Funktionen schon mit, da muss man
>>eigentlich kein C-Skript schreiben und nachher Dateien parsen.
>
> Meine Beschreibung und die Funktion als Beispiel deklariert sollte eben
> nur zeigen dass man sich einfache und trotzdem nützliche Testtools
> selber schreiben kann - und damit viel Zeit sparen. Was genau willst du
> jetzt?
> Soll ich dir zeigen, wie die Syntax zum Öffnen von Dateien in c# (zum 2.
> mal kein C++ weder C) aussieht? Wie man strings parsed?
>
> Ich zeige eine horizontöffnende Sicht und du laberst nur rum.
>
> Gruß Jonas

Nee, er labert nicht rum! Das was da oben in C-haumichblau gemacht 
wurde, kannst du out-of-the-box in VHDL erledigen. Und noch viel mehr 
(ohne die Ergebnisse erst wieder muehsam parsen zu muessen)!

Der Vorteil, wenn du das alles in VHDL (oder auch Verilog) machst, ist, 
du brauchst keine 2. Toolchain! Du machst das alles in einer Umgebung 
(compile, run). Was da oben in C-irgendwas steht, kannst du direkt in 
deiner HDL machen/hinschreiben. Du brauchst keine separat aufzurufende 
Toolchain (Stichwort: Windows/Linux). Also nimm dein C# und werde 
gluecklich. Vlt. hast du ja den Eindruck, etwas ganz tolles erfunden zu 
haben... HDLer machen sowas aber built-in schon seit Jahren!

von jibi (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
>...

Schwachfug. Warum für IO-Sachen vhdl benutzen? Hast du irgendwie nen 
Fetisch?
Klar geht das, aber in der Frage des TO ging es um "richtige" 
Testbenches. Also sogenannte judäische Testbenches und nicht die 
Testbenches von Judäa. Manoman. Ist doch klar.

>Der Vorteil, wenn du das alles in VHDL (oder auch Verilog) machst, ist,
>du brauchst keine 2. Toolchain!

Ah, c# auf Windows nennst du "Toolchain"?! Das ist wohl eher die 
ultimative Komplettlösung die dir Mircosoft da zur Verfügung stellt. Für 
ume. Man muss halt mal die Angst und Vorurteile vor anderen Sprachen 
verlieren. Ein guter Informatiker zeichnet sich sogar dadurch aus, das 
er die passenden Werkzeuge finden bzw. erstellen kann. Niemand 
interessiert sich für den Weg später...
Ich glaube langsam läuft das aus dem Ruder und wird zu subjektiv - auch 
von meiner Seite aus. Ich wollte ein Beispiel aufzeigen, dass man auch 
mal die ISE Umgebung verlassen kann um Tests zu schreiben.

... Sorry hab noch was anderes zu tun, aber an den TO:

Wenn du dann zum 30. mal den Windowsrechner für eine dez->bin Umwandlung 
benutzt hast, kannst du eventuell das schlechte Gefühl in einem 
helfenden Prgrogramm kannalisieren.

Gruß Jonas

von berndl (Gast)


Bewertung
0 lesenswert
nicht lesenswert
jibi schrieb:
> Schwachfug. Warum für IO-Sachen vhdl benutzen? Hast du irgendwie nen
> Fetisch?
> Klar geht das, aber in der Frage des TO ging es um "richtige"
> Testbenches. Also sogenannte judäische Testbenches und nicht die
> Testbenches von Judäa. Manoman. Ist doch klar.
>
>>Der Vorteil, wenn du das alles in VHDL (oder auch Verilog) machst, ist,
>>du brauchst keine 2. Toolchain!
>
> Ah, c# auf Windows nennst du "Toolchain"?! Das ist wohl eher die
> ultimative Komplettlösung die dir Mircosoft da zur Verfügung stellt. Für
> ume. Man muss halt mal die Angst und Vorurteile vor anderen Sprachen
> verlieren. Ein guter Informatiker zeichnet sich sogar dadurch aus, das
> er die passenden Werkzeuge finden bzw. erstellen kann. Niemand
> interessiert sich für den Weg später...
> Ich glaube langsam läuft das aus dem Ruder und wird zu subjektiv - auch
> von meiner Seite aus. Ich wollte ein Beispiel aufzeigen, dass man auch
> mal die ISE Umgebung verlassen kann um Tests zu schreiben.
>
> ... Sorry hab noch was anderes zu tun, aber an den TO:
>
> Wenn du dann zum 30. mal den Windowsrechner für eine dez->bin Umwandlung
> benutzt hast, kannst du eventuell das schlechte Gefühl in einem
> helfenden Prgrogramm kannalisieren.
>
> Gruß Jonas

sorry, meiner Meinung nach schwafelst du! Ich starte meine Simulationen 
(mit random pattern und/oder wahlweise auch mit fixed-pattern) mit VHDL. 
Ich muss nicht krampfhaft daran denken, vorher ein Script/Programm 
aufzurufen, um neue Testpattern zu generieren. Das macht der Simulator 
ganz alleine!

Zu C# auf Windows kann ich nix sagen, da ich hier nur Linux benutze. 
Alleine um deine Testcases hier laufen zu lassen, muesste ich mir hier 
eine C# kompatible Umgebung installieren.

Und nochmal: Warum sollte ich eine 2. Sprache (und 2. Toolchain) ins 
Spiel bringen, wenn ich es mit den built-in Faehigkeiten machen kann. 
Ich bin mal echt gespannt auf deine Antwort!

von berndl (Gast)


Bewertung
0 lesenswert
nicht lesenswert
achso, zur Vollstaendigkeit:

Ich mache auch Auswertungen ueber die Simulationen. Dazu benutze ich 
PERL. Warum: Laeuft identisch unter Windows und Linux, ist ein 
Interpreter und braucht also kein Compile.

Dein C# Ansatz bringt mich nicht wirklich weiter...

von jibi (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
>...
Schwafeln? "Weil du perl ich c#" um es mal auf deinem Sprachniveau 
auszudrücken? Ich zeige direkt ein Stück Code, erklär dazu wie und warum 
ich es eingesetzt habe. Du verlinkst steinhartes Brot und glaubst der 
zahnose To kann das kauen?

von Matthias (Gast)


Bewertung
0 lesenswert
nicht lesenswert
... oder die vhdl-build-in-conversion verwenden... ^^

von jibi (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Machen wir eine doch mal ein pro / contra Liste:

>sorry, meiner Meinung nach schwafelst du! Ich starte meine...mit VHDL.

>Man generiert dafür mit meinem kleinen
>Beispielcode die Simulationsdatei, lässt die Simulation per script
>laufen und schaut sich anschließend die Ergebnisse in der ausgegebnen
>Datei an. Das lässt sich wunderbar erweitern und sogar für umfangreicher
>Testreihen erweitern.

Tests für umfangreiche Protokolle sind ebenso umfachreich, eine 100% 
Abdeckung aller Testfälle, davon kannst du meist nur träumen bzw. du 
darfst dich nicht darauf einschießen. Lieber robuste und komfortable 
Abdeckung 95% aller Fälle + Handarbeit statt lauwarme 99% Abdeckung bei 
Vollmond.

1:0

>Ich mache auch Auswertungen ueber die Simulationen. Dazu benutze ich
>PERL. Warum: Laeuft identisch unter Windows und Linux, ist ein
>Interpreter und braucht also kein Compile.

>Der Vorteil, wenn du das alles in VHDL (oder auch Verilog) machst, ist,
>du brauchst keine 2. Toolchain! Du machst das alles in einer Umgebung
>(compile, run).

Mh...da relativierst du doch dein Aussage gegenüber meinen vollständig.
Nichts anderes sag ich doch.

2:0

Langsam geht's mir zu sehr nach, dein Auto mein Auto...
dabei habe ich gar kein Auto :D Peace

von Alexander F. (alexf91)


Bewertung
0 lesenswert
nicht lesenswert
Arbeitet hier eigentlich jemand mit Equivalence Checking?
Also ein abstraktes Modell in SystemC/SystemVerilog und eine 
Beschreibung auf RTL Level in VHDL / Verilog?

von Fpgakuechle K. (fpgakuechle) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Alexander F. schrieb:
> Arbeitet hier eigentlich jemand mit Equivalence Checking?
> Also ein abstraktes Modell in SystemC/SystemVerilog und eine
> Beschreibung auf RTL Level in VHDL / Verilog?

Equivalence Checking kommt aus der ASIC entwicklung und soll 
sicherstellen das die Funktion nicht verändert wird bei automatischen 
Syntheseschritten. Synthese meint hier jede Tool-gesteuerte Umformung 
resp Ergänzung der Netzliste. Das gängige Standardbeispiel ist die 
Überprüfung, ob der Einbau des Scanpaths (bspw für den JTAG-Boundary 
Scan) nichts "kaputtmacht".

IM FPGA-bereich stellt sich so eine Aufgabe kaum. Wenn dann greift man 
auf regressionstest (VHDL/Verilog-Simulation) mit den backannotierten 
Netzlisten zurück, verwendet also den selben Satz an 
Stimuli/Referenzpattern für unterschiedliche Abstarktionsebenen.

Die für FPGA's zurechtgeschneiderte EC-Tools dafür werden noch nicht 
lange angeboten:

http://www.xilinx.com/products/intellectual-property/1-2J8NGL.htm


An praxisbeispielen wo EC sinnvoll in der FPGA-Einwicklung eingesetzt 
wird, bin ich auch interessiert. Extra Thread dafür ist IMHO agebracht.

MfG,

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
jibi schrieb:
> Warum für IO-Sachen vhdl benutzen?
Naja, das Beispiel mit der seriellen Schnitte, das du da oben so 
explizit angebracht hast, das ist doch genau das, wofür VHDL gemacht 
ist: die Beschreibung von Systemen. Und genau für die Simulation kann 
ich ja 100% des Sprachumfangs verwenden, das ist doch toll, wo ich für 
die Synthese gerade mal 5% davon verwenden darf. Und gerade das Senden 
und Empfangen eines einzelnen Zeichens mit einer SIO ist doch mit VHDL 
in einer Funktion einfach abzuhandeln. Und wenn man das kann, dann kann 
man einfach Zeichen aus einer Datei lesen, versenden, und die parallel 
dazu empfangenen Zeichen wieder in eine Datei schreiben.

Natürlich ist die Erzeugung von Stimulidateien und die Auswertung 
der Ergebnisse evtl. leichter mit externen Tools zu erledigen (z.B. 
Daten aus der realen Welt oder mathematische Modelle), aber die 
Ansteuerung der eigentlichen Hardware, das kann VHDL doch echt super...

Zurück zur eigentlichen Frage:
Robert S. schrieb:
> ... Testbenches zeigen, die den Namen Testbench verdient hat?
Im einfachsten Fall z.B. so:
http://www.lothar-miller.de/s9y/archives/78-Bubblesort.html
Diese Testbench kann unbeaufsichtigt die ganze Nacht durchlaufen. Bei 
einem Fehler bleibt sie einfach stehen.

> In der wirklich sauber das Verhalten einer FSM überprüft wird?
Was bedeutet hier "wirklich sauber"?
Ich möchte da mal angelegentlich auf den 
Beitrag "WHEN OTHERS in einer FSM" verweisen.

von René D. (Firma: www.dossmatik.de) (dose)


Bewertung
0 lesenswert
nicht lesenswert
Lothar Miller schrieb:

> Wenn man nur einen Hammer hat, sieht die ganze Welt wie ein Nagel aus...

Den Spruch muss ich mir merken.




Ein guter Einstieg ist hier zu finden.

http://www.stefanvhdl.com/

von Klakx (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Fpga Kuechle schrieb:
> Alexander F. schrieb:
>> Arbeitet hier eigentlich jemand mit Equivalence Checking?
>> Also ein abstraktes Modell in SystemC/SystemVerilog und eine
>> Beschreibung auf RTL Level in VHDL / Verilog?
>
> Equivalence Checking kommt aus der ASIC entwicklung und soll
> sicherstellen das die Funktion nicht verändert wird bei automatischen
> Syntheseschritten. Synthese meint hier jede Tool-gesteuerte Umformung
> resp Ergänzung der Netzliste. Das gängige Standardbeispiel ist die
> Überprüfung, ob der Einbau des Scanpaths (bspw für den JTAG-Boundary
> Scan) nichts "kaputtmacht".

Ihr redet glaube beide vorbei. Die Antwort ist richtig, wenn Formal 
Equivalence Checking gemeint ist, also Formale Verifikation.

Ich glaube Alexander meint aber etwas anderes. Es bietet sich wirklich 
an (und auch für den FPGA) Testbenches in SystemC, sowie Referenzmodule 
in SystemC zu modellieren. Wenn man dies dann auf dem FPGA testet, kann 
man die Testbench leichter in die Testsoftware bringen. In vielen 
marktreifen IPs mit hoher Qualität wird dies durchgeführt.

von Marcus H. (mharnisch) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Alexander F. schrieb:
> Also ein abstraktes Modell in SystemC/SystemVerilog und eine
> Beschreibung auf RTL Level in VHDL / Verilog?

Ja. Zur Zeit allerdings Specman/e (testbench) und SystemVerilog (RTL).

SystemC fehlen wichtige Eigenschaften, die man zur Verifikation 
benötigt, z.B. Functional Coverage und Assertions. Andere Konstrukte, 
wie Constrained Random Stimulus sind zwar irgendwie vorhanden, durch die 
Beschränkung auf C++ aber nicht so richtig brauchbar. SystemC dient eher 
der Erstellung von Modellen die durchaus auch in der Verifikation 
Verwendung finden, ist aber selbst als alleinige Verifikationssprache 
ungeeignet.

von Jürgen S. (engineer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Klakx schrieb:

> Es bietet sich wirklich
> an (und auch für den FPGA) Testbenches in SystemC, sowie Referenzmodule
> in SystemC zu modellieren. Wenn man dies dann auf dem FPGA testet
Was verstehst Du hier genau unter "Testen"? Testen ist für mich ein 
realer Funktionstest an der Baugruppe, definitionsgemäss sogar in der 
Fertigung. Alles andere ist Verifikation.

>, kann
> man die Testbench leichter in die Testsoftware bringen.
Du meinst, die SystemC-basierte TB leichter in die (System-C-basierte) 
Testsoftware bringen?

von Klakx (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jürgen Schuhmacher schrieb:
> Was verstehst Du hier genau unter "Testen"? Testen ist für mich ein
> realer Funktionstest an der Baugruppe, definitionsgemäss sogar in der
> Fertigung. Alles andere ist Verifikation.

In diesem Fall: Verifikation.

Jürgen Schuhmacher schrieb:
>
>>, kann
>> man die Testbench leichter in die Testsoftware bringen.
> Du meinst, die SystemC-basierte TB leichter in die (System-C-basierte)
> Testsoftware bringen?

Ich meine, dass die SystemC-basierte TB in eine CPU im FPGA portiert 
wird. Ja, es entspricht damit einer Testsoftware. Die Tests in der 
Simulation laufen somit auch real auf der Hardware.

von Helge K. (helge_k97)


Bewertung
0 lesenswert
nicht lesenswert
Das mit der Testbench Erstellung, ist definitiv Geschmackssache.
Man muss immer abwegen, zwischen Nutzen und Sinnhaftigkeit. Was nutzen 
mir 100% Coverage, wenn ich die letzten 5-10% herbei Manipulieren muss, 
nur um die „Angstzustände“ abzudecken?
100% Coverage sehen schön aus, aber es heißt noch lange nicht ob die 
Funktionalität, besonders auf dem FPGA, gegeben ist.

Ich versuche möglichst in der jeweiligen RTL Sprache zu bleiben, das 
vereinfacht das ganze gegenüber dritten erheblich und Interfacefehler 
werden vermieden. Wenn es nicht geht, dann eben über eine weitere 
Sprachen/Skripte.

Egal in welcher Beschreibungs- /Programmiersprache die TestBench 
erstellt wird, ist es für mich wichtig, dass die Testbench über ein 
Skript gestartet werden kann und am Ende ein Status (Fail, Pass) über 
den Test mitgeteilt wird.
Die Testeinstellungen, Testablauf, Testhinweise und die jeweiligen 
Überprüfungen müssen in einem Log zur Laufzeit protokolliert werden.
Das ganze klingt zwar nach einem gewaltigen overhead, ist es aber nicht. 
Man muss sich halt vorher Gedanken machen, wie ein Test auszusehen hat.

Meiner Meinung nach, hat eine TestBench mit manueller Überprüfung 
(Waveform), den Namen TestBench nicht verdient.

von Marcus H. (mharnisch) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Helge K. schrieb:
> Das mit der Testbench Erstellung, ist definitiv Geschmackssache.
> Man muss immer abwegen, zwischen Nutzen und Sinnhaftigkeit. Was nutzen
> mir 100% Coverage, wenn ich die letzten 5-10% herbei Manipulieren muss,
> nur um die „Angstzustände“ abzudecken?

Definiere erstmal, was genau Du mit Coverage meinst. Wenn ein 
Verifikationsplan existiert, dann müssen selbstverständlich auch 100% 
davon erfüllt sein. Sonst hätte ich mir die übrigen Punkte auch 
(begründet) sparen können.

> 100% Coverage sehen schön aus, aber es heißt noch lange nicht ob die
> Funktionalität, besonders auf dem FPGA, gegeben ist.

100% Coverage sagen erstmal, dass alles was im Plan drin steht erfasst 
wurde. Es sagt nicht, ob alles drin stand. Daraus den Umkehrschluss zu 
ziehen, dass das Erreichen der 100 unnötig sei, wäre allerdings ein 
grober Fehler.

> Ich versuche möglichst in der jeweiligen RTL Sprache zu bleiben, das
> vereinfacht das ganze gegenüber dritten erheblich und Interfacefehler
> werden vermieden. Wenn es nicht geht, dann eben über eine weitere
> Sprachen/Skripte.

Das letzte Mal, dass ich eine TB in der RTL Sprache geschrieben habe ist 
über zehn Jahre her.

von mario (Gast)


Bewertung
0 lesenswert
nicht lesenswert
wir schreiben TBs meist in systemverilog, und dann einen Teil in SV, 
wenn wir im Chip einen SPI slave haben bspw. einen SPI master, und den 
rest dann ueber DPI(https://en.wikipedia.org/wiki/SystemVerilog_DPI) in 
C bzw. Matlab.
Um die testcases zu finden wird ordentlich nachgedacht, und wenn man 
ferit gist kann man noch mal coverage analyse laufen lassen, dass auch 
jedes FF mal geschalten wurde im test.
muss man aber wissen ob es einem das wert ist beim FPGA.
wichtig ist gute stimuli zu erzeugen, das wird bei uns also mit einer 
mischung aus C und SV gemacht.
ich habe auch schon ein prjekt gemacht wo wir die stimuli mit python 
erzeugt haben und dann ueber vhdl eingelesen und abgespielt, kommt halt 
immer drauf an worauf man lust hat. in einem FPGA-Projekt macht es aber 
sicherlich nur bedingt sinn das ganze system 2 mal zu implementieren.

von Klakx (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Marcus Harnisch schrieb:
> Definiere erstmal, was genau Du mit Coverage meinst. Wenn ein
> Verifikationsplan existiert, dann müssen selbstverständlich auch 100%
> davon erfüllt sein. Sonst hätte ich mir die übrigen Punkte auch
> (begründet) sparen können.

Bei Funktionscoverage natürlich 100%.

Ich glaube hier ist jedoch die Rede von Codecoverage. Da gibt es immer 
ein paar Sachen. >98% gilt üblich als ausgezeichnete Abdeckung.

von Hanni (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
mario, hoffentlich sind Eure Testcases ausgefeilter als Deine 
Rechtschreibung - einfach nur grauenhaft!

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
-1 lesenswert
nicht lesenswert
Hanni schrieb:
> mario, hoffentlich sind Eure Testcases ausgefeilter
Pluralis Majestatis?
Sonst müsste nach aktueller Rechtschreibung das e klein sein.
Hanni schrieb:
> Rechtschreibung - einfach nur grauenhaft!
Und kompliziert! Und man fängt sich so leicht ein Eigentor ein...

: Bearbeitet durch Moderator
von Helge K. (helge_k97)


Bewertung
0 lesenswert
nicht lesenswert
Marcus Harnisch schrieb:
> Definiere erstmal, was genau Du mit Coverage meinst.

So schnell kann es gehen, ich meinte hier CodeCoverage.
Das eine Functionalcoverage 100% haben sollte, ist unumstritten.

von Hanni (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wie gesagt: Es ist eine Zumutung für den Leser, derartige Beiträge zu 
lesen!

von Marcus H. (mharnisch) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Helge K. schrieb:
> ich meinte hier CodeCoverage.

Dazu habe ich ja meine Meinung schon anderswo kundgetan:
Beitrag "Re: VHDL Statement coverage für Arme?"
Beitrag "Re: VHDL Statement coverage für Arme?"

Dennoch ist auch hier die Frage zu stellen, warum <100% akzeptabel sein 
soll. Das muss im Detail begründet werden, was ebenfalls wieder Aufwand 
bedeutet. Dann ist es vielleicht besser die "Angstzustände" gar nicht 
erst zuzulassen.

von Duke Scarring (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Helge K. schrieb:
> Meiner Meinung nach, hat eine TestBench mit manueller Überprüfung
> (Waveform), den Namen TestBench nicht verdient.
Hast Du trotzdem einen hübschen Namen für die optische Waveformprüfung?

von Christian R. (supachris)


Bewertung
0 lesenswert
nicht lesenswert
Waveform angucken ist zum "Debuggen" schon mal sinnvoll. Ansonsten 
versuche ich alles auf Modulebene mit Herstelle-Modellen (Flash, 
RAM...), Asserts und File I/O zu simulieren. Das Gesamtsystem zu 
simulieren ist durch die Komplexität meist so langsam, dass es nicht 
lohnt. Solange die Module durch die Simulation durchkommen ist bei uns 
der nächste Schritt, dass das Design per Teamcity gebaut wird, das 
Bitfile auf die Hardware kommt und dann von Teamcity mit automatisierten 
Tests befeuert wird. Da weiß man dann schnell, wo was klemmt. Dazu bauen 
wir zum einen in das Design "versteckte" Testmöglichkeiten ein und zum 
zweiten haben wir diverse Generatoren usw. um die Hardware zu 
stimulieren. Damit sind wir bisher sehr gut gefahren, aber wir machen 
auch weder Automotive noch Avionik.

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
Duke Scarring schrieb:
> einen hübschen Namen für die optische Waveformprüfung?
Man könnte es im Gegensatz zur "Verifikations-Testbench" einfach 
"Debug-Testbench" nennen. Denn das ist es, was mit der Waveform gemacht 
wird: eine Fehlersuche.
Wenn eine "Verifikations-Testbench" mir nach einer Änderung einen Fehler 
vor den Latz knallt, was mache ich dann? Ich suche den Fehler dann nicht 
anhand der "Fail" Meldung, sondern nehme die Waveform.

So wie ich zur Abnahme einer Elektronik auch keinen Logic Analyzer 
anklemme, wohl aber zur Fehlersuche...

von Helge K. (helge_k97)


Bewertung
0 lesenswert
nicht lesenswert
Lothar Miller schrieb:
> Man könnte es im Gegensatz zur "Verifikations-Testbench" einfach
> "Debug-Testbench" nennen. Denn das ist es, was mit der Waveform gemacht
> wird: eine Fehlersuche.

besser hätte ich es auch nicht beschreiben können

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.