Negative slack on TimeQuest report

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;

Hi

Thanks for your answer.

What do I have to do to eliminate this negative slack?

Thanks and regards

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

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?

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

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...

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

--- 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.