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

Initial DFF values after FPGA programming

Altera_Forum
Honored Contributor II
3,805 Views

Normally I design my all my logic with an asynchronous reset, so this is not an issue, but I have recently come across an area where we might reload the FPGA via nCONFIG to reset it, and not have User IO based asynchrnonous reset. In this case a DFF with enable would have the following code: 

 

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?
0 Kudos
22 Replies
Altera_Forum
Honored Contributor II
1,701 Views

See page 6-36 of the HDL coding guidelines: 

http://www.altera.com/literature/hb/qts/qts_qii51007.pdf 

 

Registers should power up with a '0' value. You can also specify a power-up value using an assignment. There is the NOT-gate pushback optimization that can change the behavior in some cases but I suspect you don't need to worry about that. 

 

Jake
0 Kudos
Altera_Forum
Honored Contributor II
1,701 Views

in verilog you have the initial block after the modul declaration 

 

module mymodul ( myclk , myreg); 

 

input myclk; 

output myreg; 

 

initial 

begin 

myreg <= myinitvalue; 

end 

 

reg myreg; 

always @ ( posedge myclk ) 

myreg <= myreg + 1; 

 

endmodule 

 

but have a look at the quartus settings about initial values, i am currently unshure which one but i think the is one settings about that. 

 

regards 

 

michael
0 Kudos
Altera_Forum
Honored Contributor II
1,701 Views

Thanks! The documentation you linked is very useful.

0 Kudos
Altera_Forum
Honored Contributor II
1,701 Views

 

--- 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.
0 Kudos
Altera_Forum
Honored Contributor II
1,701 Views

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.

0 Kudos
Altera_Forum
Honored Contributor II
1,701 Views

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

 

Jake
0 Kudos
Altera_Forum
Honored Contributor II
1,701 Views

 

--- 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 :)
0 Kudos
Altera_Forum
Honored Contributor II
1,701 Views

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
0 Kudos
Altera_Forum
Honored Contributor II
1,701 Views

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.
0 Kudos
Altera_Forum
Honored Contributor II
1,701 Views

 

--- 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.
0 Kudos
Altera_Forum
Honored Contributor II
1,701 Views

 

--- 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.
0 Kudos
Altera_Forum
Honored Contributor II
1,701 Views

 

--- 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.
0 Kudos
Altera_Forum
Honored Contributor II
1,701 Views

 

--- Quote Start ---  

I'll try to find the thread about the reliability of power-up values that vjAlter mentioned and read up on it more. 

--- Quote End ---  

 

 

http://www.alteraforum.com/forum/showthread.php?t=6067 

 

Not really much more elaboration in that thread than here. Except perhaps that it was stressed, the probably obvious, that the reset logic must be done separately on each clock domain.
0 Kudos
Altera_Forum
Honored Contributor II
1,701 Views

 

--- Quote Start ---  

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 End ---  

 

 

If this is the case, are the bits in your counter/shift register acting as synchronization registers? Since the asynchronous signal is a reset/preset, we are not violating the flip-flop's Data input to rising-clock setup time, but instead de-asserting a preset while the clock is rising. I assume from what FmV said that the problem is some registers interpret this as a reset followed by a rising clock, and other interpreting it as a rising clock followed by a reset. 

 

I do not know if this can lead to metastability the same way setup time violations can.
0 Kudos
Altera_Forum
Honored Contributor II
1,701 Views

Here. You can use this. Use the assignment editor in Quartus to specify a power-up level of 0 to "count" within your design instance. 

 

Jake
0 Kudos
Altera_Forum
Honored Contributor II
1,701 Views

 

--- Quote Start ---  

I do not know if this can lead to metastability the same way setup time violations can. 

--- Quote End ---  

 

i have seen it affect a design in this way. i was convinced it was a timing issue because fit to fit and even device to device behavior would vary. in the end it was solved by synchronizing the reset in a second clock domain. 

 

:eek:
0 Kudos
Altera_Forum
Honored Contributor II
1,701 Views

I am a bit confused now...because any release near clk edge will violate Tsu/Th 

I will strongly believe that powerup reset release will not be made any close to any clk edge. The silicon people wouldn't let that happen on the very first clk edge or can they? 

After all we are told to take care of reset release at field.
0 Kudos
Altera_Forum
Honored Contributor II
1,701 Views

hmm i see i've gone and caused confusion. let me see if i can find the design and get some details. i think there was a reset counter involved.

0 Kudos
Altera_Forum
Honored Contributor II
1,701 Views

 

--- Quote Start ---  

Since the asynchronous signal is a reset/preset, we are not violating the flip-flop's Data input to rising-clock setup time, but instead de-asserting a preset while the clock is rising... 

I do not know if this can lead to metastability the same way setup time violations can. 

--- Quote End ---  

 

 

I do think that reset release has a minimum setup requirement, and if that is violated then it can produce metastability.
0 Kudos
Altera_Forum
Honored Contributor II
1,472 Views

 

--- Quote Start ---  

I will strongly believe that powerup reset release will not be made any close to any clk edge. The silicon people wouldn't let that happen on the very first clk edge or can they? 

--- Quote End ---  

 

 

I don't think the silicon people have any way to prevent that.
0 Kudos
Reply