Implementation and Timing of Reset Circuits

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.

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

Hi,

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

kaz

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

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