Site hosted by Angelfire.com: Build your free website today!

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 ( gururajk@mindtree.com) 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 inactive level.
    • Ports should be declared in the order - inouts first, outputs next and inputs last.
  • 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:

   $lint_check(["check_name"],["check_port"], ["check_if"]);
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.

Download

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.



© Vineyard Research Inc. 2001