incomplete sensitivity list check in Quartus II

[Altera_Forum]

I wrote some VHDL code with incomplete sensitivity list as following and compile it with Quartus II. But, Quartus II didn't give any warnings on this. 

Does anybody know how to make quatus ii to check incomplete sensitivity list and give warnings?  Also how to make Modelsim to report the same warnings?   p_3: process (iCLK) begin if rising_edge(iCLK) then if mDVAL = '1' then if iX_Cont(0)='1' and iY_Cont(0)='1' then rRed <= taps_1; rGreen <= taps_1_d0; rBlue <= taps_0_d0; elsif iX_Cont(0)='0' and iY_Cont(0)='1' then rRed <= taps_1_d0; rGreen <= taps_0_d0; rBlue <= taps_0_d1; elsif iX_Cont(0)='1' and iY_Cont(0)='0' then rRed <= taps_1_d0; rGreen <= taps_0_d0; rBlue <= taps_0_d1; elsif iX_Cont(0)='0' and iY_Cont(0)='0' then rRed <= taps_1_d0; rGreen <= taps_0_d0; rBlue <= taps_0_d1; end if; end if; end if; end process; end trans;

[Altera_Forum]

In this code there is no incomplete sensitivity list because the general description of a register is: 

 process(clk) begin  if rising_edge(clk) = '1' then  q_reg <= q_next;  end if; end process;  The process only activates on clk change ( when you change the input of flip-flop D, the output don't change until active clock edge). So you don't need q_next or equivalent expression in the sensitivity list.

[Altera_Forum]

bertulus, thanks for your answer, what's the principle for adding signals to sensitivity list? For the code below, is the sensitivity list complete? 

process (vin_clk,rst_n,frame_flag_vin,vin_de,data_cnt) begin if rising_edge(vin_clk) then if (rst_n = '0') then data_cnt <= (others=>'0'); elsif (frame_flag_vin = '1') then data_cnt <= (others=>'0'); elsif (vin_de = '1') then if (data_cnt = vin_width - 1) then data_cnt <= (others=>'0'); else data_cnt <= data_cnt + 1; end if; else data_cnt <= data_cnt; end if; end if; end process;

[Altera_Forum]

You have over specified on this process, as it is a synchronous process. You only need to add signals to the sensitivity list that can cause a change in the output values. For a synchronous process, values can only change when you get a clock edge - this causes the process to re-run. 

 Any signal in a sensitivity list will cause that process to be re-evaluated on signal change in simulation. So adding too many signals can cause simulations to slow down as it keeps re-evaluating the process unnecessarily. On the flip side, for a non-synchronous process, adding too few signals can cause simulation behaviour to missmatch the real logic. For example:   process(clk) begin if clk = '1' then op <= ip1 and ip2; end if; end process;   In simulation, the waveform for this process would make it look like a clocked process. But the synthesis tool would create a transparent latch. This would cause missmatches.

[Altera_Forum]

Dear Tricky, Thanks for your answer. If I understand correctly, in the sensitivity list of my code, I can delete all signals except for clk. And make it look like: process (vin_clk). Am I correct?

[Altera_Forum]

That is correct.

[Altera_Forum]

Is the consequence of over-specifying sensitivity list only limited to making simulation very slow? Is there any other consequence like making my real logic uncorrect?

[Altera_Forum]

Over speccing them wont really slow simulation down too much - modelsim et al. now should be clever enough to work out whats really needed. But its still potential for extra simulation burdon. 

 A sensitivity list is just for simulation - and it is just a means to tell the simulator when a process should be executed. So you're unlikely to have correct logic and incorrect simulation because of a sensitivity list - its probably the code inside the process.   You could cause errors in a testbench. Say you wanted to write something to a file every time a certain signal changed. Putting extra signals in the sensitivity list would make it write out to the file too often, but this is a bit contrived.   --Output when A changes process(a,b) begin report "a is " & to_string(a) severity note; --oops, this also reports when B changes too end process;

[Altera_Forum]

Dear Tricky, Thanks for your reply which makes me understand deeply and clearly.