github-actions[bot] on nightly
synth/elab-vhdl_expr: handle sl… testsuite/synth: add a test for… (compare)
rustbranch in the repo. We already setup CI enhancements, for CI to work on all platforms.
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.
rustbranch, ask about it, try to understand why Tristan did not switch to Rust yet, even though it has been discussed so much.
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.