RFI: Getting Rid of Useless Warnings

One part of stabilizing a design is getting rid of warnings. For example, if the tool tells me that it appears I forgot to put a signal on the process sensitivity list and the result from synthesis might deviate from the source code simulation model, I should fix that and I am thankful to the tool that it helped me. The goal is to have a warning-free design in such a way that any single new warning will raise my attention. With 125 warnings in a clean run, and 125 warnings in another run, a real mistake could get through unnoticed without deep, human analysis of the report.

The case is different for warnings that are from the following categories:

1. A warning as an underrated error,

2. A warning as an overrated note,

3. A warning I cannot get rid of the tool behavior,

4. A warning I cannot get rid of because of IP protection.

For (1), one has to think of a warning as an error which the tool can work with nevertheless. This is the only warning one should actually see, and that are the ones one should have to fix. Currently, Quartus has two separate criticality levels, warning and critical warning, but it is useless to have differences in behavior reported as non-critical warnings, as described below.

(2) happens in cases where you specify some behavior which the synthesized design will perfectly cover, but the tool thinks that the user wants to be informed of some applied optimization steps.

Consider a general-purpose memory queue with multiple ports, and on some ports the receiver just uses a fraction of the supplied memory output pins. It is perfectly okay to remove the memory cells for these pins as it won’t have an effect on the behavior, but the tool warns me about this optimization. At best, this should lead to a note. As such warnings are typically warnings from the fitter, one cannot even disable the messages by writing special altera comment lines into the source code.

Same goes for GND connected outputs. If it’s specified that way, do it that way, there is no cause for a warning. Especially for cases where one has a common pinout but enables features on a case-by-case basis or through evolution starting with a simple mock-up, the chance is high that inputs stay unused and outputs stay stable without any conditional logic driving them. I don’t need the synthesis tool to inform me of that condition, that’s what simulations and their test cases are for.

(3) is for cases like the following: You describe a perfectly synchronous register, with initial value, reset input and all cases covered. The tool finds out that it can synthesize it together with some other registers as a shift register megafunction altshift_taps, and the next optimization places the memory cells into MLAB which cannot be put into a power-on reset state as specified. For me this is a clear synthesis fault. I never asked for that kind of non-equivalent optimization. It’s like asking for milk and getting orange juice together with a warning that there are small deviations in behavior. Here, the subtile part is that this warning can come and go, depending on optimization effort, inter-block connections and so on, so there is a chance that this issue will hit YOU in your design without preparation.

Another case is for LVDS pins. Suppose your design has single-ended inputs and outputs and you want to connect them to LVDS I/Os. The pin planner and the fitter automagically assign the complement pin for that and, fair enough, put a warning that there are unspecified changes to the design, i.e. added pins. But there is no way documented – at least nothing I could find – to get rid of the warning, e.g. by placing a dummy complement pin which could say: “I know that I’ll need a complement pin for LVDS or transceiver I/O, so I specify that differential pair as a constraint”, and the warning would be gone. No, doesn’t work that way. It looks as if the tool programmer assumes that the user likes to have his post-fitter pin report be placed into the warnings page.

(4) goes for annoyances from auto-generated or encrypted ‘source’ files from IP blocks like PCIe Hard IP macro. Here, one .vhd source file is missing from the .qip (which the tool finds by itself, nevertheless), there some internal simulation-only pins stay unconnected leading to warnings about their automatic connection to GND. Then some warnings for unchanged variables in a VHDL process from the tool standard library are raised, finally there are warnings from encrypted IP blocks which I cannot get rid of at all.

Is it just me? Can’t we have a tool that helps us get a warning-free design instead of us getting used to a significant level of warning ground noise?

What do you think?