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?
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.
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.
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?
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?
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
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.
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.
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.
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.
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.
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.
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.
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.