Crossing clock domains, PLL and TimeQuest

There are two cases: either the clocks are synchronous to each other or they're asynchronous.

Being synchronous means that the relative position of their edges is known or can be calculated with a limited uncertainty and thus, TimeQuest can analyse the timings.

Being asynchronous means that relative position of the edges is not known, so TQ can't analyse the timing.

To know if two clocks are synchronous or not, you need to figure out if you can know where their relative edges are or not.

PLL output clocks are synchronous to their input clock. Even if you use two different internal PLLs feb by the same input clock, their outputs are synchronous to the input and among themselves.

On the other hand, two clocks from two different crystals are asynchronous. Even if they have the same nominal frequency, their frequency won't be exactly the same and their relative phase will be unknown.

Asynchronous clock are harder to deal with but simple to summarize: you're working without safety net. You have no timing analysis there and your design may suffer meta-stability.

What you need to do is to design using proper asynchronous clock domain crossing techniques to minimize meta-stability, such as a DCFIFO with 2 or more stages or synchronizer register chains.

And you need to use exclude those paths from timing analysis using set_false_path or set_clock_groups, as any analysis of them would be non-sense (and it also prevents Quartus from recognizing synchronization register chains).

Synchronous clocks, which is your case, is simpler to use: TQ can analyse the timings and you can trust it.

All you need to do is to constrain the clocks properly. Which in case of internal PLLs, means adding derive_pll_clocks and derive_clock_uncertainty to the .sdc.

Now, having a properly constrained design doesn't mean it will get timing closure, which is what you're experiencing.

To fix those setup failures, you need to look at the failing paths timing and logic.

Maybe you need to add some registers to the design to split the worse paths. Or maybe you need to set some multi-cycle exceptions to relax the timings requirements on those paths.

If you think you can add multi-cycle exceptions, take a look at this:

http://www.scribd.com/doc/14475172/multi-cycle-paths