- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @ 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?Link Copied
5 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I 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?)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks 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_uncertainty
Is there a way to send emails to users here in the Altera Forum?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Okay, 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.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank 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.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I 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?
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page