[HN Gopher] SUS Lang: The SUS Hardware Description Language
___________________________________________________________________
SUS Lang: The SUS Hardware Description Language
Author : nateb2022
Score : 36 points
Date : 2025-07-07 16:16 UTC (6 hours ago)
(HTM) web link (sus-lang.org)
(TXT) w3m dump (sus-lang.org)
| randomNumber7 wrote:
| 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.
| mdhb wrote:
| 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.
| 1024bees wrote:
| 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
| artemonster wrote:
| 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.
| bgnn wrote:
| 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.
| thijson wrote:
| It would be nice to have a simulator like Verilator for VHDL.
| kvemkon wrote:
| There is mature GHDL https://github.com/ghdl/ghdl and
| rather new NVC https://github.com/nickg/nvc.
| thijson wrote:
| I was aware of GHDL. NVC looks like it's potentially more
| performant.
| almostgotcaught wrote:
| > 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.
| artemonster wrote:
| 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
| bgnn wrote:
| 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.
| almostgotcaught wrote:
| > 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).
| KerrAvon wrote:
| 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.
| GianFabien wrote:
| 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.
| UncleOxidant wrote:
| 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.
| burnt-resistor wrote:
| 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.
| ei8ths wrote:
| this whole thing is sus...
___________________________________________________________________
(page generated 2025-07-07 23:00 UTC)