Here's a sort of a general toss-out. When I'm writing code in C, one of my rules is that I turn on -Wall (and a mess of other warnings) and I won't ship until I've got 0 warnings in the build.
I've never managed to follow a similar pattern on my FPGA designs. Both on Xilinx and Altera I always get 4 gillion warnings, all of them trivial. So I glance through the list, looking for anything that looks serious, but that process is both exhausting and not rigorous. Does anyone actually manage to get their FPGA builds to a zero warning state? Or is that yet another way in which FPGA design tools get circles run around them by software design tools?
--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.
Enough that I have found rules like yours to be too strict.
One difference with the usual FPGA tools is that they do the processiing in stages. Some of the warnigns might complain about effects due to processing in earlier stages.
If there are some warnings that you know that you don't need to worry about, then I would use "grep -v" on the file before looking, so that I wouldn't see useless ones.
At least for Xilinx, the grep feature is built-in as "Message Filtering" which helps you to ignore warnings you consider trivial. I find that warnings in behavioral simulation - whether ModelSim or ISIM - are generally of the type you should not ignore. So I make sure I don't have warnings when I compile for simulation, then look through the filtered warnings for synthesis.
Another thing I do, since I use Verilog, is to always use: `default_nettype none which promotes a lot of connectivity warnings to errors.
Den torsdagen den 30:e augusti 2012 kl. 18:59:43 UTC+2 skrev Rob Gaddi:
I also never get zero warnings, "There is an 'U' or 'X'" when starting sim for external IP which I don'twant to touch, there is ununused bit in a word in a reg-bank (during synt) or some outputs of an inferred BRAM are unused (P&R). Intermixed (in the log-files) with these hundreds to thousands warnings are some important warning that really matters, but they easily get drowned.
I am using "make" to sim/synt/par the design, but the make "goal" is not to obtain the result file (i.e sim log file, synt netlist file, P&R bit file) but to obtain a filtered version of the log file which passes a text filter (grep -v) with no remaining errors/warnings/failures. The list of acceptable warnings is kept in a (suppression) file which belongs to the project. (So the "make" goal is to obtain a suppressed log file, not the sim-log/netlist/bit-file. Whats the use of a bit file that failed timing?? The netlist is obtained as a side effect of obtaining a filtered log file).
Once a new warning breaks the build I update the suppression file (or the src (vhdl) file) to accept the new warning. Basically the suppression file contains a list of patterns (regexps) that are "acceptable".
Our typical build flow (lattice/xilinx) is more like sim/synt/build/map/par/trace/bitgen, and each step will produce a log file that can be suppressed. So seven different suppress files are in work.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.