Hi, ich versuche gerade den Opencores DDR-Controller http://www.xdr.com/dash/fpga/oc_ddr.tgz zum Laufen zu bringen, erstmal in der behavioral Simulation in ModelSim. Habe mir die Dateien dafuer in ein ISE Webpack 9.2i Projekt importiert und simuliert. Soweit ich mir das ganze angeschaut und mit dem RAM-Datenblatt verglichen habe sieht das Timing auch gut aus. Allerdings meldet die Testebench jede Menge Lesefehler (fuer jede Adresse um genau zu sein). Ich wuerde mir nun gerne den Inhalt des RAMs angucken um zu sehen ob das Schreiben ueberhaupt geklappt hat. Im RAM-Modell (siehe Anhang) gibts auch ein entsprechendes Array fuer jede Bank. Wie kann ich mir dieses Array sinnvoll anzeigen/exportieren lassen in ModelSim? 512MBit Daten machen in der Waveform-Anzeige nicht allzuviel Sinn... Vielen Dank fuer eure Tips! Sebastian
Hallo, es gibt in Modelsim im Workspace-View ein Memory Reiter. Dort ist der Zugriff auf den Inhalt der Speicher (alle Speicherarrays) zur aktuellen Simulationszeit möglich. Du machst einfach einen Doppelklick aufs angezeigte Array und der Speicherinhalt wird angezeigt.
Da Micha wrote: > es gibt in Modelsim im Workspace-View ein Memory Reiter. Dort ist der > Zugriff auf den Inhalt der Speicher (alle Speicherarrays) zur aktuellen > Simulationszeit möglich. Du machst einfach einen Doppelklick aufs > angezeigte Array und der Speicherinhalt wird angezeigt. Ah, das ist genau was ich gesucht habe... nur ein Problem: das gesuchte Speicherarray taucht dort nicht auf. Habe in der ModelSim-Doku nachgeschaut, offebar entspicht das Array nicht den als Speicher erkannten Typen. Wenn ich versuche das Array haendisch hinzuzufuegen bekomme ich folgende Meldung:
1 | > add mem /tb/i_mt46v16m16/state_register/bank0 |
2 | # ** Error: (vsim-3663) Object '/tb/i_mt46v16m16/state_register/bank0' is not a memory. |
3 | # |
Der Speicher ist wie folgt deklariert:
1 | TYPE Array_ram_type IS ARRAY (2**cols_bits - 1 DOWNTO 0) OF STD_LOGIC_VECTOR (data_bits - 1 DOWNTO 0); |
2 | TYPE Array_ram_pntr IS ACCESS Array_ram_type; |
3 | TYPE Array_ram_stor IS ARRAY (2**addr_bits - 1 DOWNTO 0) OF Array_ram_pntr; |
4 | |
5 | VARIABLE Bank0 : Array_ram_stor; |
Was kann ich da tun?
1 | TYPE Array_ram_type IS ARRAY (2**cols_bits - 1 DOWNTO 0) OF STD_LOGIC_VECTOR (data_bits - 1 DOWNTO 0); |
2 | TYPE Array_ram_pntr IS ACCESS Array_ram_type; |
3 | TYPE Array_ram_stor IS ARRAY (2**addr_bits - 1 DOWNTO 0) OF Array_ram_pntr; |
4 | |
5 | VARIABLE Bank0 : Array_ram_stor; |
Nur zum Verstaendnis, ACCESS ist mir in VHDL noch nie begegnet: Es handelt sich hier um ein Array aus Pointern? Wusste gar nicht das es sowas in VHDL gibt... Sebastian
Ich glaube, du kannst mit ACCESS nur auf natural numbers zeigen, nicht auf andere Objekte. Lassen sich ACCESS Types überhaupt synthetisieren?
Gast wrote:
> Lassen sich ACCESS Types überhaupt synthetisieren?
Ich wuerde mal stark vermuten das nicht, aber es geht hier eh nur um ein
Simulationsmodell, von daher spielt das keine Rolle.
Du könntest Dir zum Test nur die unteren Speicherbereiche in der Waveform anzeigen lassen: z.B.: Col 0 bis 3 der Bank 0 und dann auch nur auf diese zugreifen.
Da Micha wrote: > Du könntest Dir zum Test nur die unteren Speicherbereiche in der > Waveform anzeigen lassen: z.B.: Col 0 bis 3 der Bank 0 und dann auch nur > auf diese zugreifen. Auch das klappt nicht. Egal ob ich es zum Beginn oder waehrend der Simulation probiere, bekomme ich folgende Fehlermeldung:
1 | # Drop insertion failed: /tb/i_mt46v16m16/state_register/bank0(0) |
2 | # (vish-4014) No objects found matching '/tb/i_mt46v16m16/state_register/bank0(0)'. |
Im "Locals" Fenster kann ich bank0 aber aufklappen und es werden die (8196) Untereintraege angezeigt... Ich werde aus der ganzen Sache nicht schlau... aber ich will eigentlich auch nicht an dem Simulationsmodell rumbasteln. Das soll ja gerade unveraendert bleiben... wenn ich meine kaputte Schaltung an einem kaputtgespielten RAM-Modell verfiziere kann ich's auch gleich sein lassen :-/ Ratlos... Sebastian
Nehme doch einfach die komplette Bank mit in die Simulation. Wenn ich dass mit den Pointern richtig verstanden habe, existieren die Speicher hinter diesen sowieso noch nicht (alle = NULL). Ich vermute mal, dass das Model eine Speicherverwaltung für die Ram-Columns hat und diese erst anlegt, wenn sie gebraucht werden. Wenn Du jetzt nur einen kleinen Speicherbereich benutzt, sollte sich der Speicherverbrauch der Simulation auch in Grenzen halten. Gruß DaMicha.
Hrm... dann hab ich den ganzen Brocken in der Waveform-anzeige? Kann ich mir nicht so recht vorstellen das das funktioniert. Werde das aber nachher mal ausprobieren. Habe damit wenigstens ein bisschen weiterkomme doch erstmal das Modell "gehackt" und das dynamische Konstrukt durch ein statisches Array ersetzt und natuerlich die dynamische Speicherverwaltung rausgeworfen. Nun kann ich mir das ganze wenigstens im "Memory" Fenster von ModelSim angucken und es wandern auch die Werte rein die die Testbench erzeugt. Sebastian
Wenn du das Array statisch anlegst brauchst du aber viel RAM. Und ich zweifle, dass du damit den Fehler findest. Ich hatte zb bei einem Simulationsmodell den Fall, dass es etwas zu streng war und bei der Initialisierung trotz Spec-konformen Verhaltens (auf den Addressleitungen 'X's aber die Kommandoleitungen waren korrekt gesetzt) in einen Fehlerzustand ging und gar nichts mehr machte. Ich würde mir an deiner Stelle die interne State Machine die sich um Schreiben/Lesen kümmert suchen und dort mit report bzw. assert versuchen, Ausgaben zu bekommen, die dir zeigen, ob es überhaupt durch die Initialisierung kommt und wann es Fehler sieht. DRAM Simulationsmodelle sind so ein eigenes Thema ...
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.