Input signal synchronization

[zer0c00l]

I have a design that takes CLK A. Within this design there is a sub-block which takes CLK B. The design has a clock divider which takes CLK A and divides it by half to give CLK B which is used by the sub-block. Now I want to synchronize an external signal (coming from outside of the design) and use it in my sub-block. It won't be used in CLK A domain, and only be used in CLK B domain. Can I synchronize this external signal with a standard 2FF synchronizer in CLK A domain and just use it in CLK B domain since CLK B domain is derived from CLK A. The signal itself is relatively slow even from CLK B perspective.




In the above approach is the input signal still considered synchronized from the perspective of CLK B since CLK B is derived from CLK A

[hamster_nz]

The signals may be synchronized enough for this deisgn to work reliably.

You would need to use your tools to perform static timing analysis to confirm it is - if the relative phase of the two clocks is not favorable you may still get timing violations.

If you just use FFs to divide your clock you may not get a valid derived clock constraints, and Static Timing Analysis may fail to check it properly.

You will need to look very closely at the timing report to be sure it is accurate.

[KrudyZ]

If CLKB is just one half of CLKA then I would create a clock enable line for the sub-block using a simple toggle flip flop and run everything off CLKA.

[SiliconWizard]

The question is, why not synchronize with CLK B directly? Probably something we are missing here.

Otherwise, you'd need to tell us what the clock divider is exactly. Is it using a dedicated clock divide resource with a guaranteed phase relationship with CLK A? Is it written in pure HDL?

[nctnico]

I wouldn't implement the circuit this way on an FPGA assuming the clock divider is implemented using regular FPGA logic. The delay from clock A to B is unknown. It is also possible the clock B contains false edges due to variations in LUT  and interna delay timing.

A better way is to synchronise all internal logic to clock A.

[SiliconWizard]

Implementing "CLK B" as a clock enable of some kind, with all processes in the CLK A domain (do not even talk about a CLK B), would be the easiest way of achieving this while still using pure HDL.
In which case you'll resync the input signal to CLK A and call it a day.

[asmi]

Implementing "CLK B" as a clock enable of some kind, with all processes in the CLK A domain (do not even talk about a CLK B), would be the easiest way of achieving this while still using pure HDL.
In which case you'll resync the input signal to CLK A and call it a day.

This will only work if the reason you're using slower clock is external (say, you need to provide that slower clock to external device, or sample slower input signal), and not internal (like having too much logic for a short clock cycle, and so expanding the clock cycle to fit all that logic if you can't/don't want to pipeline it for some reason). Otherwise you'd be forced to write multicycle timing constaints, and/or  virtual clocks (on some devices you can force your logic output signals into the clock backbone, and if you treat that new "virtual" clock as asyncronous to original, you can still do a proper timing closure, even though the toolchain will likely moan and bitch at you all the way through this ordeal), which is obviously not "pure HDL", or ignoring timing errors in the slow clock domain - which is even worse option.
This "clock enable" way only works in very limited situations - like when you sample signals which are much slower than your main clock, in pretty much all other cases you are much better off using proper timing chain (like PLL/MCMM and the like). That said, I would rather invest my efforts into figuring out a way to pipeline the logic instead of introducing more internal clock domains. In most of my designs I run most of my logic in the single clock domain, and only use other clock domains when implementing some I/O interface - and even then I only run the absolute minimum logic in I/O clock domain to condition signals for passing them into/out of my main clock domain - typically via FIFO.

[radiolistener]

In the above approach is the input signal still considered synchronized from the perspective of CLK B since CLK B is derived from CLK A

No, CLKB is not synchronized with CLKA, because it's phase depends on a delay and jitter in the clock divider module, which is random.
You're needs to transfer signal from CLKA clock domain to CLKB clock domain.

But as nctnico mentioned above, there is no guarantee that CLKB is reliable and has proper phase delay, because you're generated it with custom logic instead of using PLL module.

I'm using such approach to get slow clock due to PCB layout issue, because there is no way to use PLL (the signal is connected to a usual fpga pin, so it cannot be feeded to PLL in Altera Cyclone 4), but such clock is not stable. I need a slow clock for a large and slow logic. It can work properly after one compilation, but can stops to work properly after some change in the design (even not related to this part of circuit). I didn't find the way to generate reliable clock with custom logic instead of PLL on Cyclone 4.


In order to transfer signal into CLKB clock domain, you're needs to add a second synchronizer clocked from CLKB.

Something like that:

[fourfathom]

No, CLKB is not synchronized with CLKA, because it's phase depends on a delay and jitter in the clock divider module, which is random.

Unless, for example, the CLKB divider toggles on the negative-going edges of CLKA and the synchronizer triggers on the positive edges of CLKA.  Then you will have a half-cycle of setup and hold (minus delays and jitter).  That might work reliably.

But I agree, if possible run with a single clock domain and synchronize external signals within that domain.  Where practical use clock enables rather than divided clocks.

[radiolistener]

I didn't find the way to generate reliable clock with custom logic instead of PLL on Cyclone 4. If someone knows how, please let me know. I need a slow clock for a large slow logic, but the problem is that PCB layout has clock connection to a usual pin, so I cannot use it to feed PLL.

Original external clock is 125 MHz (Ethernet GMII), but slow logic needs about 2-5 MHz. I'm using classic clock divider with a counter register. But it works unreliable and depends on compilation process.

[asmi]

I didn't find the way to generate reliable clock with custom logic instead of PLL on Cyclone 4. If someone knows how, please let me know. I need a slow clock for a large slow logic, but the problem is that PCB layout has clock connection to a usual pin, so I cannot use it to feed PLL.

Original external clock is 125 MHz (Ethernet GMII), but slow logic needs about 2-5 MHz. I'm using classic clock divider with a counter register. But it works unreliable and depends on compilation process.

The usual solutions to this problem are pipelining and/or retiming. Try splitting this "slow" logic into smaller stages which would complete in one "fast" cycle reliably, and add pipelining registers between these stages. Retiming is a method of last resort because it relies on synthesis to figure out ways to move logic around between pipelined stages, and as such can be a hit-and-miss affair sometimes.

[nctnico]

I didn't find the way to generate reliable clock with custom logic instead of PLL on Cyclone 4. If someone knows how, please let me know. I need a slow clock for a large slow logic, but the problem is that PCB layout has clock connection to a usual pin, so I cannot use it to feed PLL.

Original external clock is 125 MHz (Ethernet GMII), but slow logic needs about 2-5 MHz. I'm using classic clock divider with a counter register. But it works unreliable and depends on compilation process.

You are probably getting glitches from the logic. Did you try to resample the resulting clock using the 125MHz clock? That should get rid of glitches due to logic delay variations.

[zer0c00l]

Thanks everyone for your input. This will be implemented on an ASIC. The clock divider module is a clock gate IP