# Long enumeration in VHDL to recognize a state machine

In order that Quartus II recognizes a state machine in a case / when statement the case must be applied on an enumerated type. In my code I am using a case on integer number going from 0 to 230. And there are a lot of ranges like "when 34 to 50 =>" for instance. What is the best and shortest way to enumerate in this case based on an integer? In order to let quartus recognize the state machine which helps me to analyse my implementation.

• Your reference to Quartus 13.0 may not be of paramount interest. Recognizing a state machine may have mapping hierarchy and reporting implications that can be dealt with for other descriptions (a counter counters are state machines they manage to synthesize just fine). An enumerated type has ordered named values representing position (names for scalar numerical values). You can use ranges of enumeration values and relational operators.The big effort for an enumerated type would be it's declaration (insert ST IV joke about opening all the little cans of anchovies here). – user8352 Oct 26 '20 at 4:58

Unclear what you are trying to achieve.

First, it seems like an odd restriction for Quartus to restrict state types to enumerations instead of other discrete types like integer or unsigned. But...

Do you really have 231 discrete states?

Or is range 34 to 50 a single state?

If you need to remain in that state for 17 separate events, consider a state and a separate counter. You could implement that as a pattern similar to a state machine with multiple delays.

If you need to translate a numeric input to a state, write a to_state(int) function returning your enumeration type.

If there is similarity between groups of states, you might look at a hierarchical state machine or even decompose the state machine into one central SM controlling several others via handshaking.

EDIT from the relevant manual section aaah...

"VHDL state machines that do not meet these conditions are converted into logic gates and registers that are not listed as state machines in the Report window."

So you can use another discrete type like a ranged Natural, and it'll synthesise, probably to the same logic, you just don't get the nice report. I'd be tempted do that (write it in the most natural style) just to use the (speed/size) results as a benchmark to compare with the "Altera approved" style.

Project or company coding style rules may prohibit that, or require the pretty report artefact for verification, so I'm not pushing this as a solution, just as a way to calibrate the "official" solution ... possibly as a golden model for simulation (verify both SMs remain in step).

• Thank you for the answer. But yes as in intel.com/content/www/us/en/programmable/quartushelp/13.0/… it is clearly noted that "The type of the signal or variable that represents the state machine must be an enumerated type." – Project2016 Oct 25 '20 at 18:32
• Some quick testing seems to indicate there may be some differences in resource usage at least part of the time. I took the design on the linked page, and converted it to use an std_logic_vector instead of an enumeration. That changed it from using 2 LUTS and 3 "dedicated logic registers" to using 4 LUTs and 2 dedicated logic registers. So at least what shows up in the report looks different (but I don't know enough about their dedicated logic registers to be sure how much real difference that makes). – Jerry Coffin Oct 26 '20 at 3:22
• On the other hand with (ancient) Xilinx ISE, it's recognized as a state machine either way, and uses identical resources either way. – Jerry Coffin Oct 26 '20 at 3:45
• @jerryCoffin interesting test. But concerning being Xilinx ISE or Quartus II maybe it is true for this case but not true in general. What I mean is that the used resources may depend on how the VHDL code is written. Maybe it shouldn't be like that but the design suites inferences are not completely independant of how the code is written (without considering directives which is another thing). Am I wrong? – Project2016 Oct 26 '20 at 9:25