Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Register Log in

process sensitivity list problem in FSM (VHDL)

Status
Not open for further replies.
E

EceWoman

Newbie level 3
Joined
Jul 26, 2017
Messages
3
Helped
0
Reputation
0
Reaction score
0
Trophy points
1
Activity points
59
Hello! I'm new in VHDL programming and I have a problem understanding sensitivity list. So, I was trying to solve an exercise (9.14 from Frank Vahid's book) and tried to implement the FSM in the picture. I wrote the following that didn't work - I won't copy the whole code but the specific part:

Oj4jKoQ.png

(1st wrong solution with 1 process)

Code VHDL - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

process(clk)
    begin
        if(clk='1' and clk'event) then
            if(reset='1') then
                state <= liOFF ;
            else
                state <= nextState;   
            end if;
        end if;
    
    end process;
 
    -- combinational logic
    process(state)
    begin
        
        case state is 
            when liOFF =>
                l <='0';
                if (call = '1') then
                    nextState <= liON;
                else
                    nextState <= liOFF;
                end if;


then, after searching at book I found these two solutions that actually work :

(2nd solution with 2 processes)

Code VHDL - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

process(clk)
    begin
        if(clk='1' and clk'event) then
            if(reset='1') then
                state <= liOFF ;
            else
                state <= nextState;   -- gia 0 ns ?
            end if;
        end if;
    
    end process;
    
    
    -- combinational logic
    process(state,call,cncl) -- state and 2 input signals in sensitivity list
    begin
        
        case state is 
            when liOFF =>
                l <='0';
                if (call = '1') then
                    nextState <= liON;
                else
                    nextState <= liOFF;
                end if;


and

(3rd solution with only 1 process)
Code VHDL - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

process(clk) -- one process with only clk in the sensitivity list
    begin
        if(clk='1' and clk'event) then
            if(reset='1') then
                state <= liOFF ;
            else
                state <= nextState;   -- gia 0 ns ?
            end if;
        end if;
    
    -- combinational logic
    case state is 
            when liOFF =>
                l <='0';
                if (call = '1') then
                    nextState <= liON;
                else
                    nextState <= liOFF;
                end if; 
 
end process;


I would be glad if you could answer my questions :

1 - why my suggested solution didn't work ? if I use 2 processes do I have to include all signals in the second sensitivity list? ( "process(all)")

2 - if I insert all input signals in the sensitivity list is there any possibility for failure ? for example , if state signal remains stable, but call signal (input) changes in the second process?

3 - in the case of using 2 processes, the hold/setup times for example of the state signal doesn't affect us ?

Thank you for your time!
 
Last edited:

From a hardware viewpoint, process(all) is the way to make the simulation behave like real hardware, avoiding any sensitivity related simulation mismatches. The sole purpose of sensitivity lists is to fasten the simulation process, at the risk of ignoring events in case of an incorrect list.

The issue with the 3rd solution is that it uses clk'event as trigger for the combinational logic block simulation, causing an additional delay compared to hardware behaviour, in other words it involves a simulation mismatch.
 
well, I tried the second solution but it works only for synchronously changeable input signals. I had to add a " if (state'event) then.... end if; " in the process " process(state,call,cncl)" . Do you find this correct ?

Looking at most of the tutorials, people use the second solution but I faced the above problem. We assume in advance that as soon as we are talking about a synchronous circuit, inputs are always changed synchronously ?
 
Last edited:

no, there is no need for state'event, as this will be what triggers the process. It will work for async input, as long as all signals that the process depends on are in the sensitivity list, ot you use (all)
You havent posted a complete code example as all of the examples have incomplete case statements, which is illegal.
 

It's better to use 2 different processes -

1. For defining the state register including clk,reset and nextstate in the sensitivity list.

2. For defining the state machine (combinational part) including state and other signals used in the conditional statements for defining the nextstate.

This will ensure proper simulation and synthesis of your logic.
 

mjuneja said:
It's better to use 2 different processes -

1. For defining the state register including clk,reset and nextstate in the sensitivity list.

2. For defining the state machine (combinational part) including state and other signals used in the conditional statements for defining the nextstate.

This will ensure proper simulation and synthesis of your logic.
Click to expand...

This discussion is a matter of opinion.
using two states hang around because old synth tools required a separation of logic and registers. This style stuck around in tutorials, text books and now many people learn it as "the best" way to do it.
Actually, now, most would recommend a single clocked process style as it removes the possibility of latches, and all logic will be synchronous.
 
  • Like
Reactions: CataM

    C

    CataM

    Points: 2
    Helpful Answer Positive Rating
An engineer should be familiar with both styles. Record types can be used with the two-process style to reduce the verbosity. Variables and procedures can be used in the one-process style to make output logic easier to write (and possibly less verbose).

Two-process makes the most sense when a combinatorial output needs next_state.
 
Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top