Ich habe ein großes RAM in mehreren Blöcken (nötig wegen varianter
Vorbelegeung) mit Muxer und Decoder gewrapped und im Timing so
hinbekommen (outputs registriert, Daten gepuffert), daß es sich genau so
verhält wie erwartet: 2 clks nach Anlegen der Adresse sind die Daten aus
allen Registern da. Die Simulation (ich simuliere alles auf 1ps) lässt
ein OriginalRam und ein so verschaltetes Multi-Blockram parallel laufen
und in ModelSIM sind die Ausgaben voll idientisch.
Nun habe ich das RAM im FPGA synthetisiert und das VHO wieder im
Modelsim genutzt, um das nochmal zu simulieren und siehe da, nun ist
meine Struktur angeblich um einen Takt zu schnell. (Das Referenzram mit
Solltiming ist ja nach wie vor dasselbe, Ansteuerung auch.)
Ich habe den Verdacht, daß es aber nur scheinbar so ist und ModeSIM sich
einfach vertut. Leider kann ich das nicht Testen, da noch keine Hardware
da.
Frage: Quartus erzeugt nebst dem VHO auch ein XRF und ein SDO. Wie setze
ich die ein, daß ModelSIM das richtig macht?
Ohne Dir nahezutreten, aber die Wahrscheinlichkeit dass Du dich vertan
hast ist größer als ModelSim.
Wenn Du dein Design korrekt aufgebaut hast, dann ist es überhaupt nicht
wichtig, ob Du mit 1ps, 10ps, oder 1 ns simulierst (außer Du hast
irgendwelche krummen Frequenzen).
Versuch einmal Teile deines Designs zu posten.
@ R.D. (Gast)
>meine Struktur angeblich um einen Takt zu schnell. (Das Referenzram mit>Solltiming ist ja nach wie vor dasselbe, Ansteuerung auch.)>Ich habe den Verdacht, daß es aber nur scheinbar so ist und ModeSIM sich>einfach vertut.
Das glaube ich kaum. Ich behaupte mal deine Testbensch ist schuld. Denk
dran, Takt und Eingangssignale dürfen NICHT gleichzeitig wechseln. Erst
Taktflanke, kurze Pause (1ns reicht), Daten wechseln.
MFG
Falk
Falk Brunner wrote:
> Denk dran, Takt und Eingangssignale dürfen NICHT gleichzeitig wechseln.> Erst Taktflanke, kurze Pause (1ns reicht), Daten wechseln.
Gilt das generell für Simulationen mit ModelSIM?
Auch wenn ich ein vollständig synchrones Design habe, sollten die
Eingangssignale nie zusammen mit dem Clock-Input wechseln?
@ Martin Kohler (mkohler)
>> Denk dran, Takt und Eingangssignale dürfen NICHT gleichzeitig wechseln.>> Erst Taktflanke, kurze Pause (1ns reicht), Daten wechseln.>Gilt das generell für Simulationen mit ModelSIM?
Das gilt für jede Simulation in VHDL.
>Auch wenn ich ein vollständig synchrones Design habe, sollten die>Eingangssignale nie zusammen mit dem Clock-Input wechseln?
Ja. Stichwort Delta-Zyklus.
MfG
Falk
Die verhaltenssimulation läuft schon etwas anders als in echt,
konvertiere doch den code nach der synthese nach vhdl und simuliere
diesen. oder dann nach place und route, (simuliert aber ewig).
ich hatte mal ein ddr-FF design, da muss ein takt negiert beschrieben
werden. legte ich den Takt direkt an das FF und den takt nach dem
negator an den anderee FF-takteingan kam ein falsches ergebnis, da die
Signalzuweisung halt einen simutakt braucht. Als schnippsel
"falsche" simu:
portmap
..
clk => clk,
clk_n => takt_n,
..
takt_n <= not clk;
Richtige simu:
portmap
..
clk => takt,
clk_n => takt_n,
..
takt <= clk;
takt <= not clk;
das problem ist, das man den code vor der synthese simuliert und so die
ganzen feinen unterschiede zwischen echt (mit laufzeiten) und
VHDL-verhaltensmodel (deltazyklen (Simuschritt) statt laufzeit)
reinbekommt.
@ Haarspalter (Gast)
>Die verhaltenssimulation läuft schon etwas anders als in echt,
???
>konvertiere doch den code nach der synthese nach vhdl und simuliere
Quark.
>diesen. oder dann nach place und route, (simuliert aber ewig).
Eben.
In einem ordentlichen Design mit RICHITGER (tm) testbench gibt es keine
Unterschiede zwischen Verhaltes und Post-Fit Simulation.
>ich hatte mal ein ddr-FF design, da muss ein takt negiert beschrieben>werden. legte ich den Takt direkt an das FF und den takt nach dem>negator an den anderee FF-takteingan kam ein falsches ergebnis, da die>Signalzuweisung halt einen simutakt braucht. Als schnippsel
Dann ist deine Testbench nicht OK.
MFG
Falk
Dann ist so eine Situation in der Simulation wie im Anhang also
schlecht?
dutycycle ist ein Eingangssignal, int_clk der Systemtakt.
Stichwort Delta-Zyklus => werde mich dann mal auf die Suche machen.
Warum verhält sich denn dann die unsynthetisierte Simulation richtig ?
Ich habe noch nie irgendeinen Versatz so reinprogrammiert und immer hat
alles gestimmt. So etwa sieht die sitmuli aus : (es gibt nur den einen
clock in dem modul)
1
waituntilrising_edge(master_clock);
2
3
tekram__addr<="0000000000000001";--test"do not write"
4
tekram__data<="10000000000000000000000000000001";
5
tekram__ena<='0';
6
waituntilrising_edge(master_clock);
7
8
tekram__addr<="0000000000000010";--test"do a write"on2
9
tekram__data<="01000000000000000000000000000010";
10
tekram__ena<='1';
11
waituntilrising_edge(master_clock);
12
13
tekram__addr<="0000000000000001";--test"do a write"on1
14
tekram__data<="10000000000000000000000000000001";
15
tekram__ena<='1';
16
waituntilrising_edge(master_clock);
17
18
tekram__addr<="0000000000000010";--test"do an overwrite"on2
@ Martin Kohler (mkohler)
>Dann ist so eine Situation in der Simulation wie im Anhang also>schlecht?>dutycycle ist ein Eingangssignal, int_clk der Systemtakt.
Naja, da kann man nicht sehen, ob die Signale EXAKT gleichzeitg wechseln
oder dutycycle doch Bruchteile von ns später. Das kann man nur in der
Testbench sehen.
MFG
Falk
@ R.D. (Gast)
>Warum verhält sich denn dann die unsynthetisierte Simulation richtig ?>Ich habe noch nie irgendeinen Versatz so reinprogrammiert und immer hat>alles gestimmt. So etwa sieht die sitmuli aus : (es gibt nur den einen>clock in dem modul)
Keine Ahnung. Vielleicht liegts an Prozessen, die das Eingagssignal
kombinatorisch durchläuft, und somit einen zusätzlichen Deltazyklus
verzögert.
MFG
Falk
Falk Brunner wrote:
> Naja, da kann man nicht sehen, ob die Signale EXAKT gleichzeitg wechseln> oder dutycycle doch Bruchteile von ns später. Das kann man nur in der> Testbench sehen.
Die Signale sind exakt synchron auf jeden 20ns Takt gelegt.
Es wäre daher in meinem Fall wohl möglich, die fallende Flanke auf den
20ns Takt zu legen, so dass die steigende (aktive) Flanke immer zwischen
die Datenwechsel zu liegen kommt.
Würde das Sinn machen?
@ Martin Kohler (mkohler)
>Die Signale sind exakt synchron auf jeden 20ns Takt gelegt.>Es wäre daher in meinem Fall wohl möglich, die fallende Flanke auf den>20ns Takt zu legen, so dass die steigende (aktive) Flanke immer zwischen>die Datenwechsel zu liegen kommt.>Würde das Sinn machen?
So in etwa. Es reicht eine minimale Verzögerung, theoretisch auch 1ps.
MFG
Falk
Zurückkommend auch mein Problem: Ich habe jetzt waits von 1 ns
eingesetzt und trotzdem dasselbe Ergbenis. Ich glaube, daß ich das VHO
nicht richting einsetze. Wie macht man das ? Wie binde ich die ebenfalls
erzeugten XRF und SDO files ein ? Die stehen ja auch im
"ModelSIM"-Verzeichis.
Weis das jeamand ?
