PLL locking and reset generation in Cyclone III

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

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

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.

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

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