Warum zeigt mein nativer Fixpunkt-DSP-Block eine unerwartete Latenz in der Simulation an?

Bei einigen Kombinationen von Parametern, Simulatoren und RTL-Codierungsstilen unterscheidet sich die Latenz dieses Blocks in der Simulation von der erwarteten Latenz durch , - eine Uhr. Die tatsächliche Hardware weist die erwartete Latenz auf.

Dieses Verhalten wird beispielsweise angezeigt, wenn der Takt, der den DSP-Block antreibt, eine verzögerte Version des Takts ist, der die Eingabedaten generiert, was mehr Simulationsverzögerung für den Eingabe-Takt als für die Eingabedaten einführt.

Um dieses Problem zu umgehen, müssen Sie sicherstellen, dass Verzögerungen zwischen dem Takt, der Eingabedaten zum DSP-Block generiert, und dem Eingabe-Takt des DSP-Blocks durch Verzögerungen bei den Eingabedaten ausgeglichen werden. Alternativ stellen Sie sicher, dass die Eingabedaten zu einer späteren absoluten Zeit, oder einer späteren Simulations-Delta-Verzögerungszeit, im Vergleich zum Eingabetakt des DSP-Blocks ankommt.

Beachten Sie, dass z. B. mehr Zuweisungsanweisungen auf dem Taktpfad im Vergleich zum Datenpfad Unterschiede bei der Simulations-Delta-Verzögerung zwischen diesen Pfaden verursachen.

Um dies zu erreichen, ändern Sie Ihren Testbench auf:

1. Stellen Sie sicher, dass die Takterzeugungseingaben im nativen DSP-Block genau das gleiche Signal sind wie die Takteingabe für den nativen DSP-Block.
2. Wenn #1 nicht durchführbar ist, verzögern Sie die Eingabedaten relativ zum Takt.

Betrachten Sie zum Beispiel den folgenden originalen RTL-Code:

Original RTL:

clk_gen: Prozess
Beginnen
clk_orig <= \'0\';
Warten Sie auf 5 ns;
clk_orig <= \'1\';
Warten Sie auf 5 ns;
Endprozess;

...

wenn (rising_edge(clk_orig))
ax <= ax 1;
ay <= ay - 1;
End if

mac_test_bad_style: mult_acc
Port-Karte (
...
ax => std_logic_vector(ax), -- [in]
ay => std_logic_vector(ay), -- [in]
clk => ("00" &clk_orig), -- [in]
resulta => resulta2, -- [out]
...
);

resulta2 zeigt einen Takt weniger Latenz als erwartet an. Beachten Sie, dass die Verkettung von "00 &clk" in der CLK-Portzuweisung des Multiplikators eine Simulations-Delta-Verzögerung aus dem "clk_orig" hinzufügt, der die Eingabedaten generiert.

Mögliche Problemumgehungen:

Beispiel 1, Empfehlung: Verwenden Sie durchgehend eine 3-Bit-Taktfrequenz

Sie können die 3-Bit-Taktfrequenz des Multiplikators direkt generieren und das aktive Bit verwenden, um die Eingabedaten zu takten:

clk_gen: Prozess
Beginnen
clk3bit <= \'000\';
Warten Sie auf 5 ns;
clk3bit <= \'001\';
Warten Sie auf 5 ns;
Endprozess;

...

wenn (rising_edge(clk3bit(0)) dann
ax <= ax 1;
ay <= ay - 1;
End if

mac_test_bad_style: mult_acc
Port-Karte (
...
ax => std_logic_vector(ax), -- [in]
ay => std_logic_vector(ay), -- [in]
clk => (clk_3bit), -- [in]
resulta => resulta2, -- [out]
...
);

Beispiel 2, Alternative Empfehlung: Fügen Sie die entsprechende Verzögerung zu den Eingabedaten hinzu

Die Anweisung \'clk => ("00" &clk_orig)\' verursacht, dass der \'clk"-Port eine zusätzliche Simulations-Delta-Verzögerung von \'clk_orig\' hat, die die Daten vorantreibt. Um dies zu überwinden, können Sie den ursprünglichen clk_gen prozess verwenden und nur Simulation-Delta-Verzögerungen zu den Daten mit Zuweisungsanweisungen hinzufügen.

clk_gen: Prozess (gleich wie im Original)

ax_del <= ax;
ay_del<=ay;

mac_test_bad_style: mult_acc
Port-Karte (
...
ax => std_logic_vector(ax_del), -- [in]
ay => std_logic_vector(ay_del), -- [in]
clk => ("00" &clk_orig), -- [in]
resulta => resulta2, -- [out]
...
);