Hallo,
ich spiele gerade ein bisschen mit MyHDL ein und verwende MyHDL 1.0dev
mit Python3 auf Linux 64bit. Dabei bin ich auf das Problem gestoßen,
dass während einer langläufigen Simulation der Memory-Footprint ständig
wächst. Irgendwann ist dann natürlich Schluss und die Simulation raucht
ab. Das Design ist ziemlich groß, im Detail ist es ein Mersenne-Twister
MT19337. Den kann man auffassen als eine riesige FSM mit knapp 20k
Zustandsbits und entsprechend komplexer Übergangs- und Ausgangsfunktion.
Bis zum Absturz liefert die Simualtion korrekte Ergebnisse.
Ich stehe noch etwas im Dunkeln, woran das liegt, aber hat es etwas mit
Slicing und Konkatenation von Signalen zu tun. Wenn ich die weglasse
(was natürlich zu einer funktional falschen Simulation führt), dann
bleibt der Speicherbedarf konstant (oder wächst so langsam, dass ich es
nicht erkennen kann).
Das Problem tritt auf mit CPython2, CPython3 und PyPy3_beta, bei
letzterem aber weniger drastisch. Mit Pypy3 kann ich mehr Schritte
simulieren bevor der Speicher voll ist, als mit CPython (Und etwa 6mal
so schnell. Coole Sache das PyPy)
Ich meine, der Speicherbedarf darf natürlich von der Designgröße
abhängen, aber eigentlich nicht von der Simulationsdauer. Wozu sollten
alte Zustände gespeichert werden? Das Problem ist unabhängig davon, ob
ein vcd-Dump rausgeschrieben wird oder nicht.
Bevor ich hier Sourcecode poste, meine Frage: Hat jemand mal ein
ähnliches Problem mit Myhdl gehabt?
Im Zweifel mal ein großes zusätzliches Swapfile anlegen: man mkswap, man
swapon.
Außerdem mal mit ulimit -a die Limits anzeigen lassen, eventuell ist
auch da was zu niedrig wie "stack size".
Die Speichergröße ist nicht das Problem. Wenn ich die Anzahl der
Simulationschritte reduziere, läuft die Simulation bis zum Ende durch.
Auf einem Rechner mit mehr Speicher liegt die Grenze eben höher. Ein
2GB-Notebook schafft etwa 500 Schritte, ein PC mit 8GB etwa 8500. Mit
genügend Schritten kann man so jeden PC plattmachen.
Die Frage ist, warum der Simulator im Betrieb überhaupt immer mehr
Speicher reserviert. Das handgeschriebene VHDL-Simulationsmodell mit
GHDL oder Modelsim zeigt dieses Verhalten nicht.
Vancouver schrieb:> Das handgeschriebene VHDL-Simulationsmodell mit> GHDL oder Modelsim zeigt dieses Verhalten nicht.
Wollte ich gerade vorschlagen, GHDL auszuprobieren ... MyHDL kenn ich
garnicht, ist das besonders schnell oder toll?
Da du was von Python geschrieben hast, ist ersteres vmtl auszuschließen
- interessieren würde es mich trotzdem :)
*edit*: Ah, sowas wie ein Python nach VHDL Translator ... Was es alles
gibt^^
Mampf F. schrieb:> Ah, sowas wie ein Python nach VHDL Translator
Nein, eigentlich nicht. MyHDL ist eine Python-basierte
Hardwarebeschreibungssprache, d.h. Du beschreibst dein Design auf
RTL-Level aber mit Sprachkonstrukten von Python. Das kannst du dann
simulieren, indem Du es wie ein Python-Programm laufen lässt. Das ganze
hat den Vorteil, dass du für die Verifikation den gesamten Sprachumfang
von Python mit allen Bibliotheken nutzen kannst. Dagegen sieht selbst
SystemVerilog ziemlich alt aus, nachdem was ich bisher ausprobiert habe.
Wenn alles funktioniert, kannst Du dann daraus VHDL oder Verilog
erzeugen lassen und wie gewohnt weiterarbeiten. Für die HDL-Erzeugung
ist natürlich nur ein Subset der Sprache geeignet.
Und laut Autor ist die Simulation schneller als übliche HDL-Simulatoren,
was mich auch nicht wundert, zummindest wenn man PyPy verwendet. Aber
bestätigen kann ich das noch nicht, ich habe noch keine direkte
Gegenüberstellung gemacht.
Vancouver schrieb:> Nein, eigentlich nicht. MyHDL ist eine ...
Vielen Dank für deine Erklärung! Das hört sich interessant an :)
Testbenches in VHDL sind oft wirklich schrecklich, wenn man so Sachen
wie File I/O benötigt und furchtbar langsam ist es auch.
Ich glaube, ich teste das Tool mal ... Hätte eine Anwendung dafür ...
Hatte den sagenumwobenen Chris Audio-Dynamic-Compressor
(Audacity-Plugin) von Lisp nach Python nach C nach VHDL portiert ... Da
könnte ich mal schauen, ob ich die Python-Version mit MyHDL zum Laufen
bekomme :)
Mampf F. schrieb:> ob ich die Python-Version mit MyHDL zum Laufen> bekomme
Du kannst damit keinen normalen Python-Code in Hardware gießen. MyHDL
hat fast die selben Konstrukte wie VHDL, aber formuliert in Python. Du
musst Register und Schaltnetze beschrieben, einen Takt erzeugen und das
Ganze in Komponenten strukturieren, von denen Du Instanzen erzeugst und
miteinander verbindest. Es gibt Signale und Variablen ähnlich wie in
VHDL.
Aber Du kannst natürlich den Python-Code deines Kompressors im selben
Modell mitlaufen lassen und die Ergebnisse direkt vergleichen. Damit
hast du den zentralen Vorteil von MyHDL ausgenutzt. Oder nur Teile in
MyHDL umsetzen und als Model in the Loop mit Deiner Implementierung
laufen lassen.
Mampf F. schrieb:> Testbenches in VHDL sind oft wirklich schrecklich, wenn man so Sachen> wie File I/O benötigt und furchtbar langsam ist es auch.
Was wäre die Alternative?
S. R. schrieb:> hast du mal beim> Entwickler (Erfinder) von MyHDL angefragt
Nein, noch nicht. Ich bin dabei, ein einfaches Modell zu schreiben, das
den gleichen Effekt zeigt.
Moin,
klingt nach einem Problem mit zirkularen Referenzen - generell eine
Python-Stolperfalle. Die Reference counts für die concat'teten Objekte
würde ich mal ausgeben, wenn die sinnlos raufzählen, wird irgendwo was
unbenötigtes nicht freigegeben. Muss nicht zwingend ein MyHDL-Bug sein.
An F. schrieb:> Ergebnis der Untersuchung?
Bisher keins wegen Zeitmangel. Aber ich muss mich ohnehin in nächster
Zeit wieder damit auseinander setzen, dann werden wir weitersehen.
