Why cant I add a 5th state to my state machine?

[Kalle]

The attached program works fine, but if I change to this:

type state_type is( STATE1, STATE2, STATE3, STATE4, STATE5);

That is, add a 5th state, it wont work anymore. No leds comes on and it doesn't respond to any button presses.
Weather or not I actuelly use the 5th state doesn't change anything, it still wont work.

When I compile the program it compiles fine. No errors but I do get a couple of warnings:

Pruning register bit 0 of Next_State(0 to 4).
Pruning register bit 0 of Present_State(0 to 4).

This is of course to be expected.

I use Lattice ICECube2 and Diamond programmer. And the fpga is ICE40UP5K-SG48ITR.
The board is something I designed myself. Nothing remarkable, just an experimental board with a few leds and buttons, switches and so on.

Any idea or suggestion would be much appreciated.

[ejeffrey]

Try it in a simulator?

[lintweaker]

Neither Present_State nor Next_State is initialized in any way. An initial value would be good.

[Valueduser]

Two things are jumping right out at me, first you have no resets in the system and second is the "when others => null;" statement.  If you should ever make it to the "when others" statement your FSM will effectively be disabled.  You should simulate this, my guess is Present_state is going to come up as undefined.

[ejeffrey]

Yes, it's almost certainly the failure to initialize/reset Present_State.  When you only had a 2-bit register, all 4 possible startup states had a valid next state, so regardless of how it powered up it would still operate.  It still won't work in a simulator which will just show XX.  However, once you add a 3rd state bit, there are undefined states which don't go anywhere.  Probably if you defined all 8 possible 3-bit states, it would "work" again.

[MDS.CEng]

A simulation of your code runs OK having added IEEE libraries so no help in solving this problem.
Expect State variables are in the wrong state (invalid value). To make safe change

Code: [Select]

when others => null;to

Code: [Select]

when others => Next_state <= STATE1;which will make the state machine safe as any unknown state values will be corrected.
The FSM overall design is not normal. The FSM Stepping process would normally be not clocked. See
https://vhdlwhiz.com/n-process-state-machine/
for types of FSM.
Generally give everything a start-up value such as

Code: [Select]

LED_1 : out STD_LOGIC  := '0' ;

Code: [Select]

signal Present_State : state_type  := STATE1 ;if you are not going to have a reset, as some FPGA will set registers to a requested output state during power up (expect ICE40 do but have not used that type of FPGA). Otherwise your code will have to be "bad value safe" where any unwanted value is set to a valid one.

Hope this helps
Mark

[pgo]

This is a comment on the last post rather than a reply to the OP.

Code: [Select]

LED_1 : out STD_LOGIC  := '0' ;

It is not a good idea to routinely initialize standard_logic (SL)  signals in VHDL.
SLs have a 'U' state to allow you to recognize in simulation that you have a signal that is not being controlled.  If you routinely initialize your signals to '0' you defeat this.

In any case what does this mean?  If you are talking about a non-registered signal then you are basically saying that you want a piece of wire to have an initial value when you turn on your circuit!!!  There is no physical meaning to this.  If control of the 'wire' is needed at startup the your circuit logic (i.e. the rest of your VHDL) should be doing this.

It is possible to use initial values with signals that are registered (clocked) but I prefer not to do this.  Not all synthesis tools respect this and it may lead to problems with synthesis if the physical implementation of the FFs doesn't support the appropriate mechanism.  For example, some device only support initialization to '0' so an '1' value lead to problems or at least extra circuitry for no reason.  Some storage elements don't support this at all.
 
The usual approach is to make sure there is an explicit reset mechanism in your design that establishes a start-up value for any storage elements if needed.  Values for non-registed signals will then flow from this.

bye

PS.  The above applies to synthesis only.  For test-benches it's fine.

[SiliconWizard]

You're not initializing the states and you're not handling STATE5 that you added. If the Next_State signal happens to be STATE5 when it starts, your FSM is basically stuck forever, as it implements no way of getting out of STATE5.
You should not make any assumption as to the value of the signals that haven't been initialized. While on most FPGAs (wouldn't be the case with "direct" synthesis on silicon), registers will be reset to "0" upon configuration of the chip, this isn't something you should rely on, and apart from that, you have no idea what the "0" value here maps to in terms of state (looking at the synthesis report may give you a clue though).

Note that both Next_State and Present_State should be initialized, as Present_State will get the value of Next_State after the first clock cycle.

Also note that you can condense this FSM in just a single process and a few lines of code. This form is very verbose, of no added value in this case, and more prone to errors due to having the code spread over more processes. It's the usual "academic" way of teaching a FSM though, which often only confuses students rather than help them IMO. It's meant to be a direct translation of the formal definition of a FSM.

[Daixiwen]

To make safe change

Code: [Select]

when others => null;to

Code: [Select]

when others => Next_state <= STATE1;which will make the state machine safe as any unknown state values will be corrected.

Be sure to check the documentation of your synthesizer before assuming that this will make your FSM safe though. I know that for example Quartus will completely ignore the "when others =>" line. If you enable the "safe FSM" assignment in the project (or for each FSM), it will automatically detect which state the FSM has during reset, and add code to jump to that state if the FSM is at an unknown state at any point. But whatever the "safe FSM" paremeter is, it will always ignore the "when others" line when it detects an FSM.

You can read more about that here. 

[ebastler]

some FPGA will set registers to a requested output state during power up (expect ICE40 do but have not used that type of FPGA).

The iCE40 does not have provisions to initialize its registers to non-zero values. The hardware just resets everything to zero. I believe the free iCEStorm toolchain provides workarounds to automatically generate initialization "code", but the official Lattice tools don't.

This causes a problem when the tools choose "one-hot" encoding for the states of a state machine, i.e. a bit vector where one out of n bits is set to encode each of n states. In that case, the all-zero configuration which the FPGA will start up with is an invalid state.

As others have suggested, I would recommend that you either implement a global reset which (among other non-zero initializations you might need) initializes the state. Or you can define an "initialized" bit which, while '0', forces a special initialization handling in your process and is then set to '1'.

[ejeffrey]

some FPGA will set registers to a requested output state during power up (expect ICE40 do but have not used that type of FPGA).

The iCE40 does not have provisions to initialize its registers to non-zero values. The hardware just resets everything to zero. I believe the free iCEStorm toolchain provides workarounds to automatically generate initialization "code", but the official Lattice tools don't.

I don't think any modern FPGAs have physical preset inputs any more.  Maybe some very small devices do but it's not common.  What synthesis tools do is to flip the sense of all registers that have a reset value of 1 and then use e.g. DeMorgans law to rewrite the logic to work with a standard reset.  It's a pretty simple operation for a synthesis tool to do and I'm surprised the lattice tool chain doesn't do it.

[Someone]

I know that for example Quartus will completely ignore the "when others =>" line. If you enable the "safe FSM" assignment in the project (or for each FSM), it will automatically detect which state the FSM has during reset, and add code to jump to that state if the FSM is at an unknown state at any point. But whatever the "safe FSM" paremeter is, it will always ignore the "when others" line when it detects an FSM.

You can read more about that here.

Nowhere does that documentation page mention the others/catch all case. Does including an others case always cause that tool to not infer a state machine?

[Daixiwen]

The documentation from Altera used to be better on this subject, but it does say

The safe state machine value does not use any user-defined default logic from your HDL code that corresponds to unreachable states.

which means that the "others" case will be ignored. I also saw this in practice, and you can always check with the RTL viewer what has been implemented from your code.
This behavior is only implemented if the synthesizer recognizes an FSM. if you have a case and a "with others=>" in some code that is not recognized as an FSM by Quartus, then it will implement it.
You need to go through the synthesize log to see whether a case in a process has been implemented as an FSM or not. I beleive it is a note level, not a warning, but you can search with the signal and/or entity name.

[ebastler]

In my understanding, it is not clearly defined whether the "others" clause is meant to catch valid states which were not explicitly dealt with in a case statement -- or also invalid binary values which do not correspond to any value of an enumerated state type.

It seems that different toolchains take different views on this. So for some toolchains, the "others" clause can be used to set a valid state after starting up with an invalid "all zero" state. For other toolchains this might not work, since they just ignore the "others" clause if all valid states have already been handled explicitly in the case statement.

[SiliconWizard]

In all cases, it catches the unhandled states (from the type that is defined), but whether it does anything else is 100% implementation-defined. Yes it depends on the tool used, but also on the way the FSM is implemented. If it's one-hot encoding, for instance, then there shouldn't be any possible binary value except those that have been user-defined. But if another scheme than one-hot is used, then anything can happen and whether a given tool will make any use of the 'others' statement in this case, just.... RTFM. No way to guess.

[coppercone2]

there are four states

[ebastler]

If it's one-hot encoding, for instance, then there shouldn't be any possible binary value except those that have been user-defined.

Well, there is the "none-hot" value, all zeros, which specifically the iCE40 will always start up with and which is not a valid state.