I used to work in the old days of digital design and was familiar with Moore and Mealy style of state machine methodology. It was an attractive University topic and also  controversial issue even then. As I moved to FPGA platforms I went to code my state machine away from that categorisation and only use one process.

In the last few years I gave up the state machine methodology altogether. I just use a counter with a commented name instead of declaring type with various names. It works no problem because if a counter doesn't work we won't be here...

The only drawback of a counter is that it lacks meaningful naming per state but a commented name per each value is no problem for me.

I don't see why I should use state machine unless it is really huge number of states.

Any comments from this forum welcome.

Kaz

Hi Kaz,

From what you have described above and in your reply to Chris below I would suggest that you re visit the use of state machines if you are using them for complex operations. I make this suggestion based on the following point. 

That being the use of state machines makes your code much more supportable in future. If you need to make changes in future you can follow the function using the sensibly and descriptively named states. 

It also as Chris points out makes it easier to review, I am pretty sure if I was presented with your code for review I would recommend you implement it in line with the industry standards, do you have to follow any coding standards?

Looking at the answer below it currently sounds like the approach you undertake is actually implementing a state machine using count values for state names if you use the current count to determine the next count. 

"I meant counter in any order and not just incrementing, so each count value decides next count value, (not exactly counter but just a set of registers)"

Although with most state machines I design these days they are hybrid having moore and mealey outputs as required for the complexity of the state machine. 

Hope this helps 

Adam 

I don't think (or design) in terms of Mealy and Moore, I just use one process.  I create an enumerated type called `t_state` and a state variable called `state` (almost always the same names - they're local to the process, so why not?)

I would suggest that whenever you write comments for your counter, there's a way to write the comments in the code.. by using an enumerated type for your state variable.  This also appears in the simulation waveforms, so you don't have to keep looking up what is supposed to be happening in state 3...

I would suggest a shift/rotate register initialized to 1000...0 (a bit per state) and check only a single bit per state.

Other state machines and counter approaches may require large comparators depending on the number of states.

However, I agree that the counter approach is quite simple and highly manageable.

I don't think it is useful to try and design a Mealy or Moore (more is less) state-machine.  In some limited cases it can be useful for analysis (reviewing the circuit of the synthesized state-machine), otherwise not useful to categorize.

In my opinion, coding state-machines make the HDL readable, it seems it would be painful to have to review (debug) someones code that simply used a counter or shift register for a complex state-machine.

In your description, a counter (or shift reg) assumes a contiguous path (?): 

    0 -> 1 -> 2 -> 3 -> 0 

and not a more complicated transition through the states (?):

        /-> 1 -> 2 -> 3 -> 0    
    0 -        
        \-> 3 -> 0

I guess if the design has no complex state-machines, sure counters and shift-regs may suffice (after 2 clock tick do QRS and 3 do XYZ).  I use counters all over the place and in places where a state-machine could be used.  But my designs also have numerous state-machines for more complex situations.

I always say: 'A State Machine is worth a Thousand Equations'.

Now I may add: 'and a Dozen of Counters' :)

I meant counter in any order and not just incrementing, so each count value decides next count value, (not exactly counter but just a set of registers)

Kaz

So your 'counter' is just another 'state machine in disguise'?

It would be interesting to see some source code of yours!

indeed. But it avoids talking about state type declaration(present and next if you prefer), state encoding and the hot topic of how many processes needed etc. To me it is all really obsolete but maintained by tools may be for marketing reasons. After all a counter is a state machine and can be declared as any set of registers. You don't need to see my code as we all have hundreds of examples:

if count = "00" ....count <= "11"...else count <= "10" ....

Pretty obvious

Kaz

I imagine many things in life that can be avoided with obfuscation. 

Just being pedantic, but a counter that counts in an arbitrary sequence is not a counter. If it looks like a duck, swims like a duck, and quacks like a duck, ... it must be a state machine :)

So you are giving up the nice symbolic names (I agree it is sometimes difficult making up good names for the states) for magic numbers?

You claim that you make one-process-only counters/state-machines. I bet you often have to add a second process to make some combinatorial outputs, don't you? And you probably have yet another clocked process to register signals that don't need a reset?

Josy

The name thing shouldn't be too hard really - just don't be too pedantic about it. I might have states with names like:

INIT, READ, WAIT_FOR_SIGNAL but if read wants to be broken up into two I'm not bothered by READ_0 and READ_1, especially of the alternative might be very long winded. Since the process will have a name and the module will have a name the state names don't need to be incredibly complex.

I find that names are well worth the small effort in making them up and declaring  a special type, for the huge gains in readability and reduction of mistakes.

I use single process state machines all the time, and very rarely need to add other processes.

MK