An implementation of a clean reset signal

Hello all,

Following some discussion in these groups and reading a couple of
articles (especially the first one turning up when you google for
"asynchronous synchronous reset design techniques", it seems that the
best and the safest way to use resets in FPGA designs is to use a
special synchronizer circuit that assures that the reset of the FFs is
asserted asynchronously, but is deasserted synchronously.

The circuit is something like (kindly borrowed from the aforementioned
article):

~~~~~~~~

entity reset_synchronizer is
port
(
  clk, async_reset_n: in std_logic;
  sync_reset_n: out std_logic;
);
end reset_synchronizer;

architecture rtl of reset_synchronizer is
  signal rff1: std_logic;
begin
process (clk, async_reset_n)
begin
  if async_reset_n = '0' then
    rff1 <= '0';
    sync_reset_n <= '0';
  elsif rising_edge(clk) then
    rff1 <= '1';
    sync_reset_n <= rff1;
  end if
end process;
end rtl;

~~~~~~~~

When the asynchronous reset line enters this module, the synchronous
output can then be used as the _asynchronous_ reset of all FFs in the
design, as follows:

process (clk, sync_reset_n)
begin
  if sync_reset_n = '0' then
    ff <= '0';
  elsif rising_edge(clk) then
   ff ....
  end if;
end process;

This seems to bring the best of all worlds - all the FFs in the design
enter reset asynchronously, without being dependent on the clock, and
exit reset synchronously. The synthesis tools can analyze the path
delays for sync_reset_n and report the times and skews.

Moreover, from a talk I had with Altera support engineers - they claim
this is the recommended way to code resets in designs, and that
Altera's tools will know to route sync_reset_n via fast global
interconnects to minimize time delay and skews. And in any case,
there's a report to see for each compilation.

What does this technique lack to be the perfect solution for resets in
FPGA designs ? It seems that it evades all the common disadvantages of
conventional sync and async resets.

Thanks in advance
Eli

"Eli Bendersky" <eliben@gmail.com> wrote in message 
news:1160034231.247522.286040@m73g2000cwd.googlegroups.com...
> Hello all,
>
>
> This seems to bring the best of all worlds - all the FFs in the design
> enter reset asynchronously, without being dependent on the clock, and
> exit reset synchronously. The synthesis tools can analyze the path
> delays for sync_reset_n and report the times and skews.
>
> Moreover, from a talk I had with Altera support engineers - they claim
> this is the recommended way to code resets in designs, and that
> Altera's tools will know to route sync_reset_n via fast global
> interconnects to minimize time delay and skews. And in any case,
> there's a report to see for each compilation.
>
> What does this technique lack to be the perfect solution for resets in
> FPGA designs ? It seems that it evades all the common disadvantages of
> conventional sync and async resets.

It lacks nothing.  In fact any design that does NOT generate a synchronously 
timed trailing edge reset is 'lacking' and will eventually fail because at 
some point that trailing edge of reset will come along at a time relative to 
the clock that violates setup/hold timing requirements and cause a flip flop 
or two to go to the wrong state.  This is all assuming that the clock is 
free running (or at least running at the trailing edge of reset).

The next question to ponder is, given that the reset must be synchronized 
anyway, why use an asynchronous reset anywhere in your design (with the 
exception of course of the above mentioned synchronizer)?  People will 
pontificate on the subject but have yet to produce any coherent reason to 
prefer async or sync.  Or they will claim some logic resource advantage that 
when you test the claim is found to be baseless (in almost every case, the 
logic and performance is darn near identical).

KJ 

Eli,

I use the technique you describe for system reset, i have a 
"reset_controller" block I paste into all my designs...  One case where I 
have clear results showing that this implementation is more efficient than a 
complete synchronous reset is in some older CPLDs (XC9500).

I assume that in these devices the implementation of an asynch reset (albeit 
one that has been synchronised) comes almost for free, whereas a synchronous 
one always appears to take more to be fitted.

> Or they will claim some logic resource advantage that when you test the 
> claim is found to be baseless (in almost every case, the logic and 
> performance is darn near identical).

I am one of "them"... Haha

--fully asynchronous reset 16-bit down-counter mapped in an xc9536

Macrocells Used  Pterms Used  Registers Used  Pins Used        Function 
Block Inputs Used
16/36  (45%)       15/180  (9%) 16/36  (45%)    18/34  (53%)  23/72  (32%)

--synchronous reset same circuit as before

Macrocells Used   Pterms Used     Registers Used  Pins Used        Function 
Block Inputs Used
16/36  (45%)        31/180  (18%)  16/36  (45%)    18/34  (53%)  26/72 
(37%)

I agree macrocells & registers is the same, but obviously the routing and 
functions required to implement the synchronous reset is not easily achieved 
in xc9500s.

Ben 

Benjamin Todd wrote:
> Eli,
>
>
> I assume that in these devices the implementation of an asynch reset (albeit
> one that has been synchronised) comes almost for free, whereas a synchronous
> one always appears to take more to be fitted.
Careful when you say 'always', because you'll be wrong.  A single test
case does not imply 'always'.  Even I said "almost every case".

>
> > Or they will claim some logic resource advantage that when you test the
> > claim is found to be baseless (in almost every case, the logic and
> > performance is darn near identical).
>
> I am one of "them"... Haha
Only under some conditions, not all.  Granted, the condition might be
continued use of a particular part, or family of parts or even the
software that you use.  Try targetting an FPGA or use different front
end synthesis software and see what the differences are.

>
> --fully asynchronous reset 16-bit down-counter mapped in an xc9536
>
> Macrocells Used  Pterms Used  Registers Used  Pins Used        Function
> Block Inputs Used
> 16/36  (45%)       15/180  (9%) 16/36  (45%)    18/34  (53%)  23/72  (32%)
>
> --synchronous reset same circuit as before
>
> Macrocells Used   Pterms Used     Registers Used  Pins Used        Function
> Block Inputs Used
> 16/36  (45%)        31/180  (18%)  16/36  (45%)    18/34  (53%)  26/72
> (37%)
>
> I agree macrocells & registers is the same, but obviously the routing and
> functions required to implement the synchronous reset is not easily achieved
> in xc9500s.
You didn't post clock cycle (i.e. performance numbers) which I'm
guessing are identical or darn near.

The reason for my "almost every case" disclaimer did have to do mainly
with CPLDs since the and/or array physical implementation of those
devices is completely different than the sea of LUTs inside an FPGA.
Since this is the 'fpga' newsgroup I didn't really mention that but I
should have.  In an FPGA there is typically (but not always) a way for
the fitter to use an otherwise unused address input to the LUT in order
to implement the reset functionality.  It's a bit harder (but not at
all impossible) to come across the case where the synchronous reset
will require an extra LUT and delay....but it also does not come up
very often and I've yet to see it come up in the critical timing path
(but it might).

The thing is though depending on the device the async reset path might
lead to timing issues as well that the sync reset wouldn't, so the
'best' advice is probably that your mileage will vary each has
advantages and disadvantages in different scenarios...and that
proponents of each method have a point (unlike those "two process state
machine" guys ;)

KJ

Eli Bendersky wrote:

> What does this technique lack to be the perfect solution for resets in
> FPGA designs ?

This method is simple and works well.
Nothing is perfect, but this is an excellent default method.
The optimum design depends on how the external
reset pulse is generated.

For an fpga, I don't want to do the reset procedure
until the logic image is downloaded and the device
is active. If a cpu is handling the download AND
if the cpu and fpga use the same clock, a cpu
port could deliver a synchronized reset pulse
to the fpga with no other logic required.

Thanks for your well-researched posting.

           -- Mike Treseler

> It lacks nothing.  In fact any design that does NOT generate a synchronously
> timed trailing edge reset is 'lacking' and will eventually fail because at
> some point that trailing edge of reset will come along at a time relative to
> the clock that violates setup/hold timing requirements and cause a flip flop
> or two to go to the wrong state.  This is all assuming that the clock is
> free running (or at least running at the trailing edge of reset).

I can think of a couple of exceptions where a completely asynchronous
reset won't cause any problems:

1. A free-running counter that has no unrecoverable illegal states
(i.e. a bad state that doesn't eventually turn into a good state) and
no requirement to be immediately operational after reset.

2. An FPGA that is waiting for an external event (like a discrete input
or CPU register write) to start doing something, and the external event
happens after the reset.

I can't think of an FPGA design that I've worked on where one of those
options didn't apply.  There's also a little bit of assumption with #1
and an HDL- that the compiler doesn't do anything funny, like recognize
that a simple up or down counter in the code can be replaced by an
LFSR, in which case there can be illegal states.

So for designs that meet those options, there's no need to panic and do
a massive product recall.  Yet for current & future designs,
synchronizing the trailing edge of a reset signal is a great idea.

On Thu, 05 Oct 2006 10:34:22 GMT, "KJ" <kkjennings@sbcglobal.net>
wrote:
>The next question to ponder is, given that the reset must be synchronized 
>anyway, why use an asynchronous reset anywhere in your design (with the 
>exception of course of the above mentioned synchronizer)?  People will 
>pontificate on the subject but have yet to produce any coherent reason to 
>prefer async or sync.  Or they will claim some logic resource advantage that 
>when you test the claim is found to be baseless (in almost every case, the 
>logic and performance is darn near identical).

How about this: In an FPGA all the flops are already async (unlike
ASICs) so you're getting hit by the potential slow setup, clk->q issue
already so you might as well take advantage of it because going to
sync reset will need a mux at the input. In an ASIC, depending on the
library, adding the reset condition mux at the input of non-reset
flops may give you an advantage or not.

> The next question to ponder is, given that the reset must be synchronized
> anyway, why use an asynchronous reset anywhere in your design (with the
> exception of course of the above mentioned synchronizer)?

A purely synchronous reset requires the clock to be running for the
reset to take effect.  The async initiated reset can still initiate the
reset even though the clock may have stopped (for whatever reason).

The xilinx primitives library shows async and sync reset flops - I was
under the impression there is no performance difference between the two
for current generation Xilinx FPGA families?
 
Regards
Andrew

Andrew FPGA wrote:
> > The next question to ponder is, given that the reset must be synchronized
> > anyway, why use an asynchronous reset anywhere in your design (with the
> > exception of course of the above mentioned synchronizer)?
>
> A purely synchronous reset requires the clock to be running for the
> reset to take effect.  The async initiated reset can still initiate the
> reset even though the clock may have stopped (for whatever reason).
>

This is an important point, which the synchronizer circuit I presented
addresses. Since the reset is asserted asynchronously (take a look at
the code), all flops will get into reset even if the clock isn't
working.

HI,

Eli Bendersky wrote:
> best and the safest way to use resets in FPGA designs is to use a
> special synchronizer circuit that assures that the reset of the FFs is
> asserted asynchronously, but is deasserted synchronously.
[..]
> What does this technique lack to be the perfect solution for resets in
> FPGA designs ? It seems that it evades all the common disadvantages of
> conventional sync and async resets.

I use this style, too. But this has a few (minor) disadvantages:
- It needs additional logic
- you need a good buffering as your signal has to be distributed to
every FF in the design within one clock cycle.
- it requires the possibility to drive the asynch. reset out of a FF.
This is normaly no problem, but if you use a dedicated clock routing to
have a fast distributed reset, you _might_ encounter a problem on
exotic fpgas.
- You have some work to do, if your design uses multiple clock domains.

- You have to think about scanchains (no problem for pure fpga designs,
but a bit harder for designs  targeting asic and fpga)
- the design needs at least one additional clock cycle to recover from
reset.  

bye Thomas