Dlaczego mój natywnego bloku DSP z wartością stałoprzetnijną wykazuje nieoczekiwane opóźnienia w symulacji?

W przypadku niektórych kombinacji parametrów, symulatorów i stylów kodowania RTL opóźnienie tego bloku w symulacji różni się od oczekiwanego opóźnienia według , — jeden zegar. Rzeczywisty sprzęt wykazuje oczekiwane opóźnienia.

Takie zachowanie będzie widoczne, na przykład, jeśli zegar napędzający blok DSP jest opóźnioną wersją zegara generującego dane wejściowe, wprowadzając w ten sposób większe opóźnienie symulacji zegara wejściowego niż w przypadku danych wejściowych.

Aby rozwiązać ten problem, musisz upewnić się, że opóźnienia między zegarem, który generuje dane wejściowe do bloku DSP, a zegarem wejściowym bloku DSP, są zrównoważone opóźnieniami na danych wejściowych. Alternatywnie upewnij się, że dane wejściowe pojawią się w późniejszym czasie absolutnym lub późniejszego czasu opóźnienia delta symulacji, w porównaniu z zegarem wejściowym bloku DSP.

Należy pamiętać, że takie rzeczy, jak więcej instrukcji przypisanych na ścieżce zegara w porównaniu ze ścieżką danych, spowoduje różnicę w opóźnieniu symulacji pomiędzy tymi ścieżkami.

Aby to osiągnąć, zmodyfikuj swój testbench na:

1. Upewnij się, że wejścia generujące zegar do bloku Natywnego DSP to dokładnie ten sam sygnał co wejście zegara do natywnego bloku DSP.
2. Jeśli nr 1 nie jest wykonalny, opóźnij dane wejściowe względem zegara.

Weźmy na przykład następujący oryginalny kod RTL:

Oryginalny RTL:

clk_gen: proces
Rozpocząć
clk_orig <= \'0\';
poczekaj na 5 ns;
clk_orig <= \'1\';
poczekaj na 5 ns;
procesu końcowego;

...

jeśli (rising_edge(clk_orig)) następnie
ax < = ax 1;
ay <= ay – 1;
koniec, jeśli

mac_test_bad_style: mult_acc
mapa portu (
...
ax => std_logic_vector(ax), -- [w]
ay => std_logic_vector(ay), -- [w]
clk => ("00" i clk_orig), -- [w]
resulta => resulta2, -- [out]
...
);

wynik 2 wyświetli jeden zegar o mniejszym opóźnieniu niż się spodziewano. Należy pamiętać, że efekt "00 & clk" we przypisaniu portu clk mnożnika dodaje opóźnienie delta symulacji z "clk_orig", który generuje dane wejściowe.

Możliwe możliwości obejścia obejmują:

Przykład 1, rekomendacja: korzystaj z zegara 3-bitowego w całym obszarze

Możesz wygenerować zegar 3-bitowy mnożnika bezpośrednio i użyć aktywnego bitu do taktowania danych wejściowych:

clk_gen: proces
Rozpocząć
clk3bit <= \'000\';
poczekaj na 5 ns;
clk3bit <= \'001\';
poczekaj na 5 ns;
procesu końcowego;

...

jeśli (rising_edge(clk3bit(0))), a następnie
ax < = ax 1;
ay <= ay – 1;
koniec, jeśli

mac_test_bad_style: mult_acc
mapa portu (
...
ax => std_logic_vector(ax), -- [w]
ay => std_logic_vector(ay), -- [w]
clk => (clk_3bit), -- [w]
resulta => resulta2, -- [out]
...
);

Przykład 2, zalecenie alternatywne: dodanie odpowiedniego opóźnienia do danych wejściowych

Stwierdzenie \'clk => ("00" & clk_orig)\' powoduje, że port \'clk" ma dodatkowe opóźnienie różnicy symulacji z \'clk_orig\' prowadzącego dane. Aby to przezwyciężyć, możesz skorzystać z oryginalnego procesu clk_gen i po prostu dodać opóźnienia delta symulacji do danych z instrukcjami cesji.

clk_gen: proces (taki sam jak oryginalny)

ax_del <= ax;
ay_del<=ay;

mac_test_bad_style: mult_acc
mapa portu (
...
ax => std_logic_vector(ax_del), -- [w]
ay => std_logic_vector(ay_del), -- [w]
clk => ("00" i clk_orig), -- [w]
resulta => resulta2, -- [out]
...
);