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. Advertisements

  2. Nigel Noldsworth

    jeppe

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

  3. Nigel Noldsworth

    Dave Pollum Guest

    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. 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:)
    Yes it seems so.
    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.
    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. Me too. They seem to be suffering a clue shortfall.
    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.
    You said it.
    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.
    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, 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. Advertisements

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.