Hallo Gemeinde! Wenn ich meine Simulation mit ModelSim unterbreche, öffnet sich (fast) immer ein Fenster mit dem Quelltext, der gerade ausgeführt wird. Sehr nervig. Kann man das irgendwie abschalten? Und wo wir gerade dabei sind: Gibt es eine funktionierende Tastenkombination um die Simulation in ModelSim zu stoppen? Momentan muß ich immer zur Maus greifen, Mauszeiger suchen, auf Button zielen und im richtigen Moment klicken. Duke
Hi, das mit dem Quelltext weiss ich auch nicht. Das Unterbrechen einer Simulation wird normalerweise selten vom Benutzer per Hand angestoßen. Meist verwendet man im VHDL/SystemC Breakpoints oder ASSERT Anweisungen um die Simulation zu beenden/anzuhalten. Vielleicht kannst du es so umbauen?
faul schrieb: > das mit dem Quelltext weiss ich auch nicht. Schade. Vielleicht hängt es ja mit der Visibility zusammen... > Das Unterbrechen einer Simulation wird normalerweise selten vom Benutzer > per Hand angestoßen. Bei mir schon. Zumindest, wenn ich sehe, da läuft was schief... > Meist verwendet man im VHDL/SystemC Breakpoints > oder ASSERT Anweisungen um die Simulation zu beenden/anzuhalten. Hehe, da würde ich ja professionell arbeiten. Aber die Idee dahinter ist natürlich richtig. Das werde ich gleich mal schrittweise umsetzen. Duke
Da mach ich mal die Ingrid: Im Modelsim-Supportnet stand (u.a.) folgendes:
1 | * Within the main modelsim.ini or local current working directory |
2 | modelsim.ini file, edit the Startup variable: |
3 | |
4 | change: ;Startup = do startup.do |
5 | to: Startup = bind all <Control-b> {vsim_break} |
Damit wird die Tastenkombination Ctrl-b einem Kommando zugewiesen. Duke
Super, Ingrid (S., nehm ich an), hab's gleich ausprobiert und festgestellt, dass das bei mir nicht funzt. Ich sehe sogar in der Modelsim Konsole, dass die lokale modelsim.ini gelesen wird, sdud aber trotzdem nicht. Bin wohl zu deppert. Ach ja, und dann konnte ich mir nicht verkneifen, bitte verzeih': Duke Scarring schrieb: >> Das Unterbrechen einer Simulation wird normalerweise selten vom Benutzer >> per Hand angestoßen. > Bei mir schon. Zumindest, wenn ich sehe, da läuft was schief... Du schaust dem Rechner beim Simulieren zu? Wo schaust Du da hin? Auf die LED der Festplatte? Und woran erkennt Du, dass etwas schief läuft? Gut, das war jetzt etwas provokativ, ich seh's ein. Aber eins frage ich im Ernst: Hat sich denn immer noch nicht rumgesprochen, dass man die Validierung des Designs in die Testbench hineinprogrammiert? Harald
Harald Flügel schrieb: > Super, Ingrid (S., nehm ich an), hab's gleich ausprobiert und > festgestellt, dass das bei mir nicht funzt. Ich sehe sogar in der > Modelsim Konsole, dass die lokale modelsim.ini gelesen wird, sdud aber > trotzdem nicht. Bin wohl zu deppert. Ne. Da hat wohl irgendwer bei Mentor erkannt, daß man damit Geld machen kann )-:
1 | The MG247619 describing a way to use keystroke combination to break a |
2 | running Modelsim simulation has been corrected, the “bind” command should |
3 | be used only with Questa/ Modelsim SE or LE. But for |
4 | ModelSim-PE(/DE/Designer) for all versions of the tool beginning with |
5 | version 6.6 the Pause/Break key can be used to break the simulation. |
> Ach ja, und dann konnte ich mir nicht verkneifen, bitte verzeih': Kein Problem ;-) > Du schaust dem Rechner beim Simulieren zu? Wo schaust Du da hin? Auf den Simulatonslog z.B. oder die Signale im Wave-Fenster. > Hat sich denn immer noch nicht rumgesprochen, dass man die > Validierung des Designs in die Testbench hineinprogrammiert? Für komplexe SoC-Geschichten, wo der C-Code flexibel das System stimuliert, bin ich für Vorschläge, die das Design elegant checken offen. Duke
Duke Scarring schrieb: >> Hat sich denn immer noch nicht rumgesprochen, dass man die >> Validierung des Designs in die Testbench hineinprogrammiert? > > Für komplexe SoC-Geschichten, wo der C-Code flexibel das System > stimuliert, bin ich für Vorschläge, die das Design elegant checken > offen. Da wird's ja nun gerade noch einfacher. Tests können im C Code selbst implementiert werden und die Simulation im Fehlerfall anhalten. Aber auch sonst ist es -- mit Verlaub -- ziemlicher Unsinn, die Simulation zu beobachten. Gruß Marcus
Bei FPGA-Designs, die einen Prozessor beinhalten, der Firmware ausführt, mache ich das normalerweise so: Ich setze eine Simulation ohne CPU-Modul (!) auf. Alle in der Luft hängenden Signale sind statt dessen mit Variablen der Testbench verbunden. Diese Variablen stimuliere ich dann mit Verilog-Tasks, die z.B. CpuRead oder CpuWrite heißen. Diese Tasks bilden das zeitliche Verhalten der CPU bei einem Datenzyklus ab. Im Testprogramm lasse ich dann eine Reihe solcher Task-Aufrufe auf den Rest des FPGA-Designs los, gewürzt mit anderen Tasks, Nops, etc. Die Reihenfolge der Tasks entspricht dem, was die Firmware tut. Genauer gesagt mach ich das umgekehrt: Ich verifiziere zuerst in der Simulation die Zugriffe und sag dann dem Firmware-Entwickler, war er in welcher Reihenfolge machen soll. Das hat bislang immer gut funktioniert. Harald
Duke Scarring schrieb: > Für komplexe SoC-Geschichten, wo der C-Code flexibel das System > stimuliert, bin ich für Vorschläge, die das Design elegant checken > offen. Naja, gerade fuer komplexe Sachen ist Testbench und Automatisierung ganz schoen aufwaendig. Andersrum wird aber ein Schuh draus: Deine einzelnen Komponenten des komplexen Designs werden mit intelligenter TB gechecked. Dann kannst du dich wenigstens darauf verlassen, dass eine Aenderung 'ganz unten' nicht Folgeschaeden hat. Und auf diesem TB Gerippe fuer die Komponenten kann man dann auch meist leichter eine TB fuer was komplexes schreiben, man hat dann meist die notwendigen 'procedures' schon mal da...
Harald Flügel schrieb: > Diese Variablen stimuliere ich dann > mit Verilog-Tasks, die z.B. CpuRead oder CpuWrite heißen. Diese Tasks > bilden das zeitliche Verhalten der CPU bei einem Datenzyklus ab. Nennt man so etwas nicht BFM (Bus Functional Model)?
Klaus Falser schrieb: > Nennt man so etwas nicht BFM (Bus Functional Model)? Richtig. Ein Prozedur/Task-basiertes BFM kann allerdings beliebing komplex und unübersichtlich werden, wenn man ein halbwegs realistisches Bild vom Datenverkehr bekommen möchte, sofern dieser der über den einfachen Registerzugriff hinausgeht. Bei kleineren CPUs ist es dann unter Umständen einfacher und sicherer, den Kern gleich selbst zu simulieren. Ist die Simulation der ganzen CPU zu belastend für die Simulation, dann kann man den Datenverkehr mit einem bus monitor aufzeichnen. Diese Daten werden dann über einen entsprechendes BFM für folgende Simulationen wieder eingespielt und können nach bestimmten Kriterien mit tatsächlichen Antworten der Simulation verglichen werden. -- Marcus
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.