Timequest and ripple clocks ... how to set up?

[Altera_Forum]

I have a set of ripple clocks. Yes, I know, don't do that, but we seem to get a decent power savings vs enables. 

 Now, I hope I'm not insane. I have a main global clock at 320MHz coming off the PLL, and I divide it down by various factors. So, lots of division, but all the derived clocks start at a flop that is clocked by my main global clock before going out.   --------------- ------- |Divider logic| -----> |D Q|-----> clk_160MHz, clk_80MHz, clk_16MHz, etc. --------------- | CLK | ------- ^ | global_clk(320MHz)   So, I use create_generated_clock to create clk_160MHz, clk_80MHz etc. Source is the global PLL clock and I divide that down. That all seems to work fine. Paths that go from clk_160MHz to clk_160MHz, clk_80MHz to clk_80MHz, etc. seem to work and all meet my requirements without much issue.  However, the moment I have a path that originates from a flop clocked by clk_160MHz and terminates in a flop clocked by clk_80MHz, Timequest starts putting in all manner of clock skew and sometimes misses setup and hold constraints. This is true even if the path is literally flop-to-flop with no logic in between (I could see missing hold, but *setup*?). This is especially bad if I try to go from a flop clocked by 80MHz moving to 160MHz or 160MHz moving back to the global clock at 320MHz.  Why? All the edges are generated from global_clk. The skew should *at maximum* be a little uncertainty + a clock to Qdelay + some routing. Certainly nothing that should make a direct flop-to-flop path fail.  I presume I'm missing something in my constraints. I looked in the TimeQuest User Guide and it mentions multicycle paths, but I'm a little reluctant to activate that by hand without a much clearer understanding of why I should do so. This shouldn't need a multicycle as it goes flop-to-flop with more than enough time to work even at 320MHz, right?  I included a screenshot of what TimeQuest thinks is the path. I can provide other data if you tell me what to generate.  Any suggestions or pointers? Thanks.

[Altera_Forum]

Strange. The FFS are far apart, so there will be a decent amount of delay. I think one of two things is happening: 

a) The fitter thought the hold requirement was larger(on-die variation is going to be bad for these long paths), and so it added delay to meet hold timing. One way to check this is to go to Assignments -> Settings -> Fitter and disable Optimize Hold Timing. Recompile and see if the setup failures go away. (You will have hold failures). Another thing to do is a report_timing on that path to see how much it meets hold by right now. You may have to check the other timing models to see which is worst. b) The placer thought it was going to meet setup timing, but when it routed it couldn't. It may have been confused by the long clock trees. If that's the case, you can overconstrain it by adding something like: if {$::quartus(nameofexecutable) != "quartus_sta"} {  set_max_delay -from [get_clocks *|clkdiv_160M|*] -to [get_clocks *|clkdiv_80M|*] 6.0 } This over-constrains it in the fitter but not the final timing sign-off. Note that if it's a hold timing issue where it's adding delay, you could do the opposite by loosening the hold requirement with: if {$::quartus(nameofexecutable) != "quartus_sta"} {  set_min_delay -from [get_clocks *|clkdiv_160M|*] -to [get_clocks *|clkdiv_80M|*] -0.2 }  More basic, why can't you have the PLL create multiple clock outputs? I think that would be the easiest solution as they would all be aligned nicely.  (I'm a bit surprised the clock enables are that much worse. If you used enables, you would have one global clock line toggling at 320MHz and then a lot of logic that gets enabled/disabled. With this new implementation, you still have the global toggling at 320MHz, but the 160MHz and 80MHz(and probably all of them) are feeding additional Global clock lines, which consumes a decent amount of power.

[Altera_Forum]

--- Quote Start ---  More basic, why can't you have the PLL create multiple clock outputs? I think that would be the easiest solution as they would all be aligned nicely. (I'm a bit surprised the clock enables are that much worse. If you used enables, you would have one global clock line toggling at 320MHz and then a lot of logic that gets enabled/disabled. With this new implementation, you still have the global toggling at 320MHz, but the 160MHz and 80MHz(and probably all of them) are feeding additional Global clock lines, which consumes a decent amount of power.  --- Quote End ---   I have quite a few choices for user selectable divisors, so I don't have enough PLL outputs or I would have done that. :( However, I will go back and take a look at clock enables again. It's possible that something has changed now that I have more of the system in place. I guess I should be concerned that I have done something that doesn't have an immediately obvious solution.

[Altera_Forum]

--- Quote Start ---   I'm a bit surprised the clock enables are that much worse. If you used enables, you would have one global clock line toggling at 320MHz and then a lot of logic that gets enabled/disabled.  --- Quote End ---    Whoa, but won't I have to specify multicycle setup and holds for every single path on those enabled clocks? That's going to be a nightmare for 32+ divided down clocks, no?

[Altera_Forum]

You should specify multi-cycle constraints for the clock enabled registers, but it can be automated, so it's not a nightmare. 

 Check http://www.altera.com/support/examples/timequest/exm-tq-clock-enable.html for an example.