Honored Contributor
Honored ContributorIMHO, any incremental compilation flow that worked the way you describe would be unusable. It can't ignored fundamental changes to your design source files or, in this case, inherited parameters. Notice that Quartus II runs Analysis & Elaboration prior to telling you what partitions require synthesis? It's probably building up your design hierarchy for a reason -- like to check for fundamental design changes such a change to a parameter setting. I can easily think of a parameter checking algorithm: If parameter P on the instance that defines partition X changed value, then schedule partition X for synthesis.
Yes, the synthesis is independent, but synthesis is about optimization and mapping. By design, synthesis doesn't alter the functionality of your design, unless there's a bug. :) Ok, maybe that's an over-simplification...there may be a few corner cases where synthesis alters the functionality somewhat in order to make a mapping possible. Any good synthesis tool will keep these to a minimum and issue warnings in all such cases. What you're describing sounds more like bottom-up design (each partition is effectively compiled like it was its own project) rather than top-down design. You do have a point about how the partitions are organized. If the parameter setting is passed down from the top-level hierarchy, and only one lower-level hierarchy uses the parameter, it's probably better to move the parameter override down to the lower-level instance. Otherwise, you'll recompile much of the design hierarchy every time you change the parameter.
