Simulator simuliert falsch (ActiveHDL)

[Fpga I. (fpga-ing)]

Hallo zusammen,

ich bin gerade mal wieder über ein Tool Problem gestolpert, diesmal mit 
dem ActiveHdl:

ilOddr_20_direct_input: ODDR1
    port map (
        Clk     => sFastClk,
        Data    => sDirectOddrInputBits_20,
        Q(0)    => sOddrOutDirect_20
    );
    
sAbstractedOddrInputBits <= sDirectOddrInputBits_20;

ilOddr_20_abstracted_input: ODDR1
    port map (
        Clk     => sFastClk,
        Data    => sAbstractedOddrInputBits_20,
        Q(0)    => sOddrOutAbstract_20
    );

Dieser Code führt dazu, dass das Signal sOddrOutAbstract_20 gegenüber 
dem Signal sOddrOutDirect_20 um einen Clock Cycle verzögert ist. Für 
mich sieht es danach aus, dass der Simulator nicht alle benötigten 
DeltaCycles berechnet o.ä.

Den vollständigen Code findet Ihr im Anhang. Zur Simulation einfach das 
Script sim.do im Verzeichnis ActiveHdl starten. Der Fehler ist abhängig 
davon, wie das Signal sDirectOddrInputBits_20 generiert wird. Eine 
andere Implementierung für eine andere Frequenz 
(sDirectOddrInputBits_25) funktioniert hingegen einwandfrei.
Ich verwende ActiveHdl 10.1, der mit Lattice Diamond 3.5 mitgekommen 
ist. Auch eine alte ActiveHdl Version verhält sich identisch.
Habt Ihr solche Effekte auch schon mal beobachten können? Habt Ihr eine 
Idee, wie ich den Fehler umgehen kann?

Viele Grüße
M.F. (aka Fred)

[Pat A. (patamat)]

Ohne jetzt den Sourcecode simuliert zu haben, sieht das für mich nach 
einem Delta-T Problem aus.

Stell den Simulator mal um, so dass auch Delta-T-Zyklen angezeigt 
werden. Und dann schaue mal auf die zeitliche Korrelation von Takt und 
Daten.

Eine Zuweisung wie "sAbstractedOddrInputBits <= 
sDirectOddrInputBits_20;" erzeut immer einen weiteren Delta-T-Zyklus und 
damit eine Verschiebung gegenüber dem Takt.

Nach meiner Erfahrung treten solche Probleme dann auf, wenn der Takt bei 
Delta-T > 0 auftritt. Dadurch ändern sich einige Signal vor dem Takt, 
andere erst nach dem Takt und damit erst einen Taktzyklus später.

Abhilfe schafft in diesem Fall eine Verzögerung des Taktes mit z.B. 
"after 1 ps".

[VHDL hotline (Gast)]

M. F. schrieb:
> Habt Ihr eine
> Idee, wie ich den Fehler umgehen kann?

Das Problem liegt hier

oSysRst     <= sSysRst;
oSysClk     <= sSysClk;
oFastClk    <= sFastClk;

Mach keine Taktzuweisungen per <= , da die ein delta cycle delay in den 
Taktpfad einbringen.

So etwas ähnliches wurde hier schon diskutiert

Beitrag "Verständnis von delta-Zyklen in der Simulation"

siehe dort auch den Link, den ich im zweiten Post geschrieben habe.

[Sigi (Gast)]

Dein Problem liegt zum einen in der
Clock-Zuweisung innerhalb GlobalModule
und zum anderen an
sAbstractedOddrInputBits_20 <= sDirectOddrInputBits_20;
im Top-Modul. Damit verschiebst du die
Gültigkeit zu Ungunsten der DDR-Clocks.
Zeichne dir einfach mal den
Zuweisungsgraphen auf und mach dir klar,
das ODDR-Register ja wie Register nur
max. "gleichalte" Werte akzeptieren.

Wenn du ein Signal sDDRClk einfügst, statt
sFastClk in den ODDR1 Komponenten sDDRClk
verwendest und die Zeile
sDDRCLK <= sFastClk einfügst, dann müsste
die Simulation wieder klappen (notfalls noch
ein zweites sDDRClk2 <= sDDRClk etc.).
Das aber bitte nur als Notnagel sehen,
besser das Ganze "gesund" aufsetzen!

[Fpga I. (fpga-ing)]

Hallo zusammen

vielen Dank für Eure Antworten! Ich hoffe, dass ich es nun richtig 
verstanden habe und keinen Knoten im Kopf habe.

Ich fasse mal kurz zusammen, wie ich die Delta Zyklus Thematik 
verstanden habe:
 - Die Zuweisung oFastClk    <= sFastClk; verzögert oFastClk gegenüber 
sFastClk um einen Takt.
 - Zuordnungen wie z.B. sAbstractedOddrInputBits <= 
sDirectOddrInputBits_20 sollten unkritisch sein, da es sich hierbei um 
Daten und nicht um Taktsignale handelt (zumindest aus der Sicht der 
Simulation)
 - Die Clock Verzögerung kann dazu führen, dass sich Signale 
vermeintlich schon kurz vor der Taktflanke ändern, nämlich genau dann, 
wenn ich sie mit sFastClk schreibe und mit oFastClk lese

Dies ist in meinem Beispiel der Fall, da ich im Global Module mit 
sFastClk arbeite und ausserhalb mit oFastClk. Der folgende Code sollte 
somit mein Problem beheben:

ilPll100M0 : PLL100M0
port map (
    CLK     => iExtClk,         -- external clock "ExtClk"
    RESET   => sPllReset100,    -- External Reset
    CLKOP   => sSysClkPll,      -- normal internal system clock (= 50.0 MHz)
    CLKOS   => sFastClkPll,     -- fast internal system clock (= 100.0 MHz)
    LOCK    => sPllLock100      -- PLL Lock Signal, used for PLL20M0 reset
);

-- Output Assignment
oSysRst     <= sSysRstSyn(sSysRstSyn'high);
sSysRst     <= sSysRstSyn(sSysRstSyn'high);
sSysClk     <= sSysClkPll;
oSysClk     <= sSysClkPll;
sFastClk    <= sFastClkPll;
oFastClk    <= sFastClkPll;

Liege ich mit meiner Annahme richtig?
Muss ich das Reset Signal ebenfalls mit dieser doppelten Zuweisung 
versehen? (Reset ist in Prozessen asynchron beschrieben)
Simuliere ich so, dann stelle ich fest, dass ich noch einen Fehler in 
meiner Implementierung habe, da die ODDR Ausgänge eben doch nicht 
synchron zu sReferenceClk sind.

Wo wir gerade bei dem Thema sind:
sSysClk und sFastClk kommen beide aus der PLL, unterscheiden sich in der 
Frequenz um den Faktor 2 und sind phasengleich. In der Synthese brauche 
ich mir bei Taktübergängen somit keine Gedanken machen, da das FPGA Tool 
ja die Taktbeziehung kennt und somit sich auch um das Timing kümmern 
kann. Ich muss lediglich darauf achen, die entsprechenden Signale auf 
einen schnellen Takt zu verkürzen oder auf dem Rückweg auf 1 langsamen 
Takt zu velängern.
Wie sieht es jedoch in der Simulation aus? Kann ich von einer 
Gleichzeitigkeit der beiden Takt Events ausgehen? Muss ich hier noch 
Vorkehrungen treffen?

[Marco (Gast)]

Normalerweise sollte das gehen, weil die Takte mathematisch exakt gleich 
sind. Das Delta-Problem bleibt Dir aber auch da.

[Fpga I. (fpga-ing)]

@Marco
Danke für die Antwort.

M. F. schrieb:
> Liege ich mit meiner Annahme richtig?
> Muss ich das Reset Signal ebenfalls mit dieser doppelten Zuweisung
> versehen? (Reset ist in Prozessen asynchron beschrieben)

Kann mir jemand Antwort auf diese Fragen geben?