I think if coded correctly, the reverse case statement FSM coding style should automatically create a case statement that is parallel, without requiring the ‘parallel_case’ directive. Since each state is represented by a unique number, each case expression is effectively comparing 1 unique register bit against 1’b1. Therefore no overlap between the different case expressions should be possible, which matches the definition of parallel case.

Put in another way, the question is what really happens when one codes a reverse case statement in Verilog with no ‘parallel_case’ directive. Does synthesis assume that the input to the case-statement is not parallel and hence not one-hot and hence infer priority logic? I’d love to hear your thoughts.

I have not had a chance to look closely at the synthesized netlist of a one-hot encoded state machine written with enumerated type and regular case statement. I believe with today’s compiler technology it should synthesize the same as the reverse case statement method (i.e. optimized to do single state bit comparisons). I coded my most recent design this way based on this belief. I’ll let you know when I can verify exactly the gates that Design Compiler synthesized 🙂

Thanks for your comments! Yes I had been intending to make an update to this page for while, especially about your first point on waveform display of the state vector. After simulating my coworker’s code in the original coding style, I also realized simulators do not visualize state vectors written this way very well. I would agree that specifying the one-hot state encoding in the enum type should be equivalent and will display better. Your proposed code is indeed how I would write a one-hot state machine using SystemVerilog today!

typedef enum logic [3:0] {
IDLE = 4’b0001,
READ = 4’b0010,
DLY = 4’b0100,
DONE = 4’b1000,
SX = 4’x
} state_t;
state_t state, next;

// Sequential state transition
always_ff @(posedge clk or negedge rst_n)
if (!rst_n)
state <= IDLE;
else
state <= next;

// Combinational next state logic
always_comb begin
next = SX;
unique case (state)
IDLE : begin
if (go)
next = READ;
else
next = IDLE;
end
READ : next = DLY;
DLY : begin
if (!ws)
next = DONE;
else
next = READ;
end
DONE : next = IDLE;
endcase
end

// Make output assignments
always_ff @(posedge clk or negedge rst_n)
…

Hi VK, thanks for your comment! When you say the code “kills x-prop”, I think you mean that if “ws” or “go” input has the value of X, then the “if(x)-else” coding style will take on the “else” case, rather than also corrupting the outputs (in this case the “next” vector)? Yes you’re right, and I’ll admit I’ve coded this kind of bug before! Recently our team has turned on the Synopsys VCS x-propagation feature to detect this kind of problem. It corrupts the output even with this “if-else” coding style (see my post on x-prop). If that’s not available, then yes, the code you propose will also do the job. Previously I also coded a “default: next <= 'x" in my state machines, but the RTL linting tool we use complains about this, so I've moved away from this style. VCS x-prop will also catch this kind of problem.

// Combinational next state logic
always_comb begin
//next = ‘0; // Comment out; see added default in case statement instead
unique case (1’b1)
state[IDLE] : begin
// Ensures x-prop if go === x
next[READ] = go == 1’b1;
next[IDLE] = go == 1’b0;
end
state[READ] : next[ DLY] = 1’b1;
state[ DLY] : begin
// Ensures x-prop if ws === x
next[DONE] = ws == 1’b0;
next[READ] = ws == 1’b1;
end
state[DONE] : next[IDLE] = 1’b1;
// Add default to propagate Xs for unhandled states or if state reg went X itself
default: next <= 'x;
endcase
end