0

I am reading the book Free Range VHDL and here is an example of chapter 8.

-- library declaration
library IEEE;
use IEEE.std_logic_1164.all;
-- entity
entity my_fsm1 is
    port (  TOG_EN  : in  std_logic;
            CLK,CLR : in  std_logic;
                 Z1 : out std_logic);
end my_fsm1;
-- architecture
architecture fsm1 of my_fsm1 is
   type state_type is (ST0,ST1);
   signal PS,NS : state_type;
begin
   sync_proc: process(CLK,NS,CLR)
   begin
     -- take care of the asynchronous input
     if (CLR = '1') then
        PS <= ST0;
     elsif (rising_edge(CLK)) then
        PS <= NS;
     end if;
   end process sync_proc;

   comb_proc: process(PS,TOG_EN)
   begin
      Z1 <= '0';        -- pre-assign output
      case PS is
         when ST0 =>    -- items regarding state ST0
            Z1 <= '0';  -- Moore output
            if (TOG_EN = '1') then NS <= ST1;
            else  NS <= ST0;
            end if;
         when ST1 =>    -- items regarding state ST1
            Z1 <= '1';  -- Moore output
            if (TOG_EN = '1') then NS <= ST0;
            else  NS <= ST1;
            end if;
         when others => -- the catch-all condition
            Z1 <= '0';  -- arbitrary; it should never
            NS <= ST0;  -- make it to these two statements
      end case;
   end process comb_proc;
end fsm1;

Is there any difference if I remove NS from the sensitivity list of sync_proc?

sync_proc: process(CLK,NS,CLR)
begin
-- take care of the asynchronous input
  if (CLR = '1') then
    PS <= ST0;
  elsif (rising_edge(CLK)) then
    PS <= NS;
  end if;
end process sync_proc;
stefanobaghino
  • 11,253
  • 4
  • 35
  • 63
HYRY
  • 94,853
  • 25
  • 187
  • 187
  • 3
    Possible duplicate of [When must a signal be inserted into the sensitivity list of a process](https://stackoverflow.com/questions/8991223/when-must-a-signal-be-inserted-into-the-sensitivity-list-of-a-process) –  Jan 29 '18 at 07:05
  • Definitely a duplicate – JHBonarius Jan 29 '18 at 08:17
  • 3
    NS doesn't need to be in the sensitivity list of the process. It's sampled by the rising edge of CLK which is in the sensitivity list. What ever it's current value is will be assigned to PS's projected output waveform. There are better books to teach yourself VHDL. –  Jan 29 '18 at 08:28
  • 2
    Side recommendation: Do not get in the habit of using "ns" and "ps" as signal names. In a testbench you will want these to mean time units ns and ps. If you have a local name signal name ns and/or ps, they will take precedence and your simulator will not give you very useful error messages. – Jim Lewis Jan 29 '18 at 16:36
  • If `PS` is "previous state", and `NS`is "next state", then what is the **current state**? ... What I'm getting at is: you should properly name your variables. And if you integrate the state machine in a single process, you don't need this next/current/previous state-thing. – JHBonarius Jan 30 '18 at 09:45

2 Answers2

1

After examining the question this is considered a duplicate of as well as it's answer lacking any authoritative reference as to when a signal belongs in the sensitivity list it may be worth asking where is that information derived from?

You could note Free Range VHDL only mentions wait as a reserved word in VHDL. There's much more to it than that. A process statement described in the VHDL standard (IEEE Std 1076-2008 10.3 Process statement) tells us:

If a process sensitivity list appears following the reserved word process, then the process statement is assumed to contain an implicit wait statement as the last statement of the process statement part; this implicit wait statement is of the form

wait on sensitivity_list ;

And then goes on to dicuss how the rules of 10.2 Wait statement are applied to a sensitivity list consisting of the reserved word all.

The syn_proc from architecture fsm1 of entity my_fsm1 from Free Range VHDL Listing 7.1 Solution to Example 18 has a sensitivity list in accordance with the rules found in 10.2 Wait statement for an implicitly generated sensitivity.

However, that's not the complete set of authorities. There's also IEEE Std 1076.6-2004 (RTL Synthesis, now withdrawn) 6.1.3.1 Edge-sensitive storage from a process with sensitivity list and one clock:

d) The process sensitivity list includes the clock and any signal controlling an <async_assignment>.

Where <async_assignment> is defined in 6.13 Modeling edge-sensitive storage elements:

<async_assignment>. An assignment to a signal or variable that is not controlled by <clock_edge> in any execution path.

And <clock_edge>is defined by convention (1.4) as one of the forms for clock_edge defined in BNF found in 6.1.2 Clock edge specification.

(translation: d) above means what you think it means when you read it.)

This tells us what signals are necessary here. There are no restrictions on unnecessary signals in the process sensitivity list. However their effect can be discerned from IEEE Std 1076-2008 10.2 Wait statement:

The suspended process also resumes as a result of an event occurring on any signal in the sensitivity set of the wait statement. If such an event occurs, the condition in the condition clause is evaluated. If the value of the condition is FALSE, the process suspends again. Such repeated suspension does not involve the recalculation of the timeout interval.

For a wait statement:

wait_statement ::=
    [ label : ] wait [ sensitivity_clause ] [ condition_clause ] [ timeout_clause ] ;

it helps if you know the condition clause is optional as indicated by the square brackets above:

The condition clause specifies a condition that shall be met for the process to continue execution. If no condition clause appears, the condition clause until TRUE is assumed.

That means the process will resume for any event on any of the signals in the process sensitivity list and will traverse it's sequential statements.

There is no harm to the state of the design hierarchy during simulation by executing the sync_proc for an event on signal NS. Neither assignment statement in the if statement subject to conditions will execute. You could also note the same holds true for an event on the falling edge of CLK.

The objective in paring the sensitivity list is to minimize the number of times the process is resumed needlessly. The bigger more complex the design model the slower simulation will proceed, particularly dragging around needless resumptions and suspensions.

Of the three signals shown in the process sensitivity list only three binary value transitions are of interest, and none on signal NS. The current value of NS is assigned to PS on the rising edge of CLK.

A process suspends and resumes in a particular wait statement. A process with a sensitivity list shall not contain an explicit wait statement (10.3), meaning it will have only one wait statement, the implicit one.

It would seem with your first question on VHDL here you've reached beyond the limits of answers the book Free Range VHDL can supply.

A better entreaty on the subject might be The Designer's Guide to VHDL, 3rd edition by Peter Ashenden.

The idea being conveyed here that you can't get why without knowing how.

0

We always use process block with clock and reset in sensitivity list to describe sequence circuit.And use process block with every driver signals in sensitivity list to describe combinational circuit.

Sometimes sensitivity list is only important for simulations but if you forget a signal or add too many signals in sensitivity list you may get the wrong simulation result. Most time the real FPGA function will work fine if your logic is correct.

But it can cause some problem.

For example, if you describe a function like a=b&c in an always block with sensitivity (b); But you forget c. Then in your simulation a will not change when c is changed. But the circuit in real FPGA, will be the correct description of the function a=b&c. And you may get a warning when you synthesize your code.

You can call it ‘pre-sim and post-sim inconsistent’.

The real scary thing is that your pre-sim is right but your post-sim is wrong. That may cause the FPGA to incorrect function.

So I advise you to describe the circuit than the function when you write VHDL code.

Liang He
  • 133
  • 1
  • 1
  • 9