Pour certaines combinaisons de paramètres, de simulateurs et de styles de codage RTL, la latence de ce bloc dans la simulation s’écarte de la latence prévue par , - une horloge. Le matériel réel présente la latence attendue.
Ce comportement sera constaté, par exemple, si l’horloge à l’origine du bloc DSP est une version différée de l’horloge qui génère les données d’entrée, introduisant ainsi plus de retard de simulation pour l’horloge d’entrée que pour les données d’entrée.
Pour contourner ce problème, vous devez vous assurer que les retards entre l’horloge qui génère des données d’entrée dans le bloc DSP et l’horloge d’entrée du bloc DSP, sont équilibrés par des retards sur les données d’entrée. Vous pouvez autrement vous assurer que les données d’entrée arrivent à une heure absolue ultérieure, ou un temps de retard de simulation de simulation ultérieure, par rapport à l’horloge d’entrée du bloc DSP.
Notez que des choses telles que plus d’instructions de cession sur le chemin d’horloge par rapport au chemin de données entraîneront des différences de retard de simulation entre ces chemins.
Pour ce faire, modifiez votre testbench pour :
- Assurez-vous que l’horloge qui génère des entrées sur le bloc DSP natif est exactement le même signal que l’entrée d’horloge du bloc DSP natif.
- Si la première n’est pas réalisable, retardez les données d’entrée par rapport à l’horloge.
Par exemple, considérez le code RTL d’origine suivant :
RTL d’origine :
clk_gen : processus
Commencer
clk_orig <= \'0\' ;
attendre 5 ns ;
clk_orig <= \'1\' ;
attendre 5 ns ;
processus final ;
...
si (rising_edge(clk_orig)) alors
<x = ax 1 ;
ay <= ay - 1 ;
fin si
mac_test_bad_style : mult_acc
carte de port (
...
ax => std_logic_vector(ax), -- [en]
ay => std_logic_vector,ay), -- [en]
lk => (« 00 » & clk_orig), -- [en]
resulta => resulta2, -- [out]
...
);
le résultata2 affiche une horloge moins de latence que prévu. Notez que la concatation de « 00 & clk » dans la cession du port de l’lk du multiplicateur ajoute un retard de simulation du « clk_orig » qui génère les données d’entrée.
Les solutions possibles comprennent :
Exemple 1, Recommandation : utilisez une horloge 3 bits tout au long
Vous pouvez générer l’horloge 3 bits du multiplicateur directement et utiliser le bit actif pour horloger les données d’entrée :
clk_gen : processus
Commencer
clk3bit <= \'000\';
attendre 5 ns ;
clk3bit <= \'001\';
attendre 5 ns ;
processus final ;
...
si (rising_edge(clk3bit(0)) alors
<x = ax 1 ;
ay <= ay - 1 ;
fin si
mac_test_bad_style : mult_acc
carte de port (
...
ax => std_logic_vector(ax), -- [en]
ay => std_logic_vector,ay), -- [en]
lk => (clk_3bit), -- [en]
resulta => resulta2, -- [out]
...
);
Exemple 2, Autre recommandation : ajoutez le retard correspondant aux données d’entrée
La déclaration \'clk => (« 00 » & clk_orig) entraîne un retard supplémentaire du port \'clk » du port de simulation de \'clk_orig\' qui est à l’origine des données. Pour surmonter cela, vous pouvez utiliser le processus de clk_gen d’origine et ajouter des retards de simulation à des données avec les relevés de affectation.
clk_gen : processus (identique à l’original)
ax_del <= ax ;
ay_del<=ay ;
mac_test_bad_style : mult_acc
carte de port (
...
ax => std_logic_vector (ax_del), -- [en]
ay => std_logic_vector (ay_del), -- [en]
lk => (« 00 » & clk_orig), -- [en]
resulta => resulta2, -- [out]
...
);