This is an excerpt from the Chapter 1 of the book
Principles of Verilog PLI by Swapnajit Mittra
published from Kluwer Academic Publishers. ISBN: 0-7923-8477-6
[All copyright reserved. No portion of this text can be used for
for commercial purpose without explicit permission from
the author nor can it be used for re-print in hardcopy
or electronic form.] Order the book here.
PLI - A QUICK TOUR
In this chapter we are going to take a quick tour to get ourselves
acquainted with Programming Language Interface (PLI) of Verilog HDL.
We will go through the essentials of PLI without getting bogged
down by too much of details. Our objective of this chapter would be to
acquire a workable knowledge of PLI so that we can start writing basic
programs. To achieve this, we will take an example of the very basic PLI
activity - reading the value of a register from the design database. Once
we have this we further modify it to do some other basic things
using PLI. At the end, we will review what we have covered in this chapter
and how it forms the basis for moving to the details of PLI.
WHAT IS A PLI ?
Programming Language Interface (PLI) is a way to provide Application
Program Interface (API) to Verilog HDL. Essentially it is a mechanism to
invoke a C function from a Verilog code. The construct which invokes a
PLI routine in a Verilog code is usually called a system call. The common
system calls built-in to most Verilog simulators are $display, $monitor,
WHY PLI IS REQUIRED
As the above examples of built-in PLI routines indicate, PLI is
primarily used for doing such things which would not have been possible
otherwise using Verilog syntax. For example, while Verilog has a way of
doing file write ($fwrite, which is another built-in system call), it
does not have any such construct for reading a register value directly from a file.
There are other examples toowhere PLI is the only way of achieving the
desired results. Some of them are:
Writing functional models
Getting design information - for example, there is no Verilog construct
which gives the name of the parent of the current module in the design