[SOLVED] Why don't 2 flip-flop synchronizers have a reset?

Hi,

they focus on the synchronizer function. And the synchronizer doesn´t necessarily need a reset.
But you are free to add any function (like RESET) you want ...

Klaus

What is your reason for adding a reset to the circuit?
I see no valid reason to need one.

crutschow said:

What is your reason for adding a reset to the circuit?
I see no valid reason to need one.

Click to expand...

The reason to add a reset would be so that the flip-flops can be either set or cleared when a reset signal is applied.

I can think of plenty of cases where this would not be necessary, and some where it would. For one example, what if the destination clock is not running? An async reset would be able to force a safe state.

weetabixharry said:

I can think of plenty of cases where this would not be necessary, and plenty where it would.

Click to expand...

So what are you specifically asking?

FvM said:

So what are you specifically asking?

Click to expand...

• Is there some problem/drawback with resetting a 2 flip-flop synchronizer?
• Is the answer the same for both synchronous and asynchronous (i.e. asynchronous assert, synchronous de-assert) resets?

I see you are mixing up between two concepts.
1) double synchroniser, used for any signal path when crossing clock. Including synchronising reset signal. This does not need reset.
2) reset synchroniser (reset bridge), a specific version is advised as below . The claim is that it is better if clock has stopped when you want to reset.

As to synchronous/asynchrounous: this is to do with how you apply reset to a register. The reset must pre-synchronised then you choose wiring it through D synchronous port or to async port of flip. Intel prefers async port as it reduces to just routing. Xilinx prefer synchronous port (wastes logic at D input).
In either case the reset signal itself must be pre-synchronised then wired...

With modern FPGAs the focus has moved to clock routing at expense of reset routing and it is common for reset routing to fail on either async port (recovery/removal) or on D port side (setup/hold). so yes apply it when needed such as control signals.

kaz1 said:

I see you are mixing up between two concepts.
1) double synchroniser, used for any signal path when crossing clock. Including synchronising reset signal. This does not need reset.
2) reset synchroniser (reset bridge), a specific version is advised as below . The claim is that it is better if clock has stopped when you want to reset.

Click to expand...

No, I didn't mix anything up. My question is nothing to do with reset synchronization.

I'm asking about a 2 flip-flop synchronizer and whether there is any potential drawback to resetting those registers (whether you think there may be a reason to do that or not).

weetabixharry said:

No, I didn't mix anything up. My question is nothing to do with reset synchronization.

I'm asking about a 2 flip-flop synchronizer and whether there is any potential drawback to resetting those registers (whether you think there may be a reason to do that or not).

Click to expand...

You’re asking a question in a vacuum. Is your reset synchronized (synchronous de-assert?). If your reset signal is asynchronous you might get a glitch. You need to read the specs on your flip flops.

weetabixharry said:

No, I didn't mix anything up. My question is nothing to do with reset synchronization.

I'm asking about a 2 flip-flop synchronizer and whether there is any potential drawback to resetting those registers (whether you think there may be a reason to do that or not).

Click to expand...

If your focus is just the 2 flip flop synchroniser then there is no point applying reset as the design is just a bridge so the sync/async question is not valid.

You don't need add reset burden on synchroniser as its purpose is act as bridge between two clocks. Any required reset will be within its clock domain.

barry said:

You’re asking a question in a vacuum. Is your reset synchronized (synchronous de-assert?). If your reset signal is asynchronous you might get a glitch. You need to read the specs on your flip flops.

Click to expand...

I specifically asked in my original post if the nature of the reset has an impact.

In my experience, a fully asynchronous reset is absolutely never used in a synchronous system. If a reset synchronizer is used to synchronize de-assert, then (in the majority of my experience) this is still referred to as an asynchronous reset, due to the asynchronous assert. Only a fully synchronous reset (both assert and de-assert) is referred to as synchronous (in the majority of my experience).

I am only stressing this point because I am fully aware that there is a huge split in naming conventions. Roughly half of all humans call my "asynchronous" reset "synchronous", the other half call it "asynchronous".

So, I agree with your comment that a fully asynchronous reset could be problematic (because it could be on any flip-flop in any synchronous system). My question was whether there is any specific drawback to connecting a synchronous/asynchronous (but not fully asynchronous) reset to the specific flip-flops in my diagram.

kaz1 said:

You don't need add reset burden

Click to expand...

My question is: what is this burden? What are its consequences?

The distinction between "synchronous" and "asynchronous" reset refers to FF circuits rather than their generation method. A synchronous reset input is processed on the active clock edge, an asynchronous reset is a combinational input and acting independent of the clock.

weetabixharry said:

My question is: what is this burden? What are its consequences?

Click to expand...

Timing failure...
in a dual synchroniser you already have timing failure due to clocks and you want to manage that. So why add reset and sync it to each clock domain as long as you apply reset elsewhere in the two clock domains.

FvM said:

The distinction between "synchronous" and "asynchronous" reset refers to FF circuits rather than their generation method. A synchronous reset input is processed on the active clock edge, an asynchronous reset is a combinational input and acting independent of the clock.

Click to expand...

That is true but the term covers either way.
The async port ignores clock edge. So one can force the signal to change at clock edge at generation (pre-synchronised).
The sync port is the D input so any logic around it will be seen only at clock edge.

Hi,

I see one drawback of synchronous assertion:
It does not work if the clock is missing. Maybe at power up when the clock oscillation voltage is too low...


Klaus

KlausST said:

Hi,

I see one drawback of synchronous assertion:
It does not work if the clock is missing. Maybe at power up when the clock oscillation voltage is too low...


Klaus

Click to expand...

That brings another issue. A large number of designs in the industry use synchronous reset (wired to logic at D input). So it needs clock to reset. Thus a reset e.g. button may or may not work and this is common. Power up reset is then expected to do better.

FvM said:

The distinction between "synchronous" and "asynchronous" reset refers to FF circuits rather than their generation method. A synchronous reset input is processed on the active clock edge, an asynchronous reset is a combinational input and acting independent of the clock.

Click to expand...

The distinction typically applies to 3 things:

• The assertion of the reset signal.
• The de-assertion of the reset signal.
• The FF circuit.

kaz1 said:

That brings another issue. A large number of designs in the industry use synchronous reset (wired to logic at D input). So it needs clock to reset. Thus a reset e.g. button may or may not work and this is common. Power up reset is then expected to do better.

Click to expand...

The usual solution to this is to plan a proper resetting strategy. In a modern FPGA, the general guidelines are:

• Only reset flip-flops that absolutely need to be reset.
• Use asynchronous resets (with synchronous de-assert) only on specific flip-flops that must be reset immediately on assertion of reset (e.g. flip-flops that drive safety-critical output pins of the FPGA).
• Otherwise, always favor synchronous resets.

The many advantages of resetting as few flip-flops as possible (and only with synchronous resets, wherever possible) in modern FPGAs have been repeatedly and comprehensively extolled by Xilinx:
https://www.xilinx.com/support/documentation/white_papers/wp272.pdf
https://www.xilinx.com/support/documentation/white_papers/wp275.pdf

In fact, the first rule in Xilinx's Coding Guidelines (see p. 79 of UG901) is:
"Do not asynchronously set or reset registers."

I only partly agree with the conclusions. For the FPGA families I'm working with (mostly Altera/Intel) asynchronous reset of the logic registers that need a definded initial state (output determining registers, FSM, counters, etc.) is appropriate and the preferred resource saving method.

If a modul reset at runtime is intended, you'll use synchronous resets.

I notice that the latest post is primarily discussing the problem raised in your other thread https://www.edaboard.com/threads/why-is-a-reset-with-asynchronous-assert-safe.403789/ and has little to do with synchronizers which usually don't need a reset, as already mentioned by others.

I don't know if asynchronous resets have a large resource impact with recent Xilinx FPGA.

I have worked on several projects with Intel/Altera FPGAs, but I must admit I don't know them so well. Therefore, I won't comment as I don't want to spread incorrect information.

FvM said:

I don't know if asynchronous resets have a large resource impact with recent Xilinx FPGA.

Click to expand...

One of the articles by Ken Chapman that I linked above is titled "Get your Priorities Right – Make your Design Up to 50% Smaller".

He does immediately admit that 50% may be an exaggeration:

The ideas contained in this white paper might not yield the full 50% savings potential in your design, but should save a significant amount. A 20% reduction in size can mean your design fits into a smaller device.

Click to expand...

Some of that saving comes simply from removing as many resets as possible. Instead of routing 2 signals to every flip-flop (D+R), we should only route 1 (D). There are no dedicated routing resources for resets (at least in Xilinx), so this greatly reduces congestion. Furthermore, having one enormous top-level reset would mean an enormous fan-out (so there will also be flip-flops wasted as the synthesis tool duplicates registers in order to distribute that reset signal across the FPGA without failing timing). So removing resets also helps with this.

However, using synchronous resets also reduces resource utilization. There is a widely spread misconception about this which says exactly the opposite. But this is expertly debunked by the response from "avrumw" at this link.

The key point (at least in Xilinx FPGAs) is that there is only one way to preset/clear an asynchronous FF: via the /PRE or /CLR pin. However, there are 2 ways to set/reset a synchronous FF: either via the /S or /R pin or using a 2-input MUX in the data path:



Many people see that 2-input MUX and think "that's wasting resources!". But they are wrong. This is actually Xilinx synthesis being quite clever. Each Xilinx slice has 8 flip-flops, but control ports are shared. Therefore, a flip-flop with this MUX-based reset can be packed into the same slice as other flip-flops with independent resets. So overall slice utilization can be greatly reduced.

FvM said:

I only partly agree with the conclusions. For the FPGA families I'm working with (mostly Altera/Intel) asynchronous reset of the logic registers that need a definded initial state (output determining registers, FSM, counters, etc.) is appropriate and the preferred resource saving method.

Click to expand...

I hate to drag on further on this thread... but I find it useful to correct your wording.
Intel recommends using the async port of FF but at the same time it recommends that the signal connected to this port should arrive synchronised (what I call pre-synchronised). This allows timequest to recongnise it as timing path and then report pass/fail on recovery/removal. Thus in effect it is synchronised functionally with respect to clock before arrival but structurally wired to async port.
The same pre-synchronisation approach is needed if you connect reset through D input.

So in short any reset must arrive synced to FF clock.