What is the state of state machine after power-up without re

W

Weng Tianxiang

Guest
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 Tianxiang wrote:

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.
Click to expand...
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
 
wtx@umem.com (Weng Tianxiang) wrote in message news:<511e4538.0311201706.34eab0da@posting.google.com>...
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
Click to expand...
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
 
charles.elias@wpafb.af.mil (Charles M. Elias) wrote in message news:<35849667.0311210326.742edc1a@posting.google.com>...
wtx@umem.com (Weng Tianxiang) wrote in message news:<511e4538.0311201706.34eab0da@posting.google.com>...
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
Click to expand...
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
 
Weng Tianxiang wrote:
charles.elias@wpafb.af.mil (Charles M. Elias) wrote in message news:<35849667.0311210326.742edc1a@posting.google.com>...
[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.
Click to expand...
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".
--
Tim Hubberstey, P.Eng. . . . . . Hardware/Software Consulting Engineer
Marmot Engineering . . . . . . . VHDL, ASICs, FPGAs, embedded systems
Vancouver, BC, Canada . . . . . . . . . . . http://www.marmot-eng.com
 
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.
 
Scott Dickson wrote:
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.
Click to expand...
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.
--
Tim Hubberstey, P.Eng. . . . . . Hardware/Software Consulting Engineer
Marmot Engineering . . . . . . . VHDL, ASICs, FPGAs, embedded systems
Vancouver, BC, Canada . . . . . . . . . . . http://www.marmot-eng.com
 
Tim Hubberstey wrote:

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.
Click to expand...
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
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top