When must a signal be inserted into the sensitivity list of a process - process

Question

I am confused about when a signal declared in an architecture must be inserted into the sensitivity list of a process.
Is there is a general law that can be followed in any situation?
I have real difficulties understanding when I have to include a signal in a process sensitivity list.

Answer 1

The "general law" is that
anything that your process needs to know about changes of needs to be in the sensitivity list.
For a typical synthesisable register with a synchronous reset:
process (clk) is
begin
if rising_edge(clk) then
if reset = '1' then
-- do reset things
else
-- read some signals, assign some outputs
end if;
end if;
end process;
Only the clock needs to be in the list, as everything else is only looked at when the clock changes (due to the if rising_edge(clk) statement.
If you need an asynchronous reset:
process (clk, reset) is
begin
if reset = '1' then
-- do reset things
elsif rising_edge(clk) then
-- read some signals, assign some outputs
end if;
end process;
then the reset signal must also be in the sensitivity list, as your design needs to check the value of it every time it changes, irrespective of what the clock is doing.
For combinatorial logic, I avoid using processes completely because of the problems keeping the sensitivity list up-to-date, and the potential for simulation then behaving differently to the synthesised code. This has been eased by the all keyword in VHDL-2008, but I still haven't found myself wanting to write long complicated combinatorial logic such that a process would help.

Answer 2

If a signal is in the sensitivity list of a process, the process will "wake up" and be evaluated whenever the value of that signal changes. If it is not in the sensitivity list, a signal can change, but a process will not be re-evaluated to determine what the new outputs should be.
For Combinatorial Logic: Likely you want all your input signals to be included in the sensitivity list. If they are not included in the sensitivity list, then that will result in your output not changing even when that input signal changes. This is a common error (due to carelessness). Note that in VHDL 2008 you can use "all" keyword to automatically include all necessary signals in your process and avoid creating latches.
For Synchronous Logic: Likely you only want your clock (and maybe your reset) signal in the sensitivity list. This is because you are only concerned with the value of your signals (other than the clock) when your system clock has changed. This is because you are typically describing registers (composed of flip flops) which only allow changing their output value on a clock edge.
All of this can be confusing in the case of using HDL for synthesis because only a subset of the circuits you describe in VHDL can actually be implemented within a FPGA. For example, you can't have a primitive memory element that is sensitive to two independent clock edges, even though you could describe such a circuit by including two clocks in a sensitivity list.

Answer 3

Also, the synthesis tools (talking about the Xilinx XST in this case) don't necessarily always respect the process sensitivity list. If you fail to list all the processes whose values are evaluated in the body of the process, the XST will emit a warning saying that it's going to assume that the signals whose values are evaluated are on the sensitivity list. That may lead to differences between behavioral simulations and actual hardware. Keep it in mind.

Answer 4

...also, be warned, the sensitivity list has no influence over the behaviour of your design once it is synthesised. It is only used during simulation. Hence it's quite easy to introduce a difference in behaviour between RTL and synthesised code by changes to the sensitivity list.
The rules Josh gives are good, but above all, read the warnings your tools give you and act on them. They normally check that the sensitivity list is correct and will flag any problems. Emacs VHDL mode also has a command to update the sensitivity list, and it's normally pretty good at it.
Hmmmm, Ninja'd