General Build Question

[Rob Gaddi]

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.

 

[Gabor]

glen herrmannsfeldt wrote:

Rob Gaddi <rgaddi@technologyhighland.invalid> wrote:
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.

People keep adding more warnings, just in case.

Enough that I have found rules like yours to be too strict.

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?

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.

-- glen

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.

-- Gabor

 

[glen herrmannsfeldt]

Rob Gaddi <rgaddi@technologyhighland.invalid> wrote:

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.

People keep adding more warnings, just in case.

Enough that I have found rules like yours to be too strict.

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?

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.

-- glen

 

[Christopher Felton]

<snip>

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.

I agree, I follow the same, 0 warnings for simulation. Some
simulators have -lint for extra warnings as well.

Another thing I do, since I use Verilog, is to always use:
`default_nettype none
which promotes a lot of connectivity warnings to errors.

-- Gabor

Yup, that is another good habit that we use as well.

Chris

 

[Andrew Holme]

"Rob Gaddi" wrote in message
news:20120830095944.3105154b@rg.highlandtechnology.com...

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.

I was just thinking about this recently myself. I got my latest Xilinx FPGA
project down to 23 warnings but I can't shift any more.

 

Den torsdagen den 30:e augusti 2012 kl. 18:59:43 UTC+2 skrev Rob Gaddi:

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.

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.

-- Pontus