--- Quote Start ---
The fact that you've got a Stratix IV 530 at nearly 100% utilization means you're no novice so forgive me if I state some things hear that are obvious to you.
1 - The single change that can have the most impact on timing and resource utilization is modification of the source RTL itself. This is usually the first place to look when timing fails. Many times the RTL resulted in long stages of combinatorial logic the designer was unaware of. Now of course you may not be able to do this if a lot of the logic lies within purchased 3rd party cores to which you don't have the source code.
we had most of the design blocks running fine in 90 nm (stratix ii gx). the problem is ic delay.
2 - Timing constraints - Are you sure you've constrained the timing such that Quartus isn't doing unnecessary work trying to meet timing on paths that really aren't important (crossing clock domains for instance). The fitter may take away precious routing and logic resources for paths that really don't deserve it thus making it difficult for the entire design to fit.
3 - Have you tried logiclock regions yet? Physically constraining the fitter as to where certain modules may be placed allows you to provide heuristic human insight that can dramatically help the fitter out. You know the design. You know what connects to what. Locking adjacent logic into a region can be a big help.
4 - Have you tried physical placement constraints? Similar to logiclock you may need to manually restrict the placement of certain elements to specific LABs in the device. Often this can be done by scripting.
5 - You probably have the entire design set to be optimized for speed. Are there any modules in the design that don't need to be optimized for speed. Are you aware that you can set the optimization technique specific for each module in the hierarchy? So you might optimize the entire design for speed and target specific modules to optimize for size or vice versa.
we are now doing this. like i mentioned earlier we are in stratix iv and 9.x was terrible for preserving placement via incremental compile (could not remember previous fitter results). on 10.0 sp1 and things seem to be working like we expect.
6 - Have you tried tweaking the fitter/placement effort multiplier? Try a value of 4 and see what happens.
My personal opinion is that seed sweeps and DSE sweeps are the worst methods for tackling these issues. They consume an enormous amount of time and at the end of the day you're just trying to get lucky. And if you do get it to work a single change to the design may throw the whole thing off again. Find the problem, fix it, then move on to the next problem.
Jake
--- Quote End ---
1/ we had most of the design blocks running fine in 90 nm (stratix ii gx). the problem is mostly ic delay.
2/ agreed. we are quadruple checking. multi-corner analysis is eating up lots of interconnect. this is required for the types of memory. there are over 200 clocks in the design. these mostly come from altera memory ip (we have 4 clock domains).
3/ i'm a long time user of altera tools. i can never get a straight answer out of altera as to whether logic lock pays any dividends. i guess every design is different so its hard to say for sure. the 530 seems to have crossed the line where there is now denying that floorplanning and design partition is the only answer.
4/ working on it.
5/ we now have about 10 partitions are are optimizing each one for area and then trying to meet timing (gradually crank up speed setting if needed). this seems to be working. once the entire design is locked and closed wrt timing we will run out of some type of resource.
6/ fitter effort definitely helps with design partition. for the flat compiles not much help.
the path that shows the most promise is incremental compile. as you can imagine it is a slow process. i could write a book on this experience....
thanks for taking the time for the detailed replay. i will give an update for the final solution (i think 10.0 will bring closure).
best regards
Honored Contributor
