Illogical comparator output

[Altera_Forum]

Hi ,  

i design 8 bit comparator at VHDL :  ------------------------------------------------------------------------------------------ library ieee; use ieee.std_logic_1164.all;   entity comparator is  port(   ResetP : in std_logic;  cmp_in_Tx : in std_logic_vector(7 downto 0);   cmp_in_Rx : in std_logic_vector(7 downto 0);   cmp_out : out std_logic --cmp_out is the result of the comparator   ); end entity comparator;   architecture behave of comparator is   begin process (ResetP)  begin  if (ResetP= '1') then   cmp_out <='0';  elsif (ResetP = '0') then   if( cmp_in_Rx = cmp_in_Tx) then  cmp_out <= '1';  else   cmp_out <= '0';  end if;  end if;  end process; end behave;  ------------------------------------------------------  The thing is , that the comparator output : cmp_out is consistently '1' although the cmp_in_Rx is different then cmp_in_Tx and ResetP = '0' . what is the reason for that ?   attached waveform .

[Altera_Forum]

Hi odedidush. 

 Did you run a testbench? You're using a process to compare. A process is like a black box with inputs and outputs. You have to place all inputs to the process in the sensitivity list:  process(ResetP, cmp_in_Rx, cmp_in_TX)  If you don't will be inferred latches. The process only activates if signals in sensitivuty list changes. If not, the output remains with its last value.  In practice, the synthetizer can't implement inferred latches, so your circuit keeps combinational, but simulation stills shows the inferred latch behavior. So, in this case, simultation behaves different from real fpga operation.

[Altera_Forum]

Hi bertulus ,  

You're right ,  I change to : process(ResetP, cmp_in_Rx, cmp_in_TX) and now it works .  thanks :)

[Altera_Forum]

--- Quote Start ---   In practice, the synthetizer can't implement inferred latches, so your circuit keeps combinational, but simulation stills shows the inferred latch behavior. So, in this case, simultation behaves different from real fpga operation.  --- Quote End ---    Wrong. The synthesisor can generate you infered latches, as the origional code does. And it will warn you about it. To avoid latches, you need to make sure all if statements have an else inside asynchronous processes. The sensitivity list is for simulation only, and in the OPs case this solved the code not working problem, but would have worked as expected on hardware as the synthesisor ignores senstivity lists.

[Altera_Forum]

You're right Tricky. I confused inferred latch with another concept. When you ommitted a signal in sensitivy list, like: 

 process(a) begin  c <= a or b; end process;  It seems like we're trying to describe some kind of inferred memory because a change on b not change the output. This was I was thinking.  As you said, Quaryus implement latches. I saw a technoloy map viewer and there are a subtle difference in how Quartus understand the code:  process(le, d)  begin  if( le = '1' ) then  q <= d;  end if;  end process;  This version inferred a latch.  With this:  process(le)  begin  if( le = '1' ) then  q <= d;  end if;  end process;  inferred a flip-flop d without usign 'event clause.

[Altera_Forum]

That is an interesting development. 

But its still not recomended.

[Altera_Forum]

--- Quote Start ---  With this:  process(le) begin if( le = '1' ) then q <= d; end if; end process;  inferred a flip-flop d without usign 'event clause.   --- Quote End ---   Hard to believe and against all known RTL synthesis rules, e.g. IEEE 1076.6.   Which Quartus version did you see to infer a DFF from the code?   Of course, in functional simulation q would be only changed on rising edge of le, due to the missing d in sensitivity list. But in synthesized hardware, it will be still acting as a latch.

[Altera_Forum]

I tried it and it happened in Q13