Another new HDL: https://veryl-lang.org/
It'll be a long while before either gets enough traction to be serious competition to system erilog, even if SV is, compared to modern software languages, outdated.
Spade Hardware Description Language
21–30 of 64 posts
Re: Spade Hardware Description Language
#22Earlier quoted context omitted.
Fair, but it's just a tooling issue. You don't debug your Verilog anymore at the gate-level, do you?
> just a tooling issue The word "just" is carrying the weight of the world on its shoulders…
It's been said that the arc of history bends toward just-ice...
Re: Spade Hardware Description Language
#23If the output SystemVerilog is unreadable I'm unlikely to use this. SV is still the lingua franca for physical tools. I'm not debugging timing on something that looks like this: localparam[14:0] _e_953 = 0; localparam[14:0] _e_958 = 1; assign _e_956 = \count + _e_958; assign _e_955 = _e_956[14:0]; assign _e_948 = _e_949 ? _e_953 : _e_955;
Fair, but it's just a tooling issue. You don't debug your Verilog anymore at the gate-level, do you?
When debugging/fixing timing problems, or trying to implement a functional change using only metal layers - yes, it is absolutely still necessary to debug verilog at the gate level.
Also, "just a tooling issue" is a pretty big problem when you're talking about something that wants to be adopted as part of the toolchain.
Re: Spade Hardware Description Language
#24I wonder how it compares to Bluespec?
I think this commits the same sin many other new HDLs do -- it just tries to awkwardly smush the paradigm of clocked logic into a sequential software language. The abstractions just don't match, which means you lose the mental connection between the code and the generated Verilog, which makes debugging stuff like timing awkward. I'm a big Bluespec booster, and beyond the nice typing and functional programming you get…
Where do you work that uses bluespec? Any open positions? Apologies for being forward.
Re: Spade Hardware Description Language
#25There are already Verilog and VHDL based tools alvilable. i think nopne likes to learn a third HDL. Including specific ideas into the hdl makes it less attractive to people
Each HDL has its own strengths, weaknesses, tool support & application areas. So each has its place as long as -for specific designs/projects- it's better than alternative HDLs. Users can define "better" for themselves.
Not to mention: existing designs already done in Verilog, VHDL or whatever. Converting such a design from one HDL to another may no be easy.
So as always: use the best tool for the job.
Re: Spade Hardware Description Language
#26How one writes circular circuit, for example stream of fibonnachi numbers or IIR filter? For IIR filter it would be nice if it has protoype like iir(sig : T, a : vec, b : vec) -> T
Re: Spade Hardware Description Language
#27Earlier quoted context omitted.
Fair, but it's just a tooling issue. You don't debug your Verilog anymore at the gate-level, do you?
> just a tooling issue The word "just" is carrying the weight of the world on its shoulders…
Whenever I see that I think of the Itanium where it was destined to be a success, the compiler just needed to...
Re: Spade Hardware Description Language
#28Haven't looked at this one, but IMHO HDL's are sort of the ultimate existence proof that "DSLs Are Bad Design Smell". DSLs are great and elegant and beautiful for expressing a domain solution. Once. But real solutions evolve, and as they do they get messy, and when that happens you need to address that with software tools. And DSLs are, intentionally, inadequate to the tasks of large scale software design. So they ad…
I would argue that the prevalence of HDLs proves that DSLs are a good design for problem domains that scale in complexity. The alternative is point and click CAD, which has a ceiling on the scale of complexity you can reach.
> Honestly my sense is that it's just time to rip the bandaid off and generate synthesizable hardware from Python or Rust or whatnot. More syntax isn't what's needed.
People who think the problem is that they can't synthesize a program in hardware from something like Python completely misunderstand the purpose of an HDL. You do not write a program and press a button to get that program on hardware. You write a program to generate the design and verify its correctness. It is much less like writing an imperative or functional program and more like writing macros or code generation.
Now if you want to write a Python library for generating the underlying data for programming an FPGA or taping out circuits that's actually a good idea that people have tried out - the problem you run into though are network effects. Generating designs is easy, verifying and debugging them is very hard. All the money is in the tooling, and that tooling speaks HDLs.
Re: Spade Hardware Description Language
#29Earlier quoted context omitted.
> Honestly my sense is that it's just time to rip the bandaid off and generate synthesizable hardware from Python or Rust or whatnot. I worked a bit with VHDL and the parallelism aspect is - to me - so fundamentally different than what our sequential programming languages can express that I'm not sure I a layer of abstraction between this and that. How would that work?
You mean parallelism for simulation? Generate a simulator output from your input (in VHDL if you like) and run it in an appropriate runtime. You don't need to run Python/whatever to simulate and you don't need (and probably don't want) your semantic constraints and checks to be expressed in python/whatever syntax. But the process of moving from a parametrized design through the inevitable cross-team-design-madness an…
I don't think this is about simulation. Python requires an additional DSL layer in order to express parallelism. I've personally no interest in learning that, or anything like that stuck on top some other language that's similarly unfit for HDL purposes.
Modern VHDL isn't too far off what we need. I'd rather see more improvements to that. But most crucially, we need tooling that actually supports the improvements and new features. We don't have that today, it's an absolute mess trying to use VHDL '19 with the industry's standard tools. We even avoid using '08 for fear of issues. I can't speak to how far off SV is.
Re: Spade Hardware Description Language
#30Haven't looked at this one, but IMHO HDL's are sort of the ultimate existence proof that "DSLs Are Bad Design Smell". DSLs are great and elegant and beautiful for expressing a domain solution. Once. But real solutions evolve, and as they do they get messy, and when that happens you need to address that with software tools. And DSLs are, intentionally, inadequate to the tasks of large scale software design. So they ad…
I would argue that the prevalence of HDLs proves that DSLs are a good design for problem domains that scale in complexity. The alternative is point and click CAD, which has a ceiling on the scale of complexity you can reach. > Honestly my sense is that it's just time to rip the bandaid off and generate synthesizable hardware from Python or Rust or whatnot. More syntax isn't what's needed. People who think the problem…
> I would argue that the prevalence of HDLs proves that DSLs are a good design for problem domains that scale in complexity.
The major HDLs (i.e., Verilog/SystemVerilog and VHDL) are not DSLs in any meaningful sense of the word. There exist HDLs which actually are DSLs, but they're mostly used by hobbyist and aren't gaining any significant traction in the industry.