SNUG San Jose 2002 3 Using PLI 2.0 (VPI) with VCS / Stuart Sutherland
ferent functionality and values. Because PLI 2.0 was not backward compatible, the hundreds of
existing PLI applications could not be used together with a PLI 2.0 application. Therefore, no
simulators ever completed implementing the OVI version of the PLI 2.0 standard. The original
OVI “PLI 2.0” never saw the light of day.
1995: The IEEE 1364-1995 standard
1
and the VPI library. In 1995, the IEEE standardized
both the Verilog HDL and PLI the way it stood in 1993. No enhancements were considered for
1364-1995. For the PLI, the IEEE chose to standardize both PLI 1.0 and 2.0. The former, to pre-
serve backward compatibility. The latter, because it really was a much better procedural interface.
To allow both the old PLI 1.0 and the incompatible PLI 2.0 standards to be used at the same time,
the IEEE rewrote the PLI 2.0 so that it was backward compatible. As part of that process, the PLI
2.0 routines were renamed to “VPI” (for “Verilog Procedural Interface”).
Note: In the IEEE standard, the terms “PLI 1.0” and “PLI 2.0” do not exist. There is one PLI,
with three libraries, TF, ACC and VPI.
2001: The IEEE 1364-2001 standard
2
. The IEEE spent three years defining a major set of
enhancements to the Verilog standard. These enhancements were ratified early in 2001. The new
Verilog-2001 standard adds a number of powerful enhancements to the Verilog HDL, including:
multi-dimensional arrays, re-entrant tasks, recursive functions, configurations, attributes (which
can replace those annoying synthesis pragmas hidden in comments), and several dozen other use-
ful and important features. For more details on these features, refer to the SNUG San Jose 2001
Conference paper, “Getting the Most out of IEEE 1364-2000 Verilog Standard”
3
.
2.0 Why use the VPI library?
To understand the advantages gained by using the VPI library, we must first look at the strengths
and weaknesses of the older TF and ACC libraries.
2.1 Strengths and weaknesses of the TF library
The TF library can only access the arguments of a system task or function. Due to this limited
access, simulators can predict at compile time exactly what information a PLI application will
access. This allows simulators to highly optimize the simulation data structure. VCS takes full
advantage of this, and achieves its best simulation performance when only the TF library is used.
However, the TF library cannot traverse design hierarchy, analyze design structure, modify
delays, or access RTL code. This greatly limits the types of PLI applications that can be written
with the TF library. Originally, the TF library contained just a few C functions. Over a number of
years, however, the library evolved until it grew to have more than 110 C functions. This growth
occurred with no specification to guide the evolution. As a result, the library is full of inconsisten-
cies and redundancies. The TF library also has a great number of problems with portability to dif-
ferent simulators and different operating systems. Hence PLI applications do not work the same
way on all simulators. In part, this portability problem stems from the fact that the TF library was
originally designed to work with just the Cadence Verilog-XL simulator, in the days of DEC PDP-
11 computers. The TF library does not support many of the new constructs added in the IEEE
1364-2001 standard.