sensitivity list of a process

Discussion in 'VHDL' started by Nigel Noldsworth, Dec 14, 2009.

  1. 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;
     
    Nigel Noldsworth, Dec 14, 2009
    #1
    1. Advertising

  2. Nigel Noldsworth

    jeppe

    Joined:
    Mar 10, 2008
    Messages:
    348
    Location:
    Denmark
    You should put sda in the sensivity list - should solve the problem
     
    jeppe, Dec 14, 2009
    #2
    1. Advertising

  3. Nigel Noldsworth

    Dave Pollum Guest

    On Dec 14, 2:09 pm, Nigel Noldsworth <>
    wrote:
    > 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
     
    Dave Pollum, Dec 14, 2009
    #3
  4. On Dec 14, 10:36 pm, Jonathan Bromley wrote:
    > 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;
     
    Nigel Noldsworth, Dec 15, 2009
    #4
  5. On Dec 15, 1:26 pm, Nigel Noldsworth <>
    wrote:
    > On Dec 14, 10:36 pm, Jonathan Bromley wrote:
    >
    > > 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.


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

    > > 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;


    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.

    > > 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;


    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.
    --
    Jonathan Bromley
     
    Jonathan Bromley, Dec 15, 2009
    #5
  6. Nigel Noldsworth

    Andy Guest

    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
     
    Andy, Dec 15, 2009
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. walala
    Replies:
    3
    Views:
    752
    Allan Herriman
    Sep 9, 2003
  2. Roger Dahl
    Replies:
    10
    Views:
    815
    Mike Treseler
    Oct 3, 2003
  3. antonio bergnoli
    Replies:
    5
    Views:
    4,477
    Mike Treseler
    Dec 18, 2005
  4. Steven Kauffmann
    Replies:
    21
    Views:
    2,666
    Ponceludon de Malavoy
    Jan 9, 2008
  5. neilmac
    Replies:
    2
    Views:
    650
    mcdjnaja
    Feb 7, 2008
Loading...

Share This Page