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

kaz1 said:

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.

Click to expand...

I don't think this is correct. The latest Intel "Design Practices" recommend the use of a standard asynchronous assert, synchronous de-assert reset. See this link:

These resets are asynchronously asserted and synchronously deasserted.

Click to expand...

Intel call this "synchronized asynchronous reset". I call it "asynchronous reset" (but not "fully asynchronous reset", which is never used in a synchronous system).

weetabixharry said:

I don't think this is correct. The latest Intel "Design Practices" recommend the use of a standard asynchronous assert, synchronous de-assert reset. See this link:



Intel call this "synchronized asynchronous reset". I call it "asynchronous reset" (but not "fully asynchronous reset").

Click to expand...

yes true, that is extra functionality that will help reset if clock is not available

kaz1 said:

I hate to drag on further on this thread... but I find it useful to correct your wording.

Click to expand...

I think you are only "correcting" what has been completely clear in the discussion. If not for all contributors, I apologize for causing confusion.

I consider synchronous reset what is designated sclr in the below logic element schematic and asynchronous what is designated aclr. As already discussed, aclr is typically used for initial reset and need to be released synchronous to the register clock to avoid undefined logic states.



Regarding the "wasting resources" discussion, there are apparently differences between vendors and FPGA families.

FvM said:

Regarding the "wasting resources" discussion, there are apparently differences between vendors and FPGA families.

Click to expand...

The diagram you showed looks in many ways extremely similar to Xilinx. If "LAB Wide" means "Slice Wide", then control signals are shared, just like in Xilinx slices.

Therefore, similar to Xilinx, I think a synchronous reset could be implemented in 2 ways: using SCLEAR, or by including the synchronous reset signal as another input to the 4-input LUT.

Therefore, I think efficient packing into slices may be possible in Intel if synchronous resets are used. This is not possible if asynchronous resets are used.

EDIT: For Intel, it sounds like there is a more significant performance penalty for the "MUX reset" method:

There are two methods by which a reset signal can reach a register; either by being gated in with the data input, or by using an LAB-wide control signal (synclr). If you use the first method, you risk adding an additional gate delay to the circuit to accommodate the reset signal, which causes increased data arrival times and negatively impacts setup slack.

Click to expand...

And they don't seem to mention any resource savings. (Although Intel documentation usually fails to mention almost everything, in my experience). So it's not clear if this is due to a problem in silicon, or in their build tools.

Source: Intel Recommended Design Practices: Use Synchronous Resets

When reset is released, you want the synchronizer output to be equal to the D input.
Otherwise there can be a "false" edge on the synchronizer output, that doesn't correspond to an input edge.
The simplest way to achieve this is to don't use reset for the synchronizer registers.
This means that the synchronizer starts working before reset is released, which is fine.
Nothing will be better by connecting the reset input.

I observe that "Real Digital People" have a nearly religious aversion
to asynchronous resets in general, and don't like the politics involved
in going against the state religion (as enforced by their Methodology
Harpies).

Whether there's any actual reason outside of tool incapability or
management not having your back, I couldn't guess.

dick_freebird said:

I observe that "Real Digital People" have a nearly religious aversion
to asynchronous resets in general, and don't like the politics involved
in going against the state religion (as enforced by their Methodology
Harpies).

Whether there's any actual reason outside of tool incapability or
management not having your back, I couldn't guess.

Click to expand...

An asynchronous reset occurring too close to the clock edge can cause the flip-flop output to go metastable. That’s a bad thing. It’s not religion or politics; it’s technology.

Signed,
The Real Digital People

barry said:

An asynchronous reset occurring too close to the clock edge can cause the flip-flop output to go metastable.

Click to expand...

Yes... I'm not sure how we got reduced to stating the obvious.

And that doesn't just apply to resets. Everything else in a synchronous system is synchronous for a very good reason. This isn't some agenda.

In the special case of a reset, in some cases, it is worth investing extra effort to deal with the disadvantages of an asynchronous reset in order to get access to its one major advantage: it can be asserted without its clock running. We can talk about other minor device-specific considerations, but that's it in a nutshell.

barry said:

An asynchronous reset occurring too close to the clock edge can cause the flip-flop output to go metastable. That’s a bad thing. It’s not religion or politics; it’s technology.

Signed,
The Real Digital People

Click to expand...

Similarly synchronous reset occurring too close to the clock edge can cause the flip-flop output to go metastable. This is because it is not synchronous except by name unless it arrives synced.

Too close needs be checked by timing tool. To do that it needs the incoming signal(call it sync or async) to be generated in a known way otherwise you get a false timing pass as the path is left unchecked.

It is up to you to connect it to FF port as you see best.

The notion of losing clock and so losing reset assertion may be valid but I can power cycle if my reset button fails. well if practical, or use reset bridge if it works-I am not sure.

compare: D input is pre-synced by launch register before arriving at latch. This same concept needs be applied to any incoming signal joining the fun around FF.

weetabixharry said:

Yes... I'm not sure how we got reduced to stating the obvious.

Click to expand...

Wait, what??

Your initial comment was :”I am not aware of any reason why a 2 flip-flop (or N flip-flop) synchronizer should not have a reset.”

On another hand your test engineer will hate you if your outputs are non-deterministic by one or two clocks (as can be the case in your two stage non-initialized sync-as-pipeline).

From an outsider perspective, I think the original question could not be properly answered without knowing the exact application/need. There are general good practices which could be disregarded here or there to achieve specific objetives.

This thread is not getting any closer to answering my question.

I received a more focused answer to the same question here: link. I will close this thread by summarizing the answer I received there:

There is no drawback. There could be scenarios where a reset is required in a 2FF-synchroniser, particularly in ASIC designs. Consider this case: the design in the destination clock domain is reset asynchronously, without its clock running, and then reset is released (still without the clock running). Later, the destination clock starts. The first two clock cycles could then propagate an unknown value from the 2FF-synchroniser. What if this is '1', and '1' means "launch the missile", then this is potentially dangerous. But if the synchroniser was reset along with the design, this could have been avoided. So, having a reset in a 2FF-synchroniser cell gives the designer one way of handling scenarios like this.

Click to expand...