ModelSim: Break -> Quelltextfenster verhindern

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

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

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