VPI DEBUG

INTRODUCTION

You can add new functionality to a Verilog simulator such as VCS by
linking in your C code. You can also call C code from OpenVera
testbenches. Perhaps you have a C model, made of routines in the file

model.c, and invoked with the Verilog system task $model. The C code
is known as the application, and will consist of one or more routines.
The connection between the application and the simulator is the PLI,
the Programming Language Interface. The application will be called
during simulation either directly, when VCS executes the system task
for the application ($model), or asynchronously when VCS is doing an

activity such as initialization or shutdown.

Alternately, you want to call a C routine such as log2() directly
using VCS DirectC interface, or the new DPI (Direct Procedural
Interface) that is part of SystemVerilog. Only the linking differs.

COMPILING

You must do several steps to debug the C application. The C code must
be compiled for debug, linked with the Verilog code, the simulator

must be started with the debugger, and a breakpoint needs to be added
in the application. This guide only covers using the GNU gcc compiler
and the matching gdb debugger. Other tools will have a similar flow.

First, the C code must be compiled with -g so that its debug symbols, such
as variables and routine names, will be visible at run-time.

 gcc -g -o model.c -I${VCS_HOME}/include

The -o switch tells gcc to create object code (model.o) and not an
executable. The -I switch points to the VCS include files that define

constants and the PLI routine names.

Next link the C code into your simulation:

 vcs design.v -P model.tab model.o

The Verilog code is in design.v, your C code is in model.o, and
model.tab tells VCS which C routines to call when $model is used in
the Verilog. This produces the executable simv.

Alternately, you can compile the Verilog and C code together.;Use the

VCS -CFLAGS option to pass flags to the C compiler:

 vcs design.v -P  model.tab model.c \ -CFLAGS "-g -I${VCS_HOME}/include" 

If you are using DirectC, you don't need a table file:

 vcs +dc design.v model.o

COMPILING ATC Testbenches using Rake

Currently, rake does not support extra CFLAGS to be passed to VCS or Modelsim. One has to run rake with the v=1 option, which will display the commands, not invoke them. Then, by virtue of copy & paste, you can edit the command and add the -g flag into the -CC field.

 rake test:test16 v=1

  ... ...
  vcs -full64 +warn=noSV-LCM-PPWI +v2k -sverilog +cli -q -debug -CC "-Wno-write-strings -I${VCS_HOME}/include ... "
  add the -g option into the quoted string following the -CC vcs option. Like so:
  vcs -full64 +warn=noSV-LCM-PPWI +v2k -sverilog +cli -q -debug -CC "-g -Wno-write-strings -I${VCS_HOME}/include ... "

Run it, and proceed to the next section.

RUNNING THE DEBUGGER

Now you are ready to roll! Start the debugger and tell it which
executable to use:

 gdb simv

(gdb)

Here you can set a breakpoint on a C routine:

 (gdb) br model_call

 Breakpoint 1 at 0x8050ba6: file model.c, line 12.

Now run the simulation, specifying the command line switches to use with simv:

(gdb) run -l simv.log

Starting program: /disk/user/simv

Chronologic VCS Simulator copyright 1991-2004

Breakpoint 1, model_call() at model.c:12

(gdb)

Now you can step through the code (step and next), print variable
values (print and x), look at the call stack (bt) and other debugger
tricks. If you run gdb inside Emacs (M-X gdb) you can see the source

code in one window while the debugger runs in the other.

This guide only shows how to debug code linked directly with VCS, not
shareable code. Shareable code is only loaded into memory when
needed, not at the start of execution. So you can not set a

breakpoint on your code when gdb loads the executable as your code is
not in memory yet.