FSM: next state precedence

Question

When being in a state "a1" how can I show that the next arrows will have a precedence over each other, without having an overhead of extra states?

Full example:

• We are at a1 state and signals x && y are asserted: we go to state b1
• If that condition is not asserted but x && z is asserted then we go to state b2
• If the above conditions are not asserted but x is asserted then we go to state b3

Visual concept:

In the above "FSM" we can't see that x && y is checked before the other two.

Code snippet:

always_comb begin
  case (states)
    a1: begin
      if (x && y)
        next_state = b1;
      else if (x && z)
        next_state = b2;
      else if (x)
        next_state = b3;
      else
        next_state = a1;
    end
  endcase
end

Answer 1

Ideally, you'd need to cover all the possible combinations of input events in each state to get a proper DFA (deterministic FSM).

However, you can get away by fully specifying the triggers in terms of input signals, and let your HDL default to "no transition". In that case:

• transition from a1 to b1 may be triggered by x && y && !z
• transition from a1 to b2 may be triggered by x && !y && z
• transition from a1 to b3 may be triggered by x && !y && !z

(with ! denoting logical 'not').

With an alphabet of 3 symbols (your three input signals), you get 2^3 = 8 possible combinations in every state. Ask yourself: in your current design, what happens if all of x, y and z get asserted ? You need to be specific about that.

EDIT

Let me be more specific.

Let's consider A, B, C, ... H as events, each representing one possible combination of input signals, such as:

  x y z
A 0 0 0
B 0 0 1
C 0 1 0
D 0 1 1
E 1 0 0
F 1 0 1
G 1 1 0
H 1 1 1

Then try to express your transitions in terms of A, B, C, ... H. If you can, the resulting FSM is suitable to your task. If you can't, you should probably rethink your logic.

Answer 2

Since you tagged the question with SystemVerilog, I just wanted to mention an alternative way of describing your next state logic:

always_comb begin
  case (states)
    a1: 
        priority casez ({x,y,z})
         3'b11?:  next_state = b1; // x && y
         3'b1?1:  next_state = b2; // x && z
         3'b1??:  next_state = b3; // x
         default: next_state = a1; 
        endcase
  endcase
end

Also, the commonly used state diagram does not specify priority, so you need to completely specify the transition conditions as in xbug's answer. But I don't see why you can't extend this notation, for example, mark each arc with labels 1, 2, 3, and 4, where lower numbers indicate higher priority.