February 1, 2020 10:31 PM
Maybe we need an "awesome-cosim" list ;)
@cmarqu, unfortunately, there seems to be (not) awesome duplication in this area too:
- https://github.com/VHDL/awesome-vhdl
- https://github.com/drom/awesome-hdl
- https://github.com/ben-marshall/awesome-open-hardware-verification/
- https://github.com/fukatani/awesome-hdl
I believe there is not so much content to justify having so many different projects. VHDL would be a good neutral place to gather all of them, however, it might seem that SystemVerilog or cosim libs might not fit, because of the name. @Paebbels, what do you think? Can we rename awesome-vhdl to awesome-hdl, and let it be a more general index? Since each awesome list is a markdown file, we can have multiple lists in a single repo, instead of having everything mixed. Alternatively, we can let each project be a separate markdown file with a brief description and some tags. Then, we can build lists from those tags.
- push VHDL as a language
- each language has it's list except for VHDL -> so I created one
- I don't want VHDL tools and libs be drowning between Verilog and System Verilog entries in a list
- I see verification for hardware as a part of a VHDL or Verilog/SystemVerilog list.
We shouldn't split up awesome lists by topics like, synthesis, implementation, verification, documentation, ...
So the remaining question in my point of view is:
How to handle tools that touch multiple languages like VUnit?
Normally, such tools are then listed in multiple awesome lists.
My points are:
- Due to the fragmentation of an already small community, I don't think it's desirable to keep each list in a different repo. Hence, regardless of how is the content distributed in different lists, I believe that all of them fit in a single repo.
- Many tools/frameworks/utilities aim to support multiple HDL languages. Mixing VHDL and/or Verilog with other higher-level languages (SV, Spinal, Bluespec, etc.) is supported by most non-open simulators/compilers/synthesisers, and it's a desire to have it supported by FOSS tools too. Therefore, most of the content beyond pure HDL/IP-core libs is likely to be duplicated. An issue with awesome lists is that they get outdated quite easily; keeping multiple lists in sync makes it harder.
- Regardless of how each user approaches HDL, we are all sooner or later exposed to other languages. Having common and unique projects listed together is helpful to favour synergies. E.g. February 1, 2020 10:24 PM.
I don't want VHDL tools and libs be drowning between Verilog and System Verilog entries in a list
I understand this, and because VHDL is the main language in the repo (and the best :heart: otherwise), I think that the README should correspond to VHDL-only projects. Nonetheless, common tools, and resources for other languages can be kept in other files and referenced from the README.
I'm specifically thinking about yosys, nextpnr and formal verification ATM (ping @tmeissner). By looking at search engines, one would believe that synthesis and formal verification with open source tools needs to be done with SV; there are many more resources about it. However, in the last few months, GHDL allowed to use VHDL too. I believe that this content should have some place in an awesome-vhdl repo, even if is not production-ready yet. These are times of rapid evolution and we should try to let curious people find interesting prototypes to work on.
- one struct per tool that has hierarchy references (labels or so)
ghdl: vhdl: - simulator - synthesizer repo: https://github.com/ghdl/ghdl/ text: GHDL is a free VHDL simulator supporting VHDL-1987 to VHDL-2008. - a hierarchy, that might differ per language
vhdl: - synthesizer: - pure - mixed - simulator:
Now that we agree on having multiple lists. This is a prototype I did yesterday:
Precisely, each tool/project is describe in a separate file (https://github.com/eine/awesome-vhdl/tree/hdl/content/items). The frontmatter (YAML/TOML) can contain any number of custom fields of any type. It is possible to build multiple taxonomies. By default, "tags" and "categories" are enabled.
Now that we agree on having multiple lists. This is a prototype I did yesterday:
Precisely, each tool/project is describe in a separate file (https://github.com/eine/awesome-vhdl/tree/hdl/content/items). The frontmatter (YAML/TOML) can contain any number of custom fields of any type. It is possible to build multiple taxonomies. By default, "tags" and "categories" are enabled.
looks like a nice starte, we should have 10 more items to see how it looks and how navigation feels when lists become longer
- We can have multiple dates for each project: when was it created, when was it added/last checked in the list, what's the latest release...
- We can have just the bare minimum info shown in the "list" views, and many optional details in the "page" view.
- I'm not good with creating "taxonomy architectures". But we can provide multiple lists with complex criteria. Moreover, currently Hugo is used, so the site is static. But it might be possible to use JS to create dynamic filters (not something I can do).
https://github.com/HDL for our new awesome list.
- I added ~20 items/projects to have a better feel.
- All items are now described using YAML frontmatter. The main config is also YAML.
- The Home shows all the categories that are defined in the main config file, even if some are empty yet: https://eine.github.io/awesome-vhdl/. https://eine.github.io/awesome-vhdl/categories/ shows the categories that are being used.
- https://eine.github.io/awesome-vhdl/tags/ shows the tags that are being used. These are also shown in the footer.
Maybe it should become some dynamic thing with a visualization like http://everynoise.com/, and you would define some "attraction factor" between projects. Like VUnit to VHDL: 8/10, VUnit to SV: 2/10. But I don't know - I never use such lists "awesome" directly. Maybe indirectly because search engines derive correlations from it.
@cmarqu, honestly, I would not know how to set those metrics, should I need to do it manually. For example, I understand why you said VUnit to SV 2/10, but I think that 5/10 or 7/10 would also be acceptable. It depends on what you pay attention to. The point with everynoise is that it is created algorithmically. I believe it would be interesting to do some data mining with the list of projects. GitHub's, GitLab's and Bitbucket's APIs provide quite a lot of data points, on top of git itself. It would be a matter of gathering all the data, creating a nice matrix, normalising and finding correlations. PCA/SVD can be used to find the proximity. Moreover, it'd be interesting to see how do clustering algorithms behave. Anyway, I believe that this is out of scope for now. First, we need a "database" that can be read programmatically (the proposed new awesome list format) and we need to fill it.
hdl was now transfered to our control. We can now implement our awesome list at:
The GitHub organisation name
hdlwas now transfered to our control. We can now implement our awesome list at:
A very first version was uploaded. Any feedback is welcome. The categories, which fields to define for each resource, the layout of the site... anything is open for discussion.
In an AXI4-lite product I have defined the memory map adresses as constants in a global package file, and now I would like to create a new memory map which is different and feed it to the downstream modules withouth changing the package use clauses in the various vhdl files. I may have to chante all files once to incorporate the new methodology, but the idea is to later avoid having to create multiple copies of same vhdl file just because I need to include a different package file with the different memory map constants. I also need to be able to instantiate both memory maps at the same time in the same FPGA because one module is on BAR1 to AXI and the other is on BAR2 on AXI. These are two IPs with different toplevel, but many common sub-modules. Maybe not a good description of my problem, but it is about maintaining "same same, but different" in git.
https://gitlab.com/IEEE-P1076/VHDL-Issues => create an issue
pyVHDLModel and can be grabbed directly from PyPI. It's a split from pyVHDLParser.