--- Quote Start ---
derive_pll_clocks constraints the PLLs in a "self-contained" way. For example, if PLL clk2 output does a 2x clock, then the create_generated_clock assignment basically says, "I am 2x of whatever clock comes into the PLL". This way the first PLL doesn't need to know the name of the port driving it that you put the create_clock on, and the second PLL doesn't need to know that it's being driven by a PLL. It's designed to "just work". Without any more details, I'm assuming it's correct.
The one that that may occur is your outputs of the second PLL are not exactly in phase with the first PLL. So there will be skew on transfers between the PLLs which can cause issues. This isn't a constraint issue, but the physical design. But without more info, it's hard to say why it's failing. When you look at the failing path, does the constraint(setup relationship?) seem wrong? What about the clock skew? Once those are ruled out, it's the data path.
--- Quote End ---
Thanks - but useful as the answer is, it doesn't match my question 8-}. The first PLL drives ONLY the 2nd PLL. My problem is that if I just connect them together, and specify the input clock, and "derive pll clocks", TimeQuest seems to ignore the constraints. If I try to put the "create_generated_clock" constraints in explicitly, and comment out derive_pll_clocks - it complains of duplicate constraints (as if the derive_pll_clocks is still there).
can someone who has done this successfully show me how they did it?
Thanks!
/j
Honored Contributor
