Efficient State Machine Design

The state machine code on page 11 of the document you posted is a good example of a one-hot encoded state machine.

To address another point made - yes, Quartus can be made to encode state machines as it sees fit or in a particular manner. However, it'll only do this if it can recognise specific bits of code you intend to be a state machine (Sree your request for a template is very sensible in this respect). Alternatively, you could use Quartus' built in state machine wizard to make it clear - not a route I'd consider.

Any FPGA design (that used Flip-flops) could be considered a state machine. I certainly don't want Quartus to determine what the best method of encoding my design. I (probably) want my N-bit counter remaining just that and not be turned into 2^N D-types. The same functionality could be realised. A counter is, after all, a state machine.

The point I'm making is that it is far better to understand what you want from your design, how you want it to be implemented and write the code appropriately. (Sree, I appreciate that seems to be what you're trying to do here.)

Cheers,

Alex

How confusing pages 10 & 11 are is somewhat subjective. Both appear pretty clear to me - if (perhaps) formatted a little strangely for the purposes of publication.

Not worrying about one-hot encoding.... hmm

Yes, FPGA processes are faster allowing faster clock speeds. However, that simply pushes what is achievable. To say that you need not worry about one-hot encoding is entirely dependant on what you're trying to achieve. One-hot encoding is a technique that will remain in my tool box.

Cheers,

Alex

I think you will find that by default the Quartus tools will analyze your state machine, discard the current encoding (one-hot, binary, gray, etc), and then re-encode the state machine during the implementation phase, which for most state machines will end up being one-hot encoded. This is usually the most space and time efficient encoding given FPGA cell architecture. So what you write in your HDL (encoding-wise) really does not matter.

For reference, I would recommend the O.P. read the Quartus Tools Handbook for the version they are using, specifically Volume 1: Design and Synthesis, Chapter 16, Synthesis Options, State Machine Processing. For v16.0.0 (which I am using) this is on page 16-30, but will depend slightly on the specific tool version, I suspect. It describes how the default state machine (re)encoding for FPGAs is "one-hot", but other options are "sequential", "gray", "johnson", "compact", and "user". You can add an attribute (syn_encoding) to the state register definition to specify the specific state machine encoding desired. Or set the syn_encoding default to be, instead of "auto", to be "user" to force quartus to leave your state machine designs as is.

Here's my version of it.

//
// State Register and Outputs Register
//
always @(posedge clock) begin  // Sequential logic.
	state <= next_state;      // State Register
	outputs <= next_outputs;  // Outputs Register
end

Also needs a couple of more always blocks for the Next State Logic and Next Outputs Logic using combinational logic, e.g.:

//
// Next State Logic
//
always @* begin  // Combinational logic.
	if (reset) begin
		next_state <= STATE_RESET;
	end
	else begin
		case (state)
		.
		.
		.
		endcase
	end
end

//
// Next Outputs Logic
//
always @* begin  // Combinational logic.
 
	// Using a look-up table.
	if (reset) begin
		// Look ahead to the reset state for the next outputs.
		next_outputs <= outputs_table[STATE_RESET];
	end
	else begin
		// Look ahead to the next state for the next outputs.
		next_outputs <= outputs_table[next_state];
	end
 
	// Or alternatively without a look-up table.
	//case (next_state)
	//.
	//.
	//.
	//endcase
end