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.

Previous | Next

COMPILING AND LINKING A PLI ROUTINE

When the Verilog simulator encounters a user defined system call, in order to make it understand the existance of the call and properly execute it, the PLI routine has to be compiled and then bind together with the existing binary of the simulator. Though the integration of the PLI code with the verilog binary can be done manually by running c-compiler and merging the object files, it is usually done through a script for convenience. In Verilog XL, a program called vconfig generates this scripts, whose name, by default, is cr_vlog. The program vconfig asks the name of the compiled verilog that you prefer. It also asks whether to include model libraries (which themselves are PLI code) from standard vendors. At the end it asks for the path for your veriuser.c file(s). Once the script cr_vlog is generated, just by running it one can get the new Verilog simulator binary which would recognize the user defined system call.

RESULTS OF RUNNING THE PLI ROUTINE

A sample run of the compiled Verilog having our PLI routine producesthe following output for Verilog-XL simulator.

=============================
VERILOG PLI FIRST_ATTEMPT
($print_reg)
=============================
Compiling source file "test.v"
Highest level modules:
my_module
$print_reg: The value of the specifiedregister is 15
$print_reg: The value of the specifiedregister is 3
L9 "test.v": $finish at simulationtime 400
15 simulation events
CPU time: 0.2 secs to compile + 0.1secs to link + 0.0 secs in simulation
End of VERILOG-XL 2.2.1 Jun 1, 199722:44:02

Self-test :
Repeat this experiment to a wire. The system call should readand print the value of the wire. Run the PLI routine on a net which istri1, rather than wire. Check its value when nobody is actively drivingit.

GETTING THE SIMULATION TIME

Although the PLI routine in the previous example worked as expected, from the result one can see there is one serious fault - from the result there is no way to figure out the simulation time when the register changed the value. With multiple invocation of this routine (as in this case) the problem becomes even worse.

This can be solved using another utility function tf_gettime()which tells the current time of the simulation. This has been done in a new revision of our calltf routine below by making minor modification tothe existing code. Also for convenience, the value of the register is displayed in hexadecimal rather than decimal.

void my_calltf(){
io_printf("$print_reg : The value of the specified register at time %d is %h", tf_gettime(), tf_getp(1));
}

As shown in the routine, tf_gettime() returns the current simulation time and it does not need any input parameter. A sample run of the modified version of our routine give the following output.

=============================
VERILOG PLI FIRST_ATTEMPT
($print_reg)
=============================
Compiling source file "test.v"
Highest level modules:
my_module
$print_reg: The value of the specified register at time 100 is a
$print_reg: The value of the specified register at time 300 is 3
L9 "test.v": $finish at simulationtime 400
15 simulation events
CPU time: 0.2 secs to compile + 0.1secs to link + 0.0 secs in simulation
End of VERILOG-XL 2.2.1 Jun 1, 1997 23:44:02