mikrocontroller.net

Forum: FPGA, VHDL & Co. Verifikationsplan


Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Matthias G. (mgottke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ?

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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):
  signal simulation_running : boolean := true;

  ...
  ...

  clk   <= not clk  after 20 ns when simulation_running; 
  
  ...
  ...
  main: process:
   ...
   report "Simulation ends."
   simulation_running <= false;
   wait;
  end process;

  ...

Duke

Autor: Matthias G. (mgottke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Klaus Falser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Matthias G. (mgottke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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.

Autor: Segor (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: berndl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Matthias G. (mgottke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: nixda (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: berndl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: berndl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: berndl (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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).

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]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [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.