Register power-up values not reliable

[Altera_Forum]

I just noted Altera posted a new knowledge base article, stating that the register power-up values are not 100% reliable: http://www.altera.com/support/kdb/solutions/rd06112009_450.html 

 Isn't it a bit too late for issuing such a warning? I know that an external reset is considered good practice. But this is the firt time I see the warning, and I am sure during all these years, many cores were developed relying in the initial register values.  A more detailed elaboration of the problem would be nice. In some cases I used the PLL locked signal as an internal power-up reset source. Would be interesting to know if the PLL lock power-up counter is affected or not.

[Altera_Forum]

so does this mean that an external connection from init done to the global clear input must be done ? (did not check the logical level if this signal must be inverted)

[Altera_Forum]

I don't hear a general limitation from the said knowledge base article. It rather seems to mention an obvious design behavior related to the fact, that the power-up reset isn't synchronously released. 

 But I basically agree to the comment, that Altera may want to elaborate the said "support solution". As presented, it's more or less meaningsless. Also the mentioned Quartus Handbook page 6-37 doesn't give new insights.   The obvious point is however, that you should use a synchronously released reset, if you require all state-machines, counters and similar state memories to start with a design wide consistent state.  Regarding PLL lock, it's sufficient in most cases to rely on the default PLL behaviour. But the reset of PLL driven design parts (typically most of the design) should be actually released after PLL lock. I don't see additional problems brought up by the discussed behaviour of power-up reset.

[Altera_Forum]

--- Quote Start ---  Regarding PLL lock, it's sufficient in most cases to rely on the default PLL behaviour. But the reset of PLL driven design parts (typically most of the design) should be actually released after PLL lock. I don't see additional problems brought up by the discussed behaviour of power-up reset.  --- Quote End ---    I use the PLL programmable counter to hold lock low. Then I use the PLL lock signal as async reset to a register that is my global reset. This way I get a power-up reset signal that is generated internally and released synchronously.  The problem is how the issue affects the PLL lock counter. If power-up values are not reliable, then I'm not sure anymore if the PLL programmable hold-lock counter is reliable.

[Altera_Forum]

Note that the article doesn't say the register comes up in an unkown state or have some strange behavior. This is a case of the user clock and the release of reset not being synchronized. External reset, in my opinion, is not good practice but an absolute necessity. Probably the number one thing I've seen designs have sporadic field failures is incorrect reset structures. It's a touchy topic because lots of designs are not done correctly yet will never have a failure. Taking a guess, I would say 95% of logic is immune to issues coming out of reset, with some designs having more but some designs being completely immune.  

One nice thing is that TimeQuest automatically analyzes this(Recovery and Removal) and doesn't let the user easily turn this off. But if the user hasn't put in reset logic, or is cutting timing across domains, there's nothing that can be done. I do wish this was better documented/discussed. Users tend to ignore resets, or quickly throw them in without understanding, until they have a failure and have to take a step back to analyze. One thing about resets is that, usually they're very easy to implement correctly, as long as it's done up front.

[Altera_Forum]

--- Quote Start ---  Note that the article doesn't say the register comes up in an unkown state or have some strange behavior. This is a case of the user clock and the release of reset not being synchronized. External reset, in my opinion, is not good practice but an absolute necessity.  --- Quote End ---    But external reset is not easy to implement in the FPGA world. This is not a true physical power-up reset, but a user-mode startup reset. Plus, with many designs using internals PLLs, external reset doesn't solve the problem of synchronous release.  A perfect external reset would need to track both the INIT_DONE signal and each of the PLL clocks outputs. Connecting external reset to INIT_DONE is not difficult, but syncing to the PLL outputs is not practical in many cases.

[Altera_Forum]

You're right. I typed external reset but didn't mean it. The reset(whether external, internal or both) needs to be synchronized to each clock domain group, as well monitored from any system level functions like the PLL locked signal. This is not trivial, but once you do it, not that difficult either.

[Altera_Forum]

Just to understand that correct. 

external reset signal from input pin should go into 2 cascaded dff to get a clock synchron reset. this reset is the system reset, that feeds nios and all other logic also the pll locked signal should be connected to the nPresets of the DFF's that this reset is hold as long as the pll is not locked.  but if the pll unlockes then the design is will perform a reset this leads to the question if the pll can unlock during operation. and what happens during unlock or how unlocked the pll could get. would the system still be operable ?

[Altera_Forum]

A PLL can loose lock in operation, e.g. due to simultaneous switching outputs noise affecting the input clock. If this happens, reliable system operation can't be expected any more. A PLL reset is required to restore the designed phase relation of output clocks. Because the output clocks possibly creates timing violations during PLL unlock, the connected logic can reach illegal states. Thus, if not particularly designed for safe recover, it must be reset. 

 In other words, PLL loose of lock can't be regarded as normal operation, although a system can be designed to preserve basic functionality in this situation.