( ESNUG 421 Item 3 ) -------------------------------------------- [12/10/03]
Subject: ( ESNUG 403 #5 ) HAL, LEDA, Verilint, HDLLint, Surelint, SpyGlass
> Our little company will soon be looking for a Verilog linter. We don't
> need a 5-figure, GUI-heavy "Design Analysis tool". We just want a
> linter. Preferably something straightforward and inexpensive (ideally,
> like Verilint before it was sold to Avanti.) I'm guessing there are
> some good tools out there filling the price/functionality space that
> Verilint left behind, but being from smaller outfits they may not be
> well marketed. I was wondering if anyone had any recommendations. I
> was also wondering what experience people have had with Cadence's "HAL"
> Linter.
>
> - Jeff Winston
> Engim, Inc. Acton, MA
From: Jeff Winston <jwinston=user domain=engim spot calm>
Hi John,
Since the ESNUG community helped me start my search for a worthy lint tool,
I thought it was appropriate to let you all know how it turned out.
Background: I started by searching the web and polling ESNUG users for
possible options. I ruled out Verilint and Surelint because at the time
neither had Verilog 200x in their roadmap. I also ruled out Verity-Check
Designer and SpyGlass as they seemed to have a different primary focus
than pure linting. (My apologies if I mis-read their websites). This
left me with HAL, VnCheck, HDLLint, and LEDA. I tried out all four tools
last spring (sorry for the delay in the writeup), and my assessments are
below.
What I was looking for:
I was a past fan of Verilint, and so I was looking for an easy-to-use,
minimal-setup, command-line based Verilog linter. GUIs did not interest
me, and I did not check them out. It had to be easy to review the output,
and there needed to be a minimum of false positives and bugs.
For rules, I wanted a tool that came, out-of-the-box, with a rule set
slightly more conservative than I needed. If it was a lot more
conservative it would take me forever to pare the rule list down, and
if it was less conservative I would be missing checks that I needed.
I didn't expect any tool to have exactly the rule set I wanted, but I
wanted to be able to reduce the rule set to something usable with a
limited amount of effort. I also wanted to be able to block it from
checking part of the design (the best way, in all cases, turned out to
be to simply not load the files I didn't want it to check). I tested the
linters on completed designs, as well as on some fractured first-pass
code. Here's what I found:
Cadence HAL -- I checked this tool (from Cadence) out briefly last fall.
At the time, it required prior successful elaboration (using ncelab) and
so had limited use as a syntax checker on first-pass code. I understand
that they are improving the tool and adding some syntax checking, but I
didn't have time to check it out again. Others looking for a linter, who
already have NC-Verilog in-house, should probably check out HAL (and
please publish your findings!)
TransEDA VnCheck -- This tool is part of the VnNavigator suite. I got the
sense that the GUI was slick (including something that converts RTL state
machines to state diagrams), but the lint functionality had some issues.
It was hard to find an out-of-the-box rule set that met my requirements,
and to modify the rule sets I had to make local copies of the rules
files and edit them (not a big deal as they were ASCII). One pain was
that most lines in the reports were in excess of 240 characters with the
important information on the far end. The tool was also the slowest I
used (its Java-based). The largest problem was that many rules generated
false positives. To TransEDA's credit, they put me in contact with a
developer. He was already aware of almost all of the tools' drawbacks,
and said all my concerns would be addressed in a major Q4 '03 update.
So, their Q4 release may well be worthwhile, and people shopping after
its release should probably check it out and publish your findings! :)
Synopsys LEDA -- This was the most thorough and robust tool I tested, and
I used its output as the reference to check the other tools. For the site
that wants to set up and maintain its own rule sets, LEDA provides plenty
of capability and documentation to do this. Out-of-the-box, its standard
rule sets overlap somewhat, so some single problems can each generate more
than one error message, and if you're not interested in a rule, you may
have to turn it off several places. However, all of this can be mitigated
if you do your own rule management.
LEDA is the only checker that copies the line that generates the message
to the output file, and actually underlines the offending section of the
line. However, LEDA does generate rather large output files, and its
format doesn't lend itself to quick review. A problem with a bus can
generate messages for each bit of a bus, and an LHS variable in a case
statement without a default produced a message each time the variable
was used. LEDA also sometimes lumps different conditions into the same
message, like "Missing or redundant signal in the sensitivity list of an
always block", or "Non driven output ports or signals detected" (the
latter could be an (nasty) undriven wire, or just an (inconvenient)
unused wire). The tool also generated a few false positives, most
notably around asynchronous loop detection, but I think LEDA was the
only tool that tried to do this check.
Like other linters, LEDA makes multiple passes, so the information about
one construct and/or module can be in several places. I'm told LEDA
provides an option to write the messages related to each module to a
separate file, so if you used this option and concatenated the outputs
you'd have something more organized. Overall, LEDA was the most solid
tool I used as it ran fairly fast, had no hangs, and a minimum of
obvious bugs. If you have the resources to manage your rules, and are OK
with the output, LEDA is a safe choice.
Veritools HDLlint -- This tool is closest in spirit to Verilint. It's
available with a GUI (called G-Lint) for additional cost. When I did the
evaluation they had planned to support Verilog 2001 this year. Unlike
LEDA, the parser doesn't stop on a syntax error, so you can check all of
a poorly-written file in one pass. The rule set out-of-the-box was close
to what I needed, and trimming it down was a straightforward 1-2 hour
task. The output was concise and easy to read. It was the only tool that
used summarization so that an error on a 32-bit bus produced one error
rather than 32. A LHS variable in a case statement without a default
produced one message rather than one message for each time the variable
is used. Their "one-line" format was well organized and easy to read.
Like the other tools, HDLLint makes multiple passes, but it's easy to
sort the one-line-per-message output.
The biggest minus was that I found a few bugs. These included problems
with how it flagged un-driven or floating signals, a situation where
disabling one message could inadvertently disable others, and another
where the existence of some high-priority "Error" problems would mask
other important "Warning" messages. Also, a few rare but valid
constructs were flagged as having problems. To the credit of Everest
Design Solutions, they were interested in my bug reports, and fixed all
my bugs within a couple of weeks. They even added a feature I requested
(un-truncated one-line-per-message reporting). Although there seems to
be little sense to how messages are assigned "Error", "Warning", or
"Note" status, this designation is easy to ignore, and so my only
remaining peeve is that there's no way to get a readable index of all
the rules.
Bottom line, though, if you want something inexpensive, easy to setup and
use, and are OK with something a bit less authoritative than LEDA, HDLLint
is a reasonable choice.
Thanks to everyone in ESNUG 403 #5 who replied to my original request.
- Jeff Winston
Engim, Inc. Acton, MA
|
|
