I have recently upgraded Quartus II from 7.3 SP2 to 8.1 and am very happy with the compilation speed (about 25% faster in my case). But does anyone know how much faster the 9.0 is comparing to 8.1? Any reason not to upgrade to 9.0 at this point? Thanks in advance. Hua

To be honest, it's worth installing and trying for yourself. (Luckily, Quartus II plays quite nicely when having multiple versions installed, although I've heard complaints about SOPC builder, but I don't use it.) The reason I say that is it's very design dependent. About the timeframe you're talking(7.2 to 8.1, I don't think there was a 7.3), the physical synthesis algorithms were improved a lot, so that easily could be the gains you see. Linux versions were also greatly improved(they were actually far behind windows for a technical reason, and were moved to being close to par). It also depends on what family you're targeting, as older families generally won't see specific algorithmic impromvenets, just generalized improvements(like the Linux improvement). I don't think 9.0 is going to improve as much, but it's worth trying to find out.

Thanks for the quick reply, Rysc. I understand that it is design dependent, but I will give it a try and post the result here just in case someone (like myself) want to get an idea about it. If anyone who had done this sort of comparison and like to share the result, please feel free to post here too. Thanks.

Hi I have a somewhat disappointing result for our design here: With Quartus 8.1, the fitter needs between 2h15 and 3h15 for different seeds, synthesis is 51min. With Quartus 9.0, the fitter needs between 3 and 6 hours, with the mean value around 5h. Synthesis is somewhat shorter (46min). I have to say that the design is made for an ASIC - and even there the clocking strategy is not very nice. For an FPGA it is disastrous. So if anyone has a cool trick with settings to remedy hold time violations due to clock skew - please tell me ;) I can't change the design for now... Thanks emanuel

Are you saying that Q9.0 is optimize positive hold requirements inside the device and that's why it's taking longer? Note that when look at compile times, I always look at the fitter messages, as it breaks out placement time, physical synthesis time(which is part of total placement) and route time, just so I can monitor where the fitter is spending time, and when comparing different results, I know what changed. If you have Assignments -> Fitter -> Optimize Hold Timing = All Paths, and Optimize Fast Corner checked, then you already have the cool settings to have the router add delays to meet your hold requirements. But naturally this increases routing resources and can make compile times get longer, or even make the design hard to route. This is expected in an FPGA with large clock skews. (There is also an Assignment -> Analysys & Synthesis -> More Settings -> Auto Gated Clock Conversion, which could help a lot of it works on your design. I don't know enough about it, and there are plenty of gated clock implementations that can't be improved, but it's probably worth a try.)

--- Quote Start --- With Quartus 8.1, the fitter needs between 2h15 and 3h15 for different seeds, synthesis is 51min. With Quartus 9.0, the fitter needs between 3 and 6 hours, with the mean value around 5h. Synthesis is somewhat shorter (46min). --- Quote End --- Hi emanuel, Have you taken the incremental compilation into consideration? Usually compiling the second time takes much shorter time than the first time. If the compilation time in 9.0 is a first-time compile while the time for 8.1 is not, it may not be fair. I am having a cyclone 3 design compiling right now in 9.0 for the second time and will post the result soon. Hua

Compilation time for Quartus II 9.0 | Altera Community

15 Replies

Altera_Forum
Honored Contributor
16 years ago
I guess I'm talking a bit weird again... sorry ;)
I have a negative total hold slack for two out of ten seeds. So I'm rather trying to get zero instead of something negative, not optimising positive values.

I'm not trying to push the hold time slack to zero from any direction (guess that is what you question was). I'm just trying to "fix" (optimise is too positive here) a very bad timing.
Altera_Forum
Honored Contributor
16 years ago
If you have a gated clock, and therefore have clock skew so the latching clock is longer than the launching clock, you end up having to add delays to meet hold timing. So even though the requirement is 0ns, in essence it still has to add delay to meet timing. Naturally anything that can be done in the code to fix this would be good. (Like moving the gating signals from logic to drive the enable of the altclkctrl block...)
How long is the route time compared to placemen? Most designs it's much less, say 5%, but your design may be skewed. Also curious what the average and peak routing utilization is? (in .fit.rpt). And do you have Optimize Fast Corner checked?
(I think you're aware of all this, just double-checking...)
Altera_Forum
Honored Contributor
16 years ago
Yes, we definitely need a lot of delay introduced. I haven't tried to run without optimize hold timings for some time, but I guess I would end up somewhere in the micro-seconds range TNS.

I can't currently do much against that, as the ASIC design is quite frozen atm. The only thing I'm not sure is if I could push the clock gating conversion for a better result with other timing constraints and a smart clock gating cell replacement. It doesn't convert anything right now.

Concerning elapsed times:
Info: Fitter placement operations ending: elapsed time is 00:21:32
Info: Fitter routing operations ending: elapsed time is 02:06:53
So I'm on the far other end then, I need 600% for the routing :-/

Concerning utilisation:
Info: Average interconnect usage is 15% of the available device resources
Info: Peak interconnect usage is 55% of the available device resources
But I have seen much higher values here, this one is for a quite nice fit. Logic utilization is 33%.

I have the optimize fast corner timing checked for 8.1. But I recently uncecked the optimize multi corner timing in 9.0, hoping to reduce the compile time somewhat.
Altera_Forum
Honored Contributor
16 years ago
Yowsers. At the end of the day, I think it is what it is. Routing is probably the biggest use of silicon in an FPGA, so they're really not designed to have lots of extra resources to fix hold violations. You may try to manually add delay to your clock trees and see if theres any way to balance them. (I don't know how many clocks you have, if they're on globals, etc.) One other thing of note is that in Q9.0 they added an "Estimated Delay Added for Hold" table, or something like that. You're already aware of why it's being added, but might be a good chart to gauge what the router is doing.
Altera_Forum
Honored Contributor
16 years ago
Getting quite off-topic here...

I've been messing around with different kinds of location assignments, trying to release the fitter, but somehow it was always worse (what a wonder...). There is always a point where the skew ends up in a loop.
We have some 20 clocks here, thereof about 5 asynchronous. The good part of the dividers are ripple counters (I hope there is no student or professor reading that now...). So somehow, I'm not really surprised by the bad result ;)

The only disappointing thing is the clock gating conversion introduced in Q8.1. From a colleague I know that Synplify managed to convert the tree.

Anyway, we are probably starting a new version this summer, so I'll try to fix this mess somewhat. They were running into problems on the ASIC as well, just much less.
So back to the topic: This will also reduce the compilation time heavily I guess.

Forum Discussion

Compilation time for Quartus II 9.0

15 Replies

Recent Discussions

The quartus license works with version 25.0 but not with version 17.0

Docker image for Quartus Pro 26.1 missing ?

Quartus did not start

Timing analysis - long combinational path

timing violation fix