A point of frustration for newer languages, that sus continues, is the lack of thought towards simulation and testbench design, and how it integrates with the language.
While it would be nice to have more elegant support for "modern" codegen in the sv/verilog/vhdl, the real unergonomic experiences are test bench design and integration. The only real options are (for sv, verilog, I have less experience with vhdl): use verilator and write your tb in cpp, use verilator and then write your testbench in cocotb, or you work at a chip design company and use one of the big 3's compilers and maybe you use UVM or cocotb. Verilator and cocotb are okay, but you're crossing a language boundar(ies) and referencing generated code -- it is both mechanical and complex to get any design working with it.
If sus had first class interfaces to create testbenches that could map to UVM or verilator, it would be much more interesting. Spade does some interesting things by having its own package manager, but doesn't (afaik) expose a ton within the language itself
I really feel that hardware description languages could need some fresh air (especially the tooling), but on the other hand it must be insanely difficult to come up with s.th. that can compete with the major players.
Hi everyone! Question for Verilog/VHDL Profis: What are your favorite documenting tools? Is there a way to automatically generate API for a project? I am looking for something like autodoc from sphinx but for Verilog.
as a HW designer that writes RTL for living I will repeat this 150 times and will put this on my gravestone: WE DONT NEED ANOTHER SHMANCY HDL. really. existing ones are moooooorrreeee than fine.
our tools suck, verification sucks. your design complexity is entirely limited by your verification capabilities (and automation infra). having fancy constructs for CDC or pipelining in HDL is utterly useless, especially that CDC checking is done by special tools that do it nearly perfect with a bit of constraints.
As a hardware engineer turned software developer (including in EDA) who has dabbled in trying to create higher-level HDLs over the years, I now tend to agree with you. As it turns out you can already do a lot of things with parametarization of modules (which has been possible in Verilog and VHDL for years (decades) now). I think a lot of SW folks who look at the problem tend to come up with something that seems better to them from a SW engineering standpoint, but also tends to ignore some of the special needs of HW design so it ends up being klunkier than just writing VHDL or (System)Verilog.
When Javascript developers don't understand something, they "replace" it because NIH and failure to understand the subject mater. They have hammers, and so everything is a nail to be replaced.
Totally agreed. This is the problem of academia unfortunately, the people working on these have no experience in designing complex chips and facing the real limitations.
We are so stupidly limited by our EDA tooling and infrastructure. I wish these efforts would have been put to use in that front.
are you sure it will do anything at all? I am not. The current setup, while objectively sucks for engineers is still quite capable and it *works*. we are far from reaching limits of what is capable to design and tape with current flows. frontend money aspect for tools is still peanuts in comparison to backend and actual fabrication, so it will not generate a renaissance era like gcc did for software
Backend and fab costs are dominant (or even packaging costs are on par with silicon costs these days), correct, but verification is an multiplier on overall costs. The cost of a re-spin is huge. To your point though, most issues warranting a resping are backend related.
I don't recall anyone being "objectively-sucks" level of unhappy with proprietary C compilers. Moving to gcc was often a regression -- because it was much slower to run and sometimes generated worse code -- for developers used to Turbo C or CodeWarrior-style IDEs.
AFAIK when it comes to using the features of recent CPU architectures, Intel's compilers produce more performant / efficient code than GCC or Clang.
A sufficiently smart compiler requires ever more clever compiler writers who are deeply knowledgeable about the many quirks of the numerous architectures.
Word. 28 years of FPGA and ASIC design here, in VHDL, Verliog and SystemVerliog. Coming from VHDL, verilog had some painful limitations (no struct/record type) but SV fixed those, and supports some surprisingly powerful metaprogramming.
But even when using plain verilog the language was never the limiting factor on the design process.
A point of frustration for newer languages, that sus continues, is the lack of thought towards simulation and testbench design, and how it integrates with the language.
While it would be nice to have more elegant support for "modern" codegen in the sv/verilog/vhdl, the real unergonomic experiences are test bench design and integration. The only real options are (for sv, verilog, I have less experience with vhdl): use verilator and write your tb in cpp, use verilator and then write your testbench in cocotb, or you work at a chip design company and use one of the big 3's compilers and maybe you use UVM or cocotb. Verilator and cocotb are okay, but you're crossing a language boundar(ies) and referencing generated code -- it is both mechanical and complex to get any design working with it.
If sus had first class interfaces to create testbenches that could map to UVM or verilator, it would be much more interesting. Spade does some interesting things by having its own package manager, but doesn't (afaik) expose a ton within the language itself
I really feel that hardware description languages could need some fresh air (especially the tooling), but on the other hand it must be insanely difficult to come up with s.th. that can compete with the major players.
Hi everyone! Question for Verilog/VHDL Profis: What are your favorite documenting tools? Is there a way to automatically generate API for a project? I am looking for something like autodoc from sphinx but for Verilog.
Also worth checking out is this project from Intel: https://github.com/intel/rohd/tree/main
> The Rapid Open Hardware Development (ROHD) framework is a framework for describing and verifying hardware in the Dart programming language.
> SUS Lang: The SUS Hardware Description Language
SUS ? Single UNIX Specification ?
this whole thing is sus...
as a HW designer that writes RTL for living I will repeat this 150 times and will put this on my gravestone: WE DONT NEED ANOTHER SHMANCY HDL. really. existing ones are moooooorrreeee than fine. our tools suck, verification sucks. your design complexity is entirely limited by your verification capabilities (and automation infra). having fancy constructs for CDC or pipelining in HDL is utterly useless, especially that CDC checking is done by special tools that do it nearly perfect with a bit of constraints.
As a hardware engineer turned software developer (including in EDA) who has dabbled in trying to create higher-level HDLs over the years, I now tend to agree with you. As it turns out you can already do a lot of things with parametarization of modules (which has been possible in Verilog and VHDL for years (decades) now). I think a lot of SW folks who look at the problem tend to come up with something that seems better to them from a SW engineering standpoint, but also tends to ignore some of the special needs of HW design so it ends up being klunkier than just writing VHDL or (System)Verilog.
When Javascript developers don't understand something, they "replace" it because NIH and failure to understand the subject mater. They have hammers, and so everything is a nail to be replaced.
Totally agreed. This is the problem of academia unfortunately, the people working on these have no experience in designing complex chips and facing the real limitations.
We are so stupidly limited by our EDA tooling and infrastructure. I wish these efforts would have been put to use in that front.
> We are so stupidly limited by our EDA tooling and infrastructure.
The problem that no one will ever solve is there's no gcc equivalent to NXT. Everything is downstream of that problem.
are you sure it will do anything at all? I am not. The current setup, while objectively sucks for engineers is still quite capable and it *works*. we are far from reaching limits of what is capable to design and tape with current flows. frontend money aspect for tools is still peanuts in comparison to backend and actual fabrication, so it will not generate a renaissance era like gcc did for software
Backend and fab costs are dominant (or even packaging costs are on par with silicon costs these days), correct, but verification is an multiplier on overall costs. The cost of a re-spin is huge. To your point though, most issues warranting a resping are backend related.
> are you sure it will do anything at all? I am not. The current setup, while objectively sucks for engineers is still quite capable and it works
go back in time to before gcc - i'm 100% sure people were saying the exact same thing about borland (or whatever).
I don't recall anyone being "objectively-sucks" level of unhappy with proprietary C compilers. Moving to gcc was often a regression -- because it was much slower to run and sometimes generated worse code -- for developers used to Turbo C or CodeWarrior-style IDEs.
AFAIK when it comes to using the features of recent CPU architectures, Intel's compilers produce more performant / efficient code than GCC or Clang.
A sufficiently smart compiler requires ever more clever compiler writers who are deeply knowledgeable about the many quirks of the numerous architectures.
> Intel's compilers produce more performant / efficient code than GCC or Clang
Intel's compiler are clang forks.
It would be nice to have a simulator like Verilator for VHDL.
There is mature GHDL https://github.com/ghdl/ghdl and rather new NVC https://github.com/nickg/nvc.
I was aware of GHDL. NVC looks like it's potentially more performant.
LLVM never works in EDA.
Word. 28 years of FPGA and ASIC design here, in VHDL, Verliog and SystemVerliog. Coming from VHDL, verilog had some painful limitations (no struct/record type) but SV fixed those, and supports some surprisingly powerful metaprogramming.
But even when using plain verilog the language was never the limiting factor on the design process.