Veryl: A Modern Hardware Description Language
github.com
github.com
I use SystemVerilog from 10+ years ago, and developed many large ASICs. But development environment of SystemVerilog was poor than software development. So I wrote some SystemVerilog tools to improve the environment like below: https://github.com/dalance/svlint
After writing it, I felt that more improvement is difficult because the specification of SystemVerilog is too complicated. (For example, even commercial EDA tool vendors can't cover all specification...)
Therefore I decided to develop a new language replacing SystemVerilog. I focus that the new language can be used by production ASIC development. I'm plan to develop a part of a new project in my company by using Veryl.
From a first impression, your language doesn't look all that different from SystemVerilog. Does it have any features that make parameterization easier than SystemVerilog? Can I, for example, easily generate hardware using higher order functions and other functional programming features like those available in Rust and Scala?
I tried to use Chisel in a large codebase to judge it can be used as SystemVerilog alternative in my company. So I found many problems which causes difficulty to apply ASIC development flow. I think that differences of semantics from SystemVerilog causes a part of these problems.
So I aim that Veryl has the almost same semantics as SystemVerilog. I think this ease to interoperate with SystemVerilog codebase too.
1. Verification - You can verify one particular part of the configuration space but verifying the full generic component is something else entirely. As far as I'm aware there's no new HDL which seriously tries to address this point.
2. Implementation - If you're generating something sufficiently advanced you likely want different micro-architecture for different configurations to reach the most optimum design (in terms of power, timing and area). As an example, take a CPU, a single, dual and triple issue core will need to be designed in very different ways. You could aim to build something which can generate all of these wrapped up as a nice CPU module with an 'IssueWidth' parameter but that's going to be harder than just writing separate 1, 2 and 3 issue width CPUs.
Certainly for more mechanical things like interconnects, interrupt controllers, pin multiplexers etc yes it can work well. However building those things in System Verilog is often done with separate generator programs anyway and overall doesn't consume much of the total project engineering time, it's just tedious work.
It does seem a lot of new HDLs focus on eradicating the annoyances and tedium you get developing with System Verilog but increase the difficulties you get in point 1 and 2 which are the actual hard bits that take up the bulk of the time.
Early days for Veryl but it's taking a different direction for most (i.e. just building a more sane System Verilog) I shall be watching with interest!
I think SystemVerilog has sufficient function for ASIC development. So I think more efficient development can be achieved if there are modern development tools like real-time semantic checker through language server, build tool handling dependencies, and so on.
Right, too big and complicated, too much stuff to decently cover in one language (more than e.g. Ada covers), and the majority of people use only a fraction of it (different identifiable user groups use different subsets).
Do you try to add the full SV feature set in your language, or do you focus on a user group/use-case?
As a verification engineer, I write large verification models by Rust, and connect them to SV testbench through DPI. The same usage can be done by Veryl. About Python, cocotb integration seems to be good for integrated unit test feature. So I've just started to consider about the idea.
The problem? Modeling large systems with modules with large I/O (DSPs or something else) and verifying those things is hard and not well suited for a complex verbose language.
Fight me, but I really think a mathworks simulink type visual modeling environment is a better way to approach this problem (and I hate mathworks with a passion, this isn’t a plug for matlab). That type of environment coupled with a way to generate high quality HDL is what I really want. I know mathworks has HDL coder and it’s ok, but still doesn’t quite do everything and you have the pay the enormous mathworks fee and can’t crowdsource platform updates as well as a well managed open source project might be able offer.
So when I see stuff like this I think “cool” but also “why???”
1. Design : architectures need to be well constructed
2. Well derived tests on case-elements/state-conditions : asserting that a specific signal-value achieves a specific state at a specific time is not hard, but coming up with the conditions are.
3. Placement & technology specific details of delays, glitch management & etc.
Event-driven simulators are essentially doing a lot of simple things correctly, so the language doesn't need to be full-featured, ideally it is as efficient as possible in computation, since checking the verification takes the most time for complex systems.
Additionally after logic has been verified, there are many physical implementation details that have to be layered on top of this, including placement & route optimizations.
Veryl to me looks like a SystemVerilog competitor in Rust-like language aspects.
Software designed chip fabrication. Please someone make this happen in my lifetime.
That's already a thing. See, for instance, https://platform.efabless.com/shuttles/MPW-8
Most of it uses the same languages, and many of the same tools, as FPGA design.
[1] https://www.mathworks.com/discovery/high-level-synthesis.htm...
Basically all non-systemverilog HDL languages suffer from the issue that they make development maybe simpler, but on the other side it will be much harder to test the code, because the systemverilog output has to be simulated. Additionally of course, synthesis and timing reports will tell you line numbers in generated systemverilog files instead of the line number of randomHDL.
I always wondered what would happen if hardware engineers bothered to learn compiler theory. Maybe this could have been a solved problem decades ago.
The challenge with hardware is that unlike "traditional" software which compiles to a fixed instruction set architecture, with hardware you might literally be defining the ISA as part of your design.
In hardware you can go from LEGO style gluing pre-existing building blocks to creating the building blocks and THEN gluing it together, with everything in-between.
The real crux of the problem is likely our modern implementation of economics -- a CS graduate who has base-level experience can bank roll a crazy salary that some guy who might have a BSEE, MSEE and PhD in Electrical Engineering ("hardware") will be lucky to get a job offer that's even enough to cover costs of education.
Until the "industry" values hardware and those who want to improve it, you'll likely see slow progress.
P.S.
VHDL (a commonly-used hardware description language) is more or less ADA. Personally I think the choice of ADA syntax was NOT a positive for hardware design but the type-safety and verbosity being a very apt fit for software.
Why doesn't this dynamic work in hardware?
Wouldn't "valuing hardware" improve their competitiveness?
I believe this to be a cultural difference as well as an economic one.
The marginal cost of open source software is $0. But if you license an ARM core, you're paying money for it (like Apple is doing for the M-series processors). ARM has to make money somehow for the development of it's core.
Open source software reduced risk -- though it took a while. And the reduction of risk was valued by most companies who wrote software, or relied upon it for it's profit stream. Major software corporations at the time (IBM, Microsoft) only increased the risk in the 1980/90's, because they were mostly rent seeking.
Most problems were seen over and over and over again, hence they could be solved with software. And when the Microsoft failed to solve them, the open source community did.
In hardware there's only a handful of companies, and open sourcing anything might lead to a competitive disadvantage. So whatever tooling AMD has, they're not going to share with Intel.
Also when you're paying ARM for a license, you're getting a good core, and a lot of good support.
I mean... is that wrong, though? In 2024, C++ will still segfault -- 45 years after it's creation in 1979. No one steering the language seems to be bothered by it. Even Bjarne Stroustrup works in the financial industry now raking in the large paychecks.
Turns out, I'm pretty cynical of software as well.
Look, I'm not saying "Software is the utmost gloriousness that will save humanity!" But what I am saying is that hardware does seem to have fallen well behind software in terms of tooling. VHDL and Verilog are still the tools used to describe hardware today as they were 30 years ago.
If you can fix the barrier to entry into hardware, you'll probably increase the demand for custom hardware.
There's maybe another bigger point here that a lot of "great tools" or "good ideas turned into reality" happened either because the person/people working on it were so motivated and/or they were in the right environment that supported this type of creativity.
Sadly, most hardware-oriented organizations are the exact opposite of creativity or "great ideas" because if they fail the physical cost to fix something is staggering.
In software you can try something, if it doesn't work, call it a learning experience, re-factor, potentially re-use and have another go at it.
In hardware if you do that few people will high five you for a valiant effort.
Historically academia was a place that could "birth" new ideas, help explore them with a pure intent to see how it worked out. These days I think people are dying to finish with school and not live a pauper's life.
industries don't value things, markets value things. RTL work doesn't pay well because the products don't sell into markets that scale like software. with the exception of NVIDIA and whatever you call Apple's teams that actually do/tweak hardware, no hardware product has the margins and scale of software. that's not culture, that's physics.
> who know plenty about compiler theory and/or have contributed significantly to it
also maybe some RTL people know about compiler stuff (phi nodes/dataflow analysis/reg alloc/etc) but most definitely do not know anything except verilog/vhdl and perl/python.
And that's an example but there are other "high-margin" hardware organizations (besides Apple) who still pay HW/EEs lower than SW/SREs.
And if you've been in engineering long enough you'll meet some pretty brilliant people, but their names might not be household or widely known. Lumping engineering into "RTL people" is pretty dismissive.
Claude Shannon, father of information theory, is less widely known for his MS work on 'Shannon Decomposition' which FPGA companies used for a long time to break combinitorial logic functions to multiplexor (MUX) based implementation. That's not "compiler theory" but that's a building block of a type of logic synthesis which compilers used. Shannon isn't a "compiler guy", just a smart dude who's intelligence wasn't bounded by one domain or discipline.
It's very hard to have an objective view of what programming language success and popularity looks like over that long a time, but I think that today there is a much narrower happy path. Either you're a dynamically typed multiparadgram language that's mostly imperative and OO in practice (Ruby, Python, Javascript), a statically typed object imperative language with brackets (C#, Go, Java), or Rust (where a lot of people don't realize how good GCs got instead). Not a ton of Haskell or SML inspired new languages.
By contrast in the 1980-1990s there were serious questions about which of Pascal, C, Objective-C, Smalltalk, C++, was going to win out for the dominant language a system is built in. Stuff like Display PostScript depended in a deep way on exposing programing languages to the engineers who had to work with it that were pretty alien.
"The Rust Reference: Influences" includes SML and Haskell.
meh lots of places aren't actually programming system verilog - they're using python/perl to generate it. that's not the same thing.
Some people when confronted with a problem, think “I know, I’ll use a different language to generate another language.” Now they have two problems.
why? how? how could that possibly be? this one is written in rust...?
because not a single one of them, ever (ever) emits a netlist. they all emit verilog (or vhdl). hence: overengineered perl scripts (which actual employed RTL engineers use heavily...).
but it doesn't make them compilers either :shrug:
The only scalable/vendor/device-neutral way to do that is to back-end your "new" HDL with Verilog/SystemVerilog/VHDL, especially if you want to simulate your design.
A long time ago people used to design chips and CPLDs/FPGAs in schematic-capture (which actually does have its place) which is basically one-step removed from being a netlist.
Among other challenges if you wanted to change to a new device (say a bigger part) or a part from a different vendor, there wasn't really "neutral" way to do this until HDLs came around.
To really change the status quo, you'd have to own EVERYTHING from the point of design entry to the physical device and all steps between.
Even with both "major" FPGA vendors now with their own synthesis and sometimes simulation capability they can barely and/or reliably make that minimum bar work.
i mean like the guy below says, but in the opposite tone, that's like saying building a C emitter is the same as building a compiler. like i just don't agree (for C, because C isn't some abstract device model and isn't (easily) optimizable) because you are forever yoked to the assumptions/affordances of the target language (which is ultimately a language and not an IR/netlist/whatever).
> The only scalable/vendor/device-neutral way
blif is a thing, eblif, xml, etc. are there points of ingress in vivado or intel's thing for any of these? i don't remember but regardless i agree they're probably not well-supported.
> To really change the status quo, you'd have to own EVERYTHING from the point of design entry to the physical device and all steps between.
nah that's not true. LLVM/GCC/etc. FOSS compilers that grew up in the last ~20-30 years prove you don't need to own the last mile to change the status quo. if you build it, device manufacturers will come.
the truth is simply that performant logic synthesis, tech mapping, place and route, etc are just all much harder to implement than XYZ compiler pass. but it could be done given maybe 20*5 highly competent engineer years? i dunno pulling it out of my ass but i know i could write some of that stuff and i'm not that smart. maybe i'm underestimating by 2x (40*5) but that's still less than most "exciting" startups that raise series A today. it just takes diligence and "hard" technical skills (familiarity with the relevant optimization literature).
> Even with both "major" FPGA vendors now with their own synthesis and sometimes simulation capability they can barely and/or reliably make that minimum bar work.
not sure what's the minimum bar you're referring to but sure i agree - i work at one of em (the one that didn't file divorce papers recently...) and i still readily admit the toolchain is trash. which is why i wish some consortium would get together and replace it (because i would love to be able to program/design on our own parts using a modern tool suite). and no circt/yosys/vtr whatever aren't there probably won't ever be (yosys in particular is terribly disappointing for all the waves/claims it makes).
You can either do what most "high-level" or "new HDL" tools do which is emit some form of "RTL" (Verilog/VHDL) or you can stick a place-holder design in the FPGA and then your LLVM-IR is basically emitting instructions for an "overlay" type of design.
And if we are being pedantic you can use Verilog or VHDL to write a purely STRUCTURAL netlist which includes hard instantiating "basic building block" primatives. i.e. have your RTL instantiate an ISERDES or OSERDES block (which I suspect will mean something to you).
But even with a "netlist" based design in RTL you still have to technology map that into building blocks of your hardware and that whole process becomes so complex people have just migrated to writing "behavorial" RTL (or translating to it from some other language, i.e. Vivado HLS).
Lastly, Vivado does support EDIF netlists as do most FPGA tools (whether they advertise it or not) but if you don't have a way to do a technology mapping stage from your high-level RTL into building blocks (which is effectively part of the "synthesis" steps), then what did you accomplish?
You completely missed my point, which was not that RTL and an ISA are comparable in any way but that many of the target codegen backends for both those compilers were contributed by the owners of the ISAs themselves. I said that in response to your claim that you need to own the whole stack to "change the status quo". You don't, you just (mighty big just) need to present a compelling enough value proposition in your stack for the device manufacturers to contribute the remainder of the stack.
And there's a book: "Retrocomputing in Clash"