Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 06:29
    tgingold closed #1924
  • Nov 26 18:59
    umarcor labeled #1925
  • Nov 26 18:59
    umarcor labeled #1925
  • Nov 26 18:59
    umarcor labeled #1925
  • Nov 26 18:58
    umarcor commented #1925
  • Nov 26 18:16
    NicoPy commented #1924
  • Nov 26 18:01
    NicoPy commented #1924
  • Nov 26 17:42
    NicoPy commented #1924
  • Nov 26 17:27
    tgingold commented #1924
  • Nov 26 12:39
    arielpodlubne commented #1925
  • Nov 26 12:31
    umarcor commented #1925
  • Nov 26 12:25
    arielpodlubne opened #1925
  • Nov 26 09:28
    NicoPy commented #1924
  • Nov 26 09:26
    NicoPy commented #1924
  • Nov 26 08:52
    szhou888 commented #1922
  • Nov 26 07:09
    tgingold commented #1924
  • Nov 26 06:34
    tgingold commented #1922
  • Nov 26 02:43
    szhou888 commented #1922
  • Nov 25 22:39
    umarcor commented #1924
  • Nov 25 22:34
    NicoPy commented #1924
Kaleb Barrett
@ktbarrett
That's unfortunate. Is there a timeline on when features will be implemented? Is there some general plan available for GHDL's future development?
Unai Martinez-Corral
@umarcor
Not at all. All the known info is whatever you can get by watching the repo and inspecting the commits that Tristan pushes. There is no further roadmap other than that. There is https://github.com/ghdl/ghdl/wiki as very general guidelines, but most of the features are added by surprise.
The same applies to bug fixes. If Tristan replies to an issue saying he is looking at it, you might expect a fix in a few hours/days. Otherwise, it can take weeks or months.
I know that Tristan wants to support generics, external names and unconstrained arrays, which are the three most relevant missing VHDL 2008 features. However, those are complex, because the elaboration model is very different from previous revisions. He was sidetracked with synthesis 2-3 years ago, which I believe we are all very thankful about. Lately, there have been several comments about Rust, JIT (deprecating GCC), supporting merging multiple revisions, etc. I believe all of those are small steps towards being able to implement 2008 and 2019 features properly. Nonetheless, that won't be quick.
With regard to interfaces, as valuable as I think they are, I would expect them to be added after the main 2008 features are done. Interfaces are more useful with generic types and unconstrained arrays.
Unai Martinez-Corral
@umarcor
Other than that, as you might already know, these last months we've been talking about proposing some kind of "VHDL Foundation" in order to be able to handle funds/donations and hopefully hire Tristan partially (through an agreement with his current employer). That is the very main priority we all agree on: having an open source implementation of the language which can be used as a reference. Once GHDL supports 2008 and 2019, it might be feasible to implement upcoming LCS after they are approved but before the standard is released. Yet, that's something that no single human can do. We can neither ask nor allow Tristan to do that himself. We need to scale.
The main problem is who is going/willing to manage that. I am "a child" and I don't have the economical stability for doing that. Someone or a group of people needs to step ahead, which "the community" accepts as legit for making good use of whichever resources are gathered in the name of "improving the open source VHDL ecosystem (tooling, tests, libraries, learning/teaching material...)".
Note that the "VHDL Foundation" is just a concept. In practice, it would probably be some group in an existing foundation. However, it needs not to be IEEE, because there would be conflicts of interest.
Unai Martinez-Corral
@umarcor
In the VASG meeting before the last one, I commented this with @JimLewis and @Paebbels. I had been mostly thinking about it from a EU perspective, and discussing it with @LarsAsplund. However, EU funds might be limited to EU citizens. Jim might try to replicate the same in the US. It would be nice if you, @marlonjames, @GlenNicholls and others could somehow coordinate.
For now, I created a private repository in my namespace in GitLab, where I'm gathering all the references and ideas in this regard. It's a pot-pourri yet, and there might be some sensible references, so I don't want to make it public. However, I have no problem for sharing it with you or others who are interested.
Jim Lewis
@JimLewis
@umarcor GHDLs support for generics on packages is good. GHDLs support for unconstrained arrays on ports is getting better. I have everything in OSVVM running.
Unai Martinez-Corral
@umarcor
@JimLewis it is, but we cannot tell at what extent it works. Tristan did not sit down and say "I will analyse all these cases and ensure that they work". Note that Kaleb asked about generics in entities, not packages. I vaguely recall that Tristan didn't find it prioritary.
Jim Lewis
@JimLewis
If I could set the priorities, I would put 2019 interfaces ahead of type generics on entities. I would put 2019 interfaces on a similar priority to external names. Although for existing code, I would say external names is higher priority.
@umarcor I don't find type generics on entities a priority either.
When I have time, I will unwind my work arounds in OSVVM and submit further test cases for unconstrained elements of composites.
Kaleb Barrett
@ktbarrett
Type generic FIFO entities are a huge deal. No more need to manually type convert and pack everything into a logic vector.
Unai Martinez-Corral
@umarcor
Here it is!
So, Tristan didn't make any assessment. He just asked about it.
Jim Lewis
@JimLewis
@ktbarrett For RTL? OK
Unai Martinez-Corral
@umarcor

generic type for entities are not yet supported. Is it something that is really needed ? (just to evaluate the priority).

To support generic types on entities, the elaboration mechanism has to be reworked. I think this is the next big project in ghdl, after synthesis.

vblanco20-1
@vblanco20-1
if GHDL wasnt coded in Ada i would try to improve it myself
vhdl 2019 interfaces are a big deal
right now every module i have just has 1 input + 1 output record, but interfaces make it so much cleaner
Kaleb Barrett
@ktbarrett
@vblanco20-1 That's my issue too. I don't know Ada, this is the only project I know written in Ada so I would be learning it solely to contribute here. I might get there one day, but there is plenty of lower cost-of-entry work I could do :wink:. A coworker, @andrewandrepowell might be looking into trying to improve GHDL for generic entities and eventually interfaces. We are a VHDL house and having a quality OS VHDL tool would be of great use to us, but GHDL is missing some key features to get our main reuse library compiling.
vblanco20-1
@vblanco20-1
ive thought of making my own HDL on top of vhdl
something kinda like vhdl (design wise) but far less stupid. and just compiles to vhdl transparently
Unai Martinez-Corral
@umarcor
@vblanco20-1, @ktbarrett, can you writte Rust? Would you be more motivated for learning Rust if you could contribute to GHDL using that language?
vblanco20-1
@vblanco20-1
i can write rust
my small vhdl tools have been in it
mostly for the hell of it, no real good reason. The language i know best is actually cpp
rust is great for this sort of work,because its string handling is the best of almost any language
the standard library of rust has tons of string related funcionality, and everything generally works through string-views, so it doesnt perform allocations and runs very fast
Unai Martinez-Corral
@umarcor
Note that there are tasks related to Ada, C, C++, Python, TypeScript, Shell, HTML/CSS/JS... in GHDL as a project. Hence, if what you want is to contribute in a language, regardless of the area, let us know. https://github.com/ghdl/ghdl/wiki
OTOH, if you want to implement/enhance a very specific area/feature of the tool/project, then you need to learn/use the language.
However, there is a rust branch in the repo. We already setup CI enhancements, for CI to work on all platforms.
Moreover, I strongly recommend you add @xiretza:xiretza.xyz's fork and look at his rust branch.
vblanco20-1
@vblanco20-1
thats hell of a lot of languages for the project
Unai Martinez-Corral
@umarcor

thats hell of a lot of languages for the project

It's a hell of a project!

vblanco20-1
@vblanco20-1
why the html?
Unai Martinez-Corral
@umarcor
documentation.
vblanco20-1
@vblanco20-1
ah
Unai Martinez-Corral
@umarcor
also, GHDL generates HTML from Ada. See the pretty printing options.
vblanco20-1
@vblanco20-1
what was the original thinking of using something like Ada for a compiler?
generally every use case ive ever seen of Ada was for things microcontroller/robot related
vblanco20-1
@vblanco20-1
on my end GHDL is the absolute first time ive seen Ada used for something like a compiler
Unai Martinez-Corral
@umarcor

what was the original thinking of using something like Ada for a compiler?

Tristan worked with Ada (at AdaCore). He is an expert in the language.
Other than that, VHDL was based on Ada. Therefore syntax and certain semantics are very similar.
The idea is that VHDL designers can read Ada. That is true. However, the actual problem is that hardware designers can hardly contribute to GHDL because it is compiler, not because of the language. We are lacking knowledge about the complexity of the tool (and the LRM). I don't think using Ada is the main stopper.

OTOH, since GHDL was started 20 years ago, the language ecosystem changed a lot.
Ada tooling feels dated compared to Python, Rust, Golang.
Yet, that's not a problem with Ada only, but also with C/C++.
I believe it's arguable whether GHDL would be better written in C. I think that's what it should be compared. Comparing Ada and Rust is unfair because Rust did not exist for 15 of the last 20 years.
Anyway, we have discussed about "rewritting GHDL in Rust" several times in the last 2-3 years. I believe it might happen at some point.
For it to be true, tho, there needs to be more momentum than around Ada.
So, please, see the rust branch, ask about it, try to understand why Tristan did not switch to Rust yet, even though it has been discussed so much.
Unai Martinez-Corral
@umarcor

ive thought of making my own HDL on top of vhdl

Please, don't call that HDL. None of us is more clever than all the people working on standardising HDL languages during the last 40 years. You will likely design a subset of a subset of an HDL which will need between 5-10y to be barely usable for any real-world application, and not just the very limited subset of use cases you need it for.
Chisel, SpinalHDL, migen, nmigen, Clash, BlueSpec, Silice, myhdl, TL-Verilog... all those are domain specific languages, most of them focused on a very specific topic (writting RISCV microarchitectures). Twice as many were created in the last decade and are absolutely dead.
We do have a problem with open source tooling for HDL. However, reinventing languages will only delay improving the tooling a decade, at least.
Writting tooling for VHDL and/or System Verilog is precisely complex and challenging because they cover lots of use cases which other languages decided to ignore for the sake of simplicity.

Kaleb Barrett
@ktbarrett
@umarcor I learned Rust a couple years ago and tried it out on some random toy projects. After fighting the borrow checker a couple times I stopped and never used it again.
2 replies