Should you remove all warnings in your Verilog or VHDL design? Why or why not?

Question

In (regular) software I have worked at companies where the gcc option -Wall is used to show all warnings. Then they need to be dealt with. With non-trivial FPGA/ASIC design in Verilog or VHDL there are often many many warnings. Should I worry about all of them? Do you have any specific techniques to suggest? My flow is mainly for FPGAs (Altera and Xilinx in particular), but I assume the same rules would apply to ASIC design, possibly more so due to the inability to change the design after it is built.

Update 4/29/2010: I was originally thinking of synthesis and P&R (Place & Route) warnings, but the simulation warnings are valid too.

Answer 1

Here's what I do, for reference. I inspect all the log files from the tool(s).

For Altera Quartus II that includes the map, fit and merge reports. I also turn on the Design Rule Check (DRC) option and check that file. For some messages that are easy to fix, e.g. port missing from the instantiation or incorrect constant width, I fix them. Other ones I look into. For ones that are in the cores, e.g. a width mismatch because I'm not using the full output deliberate, I mark them to be suppressed in the .srf file. I only suppress the specific messages, not all of the "similar messages" since there may be others, either now or in the future, which are problems.

Answer 2

I wrote a script which applies a set of regexps to the logfile to throw away lines which I "know are OK". It helps, but you have to be a bit careful with the regexps - what did jwz say about them :)

Answer 3

Here is my perspective from the ASIC world (99% Verilog, 1% VHDL).

We make an effort to eliminate all warnings from our log files, because in general, we interpret warnings as the tool telling us that we should not expect predictable results.

Since there are many types of tools which can generate warnings (simulation/debugger/linter/synthesis/equivalence-checking, etc.), I will focus this discussion on simulator compiler warnings.

We analyze warnings and categorize them into two main groups: ones which we deem will not affect the results of our simulation, and others which may affect the results. First, we use a tool's options to explicitly enable as many warnings as possible. For the first group, we then use a tool's options to selectively disable those warning messages. For the second group, we fix the Verilog source code to eliminate the warnings, then we promote the warnings to errors. If any warnings are later introduced in those categories, we force ourselves to fix them before we are allowed to simulate.

An exception to the above methodology is for third-party IP, whose Verilog code we are not allowed to modify.

That method works fairly well for RTL simulations, but it gets much more difficult when we run gate simulations using back-annotated SDF. There is simply not enough time to analyze and eliminate the literally millions of warnings. The best we can do is to use scripts (Perl) to parse the log files and categorize the warnings.

In summary, we try our best to eliminate the warnings, but it is not always practical to do so.

Answer 4

The most important reason that I can think of is simulation-synthesis mismatch. Synthesis tools do a lot of optimizations (as they rightly should) and if you leave loopholes in your design you are asking for trouble. Refer to IEEE 1364.1-2002 for details about the synthesis standard.