Hi
Habe zwar schon einen Beitrag zu diesen Thema im Forum gefunden
allerdings konnte ich mein Problem auch mit diesen nicht lösen. Ich
verwende in meinen Desing eine DCM von Xilinx und ein Blockram und würde
beides gerne in Modelsim simulieren. Habe dazu in meine do file die vhdl
Files des Rams und der DCM dazugenommen und in der Testbench folgende
Zeilen einegefügt:
library UNISIM;
use UNISIM.Vcomponents.ALL;
Wenn ich nun mein do fiole ausführe erhalte ich von der Testbench zwar
den 40Mhz Takt aber mein mit der dcm erzeugte 80MHz takt kommt nicht!?
Muss ich sonst noch etwas beachten wenn ich die dcm simulieren muss?
Habe gelesen das man die Zeit auf 1ps stellen muss?!
Danke im vorhinein für die Hilfe.
MFG Fresh
Normalerweise sollten DCM und Blockram sich ohne Probleme simulieren
lassen, wobei mir jetzt nicht klar ist, wofür Du die do Files brauchst.
Nach meiner Erfahrung muss die Auflösung auf < 1ns gesetzt werden, es
kommt aber eine Meldung, wenn man das nicht macht.
Ob deshalb die DCM nicht anschwingt oder simuliert, weiss ich nicht.
Vielleicht hast Du noch ein Problem mit dem Reset der DCM.
Wenn Du ein paar Quellen zeigt, dann kann man sie mit einem
funktionierenden Design vergleichen. Vielleicht probierst Du zuerst auch
nur mit einem einfachen Programm, das nur die DCM enthält.
> Ich verwende in meinen Desing eine DCM von Xilinx und ein Blockram
Wie hast du die erzeugt?
Selber instantiiert oder mit dem Wizzard gerneriert?
Welche Version (Tools+Core)?
Hallo Fresh,
man kann den DCM mit Modelsim einfach simulieren, mit UNISIM bist du da
genau richtig.
Ggf. hast du den feedback (CLKFB) nicht richtig angeschlossen. Z.B.:
DCM1: DCM
generic map (
CLKFX_DIVIDE => 1,
CLKFX_MULTIPLY => 3,
CLKIN_PERIOD => 10.0)
port map (
CLKIN => iClk,
CLKFB => CLK1,
DSSEN => GND,
PSINCDEC => GND,
PSEN => GND,
PSCLK => GND,
RST => sReset,
CLK0 => CLK1,
CLKDV => open,
CLKFX => sClkFx1,
LOCKED => dcmlocked1);
Lass die Simulation auch etwas länger laufen, kann sein ,dass die DCM
länger zum anlaufen benötigt...
Wolfgang
Hi
Danke für die Antworten. Habe gerade ein Problem entdeckt welches
vielleicht die Lösung ist. Ich habe die simulation Libs compeliert und
dabei sagt er das es ModelSim6.3c benötigt. Ich arbeite aber mit
QuestaSim 6.3e. Kann das ein Problem sein bei der Simulation?!?
Aber er zeigt mir im questasim im workspace bereits die ordner unisim
und xilinxcorelib an und dort sollten die ja drin sein wie ich anehme
oder?
MFG Fresh
wie Klaus oben schon schrieb: Hast du ueberprueft, dass dein Simulator
mit '1ps' Aufloesung arbeitet?
Das scheint der DCM zu brauchen, sonst geht da gar nix. Ich arbeite hier
unter Linux mit GHDL und habe bisher auch nicht heraus gefunden, wie ich
den DCM zum 'funken' kriege. Ich hab' mir dann fuer Simulation einen
eigenen DCM geschrieben...
PS: Du hast doch auch ein BRAM instanziiert? Dann lass doch deinen
Design mal mit der Eingangsclock laufen. Tut das BRAM dann? Das wuerde
naemlich den Verdacht mit der Simulatoraufloesung erhaerten...
Hi
Also ich habe in der Arbeit das Questasim 6.3e und zuhause eine ältere
Modelsim Version. Mit der Modelsim Version funktioniert zumindest die
DMC einmal. Wenn ich in der Arbeit die simulation Libs compiliere sagt
er das er Questasim 6.3c benötigt. Wie bzw woher bekomme ich nun die
Libs für die 6.3e version?! Danke im vorhinein!
MFG fresh
Üblicherweise sind die Libraries nicht so spezifisch, dass sie genau
eine bestimmte Version eines Simulators benötigen, deshalb wundert mich
dies.
Compilierst Du die Libraries wirklich aus dem Quellcode?
Versuch es mit der allerneusten Version von Xilinx.
Du musst auch unterscheiden, es gibt mehrere Libraries, welche macht
Probleme beim compilieren?
UNISIM ist wichtig für die funktionale Simulation.
Die Core-Generator Library ist für alles, was mit dem CoreGenerator
erzeugt wird, der DCM core ist aber in UNISIM.
SIMPRIM ist nur für die Timing-Simulation, diese braucht man
normalerweise nicht.
Man kann die Libraries auch getrennt compilieren, im Prinzip sollest Du
nur UNISIM brauchen, die core generator library eventuell für das BRAM.
Hi
Also meine DCM läst sich nun simulieren aber dafür kann ich den Blockram
nichts reinschreiben. Habe nun eine eigene kleine Simulation für den
Blockram erstellt und dort ist ständig die Adresse und die Daten
angelegt und auch das WEN ist auf 1 gesetzt aber im Speicher steht nur
"UUUUU...". Der Speicher ist mit den CoreGen generiert. Hätte eigtenlich
aufgrund der vhd datei gedacht das er mit 0 initialisiert ist.
MFG fresh
Hi
Ich habe aus den Xilinix heraus die Unisim Lib für meine Questasim
Version generiert und jetzt läuft die DCM. Nachdem daher die Unisim geht
verstehe ich aber nicht ganz warum der Ram nicht funktioniert. Ich teste
das ganze dadurch das ich eine adresse anlege und daten und dann setzte
ich das Wen für immer auf 1 aber im Memory steht immer uuuuuuuuu und das
obwohl er als initwert doch 0 stehen haben sollte. Daher sieht man schon
das die simulation nicht funktioniert. Hat jemand eine tip wie ich das
Problem lösen kann?!
DANKE
MFG Fresh
Kann es sein, dass kein Model für das BRAM eingebunden ist?
Man merkt dies nur an den Meldungen beim Starten der Simulation, die
Simulation läuft trotzdem!
Bekomme geradeinmal folgende Meldung wenn ich beginne den Ram zu
beschreiben:
1
# ** Note: Block Memory Generator CORE Generator module is using a behavioral model for simulation which will not precisely model memory collision behavior.
Also mit dem Core Generator hab' ich noch nie was gemacht. Hast du mal
versucht, aus den Xilinx Templates ein BRAM 'normal' zu instantiieren?
So mache ich das immer. Und ich hatte bisher nur eine Stolperfalle:
ENA_A und ENA_B muessen sowohl beim lesen als auch beim schreiben aktiv
sein.
In deinem Bsp. oben sehe ich nur WEA/WEB. Wo ist da das 'allgemeine' RAM
enable?
Hi
Das allgemeine Ram Enable kann man beim core generator auf always enable
stellen daher braucht man es nicht mehr extra. Das mit den Ram selber
zusammenbauen habe ich auch schon gehört aber ich brauche ein ram mit
1023x25 das gibts natürlich nicht standardmässig!?
MFG Fresh
Du kannst dir aber 2 RAMs 1024x16 (bevorzugt) oder 2 RAMs 512x32
instantiieren, wo ist das Problem? Das ganze in eine entity verpackt,
dann sieht das nach aussen wie 1024x32 aus.
Und da du ja die UNISIM compiliert hast (dein DCM tut ja jetzt) ist das
m.M. nach einen Versuch wert. Vlt. hat dein Simulator ein Problem mit
dem Coregen-Zeugs...
Das Modell wird aus xilinxcorelib geladen, das sieht man, soweit sollte
das in Ordnung sein.
Ich denke auch nicht, dass das Modell einen Fehler hat, deshalb denke
ich, dass das Umstellen auf direkte BRAMs nichts bringt.
Mir ist noch nicht ganz klar, hast Du im Core Generator Startwerte für
das RAM angegeben, und erwartest dass diese jetzt gelesen werden?
Oder schreibt Du ins BRAM und liest trotzdem nichts zurück?
Was auffällt ist, dass im Modell
c_init_file_name => "no_coe_file_loaded",
steht, aber dazu weiss ich nicht viel.
Der Wert 'U' steht jedenfalls für uninitialisiert.
Vielleicht zeigst Du einmal ein paar VHDL Files und eventuell einen
Screenshot des Simulationsvorgangs.
In der testbench wir einfach ab einen gewissen Zeitpunkt das Wen SIgnal
un die Daten sowie die Adresse gesetzt und ich würde dann gerne im Ram
den Wert sehen.
Testbench:
Die Adresse und die Daten sowie das Wen Signal werden auch richtig
gesetzt aber im memory_i des Rams steht nicht drin außer UUUUUUU.
Vielleicht sieht ja jemand den Fehler sofort und kann ihn mir bitte
mitteilen?! DANKE
MFG Fresh
Dazu müßte man wissen, wie das interne Modell des BRAMs funktioniert,
aber ich würde zumindest einmal die Adressen zählen lassen, oder
zumindest ändern.
Die internen Daten oder Variblen eines Simulationsmodell anzuschauen,
das man nicht selbst geschrieben hat oder nicht kennt, ist sicher nicht
der richtige Weg um auf die Funktion zu schließen.
Schreibe eine Testbench die das Verhalten von AUSSEN beobachtet, also
lege verschiedene Daten an, schreibe sie hinein und schau nach, ob das
sie beim Auslesen wieder auftauchen.
Und irgendwo steht auch die Warnung, dass das Modell Kollisionen nicht
richtig behandelt.
Man kann jedenfalls davon ausgehen, dass sich ein BRAM simulieren lässt,
Du bist sicher nicht der erste, der das macht :-)
aehm, was moechtest du mit der TB eigentlich sehen? Dein Port B ist
aussen gar nicht angeschlossen, an deinen Port A legst du eine Adresse,
Daten sowie das write-enable an. Und was erwartest du da jetzt auf
welchen Signalen?
Dein RAM soll mit der rising_edge der DCM clock arbeiten, richtig? Dann
synchronisier dich in der TB mal auf die Clock80 falling_edge ein, dann
lass mit jeder Clock mal die Adresse von 0 bis 1023 hochzaehlen,
gleichzeitig aenderst du die Daten (einfach mal von 0 aus hochzaehlen).
Das ganze einmal mit WEA=1 und danach nochmal mit WEA=0.
Da die Clock80 nur in der Component verfuegbar ist, kannst du auch die
TB clock mit 40MHz nehmen und mal direkt ans BRAM anschliessen.
Und dann sollte das eigentlich funktionieren, zumindest mache ich das so
beim instantiieren von BRAMs...
Die library legt wohl aus Performancegründen den Speicherinhalt nicht
nach außen.
Lösung:
In der Datei:
C:\Xilinx\11.1\ISE\vhdl\src\XilinxCoreLib\BLK_MEM_GEN_V3_3.vhd
DEBUG auf 1 setzen und mit Modelsim neu compilieren
(memory_i <= memory when DEBUG=1;)
Hi
Also das mit den Debug funktioniert bei der BLK_MEM_GEN_V2_7.vhd
zumindest bei mir nicht. Ich habe mir damals einfach eine Testbench
geschrieben die in den Ram schreibt und dann vom Ram liest und es
funktioniert. Habe dann im ganzen Design ach getestet und es geht auch.
Ebenfalls konnte ich es schon in der Hardware erfolgreich testen.
MFG fresh