Using Verilog parameters across incremental compilation partitions

[Altera_Forum]

I am trying to compile a design that passes a Verilog (using the Verilog 2001 syntax of specifying parameters before ports) parameter down multiple hierarchies and partitions. The parameter is specified through the SOPC builder wizard, and then is passed down multiple levels within my own IP. 

 Everything seemed to be working before. But now that I have turned on incremental compilation (to reduce compile time), it seems one of the parameters is no longer being passed down properly.  The parameter is being passed down like this: SOPC Builder (specify parameter) -> top level of my IP (partition boundary here) -> next level of my IP (2nd partition boundary here) -> two more levels (with no partitions) -> final source file/module.  What is the expected result of this setup using top-down incremental compilation? Does my final source file/module get the correct value of the parameter? (obviously I'd like it to) Or does it revert to the default value in the final source file/module.  I hope the description is not too vague... Any help is appreciated.  - Jason

[Altera_Forum]

Incremental Compilation shouldn't change the functionality of your HDL. If you're passing a parameter down through your design hierarchy, it doesn't matter if it goes through partitions UNLESS you use the Post-Fit (Strict) netlist type, which ignores changes to source files and keeps prior fitting results.  

 Have you modified your design and now you're not seeing the correct behavior? How do you know the parameter doesn't take effect? When you ran quartus_map, did you see any messages indicating that your sub-partitions were resynthesized?   It could be a bug in the software. If you delete the project database and recompile (with Incremental Compilation), do you see the correct behavior?

[Altera_Forum]

I would disagree with this, at least fundamentally(I haven't tried it in practice.) Incremental Compilation is supposed to be unaware of synthesis in other partitions. The easiest way to think of it is as if each partition were synthesized like it was its own project. The reason for this is that you can then change one partition and it will only resynthesize that partition. I don't believe there are algorithms to "recheck" parameters in other partitions and see if they've changed of not.  

If the parameter doesn't change a lot, then you should change the defaults in the lower level partition to reflect the upper changes and be cognizant anytime you do change these parameters. If they do change a lot and you don't want to have to be updating them, then this is probably not a good boundary to create a partition on. I'm sure there are other solutions like putting the parameters in another file and then sourcing it, or parsing the SOPC system with a script to get them, but probably not ideal. Note that Incremental Compilation does have some limitations. Once you use it a lot, you realize they are fundamental reasons for these limitations and what IC is meant to achieve, but sometimes it takes a little work. Here's a good document to get a better feel for it: http://www.altera.com/literature/an/an470.pdf

[Altera_Forum]

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

[Altera_Forum]

IC is designed for bottom up approaches too. There are two extremes for boundaries. One is the flat approach, where everything(synthesis, fit, etc.) has to be redone on every compile. There are a lot of benefits to this, but as we all know, it takes longer to redo everything. The other side is where the boundary is set up to be completely independent of what occurs in the other partitions. It is synthesized independent of the other partitions, which is what IC currently does. In between is a gray area. For example, checking if passed parameters are changed. Second checking if minor synthesis across boundaries could be accepted(like passing a not-gate). Or checking if a pin being driven from another partition is tied to GND or VCC. It quickly gets extremely complicated though.  

(For example, the VCC or GND one is a good example. I have seen people want an output port of one partition that is tied off to have the logic it drives in other partitions to be synthesized away. I've seen other people want the opposite, because on another build they may hook it up, and they don't want to have to resynthesize/fit the other partition.) I can see how parameters(and that's about the only thing I can think of besides some physical stuff), could be checked, but it currently doesn't work that way. There are also other caveats(what if the parameter is passed but isn't used, what if a new parameter is created.) I personally like the current implementation in that it is straightforward, understandable and direct. My experience with tools that try to figure out a lot tends to lead me scratching my head on why or why not it did something. (I'm probably paranoid, as example, I never use Post-Fit but always Post-Fit(Strict)).  I understand what you're saying, but consider it far from unusable. Note that you really don't want a ton of partitions. You want a handful at most(I have cases with more, but for other reasons...), and I do tend to think of them as separate "designs". If they are truly dependent on each other compile to compile, they should be in the same partition.

[Altera_Forum]

Thanks for the replies. I am new to using incremental compilation, so I'm still trying to figure out what works and what doesn't. 

 That's exactly what I was wondering about, whether incremental would look at each partition separately, and as a result, use the default parameter value (specified in the "top-level" of the partition).  I looked at the Quartus handbook again, and according to 2-28 of volume 1, Quartus should detect module parameters in a higher-level module and add the higher-level module to the list of dependent files of a lower-level module that uses the parameters, so the partition can be recompiled when the parameters are changed.  When I look at the list of dependent files in my partitions from the analysis phase, this does not seem to be the case. None of the higher-level modules were included as a dependent file of a lower-level module. Files that were included using `include did make it to the dependency list though. I am not sure whether declaring the parameters in the Verilog2001 style has anything to do with it... I can try changing that.  The reason I need to do this is I would like to specify the parameter when I instantiate my component in SOPC builder, and that requires the parameter to exist in the top level of my design. The parameter is actually a CPU reset address, and I can tell the reset address is incorrect when I observe the CPU operation using signaltap.  Turning off incremental compilation did fix the problem with zero change to the source code... well at least I found what the problem is.