Hallo zusammen -
Ich habe derzeit das Problem, viele Module auf ihre Funktion/Fehler etc.
zu untersuchen.
Welches Tool verwendet ihr um einen Verifikationsplan zu erstellen?
Excel?
Schreibt ihr für jeden Test eine eigene TestBench?
Dachte mir einen Plan in Excel zu schreiben, und die einzelnen
TestBenches in seperaten Reitern zu schreiben. Das ganze dann als ascii
raussschreiben lassen und simulieren.
Und - wie stellt ihr das an, wenn man die outputs mit zu erwarteten
outputs automatisch vergleichen möchte?
Hierzu hätte ich wieder excel verwendet.. aus der TestBench die outputs
in ein text-File schreiben lassen, in excel einlesen und mit einem macro
vergleichen..
Wäre für jegliche Anregung dankbar.
Grüße,
Peter
Wow: Generation Excel.
Excel ist doch was für's Marketing, nicht für Ingenieure...
Hier hat jedes Modul eine Testbench und die Referenzdaten werden per
Skript erzeugt. Außerdem gibt es eine Testbench für's Gesammtsystem, da
kann man dann sehen, ob die Module zusammenspielen.
Den Vergleich, ob ein Modul das Richtige ausspuckt macht ebenfalls die
Testbench.
Duke
Hallo Peter,
die Testpattern in Excel zu erzeugen kann durchaus Sinn machen. Je nach
dem wie umfangreich und generische die sind. Ganz egal wie du die
Testpattern erstellst, ich würde die Eingangssignale und die zu
erwartenden Ergebnisse hintereinander jeweils in eine Zeile in ein
Textfile bringen (z.B. Export von Excel). Diese Werte werden dann aus
der Testbench ausgelesen. Die Eingangssignale an die UUT weitergegeben
und die Ausgangssignale der UUT werden gleich in der Testbench mit den
zu erwartenden Werten vergleichen.
Bei einem Fehler kann die Testbench ja einen "assert" generieren und man
befindet sich dann gleich an der Stelle welche Probleme macht. Wenn der
Test Fehlerfrei durchläuft, spuckt Modelsim dann ein OK aus. Damit ist
ein test sehr schnell gemacht und bei Änderungen im Design diese sehr
schnell verifiziert.
Noch ein paar Tips:
- Für die Tests schreibe ich mir immer ein ".do"-file in dem schon die
Waves etc. schon enthalten sind.
- Am Ende des ".do"-files setze ich ein "run" mit einer sehr langen
Zeit, die sicher viel länge ist, als mein Test benötigt. Z.B. "run 100
ms". Ein OK am Ende der Testpattern generiere ich ebenfalls mit einem
"assert", da Modelsim sich nicht anders überreden lässt den Test zu
beenden. So läuft der Test immer genau so lange bis die Testpattern
abgearbeitet sind.
- Der Test mit Modelsim und dem ".do"-file rufe zudem noch über eine
Batch-Datei auf. Die Verifikation ist dann nur noch mit einem
Doppelklick im Explorer und dem Warten auf das OK sehr schnell erledigt.
- Im übrigen ist es Hilfreich in der Testbench einen Testpatternzähler
mit einzubinden, der im Fehlerfall noch die Zeilennummer aus dem
Testpatten-file liefert.
Ja, ich weiss - excel ist nicht gerade DAS Ingenieurstool.
Dennoch - irgendwie muesst ihr ja alle Tests verwalten, sprich eine
Tabelle etc. haben in der letztendlich pass/fail steht.
Aus genau der Tabelle hatte ich mir auch die Tests rausschreiben wollen.
So habe ich alles in einem file..
Was verwendet ihr als script-Sprache ? Perl ?
@Matthias:
>- Am Ende des ".do"-files setze ich ein "run" mit einer sehr langen>Zeit, die sicher viel länge ist, als mein Test benötigt. Z.B. "run 100>ms". Ein OK am Ende der Testpattern generiere ich ebenfalls mit einem>"assert", da Modelsim sich nicht anders überreden lässt den Test zu>beenden. So läuft der Test immer genau so lange bis die Testpattern>abgearbeitet sind.
Flasch.
Meine Testbenches halten an, wenn sie fertig sind (oder ein Fehler
auftritt):
@ Duke:
Tolle Idee einfach den Clock anhalten. Auf die Idee bin ich noch nicht
gekommen. Was allerdings ungünstig ist, ist dass die Waves ewig lang
werden.
Danke
@Matthias:
> Was allerdings ungünstig ist, ist dass die Waves ewig lang> werden.
Irgendwie stehe ich auf dem Schlauch, diesen Satz verstehe ich gerade
nicht.
Duke
@Matthias:
Hallo Matthias -
hast Du ein kleines Testbench Beispiel, indem Du zeigen kannst, wie Du
das machst?
<<ich würde die Eingangssignale und die zu
erwartenden Ergebnisse hintereinander jeweils in eine Zeile in ein
Textfile bringen (z.B. Export von Excel). Diese Werte werden dann aus
der Testbench ausgelesen. Die Eingangssignale an die UUT weitergegeben
und die Ausgangssignale der UUT werden gleich in der Testbench mit den
zu erwartenden Werten vergleichen.>>
Würde mich brennend interessieren. Arbeite noch nicht lange mit vhdl und
bin über jeden praktischen input dankbar..
Deshalb ja auch die Frage nach dem Verifikationsplan.
@Peter:
Es ist m.E. günstiger zwei getrennte Dateien zu verwenden: Eine für die
Eingangsdaten und die zweite für die Ausgangsdaten (und noch eine dritte
für Konfigurationsdaten, wenn nötig).
Aber ein Verifikationsplan ist etwas anderes. Da steht drin, welche
Tests durchgeführt werden/wurden. Die Tests selber wiederum können dann
systematisch sein (z.B. alle möglichen Eingangswerte), bestimmte
Grenzfälle abdecken oder mit Zufallswerten durchgeführt werden.
Da ist es hilfreich schon ein Modell in einer Hoch-/Skriptsprache (z.B.
matlab, perl, python) zu haben, womit man die passenden Vergleichsdaten
erzeugen kann.
Duke
> ich würde die Eingangssignale und die zu> erwartenden Ergebnisse hintereinander jeweils in eine Zeile in ein> Textfile bringen (z.B. Export von Excel). Diese Werte werden dann aus> der Testbench ausgelesen. Die Eingangssignale an die UUT weitergegeben> und die Ausgangssignale der UUT werden gleich in der Testbench mit den> zu erwartenden Werten vergleichen.
Ich denke nicht, dass sich eine solche Vorgangsweise für komplexere
Designs eignet.
Was soll denn überhaupt in jeder Zeile für die Eingangssignalen
drinnenstehen? Der Zustand zu jeder Taktflanke? Bei 300 MHz Taktrate und
10 ms Simulationszeit gibt das ewig große Dateien und ewig langsame
Simulation.
Wann soll denn der Ausgang abgegriffen und verglichen werden? Genau zur
Taktflanke oder später? Was ist mit asynchronen Signalen oder Busse, die
verzögert hochohmig werden?
Wie willst du denn deine Eingangsvektoren und Ausgangsvektoren erzeugen
und wie kannst Du sicher sein dass sie richtig sind wenn Du 100
Eingangs-/Ausgangssignale hast und diese für vielleicht 1 Mio Taktzyklen
beobachten willst?
Excel mag gehen, um wie gesagt, die Ergebnisse "Pass/Fail" zu sammeln,
aber nicht um die Testvektoren zu verwalten.
Gerade aus diesem Grund hat man ja VHDL (und Verilog) erfunden. Diese
sind eine Hochsprache, mit der man die Testsignale prozedural erzeugen
und überprüfen kann.
Wenn Du wirklich komplexere Designs testen willst, dann lernen
Testbenches zu schreiben. Dazu gehören BFMs (Bus Functional Models) und
sonstige Modelle von öfter verwendeten Units.
Aber letztendlich ist es immer ein Kompromiss zwischen Auswand und
Nutzen. Wenn ich Designs verkaufen will oder ein ASIC entwerfe, das ich
nicht mehr ändern kann, dann werde ich vieles sehr sorgfältig testen,
bis ich wirklich 100 % sicher bin.
Dann werde ich mir vielleicht auch die Mühe machen, Regression-Test zu
fahren, um sicher zu sein, dass durch eine spätere Änderung sich nichts
and der zuvor getesteten Funktion geändert hat.
Wenn ich ein FPGA verwende, dann werde ich mir möglicherweise zwar die
prinzipielle Funktion am Simulator ansehen, und nur wenn ich später
irgendwo Probleme habe, dies mit Hilfe des Simulators debuggen.
@ Klaus
> Aber letztendlich ist es immer ein Kompromiss zwischen Auswand und> Nutzen. Wenn ich Designs verkaufen will oder ein ASIC entwerfe, das ich
Das ist wohl wahr. Du hast hier viel ausgeführt. Und man kann sicherlich
keine allgemein Aussage treffen, welche Methode die für einen Test ist.
Das ist immer Designabhängig. Im Fall von 1000-Eingängenen und Millionen
Testpattern wird es schwierig und händisch sind die sowieso nicht mehr
zu schreiben.
Oft ist es aber geradezu sinnvoll ein Teilkomplex mit einer endlichen
Anzahl von Testpattern durchlaufen zu lassen. An einem Beispiel von
einem Addierer kann das z.B. so aussehen:
Der Addierer hat z.B. In_A und In_B und Result als Signale. Alle als
Integer (zur vereinfachung)
Die Testpattern könnten dann z.B. im File so aussehen:
2 5 7
9 23 22
...
Die Testbench ließt dann die drei Werte der Zeile ein. Leitet die Ersten
Beiden an die Eingänge, wartet von mir aus bis zur nächsten Taktflanke
und prüft den Result-Wert mit dem 3. Wert aus der Testbench. Bei einem
Fehler wird ein assert erzeugt. Dies wird so lange gemacht, bis das
File-Ende erreicht ist. Klingt doch irgendwie logisch.
Dies kann natürlich nicht alle Testfälle erschlagen. In Designs in denen
ich z.B. viele Eingänge habe und unterschiedliche Abläufe simulieren
möchte, definiere ich mir eine Art Befehlssatz. Dies sind Strings, die
in den Testpattern an erster Stelle stehen. Die darauf folgende Daten
sind dann je nach Befehl variabel. Die Testbench wiederum interpretiert
die Befehle und die Daten. Teilweise habe ich auch Makrofunktionalität
in den Befehlssatz mit eingebaut. Dies reduziert den Umfang der
Testpattern dann erheblich. Dies nur so als Beispiel.
Hi,
ich mach' das so: Zu eigentlich jeder Entity gibt es auch eine oder
mehrere Testbenches. Die arbeiten entweder mit fixen Parametern oder mit
Pseudo-Random-Pattern. Bei fixen Parametern gebe ich natuerlich auch die
erwarteten Ergebnisse vor, bei Pseudo-Random 'rechnet' die Testbench die
erwarteten Werte selber aus (in einer Procedure oder Function).
Darueber hinaus heissen meine Testbenches halt auch (Filename)
<design>_tb*.vhd.
Die Testbenches schreiben diverse Meldungen in ein Logfile
(<design>_tb*.log), da steht am Ende eben auch: 'All tests successfully
passed'.
Dann gehe ich mit einem Perl-Script ueber das Directory, werte aus was
ich alles so gefunden habe, und erzeuge davon ein <project>.html File im
passenden Doku-Verzeichnis. Da steht unter anderem auch drin, wann ich
diese Testbench zum letzten Mal laufen gelassen habe.
Damit habe ich auf 2 Bildschirmseiten eine gute Uebersicht, was ich im
Design in letzter Zeit gemacht bzw. simuliert habe, sowie eben auch der
Status.
Wenn man das einmal aufgesetzt hat und sich bei den Filenamen an gewisse
Randbedingungen haelt, dann faellt eine kurze Doku/Status sozusagen
'nebenbei' ab. Die Meldungen aus der Testbench enthalten auch noch
Infos, was diese TB denn testen will, das kommt als Kurzbeschreibung
natuerlich auch ins .html.
Also ich brauche kein Excel oder Calc...
> Darueber hinaus heissen meine Testbenches halt auch (Filename)> <design>_tb*.vhd.
Das handhabe ich genau so. Da gibt es einfache Restriktionen über
Filenamen, Erweiterungen und Verzeichnisstrukturen. Damit lässt sich das
meiste schon lösen.
Kannst Du mal dein Script mit einstellen. An dem hätte ich auch
Interesse.
Matthias
servus,
Verfikationsumgebungen werden bei groesseren Designs zumeist mit einer
constraint-random driven methodik aufgebaut. die benutzten
sprachen/tools dort sind aktuell hauptsaechlich specman-e bzw
systemverilog/ovm. dazu kommen assertions formal oder simulativ.
als planungstool gibt es zb. jasper gameplan
http://www.jasper-da.com/gameplan/ oder von cadence den Enterprise
Planner zum schreiben von verifikationsplaenen wobei letzerer im
zusammenspiel mit dem enterprise planner planung und status tracking
bzgl. unterschiedlichsten metriken abdeckt (code coverage,funktionale
coverage, directed tests pass/fail, formales pass/fail)(näheres
http://www.cadence.com/products/fv/Pages/mdv_flow.aspx). mentor hat auch
etwas in der richtung vorgestellt - habe aber den link nicht auf die
schnelle
das sind natuerlich keine pakete fuer den heimgebrauch :-). sonst gibt
es excel als input fuer eigene regression umgebungen bzw. auswertungen.
aber zumeist handelt es sich bei den excel loesungen um (lange) listen
mit directed tests.
mfg
/uwe
>Das handhabe ich genau so. Da gibt es einfache Restriktionen über>Filenamen, Erweiterungen und Verzeichnisstrukturen. Damit lässt sich das>meiste schon lösen.>>Kannst Du mal dein Script mit einstellen. An dem hätte ich auch>Interesse.>>Matthias
gerne, habe aber gerade gemerkt, dass ich in dem rekursiven Aufbau der
Dependency-List (quasi makefile) noch einen Bug habe. Wenn's dann mal
richtig tut poste ich's hier...
Gruss,
- berndl
>Also ich brauche kein Excel oder Calc...
Wie erzeugts Du in der VHDL Testbench die zu erwartenden Werte bei
algorithmischen FPGAs? VHDL kann weder Sinus, noch sonstwas, um irgendwo
einen sweep einzuspeisen. Viele Daten kriege ich auch aus MATLAB raus.
Da ist es das einfachste, die Daten und deren Erwartungswerte ins Excel
zu klopfen und sich ein VHDL-file machen zu lassen.
spricht ja nix dagegen, bei besonders stoerrischer Logik mit
vorgegebenen Werten in einer TB zu arbeiten. Zumindest mit ein paar
Eckwerten mache ich das auch immer, die TB kann ja schliesslich auch
fehlerhaft sein.
Aber die allermeisten Sachen kann man auch mit Random-pattern in einer
TB beschreiben und die Ergebnisse vorhersagen. Wenn ich auf die
Signal-waves schaue erwarte ich ja auch was ganz bestimmtes um die
Simulation bewerten zu koennen.
ok, hier wie versprochen mein PERL script zum checken des
Simulationsstatus (Beispiellogfile wie eine Testbench eine 'success'
message schreiben muss):
--------------------------------------
INFO: Testbench successfully completed
--------------------------------------
Hier nur die Sparversion, im G'schaeft ist die Ausgabe halt .html oder
.xml. Man kann auch .csv erzeugen und in excel importieren. Der Sinn der
Ausgabe sollte beim druebergehen klar werden.
Vielleicht kann's ja jemand gebrauchen, bitte den Disclaimer aber auch
beibehalten wenn ihr das verwendet und weiter entwickelt (und vor allem
Weiterentwicklungen dann auch hier posten, dann haben alle was davon).
