Hallo Leute,
ich habe vor Jahren das letzte Mal mit Xilinx zu tun gehabt. Nun nach
Jahren der FPGA Untreue muss ich mal wieder ran, jetzt jedoch Microsemi
FPGA. An sich habe ich mich nach Jahren C-Programmierung in VHDL wieder
gut zurecht gefunden. Eine Sache stört mich aber unheimlich. Simulation,
wo ich der Meinung bin, dass es früher nicht so krampfhaft war.
Wenn man was "schnell" durch simulieren möchte ohne einer DO oder einer
Testbench, klappt es im Großen und Ganzen. Jedoch, will ich irgendwann
am Zeitpunkt Null anfangen, mit dem "Restart" wird aber alles gelöscht:
Clockdefinition, Reset-Flanke, Signale, alles ist wieder undefined. Da
gibt es mehrere Häkchen zum Behalten der Information "Keep". Alle
Häkchen sind auch gesetzt. Woran kann es liegen?
VauHaDeEl schrieb:> Hallo Leute,>> ich habe vor Jahren das letzte Mal mit Xilinx zu tun gehabt. Nun nach> Jahren der FPGA Untreue muss ich mal wieder ran, jetzt jedoch Microsemi> FPGA. An sich habe ich mich nach Jahren C-Programmierung in VHDL wieder> gut zurecht gefunden. Eine Sache stört mich aber unheimlich. Simulation,> wo ich der Meinung bin, dass es früher nicht so krampfhaft war.> Wenn man was "schnell" durch simulieren möchte ohne einer DO oder einer> Testbench, klappt es im Großen und Ganzen. Jedoch, will ich irgendwann> am Zeitpunkt Null anfangen, mit dem "Restart" wird aber alles gelöscht:> Clockdefinition, Reset-Flanke, Signale, alles ist wieder undefined. Da> gibt es mehrere Häkchen zum Behalten der Information "Keep". Alle> Häkchen sind auch gesetzt. Woran kann es liegen?
Bitte was?
VauHaDeEl schrieb:> Jedoch, will ich irgendwann am Zeitpunkt Null anfangen, mit dem "Restart"> wird aber alles gelöscht:> Clockdefinition, Reset-Flanke, Signale, alles ist wieder undefined.
Wie sieht deine Testbench aus? Das, was du da beschreibst, hört sich
an, wie wenn du die Signale händisch verwaltest...
Hallo Lothar, ich habe geschrieben, dass ich zuerst ohne ein
Testbenchfile simulieren wollte. habe mir mitlerweile ein DO File
erstellt und führe "force" für einzelne Signale über die TCL console
aus. Testbench zu schreiben fand ich zuerst mühsamer, werde es aber noch
tun.
VauHaDeEl schrieb:> Hallo Lothar, ich habe geschrieben, dass ich zuerst ohne ein> Testbenchfile simulieren wollte.
Uuuups, richtig... :-o
> Testbench zu schreiben fand ich zuerst mühsamer, werde es aber noch tun.
Eine Testbench ist relativ einfach zu schreiben. Mit ein wenig Glück
gibt es Codegeneratoren, die den kompletten Frame bis hin zur
Takterzeugung erstellen (Xilinx ISE). Mit Pech muss man sich selber aus
einem Dreizeiler so eine Testbench erstellen.
Moin,
Xilinx hat irgendwann diesen klickbaren Wave-Generator (Namen schon
vergessen) aus dem ISE geworfen. Um eine Testbench in VHDL kommt man
also wohl nicht mehr rum. Allerdings kann man sich nach wie vor als
"Template" erstellen lassen.
Jedoch bin ich inzwischen weg von Modelsim und nun auch von isim. GHDL
arbeitet deutlich flotter, und man kann damit ein paar richtig böse
Sachen machen, wie z.b. shared libraries mit spezieller API dazuladen,
die die Simulation von aussen per Netzwerk zugänglich machen ("Virtuelle
Hardware").
Die Testbenches mache ich so fast nur noch in Python, resp. treibt die
echte Software die virtuelle Hardware. Gibt da auch ein paar
Forenthreads zu.
Nachteil an GHDL ist, dass es eher was für Linux-Entwickler ist, unter
Windows funktioniert alles etwas eingeschränkt.
Grüsse,
- Strubi
Hallo,
dann benutzt du sicherlich Libero. Je nach dem welche Lizenz du hast
gibt es auch ein waveform generator. Da kannste klicki-bunti deine
Signale anlegen und deine Testbench wird automatisch generiert. Falls
nicht, musst du deine TB selbst schreiben. Ist aber ne sache von 10
minuten.
Die Toolchain von Libero ist allerdings schöner und selbsterklärender
als die von xillinx oder altera. Ich arbeite gerne mit den Actel FPGAs.
Grüße
Jürgen
Martin S. schrieb:> GHDL> arbeitet deutlich flotter, und man kann damit ein paar richtig böse> Sachen machen, wie z.b. shared libraries mit spezieller API dazuladen,> die die Simulation von aussen per Netzwerk zugänglich machen ("Virtuelle> Hardware").> Die Testbenches mache ich so fast nur noch in Python, resp. treibt die> echte Software die virtuelle Hardware
Und warum brauchst du dafür GHDL?
Mache ich genauso mit Modelsim und dürfte auch mit jedem anderen gehen,
das gibt vhdl alleine schließlich schon her.
GHDL hat leider den Vorteil das man nicht vernünftig (wenn überhaupt)
aktuelle crypted Libraries der Hersteller compilen kann. Von mixed
Language ganz zu schweigen.
Moin,
>> Und warum brauchst du dafür GHDL?
Na ganz einfach: Opensource, gut erweiterbar, und läuft stabil unter
Linux (was ich von der damaligen Modelsim-Variante nicht behaupten
kann). Und es kostet keine weiteren Kindergartenlizenzen, wenn man
grosse Designs simulieren will. Vor allem ist es weniger schwerfällig in
der Bedienung (ich mag nun mal Makefiles).
> Mache ich genauso mit Modelsim und dürfte auch mit jedem anderen gehen,> das gibt vhdl alleine schließlich schon her.>
Soweit ich sehe, musste man für das volle Co-Simulationspackage mit
einem relativ schlecht dokumentierten VHPI-Interface tüchtig in die
Tasche greifen.
> GHDL hat leider den Vorteil das man nicht vernünftig (wenn überhaupt)> aktuelle crypted Libraries der Hersteller compilen kann. Von mixed> Language ganz zu schweigen.
Mixed Language kommt eh nich bei mir in die Tüte.
Das mit den obfuscated libraries ist manchmal ein Problem. Liegt aber
meist nur an kleinen perfiden Standard-Verletzungen von Seiten Xilinx.
Manche muss man nur ein bisschen deobfuscieren, und sie laufen, oder ein
paar Zeilen ändern. Die Zeit die ich sonst gegenüber isim oder Modelsim
einspare, ist das bisschen Extraarbeit wert.
>> Mache ich genauso mit Modelsim und dürfte auch mit jedem anderen gehen,>> das gibt vhdl alleine schließlich schon her.>>>> Soweit ich sehe, musste man für das volle Co-Simulationspackage mit> einem relativ schlecht dokumentierten VHPI-Interface tüchtig in die> Tasche greifen.
Du solltest mal weniger kompliziert denken. Ihr Linuxfritzen erzählt
doch immer was von "alles ist eine Datei" oder so ähnlich. Hier liegt
der Schlüssel zum Erfolg.
>> Du solltest mal weniger kompliziert denken. Ihr Linuxfritzen erzählt> doch immer was von "alles ist eine Datei" oder so ähnlich. Hier liegt> der Schlüssel zum Erfolg.
Bin mir nicht sicher, ob Du die Komplexität meiner Anforderungen
verstanden hast. Mit Dateien ist das nicht zu machen, und wenn, dann
wird's hässlich und langsam.
Konkret geht es z.B. um ein virtuelles Board mit einem SoC, der per gdb
remote-debuggt wird (Im Prinzip beschrieben:
http://tech.section5.ch/news/?p=101). Wenn man's mal durchschaut hat,
ist die Methode erschreckend unkompliziert. Ich lasse z.B. einen
Softwaretreiber in der selben Form mit der Simulation sprechen wie auch
mit der virtuellen Hardware. Solang mir keiner zeigt, dass das die
kommerziellen Tools besser und schneller (zu einem Preis unter 5000 €)
können, sehe ich bislang keine Möglichkeit, effizienter komplexe Systeme
zu debuggen.
