multiple clock domain issues

Few doubts I would like to get clarified,

  1. Weather synchronizers are required for control signals only or for data signals also?

  1. Internal to FPGA, suppose 2 different clock domains are there - do signals crossing from one clock domain to another need synchronizers? or can we avoid synchronizers by applying some constraints? If yes, what are these contraints(in xilinx)?

  2. How can we decide on a false path? suppose one signal is crossing from one clock domain to another can be declared as a false path?

  1. Is it OK to have negative hold time(

Reply to
Loading thread data ...

Depends. Asume a 8 bit datapath, can you guarantee, that data is stable while crossing the domains? What effect may corrupted data have on your design?

Usually yes, unless you manage to bring them in phase (eg. with PLL).

If timing is no issue, like databus if hand shake signals ensure the data is stable while crossing the domains.

Reply to
Thomas Stanka

If you need to guarantee that all data bits will be valid at the same time as control signals are applied and the control signals do not provide such a guarantee (handshake or other such), you will need to synchronize the data somehow. This is commonly done with asynchronous FIFOs.

Domain-crossing must be handled by logic, constraints cannot do anything about it. If the two clocks are related by DCM, the synthesis tools are often capable of figuring the constraints out by themselves but this may still require logic if the clock ratios may lead to close cross-domain clock edges.

Yes... but only if momentarily invalid data will not cause a design malfunction. For example, I built a display engine and the registers to configure the display line and column count are routed as false paths between my control bus clock and display engine clocks because the worst-case side-effect is a one-frame display glitch, which is completely insignificant since the display's PLL will need a few seconds to lock on the new timings.

Negative slack indicates that your design failed to meet your timing targets. There is no guarantee that the design will work correctly. Even if it does work on the testbench, it may become unstable with minute variations across devices, supply voltages, aging and operating temperature.

Jitter is a random variation around an average period or offset, it is caused by variations in the transistors' switching characteristics which are themselves caused by numerous factors like electromagnetic noise, supply voltage and temperature. Skew is a constant (in theory) delay mismatch caused primarily by uneven path lengths.

Since DCMs add a fair amount of jitter and require low jitter to work properly, it is likely that your cascaded DCM will fail to lock due to compound jitter, you will most likely have to use some other external clock source. I tried cascaded DCMs with V2P a few times but the second DCM never locked on, you may have more luck with the V4.

Reply to
Daniel S.

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.