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