Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
20711 Discussions

Power on Reset & state machines

Altera_Forum
Honored Contributor II
2,383 Views

Hi, I am using MAX II cplds & have a couple of questions. Can anyone explain to me what state a state machine goes into after Power-Up? if My State_type definition is this: 

type STATE_TYPE is (A,B,C,D) does it default into the leftmost state? 'A'?
0 Kudos
7 Replies
Altera_Forum
Honored Contributor II
1,080 Views
0 Kudos
Altera_Forum
Honored Contributor II
1,080 Views

Brad, wow thanks, nice quick reply, really appreciate it! I think I understand what your saying , but let me make sure. So you would tie an input pin high, & read it & then when you read a high, you know you've entered user mode & everything should be cleared. Then you'd generate a reset signal based on this sample of a high.. so in the vhdl world, it would be something like this?: 

 

the pin i tied high is input_pin 

my generated reset is umm.. generated_reset :) 

 

process(clk) 

begin 

if clk = '1' and clk'event 

if input_pin = '1' and reset_done = '0' then  

reset_done <= '1';  

generated_reset <= '1'; 

elsif generated_reset = '1' then 

generated_reset <= '0';  

end if; 

end if; 

 

end process; 

 

it should make a generated_reset signal 1 clk cycle wide after entering user_mode, that is of course, if i understand you correctly.. 

 

thanks again,  

ambien
0 Kudos
Altera_Forum
Honored Contributor II
1,080 Views

In the other thread, I was trying to guess what Whitebird was trying to do. I referred you to my post in that thread just for the discussion of a state machine powering up with all state code bits low unless you override that with a reset signal. 

 

All registers will power up low without a reset signal, and you can make your design safely use all registers low as the intended reset condition without using a reset signal. You can make your state machine have all bits low in the state code of the reset state and have only one state code bit toggle for the state transition to exit the reset state. Unless you want to be able to force the reset state later without cycling power, you don't have to use a reset signal. 

 

Without a synchronized reset signal, though, registers might exit the reset condition at different clock cycles. In most designs an external reset signal is input to the CPLD and held asserted until power has been applied long enough for it to be OK to start operation of the CPLD's logic. A proper design also synchronizes the reset signal to the clock and uses recovery and removal analysis unless the designer is careful to ensure that it is actually OK for registers to exit reset at different clock cycles. 

 

My suggestion in the other thread to create an internal reset signal (which does not use a device input pin) was just for the case where you do not always assert an external reset input at power up and you need to guarantee that more than one register comes out of reset on the same clock cycle. I suggested having a register that has its input hard tied to high, not driven by a high input pin. You might have to do some trick to keep synthesis from synthesizing away such a register. 

 

A state machine in particular might require multiple registers to exit reset at the same clock cycle. If more than one bit in the state code changes for a valid transition from the reset state to another state, you have to be sure all those potentially changing bits see the reset end at the same clock cycle so that they all change together for a valid state transition. 

 

If you are using Quartus integrated synthesis, then in the Quartus handbook see Volume 1, Section III, Chapter 8. Read the "State Machine Processing" section and the following sections. The handbook tells you how you can optionally encode your states manually (there's also a VHDL template in the text editor for this). 

 

For automatic one-hot encoding (and I'm guessing for other encodings that are not user-specified), this section of the handbook says, "Quartus II integrated synthesis encodes the initial state with all zeros for the state machine power-up because all device registers power up to a low value." I didn't know whether "the initial state" means the first state listed in the type definition or if synthesis determines it from a reset signal in the state machine to make the power-up reset state match the one controlled by the reset signal. I did an experiment and found that the state forced by an asynchronous reset signal (I didn't try a synchronous reset signal) is always the one that gets encoded with all state bits low when "State Machine Processing" is set to "Auto". The all-bits-low state isn't necessarily the first one listed in the type definition. 

 

Check the Analysis & Synthesis report for the actual state encoding. It is shown in messages and in a table.
0 Kudos
Altera_Forum
Honored Contributor II
1,080 Views

Ok, I understand what you are saying. I looked at my xxx.map.rpt & it says the State I want it to initialize to out of power-up is encoded to all 0's: 

 

Info: State "|CPLD_A_test2|foo:SM1|CURRENT_STATE.wait_state" uses code string "0000000000" 

 

But That isnt a "reset state", I dont have one. If I were to make a reset state, how would it know when to transition to my initial "wait_state"?& why do you need one? my state machine code looks like this: 

 

process(clk) 

begin 

if clk = '1' and clk'event then 

if sreset = '0' then --This is my external reset 

CURRENT_STATE <= wait_state; 

..  

.. 

end if; 

else case CURRENT_STATE is 

when wait => do your stuff 

 

 

It sounds you are saying "most designs" use an external power on reset to drive DEV_Clrn, but I am trying to get around that. 

 

 

appreciate your patience! 

 

thanks, 

ambien
0 Kudos
Altera_Forum
Honored Contributor II
1,080 Views

 

--- Quote Start ---  

But That isnt a "reset state", I dont have one. If I were to make a reset state, how would it know when to transition to my initial "wait_state"?& why do you need one? 

--- Quote End ---  

 

 

It might be OK for your wait_state to be the state the state machine enters at power-up reset. If that state waits for some signal that is synchronized to the clock before transitioning to any other state, then you're OK. If the end of the power-up reset condition could cause an immediate exit from that state, then you have to make sure only one state code bit can potentially toggle for that exit or you have to use a synchronized reset signal (whether from an input pin or created internally) to control the exit from that state. 

 

 

 

--- Quote Start ---  

It sounds you are saying "most designs" use an external power on reset to drive DEV_Clrn, but I am trying to get around that. 

--- Quote End ---  

 

 

 

Most designs have a reset on a regular input pin, not the DEV_CLRn special-purpose pin for device-wide reset. You can't use DEV_CLRn in your RTL for a reset signal.
0 Kudos
Altera_Forum
Honored Contributor II
1,080 Views

 

--- Quote Start ---  

Ok, I understand what you are saying. I looked at my xxx.map.rpt & it says the State I want it to initialize to out of power-up is encoded to all 0's: 

 

Info: State "|CPLD_A_test2|foo:SM1|CURRENT_STATE.wait_state" uses code string "0000000000" 

 

But That isnt a "reset state", I dont have one. If I were to make a reset state, how would it know when to transition to my initial "wait_state"?& why do you need one? my state machine code looks like this: 

 

process(clk) 

begin 

if clk = '1' and clk'event then 

if sreset = '0' then --This is my external reset 

CURRENT_STATE <= wait_state; 

..  

.. 

end if; 

else case CURRENT_STATE is 

when wait => do your stuff 

 

 

It sounds you are saying "most designs" use an external power on reset to drive DEV_Clrn, but I am trying to get around that. 

 

 

appreciate your patience! 

 

thanks, 

ambien 

--- Quote End ---  

 

 

 

--- Quote Start ---  

It might be OK for your wait_state to be the state the state machine enters at power-up reset. If that state waits for some signal that is synchronized to the clock before transitioning to any other state, then you're OK. If the end of the power-up reset condition could cause an immediate exit from that state, then you have to make sure only one state code bit can potentially toggle for that exit or you have to use a synchronized reset signal (whether from an input pin or created internally) to control the exit from that state. 

 

 

 

 

 

Most designs have a reset on a regular input pin, not the DEV_CLRn special-purpose pin for device-wide reset. You can't use DEV_CLRn in your RTL for a reset signal. 

--- Quote End ---  

 

 

 

 

Brad! thanks, that was the problem. in my "wait_state" the conditional was waiting on an active low signal to transition onto the next state. So It sounds like it was coming out of reset seeing this signal cleared & transitioning onto the next state. I made it active High & all seems well. I tried "pre-setting" this port, in vhdl: foo: std_logic := '1', & it still didnt fix it. shouldnt it have? after reading the manual you pointed out on state machines it sounds like these presets are done in configuration mode, not user mode. 

 

thanks! the check is in the mail. 

ambien
0 Kudos
Altera_Forum
Honored Contributor II
1,080 Views

 

--- Quote Start ---  

I tried "pre-setting" this port, in vhdl: foo: std_logic := '1', & it still didnt fix it. shouldnt it have? 

--- Quote End ---  

 

 

 

All internal registers (registers not in I/O cells) power up low and cannot be made to power up high. Synthesis might make a register appear to initialize high by inverting the register input and output. I don't know whether synthesis should do that in your case. There are synthesis warnings (might be Info messages) about power-up don't care. They probably relate to this situation. See whether you have warnings about that.
0 Kudos
Reply