rising_edge() vs process sensitivity list

Question

I've been developing in VHDL for a while in a University course and I thought that I understood how it worked, but once in a while I realize that I quite not actually understand it.

Here goes my question:

As I could understand, if a signal is in a process's sensitivity list, the process will "execute" whenever that signal changes value.

So I ask, what is the difference between these 2 pieces of code:

process(clk) is
begin
  if(clk = '1') then
      --Do Something
  end if;
end process;

and

process(clk) is
begin
   if(rising_edge(clk)) then
      --Do Something
   end if;
end process;

Shouldn't they behave equally?

Answer 1

Simulation:

Let's see how VHDL signals value are defined in VHDL. You'll find theses definitions in ieee.std_logic_1164 library.

Usually, signals are declared as std_logic which is the resolved subtype of std_ulogic defined as follow :

  type STD_ULOGIC is ( 'U',             -- Uninitialized
                       'X',             -- Forcing  Unknown
                       '0',             -- Forcing  0
                       '1',             -- Forcing  1
                       'Z',             -- High Impedance   
                       'W',             -- Weak     Unknown
                       'L',             -- Weak     0       
                       'H',             -- Weak     1       
                       '-'              -- Don't care
                       );

We can see that this kind of signals can have several others value than the usual '0' and '1'. The difference between your two processes lays here.

Let's see now how the rising_edge function is defined, always in the std_logic_1164 library :

  function rising_edge (signal s : STD_ULOGIC) return BOOLEAN is
  begin
    return (s'event and (To_X01(s) = '1') and
            (To_X01(s'last_value) = '0'));
  end function rising_edge;

  function To_X01 (s : STD_ULOGIC) return X01 is
  begin
    return (cvt_to_x01(s));
  end function To_X01;

  ----------------------------------------------------------
  -- table name : cvt_to_x01
  --
  -- parameters :
  --        in  :  std_ulogic  -- some logic value
  -- returns    :  x01         -- state value of logic value
  -- purpose    :  to convert state-strength to state only
  --                  
  -- example    : if (cvt_to_x01 (input_signal) = '1' ) then ...
  --
  ----------------------------------------------------------
  constant cvt_to_x01 : logic_x01_table := (
    'X',                                -- 'U'
    'X',                                -- 'X'
    '0',                                -- '0'
    '1',                                -- '1'
    'X',                                -- 'Z'
    'X',                                -- 'W'
    '0',                                -- 'L'
    '1',                                -- 'H'
    'X'                                 -- '-'
    );

This function actually convert the signal value to 'X' or '0' or '1'. And the function is true only when the converted new value is '1' and the converted last value was '0'.

Then the rising_edge function is true only for the following couples of [last_value;value] :

• [0;1]
• [L;1]
• [0;H]
• [L;H]

all other conditions won't be valid.

Synthesis:

[edited to remove false info]

As explained by @user1155120 in the prime post comments :

Lacking signal assignment neither process produce simulation events. Lacking an assignment target the first produces no level sensitive sequential logic (transparent latch) in synthesis. Lacking an assignment target the second produces no edge triggered sequential logic (register) in synthesis. Unlike grorel's Quartus prime other synthesis tools aren't guaranteed to produce a register for his output1. See IEEE Std 1076.6-2004 (withdrawn) 6.1.2.1 Rising (positive) edge clock., 6.2.1.1 Level-sensitive storage from process with sensitivity list (requires input signals in sensitivity list).

with output1 generated like this :

process(clk) is
begin
  if(clk = '1') then
      output1 <= input1;
  end if;
end process;

---

You must use an edge detection in your processes to make sure that registers are well created.

Answer 2

With the first, if clk changes from anything except '1' (eg 'H') to '1', "something" will get done, whereas with the second it won't. Adding an asynchronous reset illustrates this. You need:

process (clk, reset) is
begin
   if reset = '1' then
      --Reset something
   elsif rising_edge(clk) then
      --Do Something
   end if;
end process;

otherwise, "something" would get done when reset changed from '1' to '0', for example.

Answer 3

On a pure simulation semantics point of view, your first form is a real rising edge detector if and only if:

1. there is only clk in the sensitivity list (your case)
2. and the type of clk is bit

3. and clk is not declared with initial value '1' like in:

   signal clk: bit := '1';
   

If this holds, your -- do something will be executed only on rising edges of the clk. To understand why we need to look at the equivalent process with wait statement (yes, sensitivity lists are just a short hand for more general processes):

signal clk: bit;
...
process is
begin
  if(clk = '1') then
      --Do Something
  end if;
  wait on clk;
end process;

If clk is of type bit, the simulator initializes it with the leftmost value of enumerated type bit at the beginning of the simulation. As bit is declared:

type bit is ('0', '1');

its leftmost value is '0' and clk is initialized to '0'. On the first execution of the process the if test fails and the process suspends on the wait statement. From now on, it will resume only on value changes of clk. If the value change is a falling edge ('1' to '0') the if test fails and the process suspends on the wait statement. If the value change is a rising edge ('0' to '1') the if test passes, your -- do something is executed and the process suspends on the wait statement.

Because the conditions I listed above are quite constraining (especially the two first ones), and because many logic synthesizer don't really do semantics analyses but syntactic analyses (they "recognize" synchronous processes if they match certain coding patterns), your second form with rising_edge is preferable. It is standard since a long time, enough for being supported by all logic synthesizers I know.

A bit more explanation about the condition "there is only clk in the sensitivity list": as explained by Matthew, as soon as you have more than one signal in the sensitivity list (asynchronous set or reset, for example) you must use something else to express the condition. The event signal attribute is a possibility:

process(clk, reset)
begin
    if clk = '1' and clk'event then

This really says that an event just occurred on clk and that the new value of clk is '1'. While with:

process(clk, reset)
begin
    if clk = '1' then

the if test passes if an event happens on reset while clk is high. Usually not what you want.

Most synthesizers will do what you want with if clk = '1' and clk'event but it is not the whole story. If the type of clk is not bit but a multi-valued type like std_ulogic, for instance, the test passes for any transition of clk that ends with '1'. Like 'X' to '1' or 'U' to '1'. Usually not what you want, at least during simulations. This is where the rising_edge function becomes handy: it does the right thing. It uses the current value of its signal parameter s, plus s'event and s'last_value. It returns true only for transitions that you would consider as a true rising edge:

'0' -> '1'
'L' -> '1'
'0' -> 'H'
'L' -> 'H'

Your simulations work as expected and all logic synthesizers are happy with that because it is one of the patterns they recognize.

Answer 4

Since all of the other answers focused on a more formal, simulation-oriented side of the issue, I'll just add that synthesis-wise, most tools do not care much about sensitivity lists nowadays, but the rising_edge function is still essential in order to infer sequential logic (i.e.: flip-flops).