ghdl / ghdl-yosys-plugin

VHDL synthesis (based on ghdl)
GNU General Public License v3.0
296 stars 32 forks source link

Migration of this repo to ghdl (org) #98

Closed eine closed 4 years ago

eine commented 4 years ago

The plan a couple of months ago was to do a major bump of GHDL to version 1.0, which would involve moving synthesis features out of beta. By the end of february we were not there yet, so Tristan decided to release another 0.x version. See ghdl/ghdl#1108.

However, we are almost there, and it is a good time to merge/dissolve this repository into the organisation (ghdl). At least, let's discuss and hopefully agree on the details.

Name

I think we should avoid using synth in the name of the new repo. This is because using Yosys is just one option to synthesise with GHDL. There are other possible and future workflows for synthesis which use GHDL but not Yosys. Suggestions:

Issues

When the repo is moved to the org, I think that all the issues should be transferred to ghdl/ghdl and the feature should be disabled in the new/moved repo. I.e., all issues should be opened in ghdl/ghdl.

When

I believe that the repo can be moved/renamed now (when we agree on the name).

Content

From a CI perspective, it makes sense to have src and testsuite moved into ghdl/ghdl. This is mostly because of the tight coupling between the sources of the plugin and the codebase of GHDL.

However, as commented in #74, Tristan would like to have it upstreamed to YosysHQ/yosys or YosysHQ/yosys-plugins in the future. My preference would be YosysHQ/yosys#1640.


Regardless of moving src and testsuite into ghdl/ghdl, the remaining content (examples, library and openocd) could be located in a repo named ghdl/examples, together with https://github.com/ghdl/ghdl/tree/master/doc/examples.

Overall, I'm proposing to keep all the codebase and tests of the tool(s) in ghdl/ghdl and/or ghdl/yosys, and create ghdl/example to contain the "user files".

Xiretza commented 4 years ago

Just gonna throw in a -1 for ghdl/yosys. The concept of user/project namespaces ("ghdl") only really exists on github itself. As soon as the repo is cloned, it's just "yosys", making it hard to distinguish from the real thing. The other options are always easily recognized from the repo name alone.

eine commented 4 years ago

Thanks @Xiretza! Had not thought about it. Just another option: ghdl/gosys, from GHDL (+ Yosys) Open SYnthesis Suite.

suzizecat commented 4 years ago

I don't know if you are in relation with Yosys maintainers, but you should be careful with any name which may "endorse" yosys name (mainly because maintainers might not like it, and because it could confuse users). That aside, my inner glutton would go for GYosys, because this extension is at least as tasty as the japanese Gyosa counterpart (and then, I'll see myself out :kissing: :notes: )

Xiretza commented 4 years ago

@eine sure, if Claire/Symbiotic are fine with that (CC @cliffordwolf), though personally I'd prefer yosys-plugin or yosys-bridge (not so sure about yosys-frontend - if something like write_vhdl is added in the future, is it still strictly a frontend?). I don't have strong opinions about issues and examples, but I would definitely like some closer coupling with ghdl and shared tests.

tgingold commented 4 years ago

For the issues: I think issues specific to the plugin should remain in the plugin repo. Likewise for the examples: they are very specific to yosys so I think they should stay with the plugin.

tgingold commented 4 years ago

Yes, although gyosys is a nice name, it is not easy to understand the meaning of the name.

I like yosys-plugin, but I would even go further with ghdl-yosys-plugin. Maybe it is too long.

eine commented 4 years ago

For the issues: I think issues specific to the plugin should remain in the plugin repo.

I feel that a significant number of the issues in this repo are to be fixed in ghdl/ghdl. Sometimes it requires additional modifications here, but many times it does not. Hence, the number of issues which are really specific to the plugin are very few in the context of the project. We might use a label and/or a milestone to tell those apart.

Do you want to keep them separated because of how you close issues through commit messages? I might check if you can close issues in ghdl/ghdl by committing fix ghdl#000 to ghdl/whatever.

Likewise for the examples: they are very specific to yosys so I think they should stay with the plugin.

I don't think the examples are specific to Yosys only. Currently, there are almost as many nextpnr/openocd specific files as HDL sources. nextpnr is just one of the P&R tools and ECP5 a target (ref https://j.mp/openfpga-diagram). Other options, such as VPR or Vivado/ISE/Quartus will likely require additional files or helper scripts. That's why I think it is better to keep codebase and tests split from "full toolchain examples". Of course, examples can still be used as a test suite in CI.

Moreover, I think it is helpful for new users to have simulation examples close to synthesis examples. It is common practice to first simulate and then synthesise.

Yes, although gyosys is a nice name, it is not easy to understand the meaning of the name.

I like yosys-plugin, but I would even go further with ghdl-yosys-plugin. Maybe it is too long.

I see it as a title-subtitle thing: gyosys: GHDL Yosys plugin. gyosys, gosys, gyosa, whatever... Anyway, I know I have a preference towards (too) short names. I don't have a strong feeling here. ghdl-language-server is more or less the same length.

suzizecat commented 4 years ago

The interesting point with long and explicit names is that you should remember of the repository as a random folder in the user disk. If you come across ghdl-plugin-yosys, you'll immediately see that it comes from GHDL, is a plugin, for yosys.

This is not as much ensured by short names.

Just to add 2 cents on another point, I understand that as of today, this repo only provide the yosys plugin, but isn't there some synthesis features which are only related to GHDL (so this would not be only a yosys thing) ?

eine commented 4 years ago

@suzizecat, for your first point, I believe that's the main purpose of the README. Anyway, as said, I'm ok with ghdl-plugin-yosys, ghdl-yosys-plugin, ghdl-for-yosys, ghdl4yosys...

Regarding the second point, resources which are only related to GHDL are already located in ghdl/ghdl only. For example, the synth test suite: https://github.com/ghdl/ghdl/tree/master/testsuite/synth Hence, the testsuites in this repo should be related to ghdl + yosys only. The discussion is mostly about sources for implementation (P&R) which are located in subdirs examples, libraries and openocd, and which correspond to neither GHDL nor yosys. Actually, I think that these sources are not used in CI.

EDIT

The content in libraries might be required for mixed synthesis of VHDL and Verilog.

tgingold commented 4 years ago

I think I will use ghdl-yosys-plugin.

I plan to move the whole repo. We will see later for moving part of the contents.

tgingold commented 4 years ago

Now migrated (and renamed ghdl-yosys-plugin).