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):
1 | signal simulation_running : boolean := true; |
2 | |
3 | ...
|
4 | ...
|
5 | |
6 | clk <= not clk after 20 ns when simulation_running; |
7 | |
8 | ...
|
9 | ...
|
10 | main: process: |
11 | ...
|
12 | report "Simulation ends." |
13 | simulation_running <= false; |
14 | wait; |
15 | end process; |
16 | |
17 | ...
|
Duke
@ 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.
>Wow: Generation Excel. >Excel ist doch was für's Marketing, nicht für Ingenieure. Ich nutze seir Jahren Excel, um mir tabellarischen Code zu erzeugen
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.
> VHDL kann weder Sinus, noch sonstwas, um irgendwo > einen sweep einzuspeisen Aha. Und was ist das?!? http://www.csee.umbc.edu/help/VHDL/math_real.vhdl Duke
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).
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.