Categories definition

[rodrigomelo9]

Hi @eine. I was checking the categories and they seem ok from a high abstraction level. I mean, they catch almost any possibility in the first part of the category. Maybe we will need to add more sub-categories (the second and third parts). Some comments/ideas:

  categories:
    "Libraries": ""
    "Libraries:IP Core Libraries": "libraries containing multiple IP cores"
    "Libraries:IP Core Collections": "collections containing multiple IP cores"
    "IP Cores": "single IP cores"

Maybe the last one could be changed by "Libraries:Single IP Core" (I know, it is not exactly a library). Or instead, all could be changed to:

"IP Core:Single"
"IP Core:Library"
"IP Core:Collection"

    "Frameworks": ""
    "Frameworks:Verification": "frameworks for verification"
    "Verification": ""
    "Verification:Models": "single verification models"
    "Verification:Models:Memory": "verification model for Memories"
    "Verification:Models:Interface": "verification model for Interfaces"

Maybe, the last four could be included in "Frameworks:Verification" Or instead to have a "Verification:Framework" category.

    "Tools": ""
    "Tools:Grammars": ""
    "Tools:Parsers": ""
    "Tools:Simulators": ""
    "Tools:Package Managers": ""
    "Tools:Waveform Viewer": ""
    "Tools:Verification": ""

What about synthesizers, p&r, bitstream generators, programmers, complete workflow (thinking on something like SymbiFlow or IceStorm). Project/tools managers? (edalize, hdlmake, PyFPGA, etc). "Tools:Doc generatos", "Tools:Doc helpers" or similar?

    "Resources": ""
    "Resources:Books": ""
    "Resources:Twitter": ""
    "Resources:Websites": ""
    "Resources:Weekly": ""
    "Conferences": ""

Maybe "Resources:Conference"? Instead of "Resources:Twitter", "Resources:Social media"? Probably we will ned something like "Resources:Wiki" and more.

That is all for now, and of course, we always can add a needed category but is good to start with a good main categorization.

[eine]

Maybe the last one could be changed by "Libraries:Single IP Core" (I know, it is not exactly a library). Or instead, all could be changed to:

"IP Core:Single"
"IP Core:Library"
"IP Core:Collection"

Personally, I don't like "IP". I'd use Core:Single, Core:Library and Core:Collection. I think I discussed with @Paebbels what was the difference between libraries and collections, but I don't remember ATM.

    "Frameworks": ""
    "Frameworks:Verification": "frameworks for verification"
    "Verification": ""
    "Verification:Models": "single verification models"
    "Verification:Models:Memory": "verification model for Memories"
    "Verification:Models:Interface": "verification model for Interfaces"

Maybe, the last four could be included in "Frameworks:Verification" Or instead to have a "Verification:Framework" category.

The idea is that "Verification" contains pieces: models, data, articles, etc. But "Frameworks" is a more complete solution including verification models, core libraries/collections and something more (typically project/source/tool management scripts for regression testing). There might be other frameworks which include almost the same resources, but not exactly meant for verification.

What about synthesizers, p&r, bitstream generators, programmers, complete workflow (thinking on something like SymbiFlow or IceStorm). Project/tools managers? (edalize, hdlmake, PyFPGA, etc). "Tools:Doc generatos", "Tools:Doc helpers" or similar?

Yes. We didn't include them because a year ago GHDL's synthesis features were not ready yet, so most of those tools were not explicitly connected to the ecosystem we use. However, I agree that we should add them now.

edalize, hdlmake, PyFPGA, etc. fit in "Package managers". But we should add Synthesizers, P&R, bitgen and programmers. I believe that SymbiFlow and IceStorm are frameworks.

Maybe "Resources:Conference"?

I think it's ok for Conferences to be a separate category. In the end, those are the main non-virtual meeting points for the community (well, those were until the virus came...).

Instead of "Resources:Twitter", "Resources:Social media"?

Agree.

Probably we will ned something like "Resources:Wiki" and more.

Sure.

That is all for now, and of course, we always can add a needed category but is good to start with a good main categorization.

Would you mind opening a PR with the changes we discussed here? I will then revisit the theme/layout.

[rodrigomelo9]

Personally, I don't like "IP". I'd use Core:Single, Core:Library and Core:Collection. I think I discussed with @Paebbels what was the difference between libraries and collections, but I don't remember ATM.

Ok. I am not sure, but I guess that a library is ordered and a collection a lot of cores put together? :P

edalize, hdlmake, PyFPGA, etc. fit in "Package managers". But we should add Synthesizers, P&R, bitgen and programmers. I believe that SymbiFlow and IceStorm are frameworks.

Mmm edalize is a Package managers? what about fusesoc? (I assumed that Package manager means to deal with libraries/packages). I think that there are clear differences. One, manages libraries/packages, and the other one, manages tools and/or project files.

Maybe "Resources:Conference"?

I think it's ok for Conferences to be a separate category. In the end, those are the main non-virtual meeting points for the community (well, those were until the virus came...).

Sure... haha. Ok.

Would you mind opening a PR with the changes we discussed here? I will then revisit the theme/layout.

Yep, I will open a PR with what we have until now.

[eine]

Ok. I am not sure, but I guess that a library is ordered and a collection a lot of cores put together? :P

Let's let Patrick clarify 😆

Mmm edalize is a Package managers? what about fusesoc? (I assumed that Package manager means to deal with libraries/packages). I think that there are clear differences. One, manages libraries/packages, and the other one, manages tools and/or project files.

To me, both are package managers. A package is a bunch of files of different nature (not related to the VHDL term), and a package manager does nothing per se, but just prepares files for other tools/uses. In this regard, fusesoc is a higher level package manager and edalize is a lower level package manager. In fact, one is the frontend and the other one is the backend. Both tools are meant for the same purpose, and the documentation is partially mixed.

Overall, I think there are not so many tools which would force us to make such specific distinctions. It is good to have them in the same category (at least for now).

[Paebbels]

My understanding and how I promote PoC Library compared to other IP core collections (not saying there might be no libraries too) is:

• Library and Collection contain multiple IP cores
• A IP core might be as little as a single entity/architecture pair
  e.g. a 1-bit synchronizer to cross clock-domains

A collection has:

• a loose set of IP cores, with less reuse and
• maybe not matching interfaces and dependencies
• diverting coding style and standards as well as quality

In contrast, a library has:

• strong internal reuse,
• tries to unify and reuse interfaces - either commonly known like WB, AXI, ... or self-defined interfaces
• has a hierarchy/organization of IP cores
• no dependency and interface issues within same release of a library
• completeness and orthogonality
• developed with same design rules and same quality

---

PoC Library as an example has stream_buffer made from fifo_cc_got, which again is made from ocram_sdp which refering to a generic model, a models for Intel and a model for Xilinx.

A collection example is OpenCores. It's just a bunch of IP cores, without any real connection from really great to just the worse you can imaging.

[rodrigomelo9]

Hi. What about to add the following categories for languages? (MyHDL, nMigen, Chisel, Slice, etc).

• Languages
• Languages:Haskell Based
• Languages:Python Based
• Languages:Scala Based
• Languages:Verilog Based

[umarcor]

I don't think it's necessary to add those categories. I believe that all those belong to the same category. Either Languages or Tools:Languages. Then, all resources specific to one of those ecosystems should be referenced in the page of the corresponding "HDL generator".

[rodrigomelo9]

Ok, I prefer simple "Languages" :-)