RFI: Getting Rid of Useless Warnings

[Altera_Forum]

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?

[Altera_Forum]

No, it isn't just you ... 

I also get annoyed by the tons of warning messages generated by Altera's own IP. Try using a HPC II DDR2 memory controller and you get those 125 warnings about mismatches in their Verilog code. Add in a GX block and get one hundred more. Now you have to slowly skim through the warning messages to find the ones that do matter, in first degree those which are raised in your own code, then wonder whether the ones raised in Altera and Third-Party code are the result of your work, or just the result of their sloppiness?  In C-programming there is a saying : "A warning is an error waiting to happen". I personally raise warnings into errors and resolve them. But that would get us nowhere in Quartus II ...

[Altera_Forum]

I totally agree. Coming from a programming background where I always try my hardest (and usually succeed) to get my C code compiling with zero warnings, the multitude of seemingly impossible to resolve warnings in Quartus really bug me.

[Altera_Forum]

While it may be frustrating that you can't get rid of all Warnings, you can Suppress them. If you right-click on a Warning, you can select "Suppress" and then you have the option of suppressing that exact message, or all similar messages. When you suppress messages, they now show up under the Suppressed tab in the Messages window, but no longer show up under the Processing tab. So, in effect you can filter the ones you don't want to see that you know about out so that only new Warnings, or the ones you might care about show up. Conversely, if you are looking through all your Warnings and you see one that you know you have to deal with, but don't have time right now, you can Flag it (right-click on the Warning and select Flag) and it will go to the Flag tab. Then, later on you can address those Warnings that you flagged.

[Altera_Forum]

--- Quote Start ---  While it may be frustrating that you can't get rid of all Warnings, you can Suppress them. If you right-click on a Warning, you can select "Suppress" and then you have the option of suppressing that exact message, or all similar messages. When you suppress messages, they now show up under the Suppressed tab in the Messages window, but no longer show up under the Processing tab. So, in effect you can filter the ones you don't want to see that you know about out so that only new Warnings, or the ones you might care about show up.  --- Quote End ---    You don't seem to get the message (pun intended). The idea is that warning messages are not made to suppress them, they draw attention that there is an inconsistency which may lead to a non-functional design. It is up to the designer to clean-up his code to 'not generate' useless, confusing warnings. There simply is no excuse for either Altera, a Third-Party or our own code to throw (useless or 'to be suppressed') warnings.   --- Quote Start ---  Conversely, if you are looking through all your Warnings and you see one that you know you have to deal with, but don't have time right now, you can Flag it (right-click on the Warning and select Flag) and it will go to the Flag tab. Then, later on you can address those Warnings that you flagged  --- Quote End ---   This may be quite useful. Will the flag last through the next compile(s)?

[Altera_Forum]

I wasn't attempting to justify that Warnings are OK as I agree they certainly are not. Unfortunately in IP there's not much you (the user) can do to get rid of them. I was just trying to give you a way to live with them. 

 Yes, the flag will stick from compile to compile as long as the Warning message doesn't change.