A Personalized Lint-checker using PLI2.0
Ok, ok, so admittedly there are commercial
Verilog lint checkers out there (which are very useful or verbose depending
on your perspective). But, apart from all the syntax, semantic and
synthesis rules these linters check for you, there are these other
rules that you follow on your own. This is your individual coding style
developed over time. When sticking to a good coding style is always
advisable, it becomes particularly important for members of a team
to follow some generic guidelines for coding. In this article, Gururaj
Kulkarni ( firstname.lastname@example.org)
shows you how to check for some rules in your code, so that it does not
become too unwieldy within a team.
Within a team, it is essential that all members follow a common coding style.
This increases the readability as well as the maintainability of the code.
At the same time it will be rather time-consuming for anybody to spend time
to 'verify' if a certain set of rules have been followed while writing the code.
Make PLI Your Errand Boy
The next logical thing to do in order to achieve this verification is to automate
the process. Let me show you how to do this using PLI. We will start with a
list of rules below that we intend to check using a PLI application. You can
alter or add to the code easily to suite your need.
Rules that I want to check
Here are the rules that I want to check.
Naming of variables:
- All names should not be more than 20 characters or less than 3 chars.
- Any name should not use more than 3 underscores.
- Any name should not use uppercase letters.( They are reserved for special purpose.)
- All the instance names should be of the form u*.
Port related checks:
- All the ports should be connected. If a perticular port of a perticular
instance not requires to be connected, then it should be connected to
- Ports should be declared in the order - inouts first, outputs next and
if related checks:
- If-else levels should not exceed 5.
- The statement(s) that follows an if statement should be followed in next
line for more readability.
Planning the implementation
My preference was to use vpi routines to implement this
application, which I decided to call $lint_check. I planned
the usage of the application as shown below:
where the option check_name performs the lint checking for the
names of the variables etc. Options can be given in any order and
one, two or all three of the above checks can be done with one call
to $lint_check. An error is printed if invalid options/no options
are given. There is no return value from the application (making it a
task, rather than a function. Instead it prints
an error message wherever a lint voilation is found.
Typically $lint_check is called in an initial block in a dummy
module and is compiled with the actual design to be lint checked.
Click here to download the gzipped
tar-ed source code lint_check_whole.tar.gz for this application. Once you
gunzip and untar the file, it will create a directory named
lint_check. Under this directory, there is a shell script
get_lib and a Makefile. You can use either of them to
generate the .so library. Link this library in when you compile your
Verilog files. Note that the shell script as well as the Makefile
have been written for NC-Verilog environment. However, you can
modify these files easily if you use a different simulators.
This application has been tested with NC-Verilog from Cadence Design Systems.