Way to run vvp programatically, and receive call-backs to self?

[hughperkins]

Hi,

I want something like the following architecture:

[c++ program]
       => contains vpi methods
       => launches vvp on a vvp file
       => vvp file calls back into the c++ program, via vpi methods, once a clock cycle
       => at some point the vvp run finishes, and control returns back to the c++ program

The idea is that my vvp file is a GPU under simulation, and my c++ program is like an OpenCL program, which contains an OpenCL kernel. The C++ program compiles the OpenCL kernel, and feeds that to the GPU, via vpi calls from the GPU simulator. Once the GPU has received the kernel, the GPU can launch the kernel, finally returning the results to C++, via more vpi calls.

So, vpi works for me 🎉 The missing bits, I think (though I might find others), is:

• how to launch vvp programmatically, and
• how to have the vvp call back into the c++ program itself, i.e. treat the c++ program as a vpi module?

[hughperkins]

(like, an ideal option might be if vvp can be compiled as a shared object, and linked to, like -lvvp, and the calling program can contain the methods that would normally go into the vpi file, and vvp would simply find those names within the exisiting process?)

[hughperkins]

So, this is kind of a mess, but proof of concept at https://github.com/steveicarus/iverilog/compare/master...hughperkins:hp/poc-vvp-so?expand=1 It's a mess because this combines:

• modifications to vvp to make it build as libvvp.so (add lib_entry.cc ,and build libvvp.so)
• lib_entry.cc is pretty unclean
• the Makefile changes to build libvvp.so are pretty unclean
• it includes also demo/poc code to run this, i.e. testclient.cc and hello.sv

That said, it runs. It does assume that iverilog is built into install.d, at the root of the cloned iverilog repo. That being the case, to run the demo:

./configure --prefix=$PWD/install.d
make -j 8
make install
export PATH=$PWD/install.d/bin:$PATH
cd vvp
./run.sh

The output will hopefully resemble:

$ ./run.sh 
+ make
echo vvp exe ext vvp
vvp exe ext vvp
g++ -shared -Wl,-all_load   -o libvvp.so main.o parse.o parse_misc.o lexor.o arith.o array_common.o array.o bufif.o compile.o concat.o dff.o class_type.o enum_type.o extend.o file_line.o latch.o npmos.o part.o permaheap.o reduce.o resolv.o lib_entry.o sfunc.o stop.o substitute.o symbols.o ufunc.o codes.o vthread.o schedule.o statistics.o tables.o udp.o vvp_island.o vvp_net.o vvp_net_sig.o vvp_object.o vvp_cobject.o vvp_darray.o event.o logic.o delay.o words.o island_tran.o vpi_modules.o vpi_bit.o vpi_callback.o vpi_cobject.o vpi_const.o vpi_darray.o vpi_event.o vpi_iter.o vpi_mcd.o vpi_priv.o vpi_scope.o vpi_real.o vpi_signal.o vpi_string.o vpi_tasks.o vpi_time.o vpi_vthr_vector.o vpip_bin.o vpip_hex.o vpip_oct.o vpip_to_dec.o vpip_format.o vvp_vpi.o -lbz2 -lz -lpthread -lreadline -ltermcap   -ldl
+ iverilog -g2012 -ohello.vvp hello.sv
hello.sv:21: warning: @* found no sensitivities so it will never trigger.
+ g++ -I../install.d/include/iverilog -c test_client.cpp
+ g++ -o test_client test_client.o -L../vvp -lvvp
+ ./test_client
Warning: vvp input file may not be correct version!
i 0 111
i 1 321
i 2 444
i 3 x
i 4 x
i 5 x
i 6 x
i 7 x
i 8 x
i 9 x
i 10 x
i 11 x
i 12 x
i 13 x
i 14 x
i 15 x

What is happening? So:

• there is a demo c++ client file, that contains main entry point, https://github.com/hughperkins/iverilog/blob/hp/poc-vvp-so/vvp/test_client.cpp
  • has some vpi methods, and register methods for those
  • the main method calls the vpi register methods to register them
  • pretends it has compiled a gpu kernel, and loads the compiled kernel into kernel array
  • calls compile, which is a new (and poorly named...) method in lib_entry.cc, https://github.com/hughperkins/iverilog/blob/hp/poc-vvp-so/vvp/lib_entry.cc , which starts the simulation
• lib_entry.cc, https://github.com/hughperkins/iverilog/blob/hp/poc-vvp-so/vvp/lib_entry.cc is a copy and hacked version of main.cc, designed to create an entry point compile (probably should be split into compile vs simulate, or something like that, and basically does what main.cc does, but without the running-from-commandline bit
• hello.sv, https://github.com/hughperkins/iverilog/blob/hp/poc-vvp-so/vvp/hello.sv, part of the demo. Basically has a loop that calls $cpp_memread a few times, which calls back into the C++ code. We cna think of this as being called on each clock tick (which it is...). We could imagine that there could be various control instructions passed backwards and fowrad to handle running the kernel etc
• ... and that's it really

Thoughts? (obviously this should be cleaned up a bunch. Happy to help with that :) )

(So, basically the changes that would be needed on iverilog side:

• have a sharedobject entry point, somewhat like lib_entry.cc, that resembles main.cc a lot
• modify the Makefile to build a shared object using lib_entry.cc
• modify lib_entry.cc a bit, so we can pass in the path to the .vpi file to run (currently this is hard-coded :P )
• and thats it really :)

)

[hughperkins]

(created a somewhat tighter PR #667 )

[hughperkins]

Oh, hmmm, GPL 2.0. Hmmm. That sounds like it implies that if I link any code with iverilog, it has to be GPL 2.0 too. Not sure that will meet my requirements. I guess it's too late but ... dont suppose.. any chance the license for iverilog could change to eg MIT please? (i.e. something that allows linking, for non-opensource projects; edit: and for non-GPL 2.0 projects).

[hughperkins]

(for example, if I distributed a pytorch library, which used iverilog to simulate my GPU, I'd need to make that pytorch library GPL 2.0 currently; I couldn't make it MIT. I might be able to work around that by connecting to iverilog over a network, something like your smbus; but it'd be a lot more straightforward if iverilog used a less restrictive license, such as MPL or MIT).

[hughperkins]

(Indeed, I couldnt create a pytorch library that uses GPL 2.0, since pytorch is itself under a relatively permissive Caffe license, https://github.com/pytorch/pytorch/blob/master/LICENSE )

[hughperkins]

Hmmm, my reading of the GPL2 license also proscribes my creating a network interface as a vpi, so that my work can control iverilog across a network interface I feel.

https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html

"b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of [GPL v2.0]."

[hughperkins]

(hmmm, just noticed there is a bug in github UI: your COPYING file clearly states GPL, and for example here, https://github.com/hughperkins/iverilog/blob/master/COPYING it shows in github UI as GPL, but the exact same file, here, https://github.com/zachjs/iverilog/blob/master/COPYING , shows as LGPL. That seems like a dangerous github bug... )