Negative Slack after constraing the clocks

[Altera_Forum]

Hello, 

 I have a design with a couple clocks that i constrained on TimeQuest, but they still show negative slack on Hold.  I ran the analysis and synthesis first, then ran TimeQuest, checked the box for running "Post Mapping" and "Zero IC Delay". Does that mean that my clocks won't work in this design?   My SDC file:    --- Quote Start ---  #**************************************************************# Time Information# **************************************************************  set_time_format -unit ns -decimal_places 3 # **************************************************************# Create Clock# **************************************************************  create_clock -name {inclk} -period 20.833 -waveform { 0.000 10.416 } [get_ports {inclk}] create_clock -name {hbi_clock_generator:inst23|counter:counter96MHz|lpm_counter:LPM_COUNTER_component|cntr_c3i:auto_generated|safe_q[1]} -period 41.667 -waveform { 0.000 20.833 } [get_registers { hbi_clock_generator:inst23|counter:counter96MHz|lpm_counter:LPM_COUNTER_component|cntr_c3i:auto_generated|safe_q[1] }] create_clock -name {hbi_clock_generator:inst23|counter:counter96MHz|lpm_counter:LPM_COUNTER_component|cntr_c3i:auto_generated|safe_q[0]} -period 20.833 -waveform { 0.000 10.416 } [get_registers { hbi_clock_generator:inst23|counter:counter96MHz|lpm_counter:LPM_COUNTER_component|cntr_c3i:auto_generated|safe_q[0] }] create_clock -name {spi_clk} -period 20.833 -waveform { 0.000 10.415 } [get_ports { spi_clk }] create_clock -name {hbi_clock_generator:inst23|inst} -period 250.000 -waveform { 0.000 125.000 } [get_registers { hbi_clock_generator:inst23|inst }] create_clock -name {hbi_clock_generator:inst23|counter:counter48MHz|lpm_counter:LPM_COUNTER_component|cntr_c3i:auto_generated|safe_q[0]} -period 41.667 -waveform { 0.000 20.833 } [get_registers { hbi_clock_generator:inst23|counter:counter48MHz|lpm_counter:LPM_COUNTER_component|cntr_c3i:auto_generated|safe_q[0] }] # **************************************************************# Create Generated Clock# **************************************************************  create_generated_clock -name {pll|altpll_component|pll|clk[2]} -source [get_pins {pll|altpll_component|pll|inclk[0]}] -duty_cycle 50.000 -multiply_by 2 -master_clock {inclk} [get_pins {pll|altpll_component|pll|clk[2]}]     --- Quote End ---    PS: is there a tag for code in this forum?

[Altera_Forum]

You can't trust the results post-synthesis, especially with zero IC delay. Hold violations are because a signal is too fast, and if you zero out the IC delays, your making it faster than it will ever really be. I find post-synthesis TimeQuest useful for setting up my .sdc, making sure there are no syntax errors, making sure it's analyzing the things I want correctly, i.e. how paths will be analyzed, not whether or not they meet timing. Then I run a full compile to look at the fit results. 

I see you're doing create_clock on the outputs of counters. create_clock will act as if the clock starts exactly at that point. This is fine for analyzing the domain by itself, but if you want to know its relation to other domains, i.e. if you have a path going from ...safe_q[1] to ...safe_q[0], you won't get the correct analysis because the clock path before these registers are completely ignored. If you want the clock tree up to that point analyzed, use create_generated_clock. - Why not use derive_pll_clocks instead of manually entering the generated clock assignments? - There is no set_clock_groups, so all your clocks are related and any paths between them will be analyzed. This might be what you want, but you may get errors on paths crossing domains that you don't care about.

[Altera_Forum]

--- Quote Start ---  You can't trust the results post-synthesis, especially with zero IC delay. Hold violations are because a signal is too fast, and if you zero out the IC delays, your making it faster than it will ever really be. I find post-synthesis TimeQuest useful for setting up my .sdc, making sure there are no syntax errors, making sure it's analyzing the things I want correctly, i.e. how paths will be analyzed, not whether or not they meet timing. Then I run a full compile to look at the fit results. I see you're doing create_clock on the outputs of counters. create_clock will act as if the clock starts exactly at that point. This is fine for analyzing the domain by itself, but if you want to know its relation to other domains, i.e. if you have a path going from ...safe_q[1] to ...safe_q[0], you won't get the correct analysis because the clock path before these registers are completely ignored. If you want the clock tree up to that point analyzed, use create_generated_clock. - Why not use derive_pll_clocks instead of manually entering the generated clock assignments? - There is no set_clock_groups, so all your clocks are related and any paths between them will be analyzed. This might be what you want, but you may get errors on paths crossing domains that you don't care about.  --- Quote End ---    Thanks for the reply, Rysc.  I haven't constrained any paths yet and i made the clock constrains using the Reports Clocks report window, then i right clicked them and went to "Edit Clock Constrains", it generated the pll that way. Is it better to use derive_pll_clocks?  All my clocks are generated from the PLL clock of 96MHz, so they are related. The only clock that is not related is the spi_clock, which comes from a SoC master. Should i declare it differently?  I'll run the full compilation to see if the hold delays goes away. Thanks for helping me, i'm still learning about FPGAs and how to use TimeQuest.  EDIT: i only ran the time analysis after the post syntesis because the TimeQuest Training states that this is the normal design flow.

[Altera_Forum]

[QUOTE=Rysc;178810 

- Why not use derive_pll_clocks instead of manually entering the generated clock assignments?   --- Quote End ---   Hi Rysc, This is somewhat OT here, but I take advantage of your comment to ask your expert advice on this subject. I often chose the create_clock command instead of derive_pll_clocks in order to define the clock domains with simple mnemonic names: i.e. clk50mhz whereas derive_pll_clocks would have generated obscure names like inst5|altpll_component|auto_generated|pll1|clk[0] I've never used TQ extensively, since i focused mainly on other fpga design issues, so I never inquired if there was a better way to do this, still exploiting the automation offered by derive_pll_clocks. I think it's possible. But how?

[Altera_Forum]

Rysc, 

 I compiled my design an ran TimeQuest again with the same SDC file. There are still violations:    --- Quote Start ---  Setup violation on: pll|clk[2]: -4.961 slack, -777.139 End Point TNS  Hold violation on: pll|clk[2]: -4.464 slack, -12.867 TNS, 48MHz....safe_q[0]: -0.610 slack, -0.610 TNS, 96MHz....safe_q[0]: -0.007 slack, -0.007 TNS   --- Quote End ---   How do i solve these? Should i put constraint on the paths? There are a lot of Failing Paths for the pll.  EDIT: I solved the Hold violations by putting a Multicycle constraint of 1 cycle between the clocks. The Setup violation is between Nodes, and a lot of nodes, instead of clocks, should i use the same multicycle approach?