Top-down incremental compilation

Why are you using Incremental Compilation? (I ask only because methodology can be slightly different because of goals. Are you:

- Trying to preserve performance in specific modules? If so, with how much slack do they meet timing?

- Trying to reduce compile times? If so, how long are your compile times? What size device and how full is it?

- Trying to "complete" modules and lock them down.

Anyway, pointing to the source files of other projects only makes them source files in your project. It doesn't actually read in the placement of other projects or anything like that. (If that's what you want to do, then you need to follow the bottom up file, which involves exporting/importing .qxp file, which are database files of a project that contain information like how your source was synthesized, where it was placed, etc.)

There is a pseudo-bottom up approach that I use quite often. Let's say I have 5 major hierarchies beneach my top-level A, B, C, D and E. I create a partition on all five of them. Note that there might be some other hierarchies like PLLs, maybe a reset block or something, which I tend to not make a partition out of(which means it is part of the top-level partition.) Let's say block C tends to be the most critical, or the one I want to work on first, for whatever reason. I will set partitions A, B, D and E to Empty. That basically makes a black-box out of them, but it doesn't remove any of the connections hooked up to them. I will then place and route the top-level partition and partition C. I can then set C to Post Fit if I like its results and work on the next partition, which I will set to source. I can then proceed to do each one ony-by-one. A nice thing about this flow is that the fitter will be aware of anything that is post-fit. So if you're working on hierarchy B, and C is Post-Fit, the fitter knows the connectsion between B and C, and where everything in C is placed, so it can do its best to optimize B's placement to make sure these paths meet timing(note that C is Post-Fit, so wherever it was placed, it can't move.)

Some notes:

- You can change what's in a partition as you move along. Let's say you have 26 hierarchies under the top-level, A-Z, and running each one individually will take forever. But on your first pass you want to do hierarchy B, which is a large piece of logic. Set all 26 partitions and set everything but B to Empty. Work on B. You do the same for C, and then A. At that point you want to refit the top-level and the other 23 partitions. You can set the other 23 partitions to source, or you can delete their partitions altogether, so your next pass will resynthesize them into the top-level, allowing for cross boundary optimizations.

- It is generally recommended to use LogicLock regions to floorplan your design alongside your partitions. They don't have to be 1:1, meaning you could have a single LLR with 3 partitions in it(I'm doing that right now on a design). Why? On the first pass it's not a big deal whether you do this or not. But let's say you fit all five partitions A-E one at a time without any floorplanning. They will all be somewhat interspersed through each other(meaning you'll see specs of hierarchies placed throughout other hierarchies.). If you then keep 4 of the partitions as post-fit, modify the code in one partition and try to refit it, it's now got a floorplan that's got little tiny holes throughout the other logic. This is called a swiss-cheese floorplan, and it's much more difficult to get good results. If you make performance easily, or if your device isn't very full, then this may not be an issue. But if you're 90% full and barely make timing, the swiss-cheese refit might start to fail timing.

- When a partition is set to Empty, Quartus remembers where the last placement was(assuming it exists.) This allows for another type flow. You could set B-E as Empty partitions and fit partition A. Then set partition A to empty and fit B. Then do the same for C, D and E. So each partition was fit by itself. Then change all five-partitions to Post Fit, and Quartus will have kept the placement information of where they were last fit. You absolutely have to floorplan with this flow, because each fit is done without any knowledge of the other fits, and you'll end up with overlapping location assignments.

Anyway, hopefully that's a start. There's a certain amount of art to Incremental Compilation, in that it depends on your design, what your goals are, what your peformance is, what your hierarchies are, how full the device is, etc. This makes it difficult to make a cookbook recommendations with Incremental Compilation. That being said, it also makes it more powerful in that you can tailor what it does to your goals.