Tighter integration with Yosys

[pepijndevos]

I just thought it'd be good to have a place to keep track of how far removed we are from being able to upstream this project into Yosys, assuming they want it.

At this point GHDL is able to synth fairly big projects such as Microwatt, so it seems we're nearing a point where it should be generally useful. What's more, most changes to GHDL do not require changes to this plugin, so it could be upstreamed while work continues on GHDL synthesis.

So the question is what parts of the plugin are still incomplete or broken. I think once #72 gets merged, we handle all GHDL types. I think better interop with Verilog (#46) would be nice, but not sure how critical it is. Is memory inference complete on the plugin side? Any big/breaking changes that need to be made? Any blocking known issues?

The other side of the story is what the Yosys people want in terms of completeness and integration before accepting it, and how to handle the GHDL dependency. I can imagine it should be disabled by default, like Verific.

[pepijndevos]

I talked to Clifford about the options here. Basically GPL code can't go into Yosys, period. So unless some re-licensing on the GHDL side happens, upstreaming the plugin into Yosys is a no-go.

What he suggested is to add some auto-load behavior into Yosys, so that if the GHDL plugin is installed, it will be loaded automatically. Then the plugin could just be integrated in GHDL and installed. This seems like a good solution to me.

[tgingold]

The ghdl.cc file can have any license, that's not a problem.

[Fatsie]

Currently ghdl.cc has be GPL because it uses libghdl and that is GPL. Could be avoided by making libghdl LGPL.

[tgingold]

I don't think that ghdl.cc has to be GPL. It can have any license.

That's the mirror situation with the verific plugin.

[Fatsie]

Verific is proprietary but allows it to be linked in other programs. ghdl and libghdl are GPL and GPL requires that the whole program gets GPL licensed.

[tgingold]

No, GPL doesn't require that the whole program gets GPL licensed. You can perfectly mix GPL code with BSD code. Furthermore, most of the GPL restrictions apply only to binary distributions.

I think the parallel with verific stands: even if yosys is OSS, yosys+verific isn't OSS.

Would yosys people be happy to include ghdl.cc (with any OSS license) in the yosys sources ? Or does this question doesn't make sense.

[Fatsie]

No, GPL doesn't require that the whole program gets GPL licensed.

OK, I should have said GPL requires that the source code of the full program is made available.

You can perfectly mix GPL code with BSD code.

That is because BSD is compatible with GPL; there are other open source licenses like the original 4-clause BSD license that are not GPL compatible and thus code may not be mixed.

Furthermore, most of the GPL restrictions apply only to binary distributions.

Sure, but I think the purpose is to have ghdl command enabled by default in binary version of yosys though. Not just have ghdl.cc in the source tree.

I think the parallel with verific stands: even if yosys is OSS, yosys+verific isn't OSS.

The difference is that verific does not put requirements on the license of the code that is accessing it; GPL does.

Would yosys people be happy to include ghdl.cc (with any OSS license) in the yosys sources ? Or does this question doesn't make sense.

The problem is that ghdl.cc includes ghdlsynth.h and you need to link yosys with libghdl. If you do the latter than you need to make the source of the whole program available if you distribute this binary. So this will be problematic if you also enable verific because you can't distribute it's source.

As ghdl.cc needs libghdl anyway I think it better to move it to github.com/ghdl/ghdlsynth in my opinion.

[tgingold]

The problem is that ghdl.cc includes ghdlsynth.h and you need to link yosys with libghdl. If you do the latter than you need to make the source of the whole program available if you distribute this binary. So this will be problematic if you also enable verific because you can't distribute it's source.

So I think we mostly agree. But I would the problem is on the verific part, not on the ghdl part.

I simply think that you won't be able to distribute binaries of yosys with both verific and ghdl; but I am fine with that.

[eine]

What he suggested is to add some auto-load behavior into Yosys, so that if the GHDL plugin is installed, it will be loaded automatically. Then the plugin could just be integrated in GHDL and installed. This seems like a good solution to me.

I'm all in with this approach. As a matter of fact, that's how travis.sh works now. As you see, ghdl.so is installed in $prefix/lib/ghdl_yosys.so:

https://github.com/tgingold/ghdlsynth-beta/blob/1716e755e14aaaccc60a1bb9fd1e2949c6600c6c/travis.sh#L56-L59

And then linked to --datdir/plugins/ghdl.so with yosys-config.

https://github.com/tgingold/ghdlsynth-beta/blob/1716e755e14aaaccc60a1bb9fd1e2949c6600c6c/travis.sh#L61-L65

This same script is used in ghdl/docker to generate images ghdl/synth:beta, ghdl/synth:latest and ghdl/synth:formal.

So, if the main feature that we expect from some tighter integration is to avoid specifying -m ghdl when calling yosys, I believe it would suffice if yosys just looked at the plugins available in its own plugins directory.

Regarding visibility, i.e. ghdl being shown in yosys --help (as commented in December 1, 2019 5:08 PM), I think that it would be up to yosys to dynamically get the list of available plugins and print them in the help. Moreover, it would be sensible to add some specific metadata to the plugin for this purpose. Precisely, there is a help function already: https://github.com/tgingold/ghdlsynth-beta/blob/master/src/ghdl.cc#L836.

I believe that this approach would solve most of possible licensing conflicts between yosys and any plugin that any third party might develop; such as distributing yosys with ghdl.so, verific.so, etc. Yosys does its part, allowing to use any binary/module by having a very permissive license. The developers of each module decide how to build and distribute their parts, according to whatever license they might choose.

As ghdl.cc needs libghdl anyway I think it better to move it to github.com/ghdl/ghdlsynth in my opinion.

Since this repo is basically ghdl.cc, Makefile.inc and Makefile, plus a testsuite dir and an examples dir; I think that it can perfectly fit as a subdir of ghdl/ghdl. I talked to Tristan about it exactly two months ago:

1138-4EB> I thought that it might be time to merge ghdlsynth into ghdl (as a subdir). That would allow us to integrate synthesis testsuites. what do you think?

tgingold> Why not but I am not sure if it should simply be a subdir. And I'd like to wait until it is not anymore beta.

1138-4EB> Good. We'll revisit it in some weeks/months ;)

Should it be kept as a separate repo, I think that ghdl/yosys or ghdl/yosys-plugin would be more descriptive than ghdl/ghdlsynth. I believe that prefix ghdl and suffix -beta do make sense in tgingold's namespace only; and ghdl/synth might be misleading, because ghdl/ghdl does include --synth.

[eine]

@tgingold, I'd say that I asked this before, but I cannot find it now: what about the license of the netlists generated by ghdl --synth and/or the artifacts generated by yosys when using ghdl as a module?

Simulation executables generated with LLVM or GCC backends need to be distributed along with the VHDL sources, because of the runtime copyright: https://ghdl.readthedocs.io/en/latest/licenses.html. Does a similar copyright apply when yosys uses ghdl as a module?

This is slightly different to the discussion above. Once we solve the distribution license conflict, users that get pre-built yosys and ghdl would need to be aware of what they are not allowed to do, even if they can technically do it.

[tgingold]

Synthesis only transforms the input; there is no added code. So the license is fully defined by the user. It's like the code generated by a compiler.

[d235j]

@tgingold

No, GPL doesn't require that the whole program gets GPL licensed. You can perfectly mix GPL code with BSD code. Furthermore, most of the GPL restrictions apply only to binary distributions. I think the parallel with verific stands: even if yosys is OSS, yosys+verific isn't OSS. Would yosys people be happy to include ghdl.cc (with any OSS license) in the yosys sources ? Or does this question doesn't make sense.

GNU does not agree (see libreadline) — the reason this is OK is because the BSD license is sufficiently permissive to allow the combination to be relicensed under the GPL — but if the BSD code is a derived work of the GPL library, then it may still fall under the GPL — and therefore can't really be under the BSD license.

Effectively you end up with binaries falling under the following licenses: yosys: BSD licensed yosys+ghdlsynth: GPL licensed yosys+verific: proprietary licensed

[d235j]

To add to this: would the VHDL libraries supplied with GHDL need to have a runtime/static linking library exception, similar to glibc, in order to distribute proprietary bitstreams that have been synthesized using GHDL?

[tgingold]

No code from the libraries goes to the netlist.

[tgingold]

I have just added the 'good first issue' label. It concerns the 'auto-load' feature: create a small command that try to load this plugin when invoked. Needs a little bit of C++