Implementation and Timing of Reset Circuits

[Altera_Forum]

Most circuit designs employing FPGAs and ASICs are synchronous systems using a large number of flip-flops or registers. It is usually important that these synchronous elements are capable of starting or being returned to a known state (logic ‘1’ or ‘0’). This function is normally handled by a reset. There are usually one or more reset signals that are brought into the device and used, alone or in conjunction with additional circuitry to perform this function. This Tech Note examines the various types of resets; synchronous, asynchronous, and synchronized asynchronous with respect to their advantages and disadvantages, various techniques of implementation in FPGAs, and their proper timing analysis in Altera’s TimeQuest timing analysis engine. 

 Synchronous circuits are typically reset with one of two types of resets; synchronous or asynchronous resets. Synchronous resets are frequency synchronous with the clock domain of the registers they reset. Asynchronous resets by nature will arrive at the registers they are affecting with a non-deterministic timing relationship to the clock domain of the registers. Because of this, it is difficult to time these types of resets. A third category or resets is discussed here which, for the lack of a better name, will be referred to as synchronized asynchronous resets. These resets have some of the benefits of synchronous resets without some of their disadvantages, and they also avoid some of the pitfalls that can be associated with purely asynchronous resets. As shall be shown, for most situations, synchronized asynchronous resets are the preferred method when designing FPGA circuits.

[Altera_Forum]

Hi, 

 An interesting article, I guess you are the author.   I understand that in principle there are only two types of reset: 1)synchronous reset(gated with data) and  2)asynchronous reset(directly connected to port of flipflops)  It is also well-known that reset removal must be synchronised to its registers clock domain or else you will get problems especially as power-up differences of operation. I normally use a two stage synchroniser. The method explained in fig 16 of this article is interesting but I haven't tried it yet.   However, the article doesn't define clearly the LAB-wide synchronous reset and it implies at times that it is not gated but I assume it is also gated. I looked at the 766 pages of stratix ii handbook and there was only one occurence of synclr which was in a diagram same as your diagram. There is no mention of chip-wide reset. I have never used it and I don't know it resets the firmware only or the configuration as well.    For power-up reset, I can use internal counter that counts up to a maximum and stops and then I can do my reset work on its count values which yields a synchronous reset that is connected to asynchronous ports.   As to external reset(synchronised or not), I believe in most cases it is waste of design since you can do a nice internal reset including power-up reset as mentioned above.   Thanks for the article.

[Altera_Forum]

Actually, I am the author of this paper, so I will respond. 

 The circuit in Fig. 16 is the standard way that is used for many FPGA applications (or Fig. 20 if a PLL is involved) and is quite robust.  The implementation of the LAB-wide synchronous clear is shown in Fig. 3, and it IS gated with the data as indicated by the red circle.  The chip-wide reset is called DEV_CLR, and is seldom used by designers. It will asynchronously reset every register in the device, whether it is used or not. It will not respect your code in that if you have register that you want to be HI after reset instead of LO, it will not do that. It will also not respect the power-up setting for registers that would allow you to have a register power-up HI. Since it is an asynchronous reset, it will not take the registers out of reset synchronously to your clock(s), so it would seem that it would only be useful for single clock designs where it would have to be synchronized external to the FPGA. You can see why it is not usually used by many designers. (Also note that it will not reset the program memory, so the device does not need to be reprogrammed after DEV_CLR is asserted).

[Altera_Forum]

Hi, 

 thanks for this clarification esp. for the dev_clr as I never managed to get such info from the official industrial literature.   kaz

[Altera_Forum]

Hi all, 

 As a side note related indirectly to reset issues: One way of having a good design practice - when possible - is to use design synchronisation approach so that if things go wrong then the circuit will auto-recover.  Beginners usually depend too much on start-up conditions and in many cases their modules are passed over to new projects causing serious problems.  Synchronisation, here, refers to the events themselves not the clock. For example, somebody may design all processing of a stream depending entirely on first stream head...yet a better design is to redetect headers every frame or block ...etc and resynchronise accordingly. This includes state machines as well. This guarantees a trouble free flow.  kaz

[Altera_Forum]

Thanks for the sharing.. Very informative

[Altera_Forum]

thank you, it is very helpful!

[Altera_Forum]

--- Quote Start ---  The chip-wide reset is called DEV_CLR, and is seldom used by designers. It will asynchronously reset every register in the device, whether it is used or not. It will not respect your code in that if you have register that you want to be HI after reset instead of LO, it will not do that. It will also not respect the power-up setting for registers that would allow you to have a register power-up HI.  --- Quote End ---    Hmm, isn't power-up to high level implemented as NOT gate push-back? Wouldn't this mean that DEV_CLR would respect your power-up setting?

[Altera_Forum]

I like the synchronized asynchronous reset described in this paper, however, I don't understand the need for the 2nd synchronizer register in the implementation shown in Figure 16. Since the input to the 1st synchronizer register is tied high, there shouldn't be any metastability issues with its output. Couldn't that be used directly instead of passing through another register? Thanks.

[Altera_Forum]

There is a metastability issue on the first synchronizer if the clear signal is released too close to the rising edge of the clock. In that case the synchronizer output could oscillate between its previous state (0) and the new state taken from the input (1).

[Altera_Forum]

Very helpful! Especially about the PLL reset section which not mentioned in the QuartusII hand book.

[Altera_Forum]

--- Quote Start ---  Hi,   An interesting article, I guess you are the author.   I understand that in principle there are only two types of reset: 1)synchronous reset(gated with data) and  2)asynchronous reset(directly connected to port of flipflops)  It is also well-known that reset removal must be synchronised to its registers clock domain or else you will get problems especially as power-up differences of operation. I normally use a two stage synchroniser. The method explained in fig 16 of this article is interesting but I haven't tried it yet.   However, the article doesn't define clearly the LAB-wide synchronous reset and it implies at times that it is not gated but I assume it is also gated. I looked at the 766 pages of stratix ii handbook and there was only one occurence of synclr which was in a diagram same as your diagram. There is no mention of chip-wide reset. I have never used it and I don't know it resets the firmware only or the configuration as well.    For power-up reset, I can use internal counter that counts up to a maximum and stops and then I can do my reset work on its count values which yields a synchronous reset that is connected to asynchronous ports.   As to external reset(synchronised or not), I believe in most cases it is waste of design since you can do a nice internal reset including power-up reset as mentioned above.   Thanks for the article.  --- Quote End ---     Hi&#65292; Do the "reset removal must be synchronised " mean asynchronous reset input and synchrous reset output(or release)? Like below code implementations( and the attached block image):    library IEEE; use IEEE.std_logic_1164.all; use IEEE.std_logic_arith.all; use IEEE.std_logic_unsigned.all;  entity Rst_Async2Sync is   port (  clkin : in std_logic;  async_rst : in std_logic;   sync_rst : out std_logic   );  end Rst_Async2Sync;   architecture rtl of Rst_Async2Sync is  signal Sync_rst1,Sync_rst2: std_logic; begin process(clkin,async_rst) begin  if async_rst='1' then  Sync_rst1 <= '1';  elsif clkin'event and clkin='1' then  Sync_rst1 <= '0';  end if;  end process; process(clkin,async_rst) begin  if async_rst='1' then  Sync_rst2 <= '1';  elsif clkin'event and clkin='1' then  Sync_rst2 <= Sync_rst1;  end if;  end process; sync_rst <= Sync_rst2; end ;

[Altera_Forum]

Hi all,  

 I used asynchronous reset that is resynchronized when deasserted.  Clock is running at 200 MHz in a stratixIV (class -3) and I am quite surprised to see that some pathes are very hard to route for quartus 9.1 :  After being synchronized with the clock, reset is put on a global (about 2ns delay: seems to be ok) and even being routed on a global, there are still some 2ns delay time elsewhere in the reset path, especially when I need to reset registers that are close (or inside) io buffer. With a period equal to 5ns, it is quite hard to route these paths and when registers have inverted clock it is even impossible to route without recovery violation.  is it normal to have 2ns delay time in recovery path ? Is it due to the fact that registers to reset are inside io buffer ? Do I have move out these registers ?  Thanks a lot for your help

[Altera_Forum]

- - - - - - - -

[Altera_Forum]

Hi All, 

 When using the free-running counter to do a reset on powerup when the count reaches some value what is used to ensure the counter logic is reset to a known state before the count begins ??  If count starts from some uknown state presumable result is unpredictable.

[Altera_Forum]

Contrary to ASICs, FPGA always start in a known state. You can give a specific startup value for your counter. 

It can also be an idea to use the pll's loked signal as an asynchronous reset for your counter, to be sure you never start your design before the clocks are correct.

[Altera_Forum]

Thanks Daixiwen, 

 I'm sure you're right but this seems at odds with all that is taught about the importance of having a reset.  We are saying "not required" for the reset countdown timer :)

[Altera_Forum]

I just answered your question about having a known state at power up. I still think it's better to use an asynchronous reset mechanism, just to be sure the FPGA design isn't enabled before the clock is right and avoid possible problems due to bad timing.