Negative slack on TimeQuest report

[Altera_Forum]

Hello everybody 

 I'm getting some negative slack messages on TimeQuest Timing Analyzer. I have one input clock and one PLL with one clock output in my system. But all of these messages are regarding to the same signal in "From node" and "To node" fields, as follows:  slack: -0.114 From node: etcmiv_ctrl:inst|data_sent To node: etcmiv_ctrl:inst|data_sent Launch clock: altpll0:inst1|altpll:altpll_component|altpll_bo32:auto_generated|clk[0] Latch clock : altpll0:inst1|altpll:altpll_component|altpll_bo32:auto_generated|clk[0] Relationship: 0.000 Clock skew: 0.037 Data delay: 0.307  For my understanding, it sounds strange that this messages points the same signal and the same clock. What does it mean? And also, how can I fix it?  Thanks in advance for your help.

[Altera_Forum]

Hello,  

 the fact that the clock and the register is the same is perfectly normal if there's afeedback path for that register.  Ie, this would cause a feedback path.  always @ (posedge pll_clk)  data_sent <= data_sent && some_more_stuff;

[Altera_Forum]

Hi 

 Thanks for your answer. What do I have to do to eliminate this negative slack?  Thanks and regards

[Altera_Forum]

Hi, 

Check create_clock and derive_pll_clocks commands in sdc file. Have you other contraints? Clock uncertainty? Is this a setup or hold slack? Take a look at Quartus timing advisor for some hints to prevent negative slack.  Cris

[Altera_Forum]

Hi Cris 

Thanks for your help.  It´s a hold slack. My sdc file contains create_clock, derive_pll_clocks, set_clock_uncertainty and derive_clock_uncertainty, as follows:  create_clock -name {CLK} -period 20.000 -waveform { 0.000 10.000 } [get_ports {CLK}]  derive_pll_clocks -use_tan_name  set_clock_uncertainty -rise_from [get_clocks {altpll0:inst1|altpll:altpll_component|altpll_bo32:auto_generated|clk[0]}] -rise_to [get_clocks {altpll0:inst1|altpll:altpll_component|altpll_bo32:auto_generated|clk[0]}] 0.300  derive_clock_uncertainty  I'm following tips from timing advisor (at least as I've understood them :) )  Do you see how can I fix this slack?

[Altera_Forum]

Hi, 

Try/check these in Quartus settings: -Compilation process settings:   - use smart compilation  - physical synthesis optimizations: optimize for performance - Analysis and synthesis settings: check timing-driven synthesis - Fitter settings: optimize hold timing for all paths  Cris

[Altera_Forum]

Hi Cris 

 Back on this problem again. I'm actually using this options you've mentioned. I still have some negative slacks there. One example is the following:  Slack: -1.767 From node: RST_N (it's actually an input pin from my system) To node: rst_debounce:inst4|input_sync (it's actually the first register on synchonizer chain for this specific input) Launch clock: CLK (it's the only global clock, PLL input for my system) Latch clock: altpll1:inst7|altpll:altpll_component|altpll_34o2:auto_generated|clk[0] (it's one of my pll outputs, generated by "derive_pll_clocks" Relationship: 0.100 Clock skew: 0.018 Data delay: 1.264  Not sure how should I handle this...

[Altera_Forum]

Hi cprodrigues, 

Probably this happens because you are using the input clock for the synchronizer and then you sample/latch its output with the pll output clk. You should use the pll clock for the synchronizer, too. I'm not an expert on this point, but I think that you should use pll in source synchronous mode in order to use both clocks and keep under control their relative phase.  Cris

[Altera_Forum]

--- Quote Start ---  Hi Cris   Back on this problem again. I'm actually using this options you've mentioned. I still have some negative slacks there. One example is the following:   Slack: -1.767 From node: RST_N (it's actually an input pin from my system) To node: rst_debounce:inst4|input_sync (it's actually the first register on synchonizer chain for this specific input) Launch clock: CLK (it's the only global clock, PLL input for my system) Latch clock: altpll1:inst7|altpll:altpll_component|altpll_34o2:auto_generated|clk[0] (it's one of my pll outputs, generated by "derive_pll_clocks" Relationship: 0.100 Clock skew: 0.018 Data delay: 1.264   Not sure how should I handle this...  --- Quote End ---     Hi,  It is actually a Clock Domain Crossing Issue. Usually, we do not check paths that cross clock domains. You can set an exception to inform the STA tool not to check the path. You may use set_false_path command in your .sdc file. Then TimeQuest will not check this path again and naturely, this violation will disappear. Good luck!   And by the way, I think Cris is right about the synchronizer. We use the destination clock to synchronize the signals crossing the domain.