Est-ce un bug de ModelSim ou un bug de mon design

[presto]

Salut, il ya,

Je pense que ce code peut retarder l'wufifo_out »pour un cycle.

Coderocessus

commencer

attendre rising_edge (sys_clk);

Test <= wufifo_out;

processus de bout;

 

[nand_gates]

Le résultat vous avez obtenu est manifestement erronée pour le code!

Quelle version de Modelsim utilisez-vous???Sur quelle plate-forme??
Comment vous êtes la génération du signal "wufifo_out"???

J'ai essayé simple code ci-dessous.Et il fonctionne très bien pour "count_reg" signal

Code:

IEEE bibliothèque;

ieee.std_logic_1164.all utilisation;

ieee.std_logic_unsigned.all utilisation;entité est contreport (

CLK: en std_logic;

reset_n: en std_logic;

count: std_logic_vector à (7 downto 0));contre fin;com architecture de compteur estcom - com

comptage: Le processus (CLK, reset_n)

count_tmp variable: std_logic_vector (7 downto 0);

commencer - le dépouillement des

si reset_n = '0 'alors - reset asynchrone (actif bas)

count_tmp: = (autres => '0 ');

<Count = (autres => '0 ');

clk'event elsif et CLK = '1 'alors - front montant d'horloge

Count_tmp count_tmp: = 1;

<Count = count_tmp;

fin si;

dépouillement fin;

com fin;IEEE bibliothèque;

ieee.std_logic_1164.all utilisation;

work.all utilisation;tst entité esttst fin;architecture tst_behave de TST est

élément contre

port (

CLK: en std_logic;

reset_n: en std_logic;

count: std_logic_vector à (7 downto 0));

composante fin;

Nombre de signal: std_logic_vector (7 downto 0);

CLK signal: std_logic: = '0 ';

reset_n signal: std_logic: = '0 ';

count_reg signal: std_logic_vector (7 downto 0): = (autres => '0 ');

commencer - tst_behave

<= CLK CLK transport non au bout de 5 ns;

U1: carte port compteur (

clk => CLK,

reset_n => reset_n,

count => count);processus

commencer

attendre rising_edge (CLK);

compteur <= count_reg;

processus de bout;

processus

commencer

attendre 24 ns;

<Reset_n = '1 ';

attendre 1000 ns;

<Reset_n = '0 ';

d'attente;

processus de bout;

tst_behave fin;

 

[masai_mara]

J'ai observé un comportement similaire dans ModelSim et a peut-être à voir avec le calendrier des événements par le simulateur et il disparaît parfois.afin d'assurer la cohérence, il est recommandé que vous ne donnez pas votre entrée au même moment que le front d'horloge se produit.

 

[Zape]

J'ai connu le même problème une fois avec ModelSim SE 5.8c (je crois que c'était la version).J'ai été informé qu'il a été résolu dans la prochaine version.

 

[haoboy]

je l'essaie en 5.7f, mais ok.

 

[presto]

Salut, il ya,

J'ai résolu le problème.

Le problème est que la «wfifo_out 'est entraîné par le front montant d'horloge appelé« wb_clk_i, et la relation entre les wb_clk_i »et« sys_clk est

Code:

<= Sys_clk wb_clk_i;

 

[Jitendra]

Salut,
Comportement des ModelSim est correct et son à cause du style de codage.

and then schedule the assignment of signal test
.

Comme par le code de pesto, ModelSim attendra front montant de sys_clk
puis planifier l'affectation du signal de test.will be assigned to signal test
in next delta and not in the next cycle.

Ainsi, la valeur de wufifo_out
signal sera affecté au signal de test
dans le delta du prochain et non pas dans le prochain cycle.
façon simple de réaliser l'objectif d'un report de cette mission par un cycle est de l'utilisation de signal intermédiaire.S'il vous plaît vérifier le code ci-dessous, il devrait servir à cette fin.
=================================
processus
commencer
attendre rising_edge (sys_clk);
<= Test_latched wufifo_out;
Test <= test_latched;
processus de bout;
=================================and test
will be scheduled on next delta after the rising edge of sys_clk
.

Or, dans ce code, la cession de test_latched
et d'essai
sera fixée sur le delta prochaine après le front montant de sys_clk.will be assigned the value of wufifo_out
and test
will be assigned old value of test_latched
.

Signal test_latched
sera affecté la valeur de wufifo_out
et test
sera attribué ancienne valeur de test_latched.will be assigned the value of test_latched
ie value of wufifo_out
in current cycle.

Alors, la prochaine cycle d'essai
en sera affecté de la valeur de la valeur du savoir test_latched wufifo_out
dans le cycle actuel.

Cordialement,
Jitendra

 

[take_care00]

Presto Salut,

Votre solution est correcte, mais votre interprétation n'est pas.

En raison de la <= sys_clk wb_clk_i; affectateurs la norme VHDL exige que le changement sys_clk être programmé pour 1 cycle delta après un changement de signal wb_clk_i.Ainsi, Modelsim suit le comportement correct.

N'oubliez pas que dans VHDL "<=" missions sont toujours prévu pour être traitées dans le cycle suivant pendant delta ": =" affectations sont traitées dans le cycle delta même.

Prenez soin.

 

[funzero]

De même pour bloquer ou assignmnet nonblock cession de Verilog