Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
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
some of the linker errors do go away, but I still then have linker errors. I get rid of the linker errors by having
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:
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.
Original Redmine Comment
There were several usability problems with VPI, most critically being as you noted verilated_vpi.cpp/h must be included in a single user source file. Added the new --vpi switch to fix this, moved code so can multi-include the header file, and updated documentation.
Fixed in git towards 3.877.
BTW note the VPI hooks are very limited, as described in the documentation.
Original Redmine Comment
Thanks for that.
Yes, the documentation does not describe what is/is not supported. However, for the VPI functions I am using it was pretty simple to look at the code in verilated_vpi.h for the most part - and see what was and was not there. I don't know if you are using something like doxygen for some of the documentation, but that type of tool is about the only realistic way I can think of to keep the doc in sync with what is supported when you don't have enough man hours to do separate documentation maintenance. Also, different contributors would bring differing levels of rigor to that process.