signal transfer in different clock domains

--- Quote Start ---

CLKA & CLKB are unrelated.

Signal generated from CLKA can be used as syn-clear or syn-reset signal in CLKB domain directly, right?

--- Quote End ---

If a signal is crossing between unrelated clock domains, do not use it as a synchronous signal in the destination clock domain.

Hi, I'm newer in HDL design.

For me, the more important is 'why do in that way' but not 'how to do'.

Looking forward for more detailed info.

Thanks :)

Hello,

there are two issues when processing signals from an unrelated clock domain:

1. Metastability

2. Setup and hold time violation

Metastability can occur as additional problem with timing violation, it can be avoided, when two cascaded registers are used to synchronize signals.

Setup and hold time violation is always present when interfacing external signals from unrelated clock domains respectively arbitrary events, thus it's the general case.

Consider a synchronous register and an external signal changing it's state at an arbitrary moment. Then, with a certain likelyhood, the transition occurs within the setup/hold intervall, which means that the resulting output is indetermined. This isn't actually an issue, but if an external signals is an input to more than one register, the system as a whole can react in an unwanted way.

Consider a 4 bit synchronous up counter with the asynchronous external signal as count enable. You would expect that the counter either counts +1 or 0. But if the setup/hold timing is violatet, it could e. g. count from 7 to 1 instead of 8, cause some registers "see" the count event and others don't. State machines could transition to an illegal state and at worst case be caught into it. Synchronisation of the external signal with a single register (or with two cascaded to avoid metastability) assures that all registers "see" the same external state.

If more than one signal shall be transfered consistently between clock domains, the situation is much more complicated. One solution could be gray-encoding.

Regards,

Frank

Hi Frank, thanks very much for your response.

I understand what you said. But that's not the answer what I want. :(

It's my fault, I can't describe my question more precisely.

I just wanna know how DFF's syn-reset/syn-clear and asyn-reset/asyn-clear signals work.

Maybe what I need to understand is how dff work, but I can't find related document.

Could you recommend some document for me?

Thanks again!

I find that syn-clear signal always be connected data-in pin of dff instead of sclr pin.

Any different between both circuit? I think my confusion is from the knowledge gap about how dff work.

--- Quote Start ---

I find that syn-clear signal always be connected data-in pin of dff instead of sclr pin.

Any different between both circuit?

--- Quote End ---

I understand your statement to mean that you have coded the RTL in a way that you think describes a synchronous clear signal, but when you look at post-synthesis or post-compilation results you see that the signal actually feeds the register D input directly.

This is a normal situation. Synthesis in the Analysis & Synthesis step and physical synthesis in the Fitter step can rearrange the signals as long as the functionality is preserved. For device families that support synchronous clear and synchronous load, the function of a synchronous clear can be implemented by using synchronous clear directly, by synchronously loading in a zero, or by making the D input low.

Using the D input gives the Fitter more flexibility. If you look in the device handbook in the section that describes the LAB control signals, you will see that you have a limited number of special signals like synchronous clear for the entire LAB. Cyclone III, for example, can have one synchronous clear and one synchronous load in the same LAB. Let's say your RTL described three separate synchronous clear signals for reg_a, reg_b, and reg_c. Quartus could implement the one for reg_a with a true synchronous clear and implement the one for reg_b with a synchronous load of zero. In order for the Fitter to place all three of these registers in the same LAB, the synchronous clear functionality for reg_c would have to be implemented by holding the D input low. If all synchronous clears in the RTL were implemented using the D input, the Fitter would have the most flexibility possible for deciding which registers to place in the same LAB.

Quartus tries to be intelligent in the trade off between using the special LAB control signals and giving the Fitter flexibility. You can prevent use of the synchronous clear and synchronous load LAB control signals by turning off "Allow Synchronous Control Signals" project wide or on a specific part of the design. I don't remember whether I've come across a method to force the LAB control signals to be used other than describing the register at a very low level using a WYSIWYG primitive (there is documentation for that, I think in an app note or user guide outside the Quartus handbook).

Hello,

basically, you won't find a FF with a separate synchronous clear or set input, cause it's function couldn't distinguished from D input operation. With conventional digital logic devices (74LS, 74HC, 4000er series, whatever), you will find synchronous set/reset only with more complex circuits, e.g. counters or shift registers. Logic devices datasheets could be also a source of information besides electronic textbooks.

A useful internet resource is lessons in electric circuits, volume iv - digital

www.ibiblio.org/obp/electriccircuits

Regards,

Frank

--- Quote Start ---

basically, you won't find a FF with a separate synchronous clear or set input, cause it's function couldn't distinguished from D input operation.

--- Quote End ---

But at the FPGA LE or ALM level, signals like synchronous clear do exist as separate LAB control signals as discussed in my previous post. Many or all device family handbooks have a figure showing how the LAB controls signals relate to the actual flip flop, and the Resource Property Editor diagram should show that detail for at least all LUT-based devices. The actual register might have only a D and clock enable input for the synchronous inputs, but from the user's perspective the LAB control signals like synchronous clear are distinct register inputs.

A way for David to see this is to list registers in the Node Finder, right click one of the registers, locate to the Resource Property Editor, and look at how the synchronous LAB control signals get combined into the D input inside the LE or ALM. (If the particular register being looked at didn't use those LAB control signals, the resources for them will still be shown, just grayed out.) The equivalent functionality like the mux and AND gate shown for Cyclone III can be accomplished inside the LUT(s) in front of what is listed as the register primitive D input in the equations; that's when the equations look like a synchronous clear is feeding the D input.

Brad is right.

The best way to solve a practical problem like this is to see the actual result.

Thanks for Brad for telling us where to see the actual result.

Brad is right.

The best way to solve a practical problem like this is to see the actual result.

Thanks to Brad for telling us where to see the actual result.