Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

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

Status
Not open for further replies.

weetabixharry

Full Member level 4
Joined
Oct 9, 2013
Messages
232
Helped
69
Reputation
142
Reaction score
73
Trophy points
1,318
Location
Sweden
Activity points
3,462
I am not aware of any reason why a 2 flip-flop (or N flip-flop) synchronizer should not have a reset. However, almost every implementation I have ever seen has no reset.
  • 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?
1660401885319.png


My Search Results:​

These are the VHDL/Verilog implementations I have found and none of them have resets:
A google image search also finds dozens of circuit diagrams without resets connected (or at least without them drawn).

The only implementation I have found with a reset is the System Verilog implementation on p. 47 of this article.
 

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.
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.
 
Last edited:

So what are you specifically asking?
  • 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.

1660487217293.png
 

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

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

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).
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.
 
Last edited:

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

You don't need add reset burden
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.
 

My question is: what is this burden? What are its consequences?
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.
 

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

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

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.

The distinction typically applies to 3 things:
  • The assertion of the reset signal.
  • The de-assertion of the reset signal.
  • The FF circuit.
--- Updated ---

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.
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."
 
Last edited:

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

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.

I don't know if asynchronous resets have a large resource impact with recent Xilinx FPGA.
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.

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:

SyncMuxFF.png


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.
 
Last edited:

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

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top