Warnings and FPGA design

[tchicago]

I recently came across some synthesize warnings that are impossible to fix. Some of them are coming from the vendor's auto-generated IP, like PLL. Some come from the builtin blocks like oscillators, some from the inbox libraries of components.

Even the vendor's inbox samples that use those components also generate those warnings as well.

So my question is, is it normal to ignore them? If your large project generates tons of warnings and you are expected to ignore them, how can you be sure that what you are building is reliable?

From the software design industry experience, each warning should be dealt with. Either the issue is fixed, or analyzed and if confirmed to be a non-issue, then this particular warning in this particular place can be suppressed. So the build should be fully clean without any warnings. The HDL design tools don't seem to provide any way to selectively suppress specific warnings.

So it seems like having tons of warnings on the build output is just a part of life with HDL design. Is this true?

Building the blinky led inbox project from Lattice Radiant for iCE40UP:

WARNING - q:/lscc/radiant/2.2/data/reveal/src/ertl/jtag_soft.v(0): expression size 32 truncated to fit in target size 3. VERI-1209
WARNING - q:/lscc/radiant/2.2/data/reveal/src/ertl/ertl_ice40up.v(0): expression size 32 truncated to fit in target size 1. VERI-1209
WARNING - q:/lscc/radiant/2.2/data/reveal/src/ertl/ertl_ice40up.v(0): Register \top_reveal_coretop_instance/top_la0_inst_0/tm_u/trace_dout_1st_bit is stuck at Zero. VDB-5013
WARNING - Bit 0 of Register \top_reveal_coretop_instance/top_la0_inst_0/tm_u/pt_cap_mem_addr is stuck at Zero
WARNING - Skipping pad insertion on encrypted_port due to black_box_pad_pin attribute.
WARNING - The preferred point for defining clocks is top level ports and driver pins. Pad delays will not be taken into consideration if clocks are defined on nets.
WARNING - set_false_path is being ignored due to errors
WARNING - Removing unused instance inst1_rgb1Pad. VDB-5034
WARNING - Attribute 'attribute_ignored' on Instance 'secured_instance_113_59' in Module 'rvl_jtag_int(NUM_TRACE_SIGNALS=17,NUM_TRIGGER_SIGNALS=4,INCLUDE_TRIG_DATA=1,NUM_TIME_STAMP_BITS=13)' cannot be supported. It will be ignored.

I saw similar things on Altera and Xininx sides as well.

[ataradov]

Yes, warnings like this are common. It is extremely hard to write substantial amount of code that does not have some warnings.

The whole tool ecosystem for FPGAs is stuck in the 90s. And Diamond is one of the worst. It has a nifty feature that lets you promote some of the warnings to errors, but for some idiotic reason it does not work on all warning (actually documented in their manual, so not a bug). And one of those things that can't get promoted is that a net has no legal drivers. One typo and you are in for fun debug session. God, I hate FPGA tools.

Truncated widths and things being stuck at 1 or 0 are mostly normal, especially if it happens in the vendor components. The rest I don't know - have not used that part.

[rstofer]

Some of the warnings, like the mismatched width (32 vs 3) aren't possible with VHDL.  You have to clearly define how the 3 bit signal is created from the 32 bit.  Verilog tends to allow you to go willy-nilly with things and the compiler cleans it up - but not silently.

Even with Verilog, I'll bet you could clean up some of the warnings with a little more work on the code.

In the end, there are warnings  - even with VHDL.  The thing is, you need to read through them because inferring a latch, a really bad thing to do, is not an error, it is a warning.  Of course, your code likely won't work and you can spend days tracking down how you forgot a default state for outputs from a 2 process FSM so, by all means, review the warnings.

[ataradov]

Yes, size 32 truncated to <size> happens when you use constants with unspecified size (a <= a + 1). This is easily cleaned up by specifying the size (a <= a + 1'b1).

The most annoying warnings are about forward declarations. Ir you want to clean up that, you would have to declare everything before use, and that turns the code into unreadable 90s-style mess.

In theory it is absolutely possible to clean up all the warnings, but at some point it just becomes a waste of time and energy, especially if tools refuse to cooperate.

[tchicago]

Even with Verilog, I'll bet you could clean up some of the warnings with a little more work on the code.

Well, if the IP is generated by the vendor's IP wizard, fixing that resulting code is not productive. Any time you want to change that PLL's params will regenerate the IP, and the error will come back. Same thing with the IP that comes in a form of .v files in the vendor's library. Yeah, you can clean that up, but any time the toolset update comes in, it will all be overwritten. Both of these cases are kind of read-only code.

Which is why I'm asking how people deal with the warnings - filtering meaningful from meaningless. Even the same warning from one piece in read-only code could be benign, whereas coming from other place could mean a severe issue.

[rstofer]

I work from the point of view that I'm not the first person to get a warning.  It's better than even odds I can find out the meaning/resolution on Google.  Sometimes it is in a published Errata but it will almost always be on the vendor's forum.

I look at the list and try to figure out which warnings are my fault and which just happen because of the IP or vendor library.  I'm not smart enough to mess around with vendor supplied IP.  If I think I have used the interface correctly, I hit up Google.

From the description of the warning I can take a guess at its importance.  Many are not worth worrying about, inferred latches is always taken seriously.  I would try to resolve mismatched widths (although they seldom happen in VHDL).

'Stuck at 0' just means a signal hasn't been assigned a value except when it was initialized to 0 during loading.  There's a similar warning when a port output isn't assigned a value.  In this case, it might become an error when it is propagated to a higher level.  Unused signals may result in a warning saying that the logic was removed.  A component generates multiple outputs but the higher level doesn't use them all.  Logic will be removed.

You really do need to look through the list and try to figure out which warnings are caused by your code.  You can't simply blow them off.

[Daixiwen]

When you are compiling a project in Altera's Quartus, if you don't get at least a couple thousand warnings from Altera's own IPs you are doing it wrong 
That's why they invented the category "critical warning", meaning warnings you actually need to read

[BrianHG]

When you are compiling a project in Altera's Quartus, if you don't get at least a couple thousand warnings from Altera's own IPs you are doing it wrong 
That's why they invented the category "critical warning", meaning warnings you actually need to read

This I just consider a sad state of affairs where the coders just do not employ proper sound and secure coding techniques, or, during development, they just cant be bothered to clean up their final code.

[hamster_nz]

When you are compiling a project in Altera's Quartus, if you don't get at least a couple thousand warnings from Altera's own IPs you are doing it wrong 
That's why they invented the category "critical warning", meaning warnings you actually need to read

This I just consider a sad state of affairs where the coders just do not employ proper sound and secure coding techniques, or, during development, they just cant be bothered to clean up their final code.

I more think of FPGA warnings in the true sense of warning - "a statement or event that warns of something or that serves as a cautionary example.". The software software mindset that "a warning is an error and needs a fix" is just wrong.

A lot of the warnings are just because the depth of static analysis that can go on while implementing an FPGA design, which is a completely static in nature.

Imagine if a C complier could report  every variable that was actually a constant, or every variable was larger than needed for the range of values it holds,  or when a function was always called with the same parameter value so it isn't needed, or when a variable would not be available during debug, or when each loop was being unrolled for performance,

It isn't an error if my barrel shifter has two 32-bit ports, but I can only use the lowest 5 bits of the 'B' port. That is the way it is suppose to be there is no coding error:

Code: [Select]

WARNING: [Synth 8-3331] design shifter has unconnected port b[31]
WARNING: [Synth 8-3331] design shifter has unconnected port b[30]
WARNING: [Synth 8-3331] design shifter has unconnected port b[29]
WARNING: [Synth 8-3331] design shifter has unconnected port b[28]
WARNING: [Synth 8-3331] design shifter has unconnected port b[27]
WARNING: [Synth 8-3331] design shifter has unconnected port b[26]
WARNING: [Synth 8-3331] design shifter has unconnected port b[25]
WARNING: [Synth 8-3331] design shifter has unconnected port b[24]

Likewise it is no error that the ROM  memory doesn't make use of the buses 'write data' port

Code: [Select]

WARNING: [Synth 8-3331] design program_memory has unconnected port bus_write_data[31]
WARNING: [Synth 8-3331] design program_memory has unconnected port bus_write_data[30]
WARNING: [Synth 8-3331] design program_memory has unconnected port bus_write_data[29]
WARNING: [Synth 8-3331] design program_memory has unconnected port bus_write_data[28]
WARNING: [Synth 8-3331] design program_memory has unconnected port bus_write_data[27]
WARNING: [Synth 8-3331] design program_memory has unconnected port bus_write_data[26]
WARNING: [Synth 8-3331] design program_memory has unconnected port bus_write_data[25]


[ataradov]

The issue with a wall of warnings is that it is very hard to find a new one you just added that actually matters, it just gets lost.

If there was a better system for marking warnings as acceptable and only show new ones, it would also work. But current tools suck, so we have what we have. There is no meaningful way to look at new warnings, if you want to catch them, you have to read though all of them. This is obviously not ideal.

[SiliconWizard]

The issue with a wall of warnings is that it is very hard to find a new one you just added that actually matters, it just gets lost.

If there was a better system for marking warnings as acceptable and only show new ones, it would also work. But current tools suck, so we have what we have. There is no meaningful way to look at new warnings, if you want to catch them, you have to read though all of them. This is obviously not ideal.

I fully agree with hamster_nz, warnings from FPGA tools are very different from warnings issued by software compilers. Whereas I don't tolerate warnings for software, and it's always possible to write code yielding zero warning, it's almost impossible to get to zero warning from HDL to implementation.

But yes analyzing warnings in this context is very time-consuming. I also wish there were a way to mark warnings so they don't show up again, but when you think about it, it would be an extremely difficult feature to implement. Even just a slight modification in the HDL code can yield completely different warnings due to logic being synthesized and optimized in a different way, so I don't know how that could be implemented really.

[ataradov]

I don't know how that could be implemented really.

Trivially actually. Just show me a diff of a log after each run and a button to approve the changes.  This way I would need to review the original once and then just review the changes.

The only thing is that you need to treat each log entry as order-independent and don't compare line numbers in the source, so a simple text diff will not work. But if I marked "design program_memory has unconnected port bus_write_data[31]" as approved once, it should never show up again. And conversely, if it disappears from a new log, I want to know about that too.

Small changes to the code do not result in a lot of changes. It just does not happen in practice.

[BrianHG]

Such warnings like an unconnected port bits may be due to a logic bomb during development where your code never uses or sets such bits, yet you are supposed to.  So, you need to pay attention to all the warnings.

[ataradov]

So, you need to pay attention to all the warnings.

But I only need to pay attention once. And once I said that it is ok that this specific bit is disconnected, the warning should no appear on a summary report. It is fine if it is in the big log, of course.

This way if it all of a sudden ends up being connected by accident at some later point, I would know. With current tools the warning just disappears. And the issue is that warning that is "ok" disappearing is also a bad sign. And with the current tools you will not notice it.

[tchicago]

But I only need to pay attention once. And once I said that it is ok that this specific bit is disconnected, the warning should no appear on a summary report. It is fine if it is in the big log, of course.

And the software industry has long time solved this problem. You just annotate a specific place in your code with "ignore this warning # in this line", and you get a clean compile. Or provide compile option to ignore specific warnings id for a specific compilation unit. So every time something potentially hazardous pops up, it is immediately visible, and can be either fixed or marked to ignore. That way, all this metadata stays as a part of the source code, can be reviewed, versioned, etc.

[ataradov]

And the software industry has long time solved this problem.

Yeah, for sure. But as I said, FPGA tools are literally stuck in the 90s. They just bring in the new device support with no substantial changes to the way things actually work.

Even Xilinx's new and shiny Vivado is still the same pile of garbage under the hood.

[NorthGuy]

I just remember the number of warnings I get from my design. If it is more after a change, I'll look what they are.

[miken]

That's why they invented the category "critical warning", meaning warnings you actually need to read

I really hate that they did this, Xilinx too. A new category to pay real attention to, because everybody knows that regular warnings are mostly ignorable.

Of course, for work I just got asked to review a project with 4 critical warnings, and 1000+ regular warnings 

[BrianHG]

Of course, for work I just got asked to review a project with 4 critical warnings, and 1000+ regular warnings 

So long as the 1000+ warnings aren't from your own coding, there isn't much you can do.
If it is, it is up to you if you want to do house keeping or not.

[Daixiwen]

Yes that's the main problem... most of the warnings come from Altera's own IPs and there is nothing to do about it. It would be nice if it were possible to filter out the warning coming from the manufacturer's own IPs so that you can focus on the warnings from your own code.
AFAIK the warnings about unconnected ports can be solved by explicitly declaring them open for inputs (in VHDL at least, I don't know the Verilog equivalent) or to '0' for inputs. It doesn't change the compiled design in the end, but at least you clearly indicate that you are not using the ports, instead of making a reviewer wonder if you forgot them. Logic that gets optimized away later by the synthesizer generate a note but not a warning.