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
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?
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
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
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
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
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 ;).
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
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
>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
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.
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.
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,
>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
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
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
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...
>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
> 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?
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!
>... 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
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!
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...
>...
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?
... oder die vhdl-build-in-conversion verwenden... ^^
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
Arbeitet hier eigentlich jemand mit Equivalence Checking? Also ein abstraktes Modell in SystemC/SystemVerilog und eine Beschreibung auf RTL Level in VHDL / Verilog?
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,
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.
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/
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.
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.
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?
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.
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.
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.
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.
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.
mario, hoffentlich sind Eure Testcases ausgefeilter als Deine Rechtschreibung - einfach nur grauenhaft!
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
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.
Wie gesagt: Es ist eine Zumutung für den Leser, derartige Beiträge zu lesen!
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.
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?
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.
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...
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.