Open hughperkins opened 2 years ago
(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?)
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:
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:
main
entry point, https://github.com/hughperkins/iverilog/blob/hp/poc-vvp-so/vvp/test_client.cpp
main
method calls the vpi register methods to register themkernel
arraycompile
, 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 simulationcompile
(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$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 etcThoughts? (obviously this should be cleaned up a bunch. Happy to help with that :) )
(So, basically the changes that would be needed on iverilog side:
lib_entry.cc
, that resembles main.cc
a lotlib_entry.cc
lib_entry.cc
a bit, so we can pass in the path to the .vpi
file to run (currently this is hard-coded :P ))
(created a somewhat tighter PR https://github.com/steveicarus/iverilog/pull/667 )
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).
(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).
(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 )
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]."
(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... )
Hi,
I want something like the following architecture:
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: