Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migration of this repo to ghdl (org) #98

Closed
eine opened this issue Mar 27, 2020 · 11 comments
Closed

Migration of this repo to ghdl (org) #98

eine opened this issue Mar 27, 2020 · 11 comments

Comments

@eine
Copy link
Contributor

eine commented Mar 27, 2020

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:

  • ghdl/yosys
  • ghdl/yosys-plugin
  • ghdl/yosys-frontend
  • ghdl/yosys-bindings
  • ghdl/yosys-bridge
  • ghdl/yosys-module

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
Copy link
Contributor

Xiretza commented Mar 27, 2020

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
Copy link
Contributor Author

eine commented Mar 27, 2020

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

@suzizecat
Copy link

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 😗 🎶 )

@Xiretza
Copy link
Contributor

Xiretza commented Mar 27, 2020

@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
Copy link
Member

tgingold commented Mar 27, 2020 via email

@tgingold
Copy link
Member

tgingold commented Mar 27, 2020 via email

@eine
Copy link
Contributor Author

eine commented Mar 27, 2020

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
Copy link

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
Copy link
Contributor Author

eine commented Mar 28, 2020

@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
Copy link
Member

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
Copy link
Member

tgingold commented Apr 1, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants