by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Apr 02 2017 21:44
  • Mar 29 2017 21:43

    lievenlemiengre on views

    Validated & fixed definitions w… (compare)

  • Mar 29 2017 21:16

    Paebbels on views

    Added view implementations for … (compare)

  • Mar 29 2017 20:49

    Paebbels on views

    Added a view implementation for… (compare)

  • Mar 29 2017 20:38

    Paebbels on views

    Renamed package files to `*.pkg… (compare)

  • Mar 29 2017 20:34

    Paebbels on views

    Added first implementation of l… (compare)

  • Mar 07 2017 02:41

    Paebbels on range-arithmetic

    Added range arithmetic packages… (compare)

  • Mar 07 2017 02:23

    Paebbels on generic-list

    Committed pending changes. (compare)

  • Dec 27 2016 11:05

    tmeissner on tbv2_associative_array

    Add tests for dict with strings… (compare)

  • Dec 11 2016 16:37

    LarsAsplund on tbv7-event-object

    Added more test cases (compare)

  • Dec 11 2016 16:33

    LarsAsplund on tbv7-event-object

    Cleaning up Added more test cases (compare)

  • Oct 04 2016 18:42

    tmeissner on tbv2_associative_array

    Some fixes to make generic dict… (compare)

  • Sep 26 2016 20:07

    Paebbels on master

    Updated URL (compare)

  • Sep 22 2016 19:23

    Paebbels on math

    Based math test cases on Python… Made stimuli generation adapt t… Merge pull request #3 from Lars… (compare)

  • Sep 22 2016 19:23
    Paebbels closed #3
  • Sep 22 2016 19:23
    Paebbels commented #3
  • Sep 21 2016 22:32
    cmarqu commented #2
  • Sep 21 2016 20:44
    Paebbels commented #2
  • Sep 21 2016 20:40
    LarsAsplund commented on 10eb07b
  • Sep 21 2016 20:30
    LarsAsplund synchronize #3
Andre Souto
@suoto
Problem is wrt to Synplify for example is we don't have licences, otherwise it would be much easier to determine what works and what doesn't work
Patrick Lehmann
@Paebbels
I think LEON3 alsoalso ASIC tested.
what tools are you using?
Andre Souto
@suoto
I haven't been involved too much in this project, seems to be Synopsys Design Compiler
Patrick Lehmann
@Paebbels
you could try to compile components from PoC Library
if it survives this, then the tool is good :)
Andre Souto
@suoto
Yeah, only need a Synopsys license :-\
I mean, to me it sounds very weird trying to support ASIC without having tools to do it right
tgingold
@tgingold
Yes, there are many implementations of Leon3 in ASIC, in particular the rad-harden ones.
Lars Asplund
@LarsAsplund
While Vivado supports records I vaguely remember it was not recommended not long ago. I don't think I ever had any problems though.
Lars Asplund
@LarsAsplund
Just started on a small design for Lattice the other day. Yesterday it started to pass my tests so today it's time to start synthesizing. I haven't used Lattice or Synplify for over a decade so I have no idea what to expect when crunching my VHDL-2008 infested designs. It will be interesting.
T. Meissner
@tmeissner
In my experience Synplify is quite good in supporting VHDL-2008.
I only remember one thing. I had to unroll a multiplexer with variable slices to a case/if construct some time ago, but that wasn’t a VHDL-2008 thing.
Andre Souto
@suoto
Cool, really appreciate the responses
Andre Souto
@suoto
Do formal equivalence/verification tools like FormalPro support records (and more modern vhdl stuff) as well?
T. Meissner
@tmeissner
I only know Mentors formal tools (and Symbiyosys). The VHDL code never had to be changed to process it with mentors propcheck or SymbioticEDAs Symbiyosys
I’ve only done property checking, no equivalence checking
Sometimes you have to change your PSL/SVA properties, as formal tools often don’t support the full richness of these languages
Colin Marquardt
@cmarqu
Now that the VHDL-2019 standard is out, is the Framemaker document being exported in as many formats as possible so that hopefully all semantic information stays available (maybe by merging of information from several formats)?
Patrick Lehmann
@Paebbels
If you want to get you own VHDL projects or awesome VHDL projects you use or have read about be listed, create a pull-request here: https://github.com/VHDL/awesome-vhdl
eine
@eine

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:

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.

Patrick Lehmann
@Paebbels
My aims with https://github.com/VHDL/awesome-vhdl are:
  • 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
Regarding https://github.com/ben-marshall/awesome-open-hardware-verification/
  • 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.

Patrick Lehmann
@Paebbels

In my eyes, awesome-hdl should focus on being a list-of-lists with links to:

  • VHDL
  • Verilog/SystemVerilog
  • MyHDL
  • Chisel
  • SphinalHDL
  • PSL
  • e
  • AHDL
  • ABEL
  • Bluespec
  • SystemC

...

eine
@eine

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.

Patrick Lehmann
@Paebbels
I can support the idea of one repository with multiple lists.
Are we going to compile the lists from a common data source or will we hand edit lists in case of multi language tools?
Patrick Lehmann
@Paebbels
idea:
  • 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:
eine
@eine

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.

As you see, the approach is almost identical to the stubs you posted.
The only "frontend feature" in that prototype if that you can filter per tag. But I hope the concept is clear.
Patrick Lehmann
@Paebbels

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

eine
@eine
Some further thoughts:
  • 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).
Patrick Lehmann
@Paebbels
I think @drom is good in such stuff
eine
@eine

looks like a nice starte, we should have 10 more items to see how it looks and how navigation feels when lists become longer

I didn't add more because I was not sure about which fields to add/remove. Can your propose a "default struct" or just let me know if the current one is ok?

Patrick Lehmann
@Paebbels
In awesome-vhdl I tried to create a mid-sized taxonomy, that could be reused.
Will we show the taxonomy even if sections are empty?
If not (less noise at the beginning), how do user know where they should put there items?
I'm trying to get https://github.com/HDL for our new awesome list.
eine
@eine
We can show a section of "unused categories", and/or use a lighter colour for them.
Alternatively, we can create the taxonomy declaratively in the config.toml or config.yaml file. Hence, contributors will see all the expected terms, even if they are not used yet.
Patrick Lehmann
@Paebbels
both ideas sound good
eine
@eine
This is how it's done in TOML: https://github.com/eine/awesome-vhdl/blob/hdl/config.toml But I think that YAML is better suited.
Patrick Lehmann
@Paebbels
yes, it should be yaml (or json, but this requires correct counting of closing objects :( )
Colin Marquardt
@cmarqu
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.
eine
@eine
eine
@eine

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.

Patrick Lehmann
@Paebbels
The GitHub organisation name hdl was now transfered to our control. We can now implement our awesome list at:
eine
@eine

The GitHub organisation name hdl was 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.

svenn71
@svenn71
Is there a way to emulate a package include from vhdl-2017 with the package generic in vhdl-2008?
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.
Ben Reynwar
@benreynwar
I'm having trouble finding a VHPI specification or documentation anywhere. Could anyone point me in the right direction?
Patrick Lehmann
@Paebbels
VHPI is part of VHDL-2019 (and of cause part of VHDL-2008) from chapter 17 (p. 355) to 23 (p. 506)