PLL locking and reset generation in Cyclone III

[Altera_Forum]

Hi everyone, 

 I'm designing a board using one Cyclone 3 part on it. I'm defining the reset circuit and some questions come to my mind. (I'm new to Cyclone 3 and FPGA so these questions may seem trivial to you. However I read carefully the handbook and cannot find straight answers.)  Here are the questions:  1. What are the usual ways of making sure all the FF's in the design have a defined value, either 0 or 1, after configuration?   2. Can this be accomplished by defining FF initial values in the configuration bitstream? If yes, how can I achieve this in vhdl?  3. If FF initial values cannot be defined in the bitstream, should the FF's be initialized by a reset signal generated by user logic? How would that reset signal be generated? Should I use an external reset generator chip (e.g. a chip like MAX825 or LTC1326) for this?  4. Is there any internal signal available, similar to the INIT_DONE optional pin, that marks beginning of user mode? (I wonder such signal could be used in a design to generate a reset that initializes the FF's.)  5. What are the typical ways of delaying FF initialization until after system clock is available and stabilized? For instance in the schenario where system clock is generated by an external source that is applied after FPGA has already entered user-mode (such source can be, for example, another board or chassis that powers up separately).  Thank you in advance for your help and answers !  Kind regards,

[Altera_Forum]

FPGAs are supplied with internal reset that is released after configuration is finished. Designers can apply reset values to their FF or set the global feature "Powerup don't care" to false. 

 The problem is that, while this in principle works, however any reset release has its own problems unless synchronised to its clk domain.   Thus a safe way is to wait for PLL to lock ..etc applying your own reset then release resets synchronised per clk domain.Your own reset can be external or even internal using some initial logic that is protected from release problems e.g. counter starting at 0 until 3 then stop and release the reset.   I normally apply raw reset to PLLs then synchronise it per clk domain and release it connected to asynchronous ports of FFs.   Additionally, I use internal feddback reset from modules just in case.   Note some people use the so called synchronous reset Vs asynchronous but I am sure synchronous is meaningless unless signal is synchronised at source and then applying it to D or Q of FF makes no difference but to resource usage...

[Altera_Forum]

Many thanks or your help kaz! 

 Although your answer is a bit concise (for a beginner) I hope I decrypted in your message a few important points about reset related issues.   I'll try to explain (in a verbose style) what I understood. I'll thank you in advance for your additional comment.  First, I understand that the FPGA ALWAYS starts with all FF reset (at 0) after configuration is finished. I also understood that users can define the initial values in the HDL code. (However, defining an initial value of 1 for a FF will be implemented by the NOT gate push-back because all FF start at 0.)  In addition, users can apply an explicit reset signal to the asynchronous clear port of FFs. This explicit reset is needed, for instance, if the clock signal is not guaranteed to be stabilized at the end of device configuration. This reset should be applied at power-up and maintained until system clock is guaranteed to be stabilized. A way for detecting clock stabilization is to monitor the "locked" output from the PLL.  Then, comes the issue of releasing the asynchronous reset signal that you point out. Therefore, when you say "<...> using some initial logic that is protected from release problems e.g. counter starting at 0 until 3 then stop and release the reset.", I ask, how do you release the reset the "0-to-3 counter" itself?   May the "0-to-3 counter" have an asynchronous reset? Would it be acceptable practice to use combinational logic using the PLL "locked" output to drive the asynchronous clear of the "0-to-3 counter"? Thus, if my understanding is correct, this counter would be the single component in the system having an asynchronous (thus, to some extent, unreliable and unsafe) reset, whilst all remaining FF in the system would have their clear input driven by the synchronized (thus, safe) counter output. Right?   I might have used a lot of wording to reformulate the same thing in your message. I'll be happy if you could confirm my understanding and drop some more comment if I got it wrong!  Thank you again

[Altera_Forum]

Hi, 

 Your understanding is more concise than my post. In principle: vendors provide the asynch reset for all registers and provided you disable powerup don't care it will be applied setting registers to zeros except those that you explicitely apply your own values at reset. Additionally designers add reset to most or (in my case) all registers so that they override afterwards.   When you apply your own reset you have the option of applying it to async port(in effect Q output) or the the D input(called synchronous). In either case the reset signal should be presynchronised to its clk.   To protect a powrup reset counter from reset release timing problems, I will do this: pass pll_lock through two registers on the clk then use last stage tas enable    clked process: pll_locked_1d <= pll_locked; pll_locked_2d <= pll_locked_1d; if pll_locked_2d = '1' then if count < 3 then count <= count + 1; end if; if count = 3 then reset <= '0'; else reset <= '1'; end if; end if;   The pll_locked may act as any async signal, hence it is synchronised first. Thus the counter is protected away from any async reset which could disturb the initial release as bit(0) changes from 0 to 1     One obvious bug is when you apply reset to pll: if the reset depends on pll output clk then the design dies in waiting.   my full reset plan road map is this:       vendor reset ----> user powre up .....above counter ........................> user feedback .... run time from modules ........................> soft reset ...optional ........................> Hw reset ...optional (use for PLL reset)   all four resets then ORed together as master reset then synchronised by two stages per clk domain   ---> reset clk1 ---> reset clk2 ...etc   finally apply reset at registers either to D (synchronous and requires extra resource) or to asynch port(requires extra routing mainly).   The demand on timing would be recovery/removal domain for async application but moves to tsu/th of clk domain if you apply it synchronously.

[Altera_Forum]

As far as I understand, asynchronous resets can make timing closure a bit more dificult. 

Thus, as much as possible, I use synchronous resets.

[Altera_Forum]

Thank you guys for your useful and prompt help. I highly appreciate.