Honored ContributorHi,
I am Altera Dist. FAE. This specific costumer is suffering from long compile time (5 hours) for a design on StratixII180, 70% utilization. QuartusII version is 7.1. In general, these are the tricks I am aware off: - Incremental compilation - More powerefull workstations (I will be happy to have detailed suggestions regarding this point) Any more suggestions? Thank you anyway for reading this post.
Honored ContributorFirst, do they have physical synthesis on? (Assignments -> Settings -> Fitter/Physical Synthesis). This can significantly impact compile times, although it gives better results. If they do, try lowering the effort, or turning some of the options off. Note that the fitter gives very useful messages for these algorithms, something like Register Retiming took 40m and improved timing by 30ps. If you see something that takes a long time and gives little gain, turn it off(the gains are approximation since it hasn't routed yet).
My guess is that this isn't on. Note that 5 hours, especially if you're not on the fastest machine, is not that bad for this device. Yes, it can be faster, but it's not off by orders of magnitude(and we have very good compile times compared to other FPGA vendors of this size). But I understand 5 hours can be long, regardless if this is good or not. The fitter should be set to Auto Fit, which will have it run until you meet timing and the design is considered routable, and then quit, rather than wasting timing trying to outperform your requirements. (Do you meet timing?). A simple way to reduce compile time is to do a Fast Fit. This can halve the fit time, with a performance reduction of only ~10% or so. If you're testing on a board and there's anyway this will work(slow down your clock rate, put a faster device on the board, etc.) it can be well worth it. Also note that in the lab you don't have to close timing. If your off by a small % of your slack, realize that you're not dealing with the worst case PVT and that the design should still work. Incremental Compilation can be extremely helpful, but usually requires some floorplanning(LogicLock Regions up front). Why? The basic premise of IC is that it preserves the partitions you don't change. The problem is that if you don't floorplan, your placement tends to have areas of overlap(where two different partitions converge, they are fit into a the holes of the other region, like two different colored marbles thrown in a box. Now, if you lock one set down and try to fit the other set within the "holes", the fit problem becomes much more difficult and performance can get worse. Since you're only 70% full, you may not encounter this, but it's worth reading the handbook section of Incremental Compilation and LogicLock Regions to get a better grasp of this. Also note that under Tools -> Advisors there is a Compilation Time Advisor. You're going to find some of these suggestions go directly against the Performance Suggestions, which makes sense(you usually trade compile time for better performance), so if you're meeting performance is an important variable in all of this.Honored ContributorThank you, Rysc.
Honored ContributorHonored ContributorThank you, Brad
Honored ContributorAnyone know whats the speed gain of going from 32 to 64bit PC?
Honored ContributorGoing from 32 bits to 64 bits will be slower as the instructions are longer.
I also use a startix2 180, And the best speed (at a reasonable price) you can get for the moment is having a pc with win xp 32 bits, 3 GB of ram, 2 fast sata harddisk drive in parallel (raid 0), and a core2duo cpu (e6600).Honored ContributorIf you have a multiprocessor machine take note of the setting "Maximum processors allowed for parallel compilation" under "Assignments / Settings / Compilation Process Settings". This defaults to one, so QuartusII will not take advantage of multiple processors unless you increase this number (up to the available number of processors).
Honored ContributorNote that the Maximum Processors setting is given a number. Ideally, it would allow for a value like "Auto" or "Maximum", so that if you compile your design on a 2 processor system, it automatically uses both of them, and if it's on a 16 processor system(someday), it uses all of them. I believe that's in the works. But if you set the number higher than the number of processors you actually have, then it will slow down your compile times(which is why it defaults to 1). As I believe most people know, only the simplest of parallel algorithms see the performance(processor time) decrease linearly with the number of processors(where 2 processors would halve the total processing time). One of Altera's software engineers was at a multi-processor conference/tradeshow/something and basically software people in other fields were generally maxxing out at a square root improvement, so 2 processors would give a 40% improvement, 4 processors would give you a 2X improvement, etc. So extra processors helps, but not to the degree the layperson(like me) often expects.
Honored ContributorI made several test,
going from one cpu to 2 cpu (in the qaurtus option) on a dual core processor (e6600) only speed up by 10 %, because Qaurtus only uses both core at the beginning and at the end of the fitter. And aside that, sometime Quartus runs forever when 2 cpu's are used (probably a sync problem between the multithread sw code).Honored Contributor
