Initial DFF values after FPGA programming

--- Quote Start ---

A counter counting from reset state 0000 to next state 0001 in contrast can keep the reset state at worse.

--- Quote End ---

I was going to say the same.

But I wonder just out of curiosity, and would like yours and other experts opinion, if this is really 100% foolproof. Isn't it possible that the async reset release could produce setup/hold violations on the register output? If this is possible, then the next register in the counter could, in theory, become metastable.

--- Quote Start ---

Power-up state can be considered reliable, the problem is with asynchronous release of power-up reset. As a consequence, a counter or state-machine can advance to an unexpected next state on a clock edge that coincides with reset release in some cases. But it can't advance to any arbitrary state, because each single register bit either keeps the reset state or takes the next state.

E.g. a one state hot state variable, advancing regularly from 1000 to 0100 can wrongly take 0000 or 1100, but no other state. A counter counting from reset state 0000 to next state 0001 in contrast can keep the reset state at worse. This is the reason, why the said reset controller counter always works reliably in my opinion. So if you want to provide an synchronous released reset but don't have an external reset signal, it's a good way.

--- Quote End ---

I'll try to find the thread about the reliability of power-up values that vjAlter mentioned and read up on it more. Since the power-up state is only unreliable in the sense that the reset/preset may act as being asserted at two different clock cycles for two different registers(this is even less likely if the registers are in the same LAB), a counter or shifter should work just fine. I'll consider this good design practice in the case where an external reset is not available.

Thanks for everyone's help.

--- Quote Start ---

Since we can't depend on the power-up state of any of the registers

--- Quote End ---

Power-up state can be considered reliable, the problem is with asynchronous release of power-up reset. As a consequence, a counter or state-machine can advance to an unexpected next state on a clock edge that coincides with reset release in some cases. But it can't advance to any arbitrary state, because each single register bit either keeps the reset state or takes the next state.

E.g. a one state hot state variable, advancing regularly from 1000 to 0100 can wrongly take 0000 or 1100, but no other state. A counter counting from reset state 0000 to next state 0001 in contrast can keep the reset state at worse. This is the reason, why the said reset controller counter always works reliably in my opinion. So if you want to provide an synchronous released reset but don't have an external reset signal, it's a good way.

It is a good idea as detection mechanism but is certainly overkill. I have used this method and tested my circuit several thousands of time using software setup overnight and weekend. I believe having few registers starting at zero

is not a problem stastiscally.

I usually use a power-up value assignment on the reset counter to ensure it powers up appropriately. But then that's the only register you have to worry about if everything else is reset. That's really the best way.

Jake

--- Quote Start ---

It is not wise to depend on powerup feature for every single register. What I normally do is have an internal reset when fpga is configured. Though this will need a logic that starts low but at least it uses few registers e.g. counter going up from 0 to 15 and stops there, release reset at count 15.

--- Quote End ---

Since we can't depend on the power-up state of any of the registers, is there any protection if the registers used in this reset counter fail to initialize properly? For instance, if they happened to initialize to all 1s the reset would be released immediately (or perhaps never be asserted at all). There are probably ways around this. Perhaps reading the initial value of the counter into a second register, then incrementing the counter until the counter rolls over and the two registers are equal again to release the internal reset?

This might be overkill :)

I agree with kaz. All of my designs have a reset controller that provides a timed synchronous reset on FPGA power up.

Jake

--- Quote Start ---

always @(posedge clk)
  if(enable)  q <= data;

What will the value of this register be before the DFF is enabled? Is this value guaranteed? Does this act the same way across all Altera device families? What about other PLD vendors?

--- Quote End ---

You must be careful about this. We recently have a thread about the reliability of power-up values.

Unless the "Power-up Don't Care" logic option is enabled, then the power-up value is fixed. In this case, without any async signals and specific power-up value, it would be zero.

However, all registers have a chip-wide async reset that is always enabled and it is released just before entering user mode. This is how the power-up value is actually set. The problem is that this chip-wide async reset is not released synchronously to any clock whatsoever.

Another problem with implicit power-up values is that simulators are usually not aware about them.