sensitivity list of a process

[Nigel Noldsworth]

Hello there,

I have the following process for the combinatory logic of a state
machine. However during simulation it seems to me that when
rising_edge of the clock, the process is not triggered with "state"
signal assuming that sda (not on the sensitivity list) = 1. Hence the
state machine stays into idle mode. I was guessing that rising_edge of
the clock, that same value is being assigned to "state" signal and
this assignment will wake up the process. It seems I'm wrong. Can you
please shade some light please ?

receive : process (state, count) is
variable i : natural;
begin -- process receive
case state is

when IDLE =>
count <= 0;
storage <= (others => '0');
val <= '0';
--
if sda = '1' then
nxt_state <= CAPTURE;
else
nxt_state <= IDLE;
end if;

when CAPTURE =>
........
sync_receive : process (clock, reset)
begin
if reset = '0' then
state <= IDLE;
output <= (others => '0');
elsif clock'event and clock = '1' then
if enable = '1' then
state <= nxt_state;
output <= storage;
end if;
end if;
end process sync_receive;

 

[jeppe]

You should put sda in the sensivity list - should solve the problem

 

[Dave Pollum]

Hello there,

I have the following process for the combinatory logic of a state
machine. However during simulation it seems to me that when
rising_edge of the clock, the process is not triggered with "state"
signal assuming that sda (not on the sensitivity list) = 1. Hence the
state machine stays into idle mode. I was guessing that rising_edge of
the clock, that same value is being assigned to "state" signal and
this assignment will wake up the process. It seems I'm wrong. Can you
please shade some light please ?

        receive : process (state, count) is
                variable i : natural;
        begin  -- process  receive
                case state is

                        when IDLE =>
                                count   <= 0;
                                storage <= (others => '0');
                                val             <= '0';
                                --
                                if sda = '1' then
                                        nxt_state <= CAPTURE;
                                else
                                        nxt_state <= IDLE;
                                end if;

                        when CAPTURE =>
.......
        sync_receive : process (clock, reset)
        begin
                if reset = '0' then
                        state  <= IDLE;
                        output <= (others => '0');
                elsif clock'event and clock = '1' then
                        if enable = '1' then
                                state  <= nxt_state;
                                output <= storage;
                        end if;
                end if;
        end process sync_receive;

You need to add sda to the receive process's sensitivity list,
otherwise the simulator will not "run" the receive process when sda
changes.
-Dave Pollum

 

[Nigel Noldsworth]

Here's the smoking gun.  Your process reads (looks at the
value of) SDA.  Consequently, if you are trying to imply
combinational logic (which plainly is the case), it is
essential that you include SDA in the sensitivity list.

Actually the code has been written by a subcontracting company, which
the quality of code left me in an uneasy situation. We have a bug in
the system, hence I'm trying to debug it. That said, due to lack of
time, I won't be able to rewrite that code for him into a one-process,
but it would be great for me to learn those key leakage as well

please ensure that your combinational processes exhibit
all three of the truly essential features:
- complete sensitivity list
- complete assignment to all outputs
= no combinational feedback

I strongly suspect that your design may also
fall foul of the last of these.

Yes it seems so.

 What on earth
is "count" doing in its sensitivity list?  

The subcontractor placed a 3-bit adder into another case statement to
convert a serial SDA to a 8-bit shift register.
----------------
storage(WIDTH-1 downto 1) <= output(WIDTH-2 downto 0);
storage(0) <= sda;
val <= '0';
if count = WIDTH -1 then
count <= 0;
nxt_state <= PARITY;
else
count <= count +1;
nxt_state <= CAPTURE;
end if;
---------------------

The above code fragment in one of the case statement of the state
machie creates a 3 bit adder. Which is the reason why "count" is in
the sensitivity list. However this is not a proper way to code and
another reason to terminate the contract with this subcontractor.

That said in the case of a two-process state machine, for the output
of this 3 bit adder to be registered at rising_edge of the clock, I
will have to create a new process specially for adder. In the end this
adder implies 3 more DFFs. Which comes to another question. Is it
possible to add an adder in one of the case statement of the 2process
state machine which counts only when rising edge of the clock (in such
a way that the synthesis tool doesn't infer 3 DFFs? I'm interested
from a "design area" point of view.

What,precisely, are you doing with "i"?

This is used in the code below but in only one case statement.

for i in storage'range loop
val <= storage(i) xor sda;
end loop;

 

[Jonathan Bromley]

Actually the code has been written by a subcontracting company, which
the quality of code left me in an uneasy situation.

Me too. They seem to be suffering a clue shortfall.

The subcontractor placed a 3-bit adder into another case statement to
convert a serial SDA to a 8-bit shift register.
----------------
   storage(WIDTH-1 downto 1) <= output(WIDTH-2 downto 0);
   storage(0) <= sda;
   val        <= '0';
   if count = WIDTH -1 then
       count            <= 0;
       nxt_state <= PARITY;
   else
       count            <= count +1;
       nxt_state <= CAPTURE;
   end if;

AAAARGH. This is just WRONG. If you write
count <= count + 1;
in a combinational process, you are describing an
incrementer with its output directly connected to
its input. That doesn't sound very sensible to me.

The above code fragment in one of the case statement of the state
machie creates a 3 bit adder. Which is the reason why "count" is in
the sensitivity list. However this is not a proper way to code and
another reason to terminate the contract with this subcontractor.

You said it.

That said in the case of a two-process state machine, for the output
of this 3 bit adder to be registered at rising_edge of the clock, I
will have to create a new process specially for adder. In the end this
adder implies 3 more DFFs. Which comes to another question. Is it
possible to add an adder in one of the case statement of the 2process
state machine which counts only when rising edge of the clock (in such
a way that the synthesis tool doesn't infer 3 DFFs? I'm interested
from a "design area" point of view.

It's easy; far, far easier if you use a one-process FSM, but easy
anyhow. Just imagine that the counter is part of the state, and
needs handling just like the state. So your combinational process
creates a "next_count" output just in the same way that it creates
a "next_state" output; and you then register it in the clocked
process.

This is used in the code below but in only one case statement.
for i in storage'range loop
   val <= storage(i) xor sda;
end loop;

More evidence of your contractor's incompetence. For-loop
counter variables in VHDL don't need to be declared. In
this particular case it's probably harmless because the
declared variable is simply not used at all, but it is
culpably silly to provide it at all.

I'm really sorry, I assumed the code was from a clueless
student. I don't think I have ever before seen anything
so crass from a paid contractor. Sack 'em before they
cost you your reputation.

 

[Andy]

There's no need for a torrent, Jonathan's explanation will suffice.

But just to make sure Jonathan cannot be called a liar, and two posts
is the minimum qualifiable torrent, here it is:

Use single process descriptions of sequential logic, and problems just
like the OP has experienced will not happen.

The advantages of a single process description include:

No missing signals in sensitivity lists that cause simulation/
synthesis mismatches

No latches

Easier integration of clock enabled register with behavior

Half the signal declarations

Allows use of variables for code that behaves like it reads (no
suspended signal updates)

Andy