What is the state of state machine after power-up without reset conditions

W

Weng Tianxiang

One of my project contains a state machine that has no conditions with
nRESET.
The code is as follows:
SDRAMStateA : process(CLK66M)
begin
if(CLK66M'event and CLK66M = '1') then
SDRAMState <= SDRAMNextState;
end if;
end process;

SDRAMNextState is defined in another process without clock.

The state machine has 42 states.

The project design is compiled by Exemplar vhdl compiler and its
generated *.edf file is compiled by Quartus 2.1. Then the final file
is loaded into Altera APEX 20K160 chip.

The project works well, especially after power-up: it starts with the
first state.

The coding is one hot coding.

Now the project grows and we shifted the project from Altera
APEX20K160 to 20K200 with almost the same state machine without reset
condition as above.

The new project is compiled by Exemplar and by Quartus 2.1, it fails
after power-up. The data shows after power-up, the state machine
enters no valid state.

After some experiements, we get the state machine work:
SDRAMStateA : process(CLK66M)
begin
if(CLK66M'event and CLK66M = '1') then
-- enumerate all states
if(StateSDRAM(5 downto 0) = "111111") then
SDRAMState <= Reset_S;
else
SDRAMState <= SDRAMNextState;
end if;
end if;
end process;

StateSDRAM(5 downto 0) is defined as "111111" if it is not one of 42
states.

Now I want to ask such a question:
In my opinion, in one hot coding, VHDL compiler "will and should" pick
up a state as its initial state and implement it after power-up, no
matter there is or isn't reset condition.

Am I wrong or right?

Weng
 
M

Mike Treseler

Weng said:
Now I want to ask such a question:
In my opinion, in one hot coding, VHDL compiler "will and should" pick
up a state as its initial state and implement it after power-up, no
matter there is or isn't reset condition.

Without reset logic, the state register will
power up to an arbitrary state, maybe even all ones.

If your next state logic covers this value correctly,
the machine will recover in a few ticks.
Otherwise the machine will do as it is told,
that is, stay in the initial state.

-- Mike Treseler
 
C

Charles M. Elias

One of my project contains a state machine that has no conditions with
nRESET.
The code is as follows:
SDRAMStateA : process(CLK66M)
begin
if(CLK66M'event and CLK66M = '1') then
SDRAMState <= SDRAMNextState;
end if;
end process;

SDRAMNextState is defined in another process without clock.

The state machine has 42 states.

The project design is compiled by Exemplar vhdl compiler and its
generated *.edf file is compiled by Quartus 2.1. Then the final file
is loaded into Altera APEX 20K160 chip.

The project works well, especially after power-up: it starts with the
first state.

The coding is one hot coding.

Now the project grows and we shifted the project from Altera
APEX20K160 to 20K200 with almost the same state machine without reset
condition as above.

The new project is compiled by Exemplar and by Quartus 2.1, it fails
after power-up. The data shows after power-up, the state machine
enters no valid state.

After some experiements, we get the state machine work:
SDRAMStateA : process(CLK66M)
begin
if(CLK66M'event and CLK66M = '1') then
-- enumerate all states
if(StateSDRAM(5 downto 0) = "111111") then
SDRAMState <= Reset_S;
else
SDRAMState <= SDRAMNextState;
end if;
end if;
end process;

StateSDRAM(5 downto 0) is defined as "111111" if it is not one of 42
states.

Now I want to ask such a question:
In my opinion, in one hot coding, VHDL compiler "will and should" pick
up a state as its initial state and implement it after power-up, no
matter there is or isn't reset condition.

Am I wrong or right?

Weng

Weng,

I think it is a mistake to assume that a compiler will do anything not
explictly expressed in your code. As you have seen, even if one
compiler happens to furnish a reset, another may not. It is, and
always will be, a rule of mine to have a reset input to all state
machines and to have a power-on reset device on the circuit board.

Best regards,

Charles
 
W

Weng Tianxiang

Weng,

I think it is a mistake to assume that a compiler will do anything not
explictly expressed in your code. As you have seen, even if one
compiler happens to furnish a reset, another may not. It is, and
always will be, a rule of mine to have a reset input to all state
machines and to have a power-on reset device on the circuit board.

Best regards,

Charles

Thank you very much.

You are right. We cannot expect VHDL compiler to do what is not
specified, even though a better compiler sometimes do you a favor.

Weng
 
T

Tim Hubberstey

Weng said:
(e-mail address removed) (Charles M. Elias) wrote in message news:<[email protected]>... [snip]
I think it is a mistake to assume that a compiler will do anything not
explictly expressed in your code. As you have seen, even if one
compiler happens to furnish a reset, another may not. It is, and
always will be, a rule of mine to have a reset input to all state
machines and to have a power-on reset device on the circuit board.

You are right. We cannot expect VHDL compiler to do what is not
specified, even though a better compiler sometimes do you a favor.

I disagree with your interpretation that "a better compiler sometimes do
you a favor".

What probably happened is that one synthesizer generated "safe" code to
recover the state machine from illegal states while the other one
didn't. Neither one is better or worse because of this. Synthesizers
usually have switches to control this behavior and it may be that the
defaults for the synthesizers are different. Generating "safe" state
machines uses considerably more logic and produces logic that runs
slower. Sometimes you need this level of fault tolerance and sometimes
you don't. If your "better" synthesizer does not have the option to turn
off "safe" mode, then it is actually inferior since generating logic you
didn't ask for in some way (either through switches or source code) is
just plain wrong.

The real problem is that you did not do the design properly in the first
place. A reset condition should always be included in a state machine.
Whether that reset condition is supplied by an external signal or
implied as a result of the configuration process is technology
dependent. If you ever get to the point of designing an ASIC, that rule
changes to "all FFs must have a reset unless there is a very, very good
reason for not having one".
 
S

Scott Dickson

The synthesis tool is not likely creating a "safe" state machine for
one-hot encoding, as this is actualy quite complicated since the
number of illegal states is 2**N - N. For a 42 states that would be
big. What is likely happening is that the synthesis tool is
initializing the state vector to the initial state with the FPGA
configuration. A different tool, or FPGA may not provide this same
ability. You can however force an initial state to be synthesized in
VHDL, regardless of the tool. This is often used as a trick in State
Machine encoding. The best method however is to use an asynchronous
reset as others have suggested.
 
T

Tim Hubberstey

Scott said:
The synthesis tool is not likely creating a "safe" state machine for
one-hot encoding, as this is actualy quite complicated since the
number of illegal states is 2**N - N. For a 42 states that would be
big.

Actually, the number of illegal states isn't relevant -- it's the number
of legal states that determines how complex the safety logic is.

In order to implement a "when others =>" test for one-hot encoding, what
you are trying to detect is that the number of 'ones' in the state
vector is not exactly equal to 1. Using 4-input lookup tables (LUTs),
this function requires at worst log2(states)-1 levels of logic and
around 'states' LUTs. For a 42-state machine, this is only 43 LUTs and 5
logic levels. The state transition logic will need to detect this
"error" signal so at most one additional LUT per state will be required.
This is a worst-case total of 85 additional LUTs for a 42-state machine.
 
M

Mike Treseler

Tim said:
Actually, the number of illegal states isn't relevant -- it's the number
of legal states that determines how complex the safety logic is.

In order to implement a "when others =>" test for one-hot encoding, what
you are trying to detect is that the number of 'ones' in the state
vector is not exactly equal to 1. Using 4-input lookup tables (LUTs),
this function requires at worst log2(states)-1 levels of logic and
around 'states' LUTs. For a 42-state machine, this is only 43 LUTs and 5
logic levels. The state transition logic will need to detect this
"error" signal so at most one additional LUT per state will be required.
This is a worst-case total of 85 additional LUTs for a 42-state machine.

Well said.

Every time I have compared utilization between
one-hot and binary on large fpga designs, binary wins.
Perhaps handling "when others =>" is the reason why.

And perhaps the well-documented one-hot encoding
"advantage" for fpgas ignores this extra logic.

-- Mike Treseler
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,731
Messages
2,569,432
Members
44,832
Latest member
GlennSmall

Latest Threads

Top