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

FPGA Initialization / Reset

AngelVillanueva
Beginner
3,111 Views

Hi,

 

I have tried to search for information on how to manage FPGA initialization / reset and have not found conclusive information so I would appreciate some help on this topic.

 

- Is it a reset signal always necessary to initialize the FPGA to a known state? What can be done if there is no reset signal available?

- Can you know the initialization value of registers and state machines without using a reset signal?

-  Can registers and finite state machines be initialized using VHDL / Verilog code?

 

Thank you in advance.

0 Kudos
13 Replies
sstrell
Honored Contributor III
3,094 Views

At the conclusion of programming of all devices (except Hyperflex devices; see below), all outputs are initialized low.  So it's highly recommended to have a reset scheme to set things correctly.  Depending on the way the design is written, initialized registers in code can go high, but this will be after everything starts low.

Hyperflex devices (Stratix 10, Agilex) do have the ability to have outputs initialized high from device programming so you may be able to get away without design reset, but it's still recommended to do it.

0 Kudos
_AK6DN_
Valued Contributor I
3,085 Views

"..., all outputs are initialized low. " -- I think you mean to say all registers are initialized low, by default.

"all outputs" can be inferred to mean all output pins of the device, which is not correct.

Registers (and thus state machine initial state) can be set to either 1 or 0 on powerup (ie, the default value after configuration).

They can then also be set to 1 or 0 on occurrence of a reset signal (which may be different than the powerup state.

Ie, a simple verilog example that configures two registers foo and bar to be low (same as the default) and high on configuration.

 

reg foo = 0;
reg bar = 1;

always @(posedge clk or posedge rst) begin
  if (rst) begin
    foo <= 1;
    bar <= 0;
  end else begin
    foo <= bar;
    bar <= ~foo;
  end
end

 

"..., but this will be after everything starts low." ... I don't believe this is correct if you use the reg statement with an initial value.

 

and re: state machine init value, you could do something like:

 

...
localparam INIT =3'b101;
...
reg [2:0] STATE = INIT;
...

 

0 Kudos
sstrell
Honored Contributor III
3,083 Views

You're right.  I meant register outputs.

0 Kudos
Nurina
Employee
3,062 Views

Hello,


Does the above comment help?


Regards,

Nurina


0 Kudos
AngelVillanueva
Beginner
3,043 Views

Thank you for your answers.

In Quartus II Handbook Version 9.1 Volume 1: Design and Synthesis, paragraph Register Power-Up Values in Altera Devices, it seems that there are several ways of initializing the FPGA registers:

 

1. Quartus II Power-Up Level logic option.

2. Altera_attribute assignment in source code.

3. Quartus II integrated synthesis converts default values for registered signals into Power-Up Level settings.

 

Therefore, Quartus II reads the initialization values from VHDL / Verilog code. Back in the day, I was told that VHDL / Verilog initialization values were used only for simulation, it seems that is no longer the case.

There is also an important detail described in the handbook, "If the target device architecture does not support two asynchronous control signals, such as aclr and aload, you cannot set a different power-up state and reset state".

 

We have been doing tests with a Cyclone V that supports aclr and aload.

Power-Up Don't Care option of Quartus II is disabled.

During the tests, the reset signal was always disabled. Hardware Reset = 3.3V -> '1'.

Signals are monitored using signal tap.

 

We used dummy code to see what happens during FPGA initialization.

The results have been very confusing.

It seems that even if we initialize the signals following the guidelines of Quartus Handbook, the system always goes through the reset statements, even if the hardware reset is disabled.

Dummy code extract below:

 

type states is (others_s, init_s, reset_s, prueba_s);

signal current_state: states := prueba_s;

signal next_state : states;

signal r_int, next_r_int : std_logic := '1';
signal i_int, next_i_int : std_logic := '1';
signal o_int, next_o_int : std_logic := '1';

 

process (CLK, RESET)

begin

if (RESET = '0') then
   current_state <= reset_s;
   r_int  <= '0';
   i_int  <= '0'; 
   o_int <= '0';

elsif (CLK'event and CLK = '1') then
   current_state <= next_state;
   r_int  <= next_r_int;
   i_int  <= next_i_int;
   o_int <= next_o_int;
end if;
end process;

 

process(current_state, r_int, i_int, o_int)
begin

next_state  <= current_state;
next_r_int  <= r_int;
next_i_int   <= i_int;
next_o_int <= o_int;

case current_state is
   when reset_s =>
      next_state <= prueba_s;
      next_r_int <= '1';
   when init_s =>
      next_state <= prueba_s;
      next_i_int <= '1';
   when others_s =>
      next_state <= prueba_s;
      next_o_int <= '1';
   when prueba_s =>
   when others =>
      next_state <= others_s;
end case;
end process;

R  <= r_int;
I   <= i_int;
O <= o_int;

 

The values obtained in signal tap for R, I and O are:

R = '1', I = '0', O = '0'

Since we initialized their values as '1'. 

The only way to obtain a '0' is executing the reset statements.

Do you know what can be causing this behaviour?

 

Thanks.

 

 

0 Kudos
_AK6DN_
Valued Contributor I
3,024 Views

Likely power on RESET derived from the internal power rail monitors. So you get a RESET after power on and configuration whether you assert the RESET pin or not. The RESET pin just allows you to reset the chip any time from an external source after it has powered up and been configured.

0 Kudos
AngelVillanueva
Beginner
2,928 Views

Thank you for your response.

In this application, I need to be able to reconfigure the FPGA in case of CRAM error due to SEU failure.

I cannot manage the reset signal with power rail monitors since a SEU failure can happen with the power supplies fully  stabilized.

I am evaluating using the CONF_DONE or INIT_DONE signals. 

 

  • CONF_DONE: As a status output, the CONF_DONE pin drives low before and during configuration. After all configuration data is received without error and the initialization cycle starts, the CONF_DONE pin is released. As a status input, the CONF_DONE pin goes high after all data is received. Then the device initializes and enters user mode. This pin is not available as a user I/O pin.
  • INIT_DONE: This is a dual-purpose pin and can be used as an I/O pin when not enabled as an INIT_DONE pin in the Quartus II software. When this pin is enabled, a transition from low to high on the pin indicates that the device has entered user mode. If the INIT_DONE output pin option is enabled in the Quartus II software, the INIT_DONE pin cannot be used as a user I/O pin after configuration.

 

However, it is important for me to clarify if it is always necessary a hardware reset signal or there are others ways to guarantee FPGA initialization in a known state.

0 Kudos
Nurina
Employee
2,923 Views

Hello,


So you didn't enable RESET at any point?

From what I understand, without setting any value for RESET, it is at an unknown state.

So it could be at any state. The suggestion from above comment could be happening as well.


Regards,

Nurina


0 Kudos
Nurina
Employee
2,853 Views

Hi,


As far as I know, it is always necessary to use reset signal to guarantee FPGA initialization in a known state.


Have you tried your dummy code without any RESET signal? What would happen?

Also, normal practise is to use reset = 1 to enable the reset signal. Have you tried this way instead?


Regards,

Nurina


0 Kudos
_AK6DN_
Valued Contributor I
2,823 Views

"As far as I know, it is always necessary to use reset signal to guarantee FPGA initialization in a known state. "

 

Not true. After configuration each and every logic register in the FPGA will be set to a known initial state, as defined in the loaded image.

 

The main use of the external reset line is to be able, via some external logic, to force the FPGA into the defined reset condition after it has been powered on and running.

0 Kudos
Nurina
Employee
2,561 Views

Hi,

 

Yes, that's what I meant.

Thanks for making it clear.

0 Kudos
Nurina
Employee
2,561 Views

Hello Angel,


May I know if the above comment helps?


Regards,

Nurina


0 Kudos
Nurina
Employee
2,459 Views

Hi,


We do not receive any response from you on the previous question/reply/answer provided. Please login to https://supporttickets.intel.com , view details of the desire request, and post a feed/response within the next 15 days to allow me to continue to support you. After 15 days, this thread will be transitioned to community support. The community users will be able to help you on your follow-up questions.


p/s: If any answer from community or Intel support are helpful, please feel free to mark as solution, give Kudos and rate 4/5 survey


Regards,

Nurina


0 Kudos
Reply