VHDL Linting Tool
Analog Guy
made reference to VHDL linting tools, and I found some mention of
this on the internet.
What exactly does this give you over and above what the ModelSim compiler
gives you as far as warnings and errors in your VHDL code?
Mike Treseler
The Modelsim compiler syntax errors and leo synthesis warnings
about unused objects are more than enough for me.
VHDL is pretty fussy as is.
Can't imagine what else there is to find.
-- Mike Treseler
Allan Herriman
<mike.t...@flukenetworks.com> wrote:
>Analog Guy wrote:
>
>> Through some reading, I came across mention of software linting tools. It
>> made reference to VHDL linting tools, and I found some mention of
>> this on the internet.
>>
>> What exactly does this give you over and above what the ModelSim compiler
>> gives you as far as warnings and errors in your VHDL code?
>
>
>The Modelsim compiler syntax errors
By default Modelsim ignores many errors. Some things that are errors
are downgraded to warnings, and some are ignored altogether.
To fix this, edit your modelsim.ini file and turn PedanticErrors on,
Explicit off, and range checking on. (The exact string used to
control range checking varies with the version of Modelsim.)
>and leo synthesis warnings
>about unused objects are more than enough for me.
>VHDL is pretty fussy as is.
>
>Can't imagine what else there is to find.
Unwanted or poorly implemented clock domain crossings.
Unconnected nets.
Missing resets.
etc.
Regards,
Allan.
Michael P. Jenkins Brown
> Analog Guy wrote:
> The Modelsim compiler syntax errors and leo synthesis warnings
> about unused objects are more than enough for me.
> VHDL is pretty fussy as is.
>
> Can't imagine what else there is to find.
Modern VHDL linting tools are usually programmable. They let you
define exactly what you want to look for in your code. They may also
come with a set of standard rules for coding for synthesis,
simulation, etc.. So one could use a linter to enforce coding
guidelines across a team. One could also use a linter to automate
code/design reviews.
For example, let's say your team has decided to register all flops on
the rising edge of the clock. ModelSim will compile your code with no
problem if you've ignored the rising edge rule. Synthesis might give
you a warning if the library you're compiling to dosen't support
falling edge flops. But a linter can be programmed to report "Hey,
this flop is falling edge when it should be rising!" (or something
like that).
Another example is file header information. Perhaps your company has
a rule that every VHDL file must have "Copyright <current year>
Chips-R-Us" in the first four lines of code. ModelSim can care less
about this rule, which actually has nothing to do with your VHDL code.
Again, you could program a linter to hunt down the copyright in a
file and report an error if none is found.
When a design was up for review at my last job (many years ago), 5 or
6 engineers would get together for an hour or so and review the code.
We would go through the code line by line, checking to see that all
coding guidelines and rules were observed. Of course, this was a
tedious, error prone, and expensive process.
The ideal scenario would be to automate code/design reviews by
integrating linting into the revision control process. Imagine this:
As an engineer checks his/her code into the repository, a script runs
in the background that scans the code for coding guideline violations.
If there are any violations, the code can't be checked in. The
engineer gets a report with the violations and is tasked to correct
them before trying to check the code in again. As a result, anyone
using code from the repository can be (fairly) sure that the code
meets whatever guidelines have been set.
If you're interested in VHDL linting, you might take a look at the
following tools:
NLint, Novas (www.novas.com)
Vn-Check, TransEDA (www.transeda.com)
LEDA, Synopsys (www.synopsys.com)
Regards,
MPJB
Srinivasan Venkataramanan
To add few more to what others have said in support of Lint tools:
1.> Lint tools run much faster and can detect errors (like range checking)
which various tools catch during various phases (some tools have separate
elaboration step, others don't, for instance).
2.> Comparatively they are cheaper and few licenses are enough (don't count
on this "cheaper cost" - I didn't do a market survey of their costs, but am
saying in a general perspective).
3.> We can have DFT related guidelines coded right in Lint tools, which
otherwise might bite you later in the cycle.
4.> Few linters promise to do "post elaboration" checks which can identify
cross clock domain issues, hierarchical connection issues etc.
5.> For IP developers the lint reports (if they were with 0 errors/warnings)
can be another "Quality" metric (such as 100 % in conformance with RMM for
instance).
Regards,
Srinivasan
--
Srinivasan Venkataramanan
ASIC Design Engineer
Software & Silicon Systems India Pvt Ltd. - an Intel company
Bangalore, India
I don't speak for Intel
"Mike Treseler" <mike.t...@flukenetworks.com> wrote in message
news:3CD9AFCF...@flukenetworks.com...
Stefan Doll
> The Modelsim compiler syntax errors and leo synthesis warnings
> about unused objects are more than enough for me.
> VHDL is pretty fussy as is.
>
> Can't imagine what else there is to find.
Well, what I'd like to see is things like this:
- detect unused signals variables etc
- detect multiple drivers on signals which are never tri-stated
- detect missing reset clauses
- detect missing signals in sensitivity lists (but not in
clocked processes, otherwise the warnings are useless...)
- detect range mismatches on signal assigments etc
- detect code which is not synthesizable with some tools
(e.g. some stuff runs fine with exemplar, but not with
Synopsys, so there should be a "Synopsys Warning" or an
"Exemplar Warning", ideally configurable for what you
really want to check for)
Coding style checking... well I'm not sure about that. I suspect
if the coding styles are all that complex they probably waste more
time then they could possibly save. Still there may be some value
in that, too.
I haven't really used any linting tools for VHDL, does anyone know
of any which would implement these features?
Cheers
Stefan
Tom Verbeure
> Well, what I'd like to see is things like this:
> - detect unused signals variables etc
> - detect multiple drivers on signals which are never tri-stated
> - detect missing reset clauses
> - detect missing signals in sensitivity lists (but not in
> clocked processes, otherwise the warnings are useless...)
> - detect range mismatches on signal assigments etc
> - detect code which is not synthesizable with some tools
> (e.g. some stuff runs fine with exemplar, but not with
> Synopsys, so there should be a "Synopsys Warning" or an
> "Exemplar Warning", ideally configurable for what you
> really want to check for)
>
> Coding style checking... well I'm not sure about that. I suspect
> if the coding styles are all that complex they probably waste more
> time then they could possibly save. Still there may be some value
> in that, too.
>
> I haven't really used any linting tools for VHDL, does anyone know
> of any which would implement these features?
I recently looked at both VN-Check from TransEDA and SpyGlass from Atrenta.
They both do all the stuff you mentioned above and much more. SpyGlass
actually synthesizes your whole design into an intermediate format and, as
such, will even find combinational loops across multiple modules and all
kinds of testability issues.
Tom
Mike Treseler
Stefan Doll wrote:
> Well, what I'd like to see is things like this:
> - detect unused signals variables etc
Leo elaboration gives warnings for these
> - detect multiple drivers on signals which are never tri-stated
Modelsim vcom does this for std_ulogic.
> - detect missing reset clauses
I don't have a script for this, but using
emacs vdhl-mode: VHDL, Templates|Models,
will prevent them from being born.
> - detect missing signals in sensitivity lists (but not in
> clocked processes, otherwise the warnings are useless...)
emacs: VHDL,Update,Sensitivity List, finds and fixes
> - detect range mismatches on signal assigments etc
Modelsim vcom does this.
> - detect code which is not synthesizable with some tools
> (e.g. some stuff runs fine with exemplar, but not with
> Synopsys, so there should be a "Synopsys Warning" or an
> "Exemplar Warning", ideally configurable for what you
> really want to check for)
That would be nice, but it's a moving target.
> Coding style checking... well I'm not sure about that. I suspect
> if the coding styles are all that complex they probably waste more
> time then they could possibly save.
I agree. You could get consensus on a few things,
but you could also get discontent.
> Still there may be some value
> in that, too.
Might work in large organizations that can afford a style cop.
> I haven't really used any linting tools for VHDL, does anyone know
> of any which would implement these features?
I haven't either. Hope to hear a glowing review from the group.
-- Mike Treseler