synchronous clocks

enables to the entire design. The clock enables are user-programmable as a divider function of the input clock frequency. A second clock is generated on-chip by a hand-coded divider circuit (not a DCM), and this clock needs to be declared as synchronous to the input clock. Additionally I want the tool to time paths between flops across these synchronous domains - it is not doing this by default.

divider, we're supposed to use a DCM, but we are prototping an ASIC, and the divider is a part of that logic that needs to be proto-typed.

synchronous (2) the tool should minimize the skew between these clocks, i.e. balance the clock tree (3) the tool should time paths crossing the two synchronous clock domains

====================== If you use a clock to drive a divider (let's hope it is a synchronous divider) then the output of this divider will be one clock-to-Q flip-flop delay delayed from the original clock. Only a DCM or PLL can do anything about that fact. The question is, can you live with two clock domains, one of which is delayed from the other?

At best, the delay cuts into your timing margin, and thus lowers the max possible clock frequency. At worst, a flip-flop driven by the late clock receives input data from a flip-flop driven by the early clock. That can (will) create a hold-time violation, which in turn can lead to a race condition and upset your circuit hopelessly, and it would do that at any clock frequency, even a very low one. So, beware of mixing clock domains, even in an ASIC. There are tricks around this, like clocking on the opposite clock dge, but they require a good undestanding of all the timing relationships. Peter Alfke, Xilinx Applications

enables to the entire design. The clock enables are user-programmable as a divider function of the input clock frequency. A second clock is generated on-chip by a hand-coded divider circuit (not a DCM), and this clock needs to be declared as synchronous to the input clock. Additionally I want the tool to time paths between flops across these synchronous domains - it is not doing this by default.

divider, we're supposed to use a DCM, but we are prototping an ASIC, and the divider is a part of that logic that needs to be proto-typed.

synchronous (2) the tool should minimize the skew between these clocks, i.e. balance the clock tree (3) the tool should time paths crossing the two synchronous clock domains

Not necessarily true. The standard solution in an ASIC is to tell your clock tree synthesis tool the structure of your clock divider and let it balance the clock for you. There are some CTS tools which are really good in the sense that they can understand pretty complicated clock generation schemes ie not only straight dividers but a counter which generates clocks at different edges etc (500 MHz to 10, 20, 50,

100 MHz clocks etc) and move all the necessary registers in the clock tree to get a nice balanced clock tree. Even if your CTS doesn't support this automatically you can get it done manually after CTS.

Another issue with your description is that any STA tool worth its salt would trace both source and receiver clocks and tell you if you're hitting any of these problems which is necessary to do even with no divided clocks. Of course in an FPGA things are more complicated as the clock tree is already generated and clk->Q delays are quite a bit worse than an ASIC at the same process.

to the entire design. The clock enables are user-programmable as a divider function of the input clock frequency. A second clock is generated on-chip by a hand-coded divider circuit (not a DCM), and this clock needs to be declared as synchronous to the input clock. Additionally I want the tool to time paths between flops across these synchronous domains - it is not doing this by default.

we're supposed to use a DCM, but we are prototping an ASIC, and the divider is a part of that logic that needs to be proto-typed.

synchronous (2) the tool should minimize the skew between these clocks, i.e. balance the clock tree (3) the tool should time paths crossing the two synchronous clock domains

If the issue is that the ASIC tool can generate the two clocks synchronously (by balancing the clock trees) but the FPGA can't, then why not put a compensating delay in the HF clock? For example by using a DCM in phase shift mode, to match the delay of the divider - and use the delayed clock for the remainder of the logic.

Wrap the delay in a "clock buffer" block so that it conceptually matches the reality of the ASIC.

The delay can either be fixed (in which case you'll need to know it in advance, or iterate to find it) or adjustable (which would require differing connections from the ASIC). Alternatively use a DCM to multiply up the divided clock to regenerate the divider's input, but synchronised to the divider output using clkfb.

- Brian

Peter, mixing clock domains (i.e. having multiple clock domains) is part of most digital designs. I'm surprised to see such an answer from a Xilinx engineer. I prefer the other two options stated here by other engineers, but I guess the answer to my question really is to use a DCM and control delays through it rather than a hand-coded divider?

I'd still want to know if the Xilinx P&R tools could automatically handle the routing/buffering of the clock tree such that the skew between clocks declared as synchronous will be minimal. In my case, I see skew of upto 5 ns.

most digital designs. I'm surprised to see such an answer from a Xilinx engineer. I prefer the other two options stated here by other engineers, but I guess the answer to my question really is to use a DCM and control delays through it rather than a hand-coded divider?

routing/buffering of the clock tree such that the skew between clocks declared as synchronous will be minimal. In my case, I see skew of upto 5 ns.