Long runtimes for Quartus II

Question

Hi,

I'm trying to run the following flow with Quartus: analysis and synthesis -> fitting -> assembler.

I used the following two approaches:

A. Give Quartus my RTL source files for analysis and synthesis, fitting and assembling (the assembling is to generate a pof file that I can download into my FPGA).

B. Take my RTL source files, synthesize them with Design Compiler. Give Quartus the resultant netlist for fitting and assembling.

Can anyone tell me if one should expect to see hugely different runtimes for the two approaches above (assuming I run Quartus on the same machine for both methods)?

For example, I observe that for approach A, Quartus proceeds smoothly and finishes the entire process in about 4 hours whereas, for approach B, I see that Quartus gets stuck about 79% into the Fitting process and takes more than 7 hours to complete the entire flow.

FYI, my design gate count is about 80k and I'm using version 7.1 of QuartusII.

Thanks!

altera_forum · Answer

There are a couple more clues Quartus is telling you, such as if it is burning its time in placement or routing, if the timing is dificult to meet, or if the part is too full or too empty.  A quick idea is check that you have turned on Settings-&gt;Analysis &amp; Synthesis Netlist optimizations -&gt; WYSIWYG primitive resynthesis and gate level retiming.  If Design compiler choose poorly these two options might fix it.  There are also physical synthesis options, but they tend to slow down compiles in exchange for performance, generally speaking.  When you do timing closure, you will often see the parts of the design that Quartus has a hard time with, and the appropriate pipeline stages or replicated logic may not only make the timing much easier to meet, but speed up placement.

altera_forum · Answer

The main three stages of fit time, placement, routing and physical synthesis(if on), all give messages in the .fit.rpt for how long they took, so these are worth comparing.  Also compare the device resources being used.  Note that Design Compiler is an ASIC tool.  I believe they have a companion tool called FPGA Compiler, but I'm not sure if that's still available.

altera_forum · Answer

I can tell you, from experience, the routing phase is running when the fitter progress bar is at 79%.  Although it appears that the progress bar is "stuck", there is often a longer lag time at that particular % than other numbers.  You may want to take a look at a message the prints out the routing interconnect utilization (both average &amp; peak) to see if there is a noticeable difference between the two flows you are using.  Also, you should take a quick look at the fitter report file to see if the design compiler used a different set of settings than the ones used in approach A.

altera_forum · Answer

To improve routability, see the Quartus handbook, Volume 2, Section III, Chapter 8. There is a "Routing" section under "Resource Utilization Optimization Techniques (LUT-Based Devices). There is a "Reduce Routing Time" section under "Compilation-Time Optimization Techniques".

A couple of ways in addition to the interconnect usage messages to tell whether you have a routing problem:

The Fitter messages might have more than one placement and routing attempt with this message after each aborted attempt:

--- Quote Start ---

Info: Can't fit design in device - retrying with increased optimization, which may result in a longer processing time

--- Quote End ---

The routing time might be longer than normal compared to the placement time. It is normal for routing time to be a third to half the placement time.

altera_forum · Answer

--- Quote Start ---

The routing time might be longer than normal compared to the placement time. It is normal for routing time to be a third to half the placement time.

--- Quote End ---

Brad makes an excellent point. However, it is possible for the routing time to be equal to or, potentially, longer than placement. Typically, this occurs when one or more of the following conditions is true:

1) The design uses an excessive amount of wiring resources,

2) The design is using almost all of the logic resources (this causes very dense LABs to be created and the router needs to spend extra effort routing them),

3) Various "try harder" router optimizations are selected (e.g. set_global_assignment -name ROUTER_TIMING_OPTIMIZATION_LEVEL MAXIMUM), or

4) The design has a large number of very critical, balanced paths (e.g. a large crossbar)

It is possible that the different flows has caused one or more of the above conditions to change, which would ultimately explain the significant compile time difference between the two flows.

Forum Discussion

Long runtimes for Quartus II

6 Replies

Recent Discussions

Timing analysis - long combinational path

QuartusPro 25.3 Crashed after using the Signal Tap Logic Analyzer

Duplicate_hierarchy_depth / duplicate_register

Automatically added negative node for TDS output doesn't work with Agilex 5

Quartus 20.1std compilation fails for Quartus map - Device 10AS057K2F40I1SG