Dragging RTL Creation into the 21st Century

When I was at Atrenta, we always thought it would be great to do as-you-type RTL linting. It’s the natural use model for anyone used to writing text in virtually any modern application (especially on the Web, thanks to Google spell and grammar-checks). You may argue that you create your RTL in Vi or EMACS and you don’t need no stinking GUI. I have bad news for you – you are now officially part of the older generation. “Kids” graduating these days expect GUI support for any code they create. So get used to it.

Naturally there are limits to how far you can take real-time checking. It would be neither practical nor useful to launch CDC or formal analysis every time you hit the space or Return key. But that’s not what up and coming developers expect. They want the editor to flag and, if appropriate, correct the basic errors. This is especially important for VHDL development, which can be particularly challenging for VHDL novices (in which group I count myself). I should add that Sigasi provides similar capabilities for Verilog and for mixed-language.

On VHDL, you might argue “who cares – everything I do is in Verilog”. That purist stance is more difficult to sustain these days. Perhaps you have to integrate an Imagination Technologies GPU into your SoC (or one or more of many other IPs) and you need to add power management or other tweaks to support your integration. You’re going to have to deal with VHDL and the less experience you have, the more mistakes, you’re going to make (and the more time you’re going to spend trying to understand those mistakes). I can personally vouch for this. A language-aware editor would have made my life a lot easier.

Sigasi, based in Belgium, has created just such a linting capability, embedded in their Sigasi Studio product line. The base set checks for a wide range of common mistakes in VHDL:
· Unused declarations
· Duplicate declarations
· Declaration could not be found
· VHDL 2008 features in VHDL 93 mode
· Assignment validation
· Case statement validation
· Instantiation statement validation
· Library validation
· Range validation
· Deprecated and non-standard packages
· Duplicate, conflicting design unit names
· Missing return statement in function bodies
· Missing, unnecessary and duplicate signals in the sensitivity list
· Port, signal, variable, constant or generic declarations that are never read or written

A more advanced set checks for:
· Null range error
· Use of deprecated packages
· Redundant use of OTHERS
· Defining function bodies inside packages
· Infinite loops and processes without sensitivity lists
· Incorrect use of whitespace in some contexts
· Reference to unneeded libraries
· Unused declarations for ports, generics, signals, etc
· Incomplete and over-specified sensitivity lists

The most advanced version includes checks for:
· Dead states in FSMs
· Inaccessible code
· Objects never written or never read
· Naming conventions
· Consistent capitalization
· Case references
· Incomplete associate optional
· Positional association in instances

I’d like to call out a couple of these checks since they may seem like “wow, who really cares”, where in fact they can bite you badly. Start with naming conventions. Like it or not, a lot of in-house checks and generation tools depend on consistent naming conventions to drive connectivity creation and checking. Automatic connectivity creation tools are completely dependent on you following consistent naming conventions. Such a tool will automatically connect together AHB_PCI_SLAVE (on a PCI IP) and AHB_PCI_SLAVE_MIRROR (on the AHB bus), but will ignore the connection if you didn’t follow the convention. Some relatively simple name checking can save you a whole lot of problems.

Then take consistent capitalization. VHDL doesn’t care about capitalization, but this can lull you into a false sense of security. Capitalization does matter when you get to a Verilog/VHDL interface, because Verilog does care about capitalization and you’ll not get a connection if this is wrong. Both this problem and the preceding problem are good examples of things that will seem perfectly fine while you’re working on an IP but will bite you in integration (and it may take quite a while to figure out why).

Sigasi analysis will generate informational, warning and error flags and will indicate where quick fixes are available (I really wish I had those when I was messing with VHDL). The Studio applications in which the linter is available come (optionally) in an Eclipse app, so should plug in easily to common RTL development environments.

You can learn more about Sigasi check-as-you-type capabilities HERE.

More articles by Bernard…