Honored ContributorHi @ everyone!
In our project, lately we get a hold time violation. FPGA: Cyclone V Clk period: 31.25 ns The signals where the violation occurs are intern signals. In the attachment you can see more information. How can I get rid of that violation?
Honored ContributorI have trouble reading that, but it looks like there is a lot of clock skew. Run report_timing again but with the -detail full_path option, which breaks out the clock path info. Then see why they're so different and see if you can fix it(I assume these clocks are related?)
Honored ContributorThanks a lot for your support, Ryan.
I added a new screen shot showing -detail full_path. I hope it can be read better now. At the FPGA pin 50 MHz input clock is provided. A Pll generates the 32 MHz (31.25 ns) using that 50 MHz. The 32 MHz are used in the module with the violation. The .sdc already contains the lines:derive_pll_clocks
derive_clock_uncertaintyOkay, you're doing everything right. PLL -> Global clock tree, everything looks correct, etc. This shouldn't be failing.
What version of Quartus are you using? You could try overconstraining the domain, although I'm not a fan of doing it for an entire domain. I would try a newer version of Quartus is what you have is old(I've seen numerous times where this occurs due to router overestimating that it met timing and that estimate gets tuned in later versions). To overconstrain, add something like the following to your .sdc: if {$::quartus(nameofexecutable) != "quartus_sta"} { set_min_delay 0.020 -from [get_clocks <pll_clock>] -to [get_clocks <pll_clock>] } Substitute the <pll_clock> with the name of the clock. You can wildcard it too. FYI, I don't generally respond to emails for stuff like this. This is not my job function and I'd get swamped doing direct support. I generally just hop on now and then to try and answer a few things and hope others watching/reading learn from it too. (I'm not sure if that was your intent about email, just throwing it out there.) Good luck.Honored ContributorThank you very much for your support!
We use Quartus 14.0. I think, the version is not that old. I would try with it with a newer one, but unfortunately we don't have a license for it yet.Honored ContributorI used Quartus 16.0 and synthesized the project twice.
There are no timing violations anymore! Thanks, Ryan! Does it also make sense to overconstrain the logic element where the hold time violation occurs? ... instead of overconstraining the whole domain?
