Forum: FPGA, VHDL & Co. Python als Test-Umgebung für Simulationen


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 Martin K. (mkmannheim) Benutzerseite


Lesenswert?

Ich bräuchte einen kurzen Tipp zu dem Thema automatisierte Tests und 
Test-Script-Erstellung.

Ich möchte nach der Änderung eines Schaltungsdesigns einige Simulationen 
starten, die mir Ergebnisse in ein file schreiben (sollen, derzeit sind 
es Bildschirmausgaben).

Basierend auf diesen Ergebnissen, die hauptsächlich Werte aus 
Berechnungen sind, sollen dann kritische Fälle identifiziert werden. 
Diese bestehen aus einer langen Zeile, die der Simulator schreiben soll, 
die alle Startwerte für eine weitere Simulation enthalten.

Als Beispiel wären das  z.B. ein Reglerzustand, die Eingangswerte und 
die Einstellungen des Reglers und die Randbedingungen, die wirkten, als 
ein Überlauf stattfand.

Um diese Werte herum sollen dann weitere Grenzen genauer eingeengt und 
die Parameter des Reglers optimiert werden. Um das zu erreichen sollen 
diese Daten in einer weiteren Datentabelle abgelegt werden, um zu 
entscheiden, ob die neue Simulation nötig ist. Das kann ich mathematisch 
formulieren und prüfen indem die Fälle in Klassen einsortiert werden. 
Ein grundsätzlicher Fall muss dann nicht noch einmal gestartet werden, 
sondern der Fall wird etwas modifiziert, um die Abdeckung zu verbessern.

Es sollen dann mehrere weitere Simulationen mit diesen neuen Werten 
gestartet werden. Diese Simulationen müssen dann mit diesen neuen Werten 
"geladen" werden und solange ausgeführt werden, bis dieser Problem-Punkt 
erreicht ist, oder es gfs noch andere Probleme gibt.

So sollen sukzessive die Grenzen des Betriebs gefunden werden um die 
Sicherheit nachzuweisen.

Die Fragen wären:

Wäre es sinnvoll, das mit Python als Test-Umgebung zu machen, oder wäre 
eine andere Sprache sinnvoller?

Wie kann man den Simulator (Vivado nehme ich an) mit neuen Daten und 
Zuständen laden? Diese stecken meines Wissens im VHDL. Wäre es möglich, 
die Testzustände zu Beginn einer Simulation einzuladen, eventuell auch 
per file?  Oder kann man das irgendwie in die generics hinein stecken?

Wie macht man das?

von Sebastian R. (sebastian_r569)


Lesenswert?

Martin K. schrieb:
> Wäre es sinnvoll, das mit Python als Test-Umgebung zu machen, oder wäre
> eine andere Sprache sinnvoller?

Wir machen das für CI/CD mit unit tests in Python, klappt soweit echt 
gut.

von Martin K. (mkmannheim) Benutzerseite


Lesenswert?

Wie löst man das technisch? Ich hätte jetzt z.B. eine Schaltungsgruppe, 
die in der Realität von einem DSP, den ich programmiert habe, gefüttert 
wird. Für die DSP-Schiene ist es relativ einfach die Überläufe und 
anderes zu ermitteln und in Sandboxen als Abkömmlinge laufen zu lassen, 
weil die die Testcases als framework haben und alles unten drunter mit 
function calls direkt einbinden.

Wie aber ginge das mit FPGA-Software?

Es soll über die offline-Simulation laufen, damit nicht jedesmal eine 
firmware gebaut werden muss, um einen echten Test zu machen, zumal jetzt 
auch monatelang gar keine wardware da sein wird.

von Hannes J. (Firma: _⌨_) (pnuebergang)


Lesenswert?

Was auffällt ist, dass du dich schon auf eine Lösung, Python, festgelegt 
hast, ohne das Problem durchdacht zu haben. Denn die Programmiersprache 
mit der man so etwas löst ist ziemlich egal. Ich gehe mal davon aus, 
dass du einfach nichts anderes kannst als Python. Also ja, dann mach 
halt was mit einem Rotz wie Python.

Aber zuerst mal muss du dein Problem durchdacht haben. Was ist überhaupt 
meine Problemstellung? Soll nur "irgendwas" "irgendwie" passieren?

Welche Algorithmen brauche ich, beispielsweise wie "... sollen dann 
kritische Fälle identifiziert werden"? Was ist überhaupt ein "kritischer 
Fall"? Kann ich das so definieren, dass eine Software das erkennen kann, 
oder träume ich eher von Schwarzer Magie, die das "irgendwie" schon raus 
findet? Habe ich meine Statistik im Griff? Soll die Suche nach Lösungen 
("weitere Grenzen genauer eingeengt ... werden") zum Beispiel mit einer 
MC-Simulation erfolgen?

Welche Schnittstellen habe ich? Und wo? Sind sie dokumentiert oder muss 
ich was zusammenhacken? Wie komme ich (physisch, logisch) an die Sachen 
ran, die ich steuern möchte? Lassen sie sich steuern? Was möchte ich 
überhaupt steuern?

Welche Hard- und Software habe ich schon, welche brauche ich noch? Habe 
ich ein Budget zum Kauf von Hardware und Software (Lizenzen)?

Überhaupt, ist der Glaube an Wunder notwendig, damit das Ganze auf 
Papier funktioniert, oder bewege ich mich im Bereich solider 
Ingenieursarbeit?

von Rick D. (rickdangerus)


Lesenswert?

Der restlichen Antwort kann ich zustimmen, aber:

Hannes J. schrieb:
> Also ja, dann mach
> halt was mit einem Rotz wie Python.

Was soll das denn?
Was wäre denn deiner Meinung nach besser geeignet? Assembler oder 
VisualBasic?

von Martin S. (strubi)


Lesenswert?

Verstehe ich das richtig, dass du eigentlich die Funktion Stop/Go/Resume 
mit Einfrieren brauchst, damit du die Simulation zu einem spaeteren 
Zeitpunkt mit exakt dem gleichen Zustand wieder starten kannst?
Python ist grundsaetzlich zum sauberen Simulieren prima geeignet, und 
mit dem MyHDL-Simulator geht sowas per Handbetrieb, allerdings wird das 
schwierig, wenn bereits alles in VHDL vorliegt. Leider kann der 
MyHDL-Simulator keine Undefined und Uninitialized ('X' und 'U').

Dann gibt es die Moeglichkeit der Co-Simulation via VPI bei GHDL, da 
kannst du auch von aussen auf die Signal-Hierarchie zugreifen.
Betr. VPI koennte ich weiterhelfen. Das funktioniert dann grundsaetzlich 
auch mit Modelsim, xsim wieder nicht, die haben was inkompatibles, 
Funktion mir unbekannt.
In der `ghdlex`-Library fuer GHDL finden sich sonst noch Code-Fragmente 
in der OpenSource. Ich mache es typischerweise so, dass ich die 
Simulation von aussen mit echten Realdaten per virtuellem FIFO fuelle 
und den Zustand nicht neu laden muss, das waere sonst zu komplex.

Bei xsim/Vivado waere ich mit arithmetischen Sachen und VHDL 
insbesondere bei signed extensions und hin-und-her Casting vorsichtig 
und wuerde auf jeden Fall alles nochmal durch GHDL klopfen.

: Bearbeitet durch User
von Vancouver (vancouver)


Lesenswert?

Es ist durchaus sinnvoll, komplexe Tests mit einer Sprache wie Python zu 
schreiben anstatt in VHDL oder Verilog.
Ich glaube, was du suchst, nennt sich cocotb (https://www.cocotb.org/), 
das verwenden wir zunehmend in komplizierten Testumgebungen. Es gibt 
sogar eine UVM-Implementierung in Python, die du mit cocotb nutzen 
kannst.
Kurz gesagt, du schreibst deine ganzen Tests in Python, und cocotb 
verbindet sich mit dem RTL-Simulator, der im Hintergund läuft. Die "big 
three" simulatoren werden unterstützt, aber auch Verilator und soweit 
ich weiß auch GHDL.

von Christoph Z. (christophz)


Lesenswert?

Martin K. schrieb:
> Basierend auf diesen Ergebnissen, die hauptsächlich Werte aus
> Berechnungen sind, sollen dann kritische Fälle identifiziert werden.
> Diese bestehen aus einer langen Zeile, die der Simulator schreiben soll,
> die alle Startwerte für eine weitere Simulation enthalten.
>
> Als Beispiel wären das  z.B. ein Reglerzustand, die Eingangswerte und
> die Einstellungen des Reglers und die Randbedingungen, die wirkten, als
> ein Überlauf stattfand.
[...]
> Wie kann man den Simulator (Vivado nehme ich an) mit neuen Daten und
> Zuständen laden? Diese stecken meines Wissens im VHDL. Wäre es möglich,
> die Testzustände zu Beginn einer Simulation einzuladen, eventuell auch
> per file?  Oder kann man das irgendwie in die generics hinein stecken?

VDHL kann Textdateien lesen und schreiben:
1
library std;
2
use std.textio.all;

Damit kannst du Daten aus dem Simulator rausschreiben oder eben auch 
Daten und Zustände laden. Alle Daten sind mit Space getrennt in diesen 
Dateien.

cocoTB macht alles mit einem riesigen Generic.

Wir machen das gerne mal zur validierung zwischen Matlab Models und von 
Hand implementiertem VHDL. In Matlab erzeugen wir Stimulidaten und 
lassen die durch das Model laufen. Die Stimuli und die Ausgänge vom 
Model schreiben wir in Dateien. Die Testbench liest beides ein und prüft 
einfach, ob das simulierte dem erwarteten entspricht.

In deinem Fall brauchst du natürlich drum herum etwas mehr Software um 
zu sehen, was der nächste Simulationsschritt ist etc. Wie du richtig 
schreibst, das geht dann in Python, Perl, VisualBasic, Matlab, 
domain-specific-Haskel Dialekt,... :-)

VUnit ist eine Python Bibliothek um testbenches zu steuern und kann das 
mit vielen Simulatoren, vielleicht kann das auch nur den Teil "compile 
source, load design, simulate design" für dich übernehmen ohne das du 
dazu in die XSIM TCL tiefen steigen musst.

von Markus F. (mfro)


Lesenswert?

Christoph Z. schrieb:
> VUnit ist eine Python Bibliothek um testbenches zu steuern und kann das
> mit vielen Simulatoren, vielleicht kann das auch nur den Teil "compile
> source, load design, simulate design"

Nicht nur vielleicht. VUnit kann das.

Allerdings würde ich den Teil, der Werte aus der Simulation ausliest und 
zur Wiederverwendung in eine Datei packt, gleich in und als VHDL in die 
Testbench schreiben.

Mittels external names (kann ghdl aktuell allerdings nur in der 
mcode-Variante) ist das einfach. Lässt man das als Package schreiben, 
kann man es beim nächste Testbench-Run gleich als code mitcompilieren 
lassen.

von Martin K. (mkmannheim) Benutzerseite


Lesenswert?

Hannes J. schrieb:
> Was auffällt ist, dass du dich schon auf eine Lösung, Python, festgelegt
> hast,
Nein, durchaus nicht. Es wäre nur so, dass einige Berechnungen 
stattfinden sollten/könnten und die ließen sich eventuell mit Python 
erledigen.


Hannes J. schrieb:
> Welche Schnittstellen habe ich? Und wo?
Das wäre die Frage. Wie steuert man ein VHDL Simuation von außen?

Hannes J. schrieb:
> mit einem Rotz wie Python.
Ist Python so schlecht in deinen Augen?

Martin S. schrieb:
> Verstehe ich das richtig, dass du eigentlich die Funktion Stop/Go/Resume
> mit Einfrieren brauchst,
Eigentlich nicht. Aus der Simulation sollen alle kritischen Fälle 
protokolliert werden, meinetwegen 7, in denen ein System weit schwingt, 
beginnt instabil zu werden oder was auch immer von Interesse ist.

Alle Parameter werden dann aufgezeichnet und liegen vor.

Dann spielt man die Simulationen wieder ab und  modifiziert z.B. 
irgendeinen einen Reglerparameter mit sagen wir 1%,2% nach oben und 
unten.
Das wären dann 5 neue Simulationen die mehr oder weniger solcher Fälle 
aufbringen.

Auf diese Weise ließen sich die Paramter optmieren.

Martin S. schrieb:
> damit du die Simulation zu einem spaeteren
> Zeitpunkt mit exakt dem gleichen Zustand wieder starten kannst?
nein, sie müssen von vorne neu durchlaufen, um zu prüfen ob dann nicht 
eventuell neue Probleme auftauchen. Man kann sich auch vorstellen 2 
Parameter zu ändern, und hat dann mit +1,0,-1 jeweils  3x3 Simulationen 
von denen die 0,0 nicht zu machen wäre, weil dies die Ausgangssituation.

Markus F. schrieb:
> Allerdings würde ich den Teil, der Werte aus der Simulation ausliest und
> zur Wiederverwendung in eine Datei packt, gleich in und als VHDL in die
> Testbench schreiben.
Da bin ich nicht sicher, ob das so einfach geht. Der TB Code soll ja der 
gleiche Bleiben. Nur die Parameter in dem zu testenden Modul sollen 
angepasst werden. Z.B. PID -Parameter.

Als Erweiterung geht es auch um Modellparameter. Diese sollen in einer 
Schleife optimiert werden um näher an die Realität zu gelangen.

----

Der Sinn hinter dem Ganzen ist Automatisierung. Momentan lässt sich das 
auch händisch durchführen, also neue Simulation ausdenken, Werte 
niederlegen und leselegen. Es ist aber etwas stupide und lastet die 
Rechner nicht aus. Besser wäre es, es würden gleich 20-30 Simulationen 
beauftragt, die über Nacht durcharbeiten könnten.

Grundsätzlich würde es auch mit MATLAB zu machen sein, aber da müsste 
jeweils ein geändertes VHDL eingespeist werden.

Es in VHDL direkt simulieren zu lassen, wäre einfacher - ändern würden 
sich ja nur die Werte, die die Testbench einlesen kann.

von Rick D. (rickdangerus)


Lesenswert?

Martin K. schrieb:
> Wie steuert man ein VHDL Simuation von außen?
Man kann die Testvektoren aus einer Datei einlesen. Der Name der Datei 
läßt sich beim Start der Simulation auch von außen per generic setzen.
Bei Modelsim z.B. geht das mit -G<Name>=<Value>.

Wenn man das Ganze mit einem CI-System kombiniert, was die Nacht über 
alle Testbenches durchackert, bekommt man am nächsten Morgen das 
Ergebnis präsentiert.

von Martin S. (strubi)


Lesenswert?

Martin K. schrieb:
> Der Sinn hinter dem Ganzen ist Automatisierung. Momentan lässt sich das
> auch händisch durchführen, also neue Simulation ausdenken, Werte
> niederlegen und leselegen. Es ist aber etwas stupide und lastet die
> Rechner nicht aus. Besser wäre es, es würden gleich 20-30 Simulationen
> beauftragt, die über Nacht durcharbeiten könnten.

Das ist ziemlich 'boiler plate', also Standardanwendung. Ich habe das im 
ersten Lauf wohl missverstanden. Das sollte mit den klassischen 
Co-Simulationstools alles gehen.

Schau dir sonst mal das hier an 
https://hub.docker.com/r/hackfin/masocist/
Das ist vollstaendige Automatisierung der CI-Tests fuer einen RISC-V, 
dabei werden per virtalisiertes JTAG-Interface die Regresstest-Codes per 
Python in die CPU geladen. Per virtuellem UART spricht man dann mit dem 
Ding. Ist aber eher was fuer Linux-affine.

Der Originalcode ist bis auf das Memory und die virtuellen Interfaces 
exakt derselbe, wie er in der Hardware laeuft. Testvektor-Dateien in 
VHDL einlesen ist deutlich intrusiver und ausnehmend viel 
schwerfaelliger.

von Jürgen S. (engineer) Benutzerseite


Lesenswert?

Die Fragestellung klingt nach der digitalen Version von dem hier:
Beitrag "Automatische Analyse von Gleichungen bez. Fehlerrechnung"

Ich glaube, die Frage ist hier, wie man am Besten zu guten Testvektoren 
kommt. Eine Simulation mit mehreren Ansätzen laufen zu lassen, ist jetzt 
nicht so schwer. Ob man das mit Python machen muss, ist eine Frage das 
handlings. Wer ohnehin damit arbeitet, weil er die Formeln damit testet, 
wird da sicher gut aufgehoben sein. Ich frage mich allerdings, ob man 
dann die Formeln nicht direkt in Python testen und analysieren sollte.

Zu Co-Simulationen:

Von Matlab aus geht das recht elegant, da wird im Hintergrund Modelsim 
genutzt, die Simulation läuft aus Zeitgründen in VHDL auf dem FPGA. Das 
hat dann auch richtig Tempo.

Bitte 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
Noch kein Account? Hier anmelden.