Hello, I was looking a few papers on the web:
and the paper
page 10 and 11
For some time I coded my state machine as described on page 11 until I came across these documents. I mentioned this to a co-worker and he said that page 10 is too confusing and page 11 is easier to read. He also said that with today's faster processors and better compilers you should not need to worry about the speed with one-hot encoding verses other implementations. I would like to ask the forum members for their comments one writing state machines.
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.
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.
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.)
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