Make possible to link with vvp, so can run simulation programmatically

[hughperkins]

Make possible to link with vvp, so can run simulation programmatically, and have vpi call back into the same program.

See #665

[hughperkins]

Need to somehow add -fPIC on linux build. Not sure how to do this in an autoconf context?

[hughperkins]

(added -fPIC hackily into Makefile.in for now...)

[hughperkins]

(builds on both Mac OSX Big Sur, and Ubuntu 20.04, when I tried it)

[steveicarus]

This PR has promise, but could use documentation. And this brings up the issue that there is need for documentation bundled with the source. Yours might be the thread that starts us down the path of creating a Documentation/ directory, much like how the Linux kernel source has a documentation directory.

To that end, can you add to your PR a file "Documentation/embedded-vvp.txt" that documents your feature, including how (and why) to use it?

[hughperkins]

So, since creating this PR, I noticed that the license on your (very awesome :) ) project is GPL. This means that if I link my code with your project, and this PR is targeting just such a usage, taht would mean I would need to relicense my code to GPL, something I'm not very keen on doing.

Many projects recently use relatively permissive licenses, such as MIT. Pytorch has a permissive license, https://github.com/pytorch/pytorch/blob/master/LICENSE. Verilator is LGPL, which is right on the edge of being ok, but is probalby ok-ish, for my own usages, https://github.com/verilator/verilator/blob/master/LICENSE . Yosys has an unusual but permissive license, https://github.com/YosysHQ/yosys/blob/master/COPYING My own projects are on various permissive licenses, such as MIT, https://github.com/hughperkins/VeriGPU/blob/main/LICENSE

Permissive licenses mean that for example Cadence could start to use iverilog under the hood, if they chose. Giving you control over some aspects of Cadence software :) Depending on the exact license, they might or might not have to state clearly on their product that they have your product inside of it. Permissive licenses play nicely with code from other projects, and generally let people use the code for both non-commercial projects, and commercial projects.

[steveicarus]

On the matter of Documentation: I've started this PR: #675

On the matter of licensing, we have used explicit exceptions to allow for the sort of thing you are trying to do. Don't expect the license to change wholesale, since there are too many people involved who entered into this with certain expectations.

[hughperkins]

On the matter of licensing, we have used explicit exceptions to allow for the sort of thing you are trying to do. Don't expect the license to change wholesale, since there are too many people involved who entered into this with certain expectations.

Do you mean, you feel that the various contributors over the years might object to a wholesale change of license, but you feel might not object to making an explicit exception, whilst keeping the same overall license? How would an exception look like, in concrete actual writing?

[joshtyler]

Is there any interest in continuing with this PR? Running a simulation programmatically would be a very useful feature to have.

[hughperkins]

The license was not compatible with my own needs, but you're welcome to take ownership of this pr :)

…

On Wed, Jan 11, 2023, at 9:30 AM, Joshua Tyler wrote: Is there any interest in continuing with this PR? Running a simulation programmatically would be a very useful feature to have. — Reply to this email directly, view it on GitHub <#667 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA6FKGXAN5R2JT7MJLU5S3WR27YLANCNFSM5SKGATUQ>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[gatk555]

I also have an application for this, and the documentation should be no problem. I propose a short file, Documentation/usage/libvvp.rst, to say it exists, with most of the interface detail as comments in new header libvvp.h, so there is only one file to update.

In developing a prototype, I found some issues with the PR as it stands:
there is no way to pass text arguments to the simulation;
there is no way to test it without external code, not included with the PR;
and it creates a near-duplicate of main.cc that looks like a future maintenance headache.

That led me to re-work it, so there will be a new PR (but that would also be needed to add documentation). In my version, main.cc is split, not copied. Most of it becomes lib_main.cc and the new main.cc contains little more than main()
and the getopt() loop. The changed code can be built two ways.

1. vvp is a small program that links the new libvvp.so.
2. vvp remains almost the same, but the new library is also built.

With the first choice, testing happens whenever vvp runs, so that looks attractive. But now running from the build tree may require LD_LIBRARY_PATH, or use of chrpath or similar - not so attractive. One possibilty: require "configure --with-libvvp" for option 1, otherwise vvp remains the same, library is not built.

I would appreciate guidance on documentation and build choices.

[hughperkins]

@gatk555 Please go ahead and take ownership of the PR :) (and/or create a new one).

[gatk555]

Thanks!

[caryr]

@gatk555, with your libvvp work now merged into the repo is this pull request still relevant or has your pull subsumed this material?

[gatk555]

@caryr, my apologies for the sluggish response: I have only just seen that. Yes, I think this (#667) can now be closed.

G,

[martinwhitaker]

Closed as superseded by #1068.