Author Name: Arthur Kahlich
Original Redmine Issue: 969 from https://www.veripool.org
Original Date: 2015-09-25
Original Assignee: Wilson Snyder (@wsnyder)

When I tried to build a model with external C++ code that calls VPI functions, I got tons of linker errors for missing VPI support functions.

I have found that these exist at $VERILATOR_ROOT/include/verilated_vpi.cpp

At the top of the C++ source file containing the vpi function calls, if I change

#include "verilated_vpi.h"

to

#include "verilated_vpi.cpp"

some of the linker errors do go away, but I still then have linker errors. I get rid of the linker errors by having

#include "verilated.cpp"
#include "verilated_vpi.cpp"

at the beginning of the source file containing the VPI function calls.

I presume my VPI function usage in a source file separate from the Verilated model source is a typical usage case.

I would have saved some time by knowing to include both of those .cpp files in my VPI using .cpp file. I realise that if there are multiple source files calling VPI functions that are to be linked in with the Verilated model, then it would be more appropriate to have:

#include "verilated.h"
#include "verilated_vpi.h"

at the start of each such source file. Then the question becomes: does a user then include the verilated.cpp and verilated_vpi.cpp on the original verilator command line after the top level Verilog file name?

When I put those filenames there, they get added to the make variable 'VM_USER_CLASSES', which in turn causes VK_USER_OBJS to be non-empty but apparently still unused. Indeed, when I run make with the top level Verilated toplevel.mk file, I do not see these getting built.

I think I am missing something - and I hope whatever that is makes it into the documentation.