When you think about hardware description languages, you probably think of Verilog or VHDL. There are others, of course, but those are the two elephants in the room. Do we need another one? [Veryl-lang] thinks so. The Veryl language is sort of Verilog meets Rust. What makes Veryl interesting is that it transpiles to normal SystemVerilog, so it will — probably — work with your existing tool chains.
That means you can define your logic Veryl, have it output SystemVerilog, and then use that Verilog in your vendor’s (or an open source) Verilog tool. The output is supposed to be human-readable Verilog, too, so you don’t have to transport opaque blocks of gibberish.
You can find an example of the language on GitHub in the documentation. If you can read any HDL, you won’t find it very different. That might be the weakest part — from a user’s point of view, this might just as well be Verilog. The documentation claims that parsing the language is easier, but if you are just going to convert it to Verilog anyway, it might be as well to just write to Verilog. Then again, we know Verilog well enough that we are probably biased.
If you want to try it easily, there’s a browser-based “playground” to try. For example, the input:
// module declaration
module Hackaday (
// module port
v : input logic<32>,
q : output logic<32>
) {
assign q=~v;
}
Resulted in:
// module declaration module project_Hackaday ( // module port input logic [32-1:0] v, output logic [32-1:0] q ); assign q = ~v; endmodule
Perhaps a little nicer, but not an overwhelming improvement.
What do you think? Will you try Veryl? Let us know in the comments. It isn’t the only alterative choice, of course. There’s SpinalHDL and MyHDL, to name two.
Or, you can just use Python:
https://github.com/davidel/pyxhdl
What problem are we trying to solve here?…other than someone who seems to have a problem writing code to parse some text. Introducing new syntax, and an extra processing step before you get to where you were before (with what benefit?), is going a step back. This “solution” is still looking for a problem.
We have enough HDLs already (and only talking about the 2 primaries here). Verilog seems to be the go-to for most designs (or only choice for the majority hailing from the US), with VHDL available for designs with very tricky inter-dependencies (or those from the EU that seem to prefer VHDL for everything, because they over-complicate everything).
I’m getting the feeling that as soon as someone develops his own software to (usually) do a lot more development automation, and they run into problems doing so, the result is a new “language”. Is this the legacy we will be leaving the generations that follow?…known as the century of the languages?
One difficulty of Verilog is connecting signals between modules: without SystemVerilog interfaces, this goes wire by wire. helps but only for Wishbone, not AXI, AHB, APB, memory buses, MIPI, or building register maps… Repetitive tasks without a new challenge but a lot of repeated manual steps.
Most custom RTL generate Verilog, which helps with their popularity: SpinalHDL toolchain not required to use VexRiscv, only to regenerate it.
There are intermediates between going full custom RTL or full Verilog/VHDL:
– Custom RTL for the parts difficult to maintain, integrated as Verilog, main project language
– Cores in Verilog, integrated in a custom HDL to avoid plugging wires one by one.
For sure, using cores published in the “local language (my favorite little HDL)” you already use feels nice, and talking “international English (Verilog)” feels a bit more alienating, but integrating some RTL in a “foreign language (new RTL du jour)” that you do not speak is harsher.
A Babel tower of innovation, only sustained by the presence of a Lingua Frinca.
Precisely…even though it is not even a tower of innovation, because we got stuck in one spot, keeping on re-doing the same work over-and-over again (everytime these new languages takes hold, all the old code need to be dumped, or at the very least every single line revisited). We are messing with exactly the thing we use to communicate ideas to one another.
…or maybe this was how Babel ended…after no-one understood anything that anyone said, because a hammer had 20 names, and 30 different schematic depictions? End-game…literally.
Oh the Americans – first they push their English as “international language” and than Verilog? Look, i am from EU and i like my VHDL. And no, i am not from France. (and yes, this is a joke).
But seriously – VHDL is verbose – a lot – but at the end it is about as complicated as Verilog, i think they are more similar than different.
> And no, i am not from France.
I am :)
A lot of Chinese-speaking code with comments in Chinese too…
Definitely some interesting projects as well! https://github.com/T-head-Semi/
I think I was under-estimating various toolchains support for VHDL. It is almost everywhere I’ve looked. And usually I am aiming to make Verilog more verbose [2] or rather, more explicit about what is being done (every `a <= b + c` is first generating a wire `b + c`, then hooking that wire as input to a register `a`).
[2]: https://github.com/lowRISC/style-guides/blob/master/VerilogCodingStyle.md
What would be some great code base to read VHDL? Maybe https://github.com/stnolting/neorv32 ?
Note: I am novice. I probably do not know what I am talking about.
The neorv32 code looks nice – also check out grlib / leon CPU from Gaisler – https://www.gaisler.com/index.php – you will find a lot of different things there – from simple peripherals to complicated CPU core implementations
(max depth reached, replying to pigster6 there instead)
Thank you! Looks like the GPL’ed everything!
Hmmm. VHDL needs separate entity and architecture files. And don’t get me started on not being able to read back a signal defined as an output.
But then again VHDL inheritently understands time units. No need fto specify timespecs.
Verilog has warts, but System Verilog mostly fixes them.
VHDL/*Verilog* have a plethora of problems that nobody has seen to fix over the last ~3 decades, mostly because the EDA companies make money on license-hours, not results.
If you break the problem down into two phases – make your software as parallel as possible (not an HDL thing), then translate it to hardware, it’s a lot easier than going straight at writing RTL (which a bad abstraction level anyway).
https://cameron-eda.com/2020/06/16/unnecessary-problems-x-propagation/
It looks like a workaround to propose feature like, Linter, Formatter, Language server without having to pay for direct and native support of industry standard.
That’s open-source reality hundred of project or initiative, with a diversity of intent : everyone can propose things, only few will bubble up.
https://xkcd.com/927/
Diversity is needed for evolution, but for me Verilog is enough.
And I really don’t want more niche languages and toolchains just adding complexity to the workflow. Keep it as tiny as TinyCC and you may have a new fan, but if it goes the C-compiler route exploding in size and losing speed… you get what I mean… then no, thanks.
The inertia required to move a design to a new language is massive (at least in established companies, maybe startups slightly less so). The value add here is minimal if any. Really just a College project, perhaps some academic interest but will never see the light of day in industry.
Pain points of Verilog (most of which are addressed by tooling such as emacs verilog-mode): very verbose and error-prone module interfaces (SystemVerilog at least allows some signal grouping), need to follow.certain rituals.and patterns in order to something synthesised (vendor-dependent!) – block rams, FSMs, etc. Need to annotate certain things in comments – parallel case, dual flopping registers, etc.
So does Veryl have ANYTHING new in it besides being able to say varable n instead of variable[n-1:0]? if that isit why bother! if it has other new things that are similarly trivial, why bother?
In addition to SpinalHDL another notable thing worth mentioning is Chisel. Both are DSLs on top of Scala. Chisel is the thing used by many (if not all) SiFive projects. Which includes earliest riscv implementations. IMHO having powerful general purpose language produce RTL makes sense. I am surprised this approach isn’t used as widely.
Three is quite a lot of HDLs like this: Clash for Haskell, HardCaml for OCaml, Amaranth, Migen and others for Python, etc. They all are much nicer to use than VHDL/Verilog, but adoption rate in the industry is, as you say, not great.
Nowadays you can just literally draw a logic schematic of the ttl 74 logic and spit the vhdl or verilog like cad for pcb
What I look for in a Verification and Hardware Design Language:
Conciseness of expression,
Easy to read (write by 1, reviewed by many),
Strong typing to ensure correctness,
Consistent language design,
No and/or minimal race conditions,
Hardware Interface abstractions,
First class – or first class like – verification data structures.
I find this in VHDL-2019 + Open Source VHDL Verification Methodology (OSVVM).
With VHDL-2019, VHDL is at least as concise as Verilog/SystemVerilog and significantly more self-consistent. Going further, in FPGA, VHDL is the market leader for both design and verification – see the Wilson Verification Survey (any year, but most recently in 2022).
VHDL-2019 is here today in Aldec simulators. Be sure to ask your simulator vendor for support – as vendors don’t like the implement things in which you have no interest.
I of course have my eyes open for something new and better that is an improvement over what I already have. Still waiting.
Many other NeoHDLs have already been mentioned, so I’ll just plug my own: SUS. (https://github.com/pc2/sus-compiler).
I agree with the article that just having a thin wrapper over verilog is not that valuable, as the mental burden still remains. That’s why in SUS we focus on adding semantics to the code. As an example, we add Latency Counting, which shows up on the module interface so the user sees at what times certain signals should be fed in or returned. This system is also used for pipelining.
There’s a lot that can be done from a language design viewpoint to improve the HW design experience. It is just that the major vendors have no incentive to improve over the 50-yr old languages already in use.