Learning FPGAs: Heed the Warnings

After many interesting and sophisticated columns by other bloggers here on All Programmable Planet, I think it's about time to return to the basics with another entry in my "Learning FPGAs" series. This time, I will talk about one thing that people always seem to take for granted -- WARNING messages.

Why is this so? Well, as long as the code compiles (which means it does not encounter any ERROR messages), everything should be fine -- at least, that's what most programmers think.

In the software programming world, warnings can occur due to poor coding style (e.g., unused or uninitialized variables), poor pointer (memory) handling, and so forth. Most of the time, if the software code passes the compilation process and the executable runs, it's assumed that the code is working properly, unless it encounters some run-time errors that force the programmers to revisit the code and track down the fault.

By comparison, in the hardware programming world, warnings must be treated more carefully, because sometimes your system might not be behaving the way you think you've described it. In fact, sometimes a warning might cause more harm to your system than an error. This is because an error stops you from generating an image, but an unheeded warning allows you to continue and generate an image that may result in a problematic system.

It may be that warnings have less impact on software programming because the software developers are creating a program to run on a fixed architecture, whereas in hardware programming, the code is actually defining the datapath and the architecture itself, so the cause of a warning in the code might actually modify a substantial part of the datapath or the architecture in a programmable device.

When RTL code is synthesized, and is subsequently passed through place-and-route, you might be presented with any and all of the following warnings:

• Timing requirement is not met (this should be treated as critical)
• Generated/Inferred latches
• Gated clocks
• Pruned unused nets and registers (common)
• Optimized nets and registers (e.g., retimed)
• etc.

Warnings that are caused by not meeting one's timing requirements is a big topic by itself, and I won't be covering it in this blog. If you Google this, you will see that many people are discussing timing issues or timing closure, and the proper constraints that need to be set.

Latches, as I have discussed in my earlier blogs (Don't Make My Mistakes and The Wonders of the If-Else Statement), are generated by incomplete CASE or IF-ELSE assignments in asynchronous logic. In this case, you need to revisit your code and complete the assignment so that you can save the resources inferred as latches.

Gated clock design (i.e., using an output net as a clock signal to another piece of logic) is not recommended in the RTL code due to excessive skews. Based on the device architecture in question, you may feed the net through a clock buffer before connecting it to your desired logic, or you may use an additional clock enable signal to control the rate of a process.

Some warnings can be safely ignored, like "Pruned unused nets and registers," as can some "Optimized nets and registers." But it's always good practice to look through your code at least once when you encounter these warnings during the first compilation.

My main point is that although some warnings might be trivial, you should still look at them and make sure you understand them. It's important to bear in mind that sorting any problems out early in the process can save you a lot (and I mean A LOT) of time. It's better to spend your valuable time working on important things rather than spending days debugging problems that were caused by whatever caused the warning messages to be issued in the first place (the messages you ignored because you didn’t think they were important).

So, here are a few tips from me with regard to tackling the warnings in the design:

1. Keep track of the number of warnings in the current working project.
2. When adding new code or modifying existing code, observe the changes in the number of warnings when you re-compile (synthesize and run place-and-route).
3. Track any new warnings and see whether you need to make any corrections or not.

Now, I know that many of the members here on All Programmable Planet have a lot of experience, so I would welcome hearing about any other tips and tricks you would care to share regarding warning messages and how to handle them.

Related posts:

• Learning FPGAs: Don’t Make My Mistakes!
• Learning FPGAs: The Wonders of the If-Else Statement