Forum: FPGA, VHDL & Co. ModelSim: Break -> Quelltextfenster verhindern


von Duke Scarring (Gast)


Lesenswert?

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

von faul (Gast)


Lesenswert?

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?

von Duke Scarring (Gast)


Lesenswert?

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

von Duke Scarring (Gast)


Lesenswert?

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

von Harald F. (hfl)


Lesenswert?

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

von Duke Scarring (Gast)


Lesenswert?

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

von Marcus H. (mharnisch) Benutzerseite


Lesenswert?

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

von Harald F. (hfl)


Lesenswert?

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

von berndl (Gast)


Lesenswert?

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

von Klaus F. (kfalser)


Lesenswert?

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

von Marcus H. (mharnisch) Benutzerseite


Lesenswert?

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
Noch kein Account? Hier anmelden.