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