Per alcune combinazioni di parametri, simulatori e stili di codifica RTL, la latenza di questo blocco nella simulazione si discosta dalla latenza prevista di , - un clock. L'hardware effettivo mostra la latenza prevista.
Questo comportamento verrà visualizzato, ad esempio, se il clock che guida il blocco DSP è una versione ritardata del clock che genera i dati di input, introducendo così più ritardo di simulazione per il clock di input che per i dati di input.
Per risolvere questo problema, è necessario assicurarsi che i ritardi tra il clock che genera i dati di input nel blocco DSP e il clock di input del blocco DSP siano bilanciati da ritardi nei dati di input. In alternativa, assicurarsi che i dati di input arrivino a un tempo assoluto successivo o a un tempo di ritardo delta della simulazione successiva rispetto al clock di input del blocco DSP.
Si noti che, ad esempio, più istruzioni di assegnazione sul percorso di clock rispetto al percorso dei dati causeranno differenze di ritardo delta della simulazione tra questi percorsi.
Per eseguire questa operazione, modificare il testbench in:
- Assicurarsi che gli input di clock che generano nel blocco DSP nativo siano esattamente lo stesso segnale dell'ingresso di clock al blocco DSP nativo.
- Se il numero 1 non è fattibile, ritardare i dati di input relativi al clock.
Ad esempio, si consideri il seguente codice RTL originale:
RTL originale:
clk_gen: processo
Iniziare
clk_orig <= \'0\';
attendere 5 ns;
clk_orig <= \'1\';
attendere 5 ns;
processo finale;
...
se (rising_edge(clk_orig)) allora
ax <= ax 1;
ay <= ay - 1;
terminare se
mac_test_bad_style: mult_acc
mappa porta (
...
ax => std_logic_vector(ax), -- [in]
ay => std_logic_vector(ay), -- [in]
clk => ("00" &clk_orig), -- [in]
resulta => resulta2, -- [out]
...
);
resulta2 mostrerà un clock in meno di latenza del previsto. Si noti che la concatenazione di "00 &clk" nell'assegnazione della porta clk del moltiplicatore aggiunge un ritardo delta della simulazione dal "clk_orig" che genera i dati di input.
Le possibili soluzioni includono:
Esempio 1, raccomandazione: utilizzare un clock a 3 bit in tutto
È possibile generare direttamente il clock a 3 bit del moltiplicatore e utilizzare il bit attivo per eseguire il clock dei dati di input:
clk_gen: processo
Iniziare
clk3bit <= \'000\';
attendere 5 ns;
clk3bit <= \'001\';
attendere 5 ns;
processo finale;
...
if (rising_edge(clk3bit(0)) allora
ax <= ax 1;
ay <= ay - 1;
terminare se
mac_test_bad_style: mult_acc
mappa porta (
...
ax => std_logic_vector(ax), -- [in]
ay => std_logic_vector(ay), -- [in]
clk => (clk_3bit), -- [in]
resulta => resulta2, -- [out]
...
);
Esempio 2, raccomandazione alternativa: aggiungere il ritardo corrispondente ai dati di input
L'istruzione \'clk => ("00" &clk_orig)\' fa sì che la porta \'clk" abbia un ulteriore ritardo delta di simulazione da \'clk_orig\' che sta guidando i dati. Per superare questo, è possibile utilizzare il processo di clk_gen originale e aggiungere ritardi delta di simulazione ai dati con le dichiarazioni di assegnazione.
clk_gen: processo (identico all'originale)
ax_del <= ax;
ay_del<=ay;
mac_test_bad_style: mult_acc
mappa porta (
...
ax => std_logic_vector(ax_del), -- [in]
ay => std_logic_vector(ay_del), -- [in]
clk => ("00" &clk_orig), -- [in]
resulta => resulta2, -- [out]
...
);
