Long runtimes for Quartus II

[Altera_Forum]

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]

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->Analysis & Synthesis Netlist optimizations -> 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]

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]

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 & 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]

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]

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

[Altera_Forum]

Sorry for the late response. Work was a little busy and I couldn't check back. 

Thank you very much for all your answers. Some clarifications: 1. WYSIWYG primitive resynthesis is ON, physical synthesis is OFF. 2. The interconnect resource usage is indeed different for both approaches. For B, the peak usage is around 49%. For A, it was much more - around 80% I think. 3. I checked and the Fitter didn't give me any messages about not being able to fit the design. In fact, it gave me no messages at all. :( :p 4. I let the Fitter run in the hopes that it would be done in 7 or 8 hours. Unfortunately, after 20 hours, the fitting was still running.  Anyway, I've decided to continue with procedure B for the moment as I just can't spare the time to look into this matter in more detail. Thanks once again for all the help. :) :)