Synchronous Clocks

clocks in the design are synchronous, and so the clock tree needs to be built with that in mind?

Normally you can use FROM :TO style of timing constraints to inform the tools of the required time from active edge of one clock to another. If you have signals crossing the clock boundaries in both directions you would need two FROM : TO timing specs. If in addition you use more than one edge of the clocks you may need more specs.

example: NET "x1_clock" TNM_NET = "x1_clock"; NET "x2_clock" TNM_NET = "x2_clock"; TIMESPEC "TS_1x_2x" = FROM "x1_clock" TO "x2_clock" 1.75 ns; TIMESPEC "TS_2x_1x" = FROM "x2_clock" TO "x1_clock" 2.75 ns;

That being said, if the clocks are generated on chip, for example using DCM's, the tools will automatically generate the required timing specs based on the PERIOD time spec of the source clock.

HTH, Gabor

clocks in the design are synchronous, and so the clock tree needs to be built with that in mind?

What do you mean by synchronous? Typically, this means you derived one clock from the other, or both clocks from a master oscillator.

Unfortunately, you still can't consider the resulting clocks "synchronous" anymore. They may be frequency locked, but you can't guarantee phase lock without careful design analysis. You can generally clean up the situation with careful use of DCM's, but even then, use care when crossing boundaries.

I have seen a lot of designs fail due to improper treatment of clocks. As a result, I treat every boundary crossing as asynchronous, and tweak the crossing logic based on the measured phase relationship between the clocks.

clocks in the design are synchronous, and so the clock tree needs to be built with that in mind?

You can also specify an amount of clock jitter which translates into a clock uncertaintity which the router will take into account. It does tighten the timing budget.