-
Notifications
You must be signed in to change notification settings - Fork 31
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
Comments
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. |
Thanks @Xiretza! Had not thought about it. Just another option: ghdl/gosys, from GHDL (+ Yosys) Open SYnthesis Suite. |
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). |
@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 |
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.
|
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 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
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.
I see it as a title-subtitle thing: |
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 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) ? |
@suzizecat, for your first point, I believe that's the main purpose of the README. Anyway, as said, I'm ok with 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. |
I think I will use I plan to move the whole repo. We will see later for moving part of the contents. |
Now migrated (and renamed ghdl-yosys-plugin). |
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/yosysIssues
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
andtestsuite
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
andtestsuite
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".
The text was updated successfully, but these errors were encountered: