Synthetisierter Code aus Quartus ist scheinbar zu schnell

[R.D. (Gast)]

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?

[Klaus Falser (Gast)]

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.

[Falk B. (falk)]

@  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

[Martin K. (mkohler)]

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?

[Falk B. (falk)]

@ 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

[Haarspalter (Gast)]

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

korrektur, die letzte zeile muss natürlich:
 takt_n <= not clk;
lauten.

[Falk B. (falk)]

@ 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

[Martin K. (mkohler)]

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.

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

wait until rising_edge(master_clock);

tekram__addr <= "0000000000000001";-- test "do not write"
tekram__data <= "10000000000000000000000000000001";
tekram__ena <= '0';
wait until rising_edge(master_clock);

tekram__addr <= "0000000000000010";-- test "do a write" on 2
tekram__data <= "01000000000000000000000000000010";
tekram__ena <= '1';
wait until rising_edge(master_clock);

tekram__addr <= "0000000000000001";-- test "do a write" on 1
tekram__data <= "10000000000000000000000000000001";
tekram__ena <= '1';
wait until rising_edge(master_clock);

tekram__addr <= "0000000000000010";-- test "do an overwrite" on 2
tekram__data <= "11000000000000000000000000000011";
wait until rising_edge(master_clock);

tekram__ena <= '0';
wait until rising_edge(master_clock);
wait until rising_edge(master_clock);

-- read
tekram__addr <= "0000000000000000";
wait until rising_edge(master_clock);  -- observe addr 0 data 0

tekram__addr <= "0000000000000001";
wait until rising_edge(master_clock);  -- observe addr 0 data 0

tekram__addr <= "0000000000000010";
wait until rising_edge(master_clock);  -- observe addr 0 data 0

[Falk B. (falk)]

@ 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

[Falk B. (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

[Martin K. (mkohler)]

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?

[Falk B. (falk)]

@ 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

[Martin K. (mkohler)]

Ok, dann passe ich die Testbenches an und hoffe, dass immer noch 
dasselbe hinten raus kommt.

Danke für die Rückmeldung.

[R.D. (Gast)]

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 ?

[Jens Oliver (Gast)]

Braucht man die überhaupt ?