Powerup register reset values(again)

[Altera_Forum]

This is a quote from a previous post by vjAlter 

  --- Quote Start ---   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/so...12009_450.html <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.  --- Quote End ---     The fact(now known) that the powerup register values can go wrong if an incoming clk is active during configuration makes it very difficult to rely on internally generated reset.    At times we do need to generate reset internally without relying on any input. The reset counter works in practice but who knows it is at the mercy of your incoming clk

[Altera_Forum]

Cause we aren't in a guessing game, here's a regular link to the previous post. 

http://www.alteraforum.com/forum/showthread.php?t=6067 This is the quoted Altera statement. http://www.altera.com/support/kdb/solutions/rd06112009_450.html  In my opinion, the discussion in the said thread confirms my statement from the last days thread, that power-up values are not generally unreliable.     --- Quote Start ---  Using reset counter I tried in simulation various possible register initial values and ended up with failure at times.  --- Quote End ---   Can you show a design, that reproduces (at times) a failure related to "unreliable power-up resets" or whatever we call it? Because the original Altera statement isn't very informational, this would help others to clarify what's actually the problem with power-up reset and to check if the previous guesses are basically correct.

[Altera_Forum]

Hi, 

 I haven't kept the design but it is straightforward in simulation. Get a counter running from 0 to 15 and stop. do your reset pulse on the counting. apply all possible initial values for count and any other flags. Reset should be possible for all values of count except when count = 15 then you got one sample time to decide the reset and lower it.    It is not a problem to detect this case of 15 or to detect that a zero never occurred but we can't remedy that in real time when want reliable reset pulse and not just detection. The count will eventually reach 15 and stop and raising a flag that a zero didn't occur may by itself(i.e. the flag) be high in the first place. It seems logically impossible to create a pulse if there is not a single register initialised with 100% certainty.   So it remains important to rely on power up reset of vendors and make most of it avoiding its failure point.

[Altera_Forum]

The horse is dead ... Do we need to keep shooting it?

[Altera_Forum]

Who said it is dead and who killed it? That is your opinion. 

You don't seem to grasp the issue in the first place. It is true there is not much practical concern because most people have their external reset input. or their internal reset only may fail occasionally. I know several domestic units failing on power up but you can just switch them on again. It is just annoying when your design is suddenly dead or chaotic on powerup infrony of your project people.

[Altera_Forum]

Well to help give people something they can use, I also submit the attached schematic snippet. The snippet is for an external reset controller that is tied to the init_done signal of the FPGA, Not shown in the snippet is that FPGA_INIT_DONE is pulled high elsewhere. This will help ensure that you get a reset on power-up. Forgive me, I was not trying to be offensive. At the end of the day we just want our designs to work. 

 Jake

[Altera_Forum]

Dear Jak 

 External reset is not the current issue at all. It is the internal reset.  Powerup reset of vendors is available and necessary and opinion is given on how to best use it.   Similarly, there was once a post when somebody asked about bidirectional pins saying: can we use them as input/output at same time?   I posted first saying : No, it is either input or output according to sample moment, only one driver should be in action...   Then you stepped in saying: 1)yes, you can  2) but one driver has to be active....   I know you mean philosophically you output your own and read your own value, for fun perhaps.   what is going on...please? I am not after collecting more points Jak but trying to pass my boring time. Forgive me It is too hot here in London unlike Utah

[Altera_Forum]

Again. I appologize for upsetting you. However, I will answer your questions: 

 1 - I do understand the issue at hand regarding power-up values of registers. However, I think the discussion in the other thread went beyond helping the person who originally asked the question to implement a reliable design. I believe a reset counter is sufficient (if used properly) to ensure proper design operation. I was trying to simplify things and give the poster enough information to move on. That is why I also posted the schematic snippet. Again the goal for most people here on the forum is to develop reliable designs.  2 - I believe you are referring to this thread: http://www.alteraforum.com/forum/showthread.php?t=6032 I had a hard time understanding the original question. It seemed to me that the poster was confused as to whether he could read the port if he was driving it at the same time. It may seem remedial to you or I but it was not to him. It seems from the thread that his question was answered. I assume I interpreted his question properly but perhaps not.  3 - It's 97 degrees Fahrenheit in SLC, Utah today. Though I suspect it's not nearly as humid as London.  In closing, unless you have further questions for me, I will withdraw myself from this thread so you can continue to discuss power-up reset values. Again, I didn't mean to offend. It was a bit of ill-placed humor on my part.  Jake

[Altera_Forum]

I was curious and made a bit of research about the issue. The following might be obvious to some of the experts here, but I think it is interesting because the topic is barely covered by Altera literature. And most online references I've found are for ASIC designs, not for FPGA. 

 I assume for this purpose that the whole thing about power-up reset values not being 100% reliable, it is just a matter of the chip-wide reset being releases asynchronously.  The most important thing to take in mind is that Async Reset (or preset for that matter) must meet setup requirements as any other signal. If setup time is violated, then metastability might happen. Note that this applies both for internal or external reset. A circuit like posted by Jack must be synchronized internally, and it must be separately synchronized on every clock domain.  However, async reset release can't produce metastability if the synchronous input to the register is zero. This is because the output of the register was already zero as a consequence of reset being asserted, and then no oscillation could happen. Note btw, that async reset assertion can't produce metastability at all, only reset release needs to meet setup requirement.  This relates to FvM description of the reset counter behaviour. The async reset release on power-up might make the lowermost bit of the counter metastable. But it can't affect the higher bits because their input, at the time that reset is released, is fixed at zero. So the counters bits would perform as a synchronizer cascade, making the chances of failure extremelly small.  There is still a small issue here. If you are using a counter, then there is a direct combinatorial path between the lowermost bit and all the other bits. In an ASIC, this woudn't be a problem because the carry chain is usually implemented as AND gates that won't glitch. But here we are using a LUT, and I've never seen any official statement about LUT producing glitches or not when one signal changes state. If the LUTs on the carry chain can glitch, then the counter wouldn't perform as the best synchronizer.  Even then, chances of failure by metastability are probably extremelly small. This is not a sychronization performed constantly, but just once per power-up or global reset.

[Altera_Forum]

Thanks vjAlter for your contribution. There is some difference in focus though. 

 Let us start from the very start of fpga being powered up:   state1: power-on reset(POR) its duration is configurable through PORSEL pins.During this state all io are tristated so that nothing silly drives on (would be) output pins upsetting the neighbours around. Input drive is not shutdown(as I see).   state2: configuration(passing the data, the very fruit of the work) io stays tristated for same above reason.   state3: initialisation, uses internal clk(internal oscillator e.g. 10MHz) with option of external... needs 299 cycles in stratix. internal registers silenced under clear... io still tristated.   state4(user mode,or the party mode!) the final decision is release io and one clock later release registers (this is the default, you can change to "release registers  before tristates i.e. fpga active while still shutdown from outside).   Now let us look at the register release moment: I assume the clock input pins can be active at any time from the very start. Remember output drive is shut down but not input drive, hence (as any reset release) the initial state of register may not be known if fed by external clk. This is the case whichever option is chosen(registers released before or after tristates) the clk edge may not honour the timing at register release and the poor register stumbles.   So the problem to me is that we can't be sure about that initial zero state in the first place unless registers are clocked late after release(e.g by internal clk).   I must also point out to your view below     --- Quote Start ---   However, async reset release can't produce metastability if the synchronous input to the register is zero. This is because the output of the register was already zero as a consequence of reset being asserted, and then no oscillation could happen. Note btw, that async reset assertion can't produce metastability at all, only reset release needs to meet setup requirement.   --- Quote End ---  .   I believe this is not right according to my understanding. I also found similar view to your view in some vhdl books and posts!   My understanding of timing violation(please convince me otherwise) is that it can occur either  1) D input changing near clk edge (usual operation) 2) async reset released near clk edge(irrespective of D state), the register simply "wakes up" at a hard time"

[Altera_Forum]

--- Quote Start ---  This is the case whichever option is chosen(registers released before or after tristates) the clk edge may not honour the timing at register release and the poor register stumbles.  --- Quote End ---     It doesn't stumble. Read FvM analysis again.    --- Quote Start ---  I believe this is not right according to my understanding. I also found similar view to your view in some vhdl books and posts!   My understanding of timing violation(please convince me otherwise) is that it can occur either  1) D input changing near clk edge (usual operation) 2) async reset released near clk edge(irrespective of D state), the register simply "wakes up" at a hard time"  --- Quote End ---    It is not just my view, it is the view of top-world authorities. And it makes sense when you look at the transistor level construction of the flip-flop.  Async reset is usually implemented as two NAND or NOR gates (one on each of the master and slave latches). For simplicity let's assume an AND gate and positive logic. One input to the AND is your low active async reset, the other depending on the clock phase is the internal latched value or the input to the latch.  When you release async reset, the other input to the AND is still zero because both the output and the input to the latch/flip-flop were previously stable low. So the output of the AND doesn't change at all, and then the latch/flip-flop doesn't see any changes whatsoever (beyond the AND gate).

[Altera_Forum]

Thanks very much vjAlter and FvM, 

 I now spotted my error of thinking.  Basically what should have been said about reset release in various documents, therefore, is that a release near clk edge of launching register will affect the input of latching register if this implies a change of the signal state with respect to its state under reset.(never of launching register itself, this seems now obvious and common sense).   Hence I don't forsee now difficulty in depending on the chip powerup state to create my own reset provided I take care. The counter example will do.    The following example may be simpler  D <= '1'; process begin wait until clk = '1'; Q <= D; -- starts as 0 if not optimised away end process; my_reset <= D and not Q;    soon after configuration D is '1', while Q is '0' under chip reset any clk hits on the register will latch a '1' internally until release of chip reset. Thus I have one register(launch only, no problems).  This in effect copies the chip reset to my reset which I will use to synchronise to other internal clks.    Many thanks, it was fruitful finally.