Veryl: A Modern Hardware Description Language(github.com)
github.com
Veryl: A Modern Hardware Description Language
https://github.com/veryl-lang/veryl
47 comments
I probably don't have nearly as much experience as you do, but I have used VHDL, Verilog, and modern HDLs like Chisel and SpinalHDL. I think the main advantage of a modern HDL is to have the full power of a traditional programming language when it comes to generating hardware. This especially helps when making deeply parameterizable and reusable hardware in a fraction of the lines compared to SystemVerilog, and which sometimes is impossible to do in Verilog.
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?
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?
Powerful generative capabilities aren't always as useful as you might think. There's two major issues:
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!
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 agree both issues.
I experienced the whole design became to be broken by adding a trait in my Chisel work.
When I want to change a timing path related a register, Chisel-ish sophisticated descriptions could't be used.
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.
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.
I plan to introduce generics to enable module/interface/package as type parameter.
But I'm not aiming Chisel like programability.
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.
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.
> because the specification of SystemVerilog is too complicated
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?
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?
I'm focusing ASIC designers who write synthesizable SystemVerilog. So I choose language features to avoid mismatch between synthesis and simulation.
Verification engineers is a second group. But verification features like SVA and UVM are too large.
So I think it may be better to achieve these features by interoperation with SystemVerilog instead of adding them to Veryl.
I appreciated e.g. in Wirth's Lola-2 HDL that it was conceived up-front for synchronous design and you didn't waste hours to explain to people how to select the proper subset of the language for the most prevalent use-case. Concerning verification, I assume more and more people use other languages for verification than SV, e.g. Python or C++.
Thank you for your information about Lola-2 HDL. I'll check it.
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.
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.
I was going through all the alternative HDLs the other day to see what’s out there. So many one off projects to appeal to this language or that language, but none solving real problems in the space.
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???”
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???”
If you are doing hardware verification, more than using IP blocks in the space, verification tasks are typically oriented around
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.
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.
> 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
Software designed chip fabrication. Please someone make this happen in my lifetime.
Software designed chip fabrication. Please someone make this happen in my lifetime.
> 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.
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.
Funnily enough, Matlab offers a high-level synthesis (HLS) tool to lower Matlab code and Simulink models to Verilog [1]. I have not personally used it, but the last I heard, it works well enough for those who need it and Matlab puts in the work to support it. However, HLS is another whole can of worms, and it can be confusing when discussing new HDLs and the distinction between an HLS tools and high-level HDL dialects.
[1] https://www.mathworks.com/discovery/high-level-synthesis.htm...
[1] https://www.mathworks.com/discovery/high-level-synthesis.htm...
Matlab HLS is fantastic due to the restricted problem space. The C-to-hardware HLS stuff often has more mixed results.
I do not see the point, there is not much syntactical sugar.
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.
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.
System Verilog is the C++ of chip design. It sucks, but it’s everywhere and tied into everything. Like C++ there are so many ways to write dangerous code. We do need a new chip design language but it’s going to take something special to move the needle.
30 years or so ago, there were a handful of programming languages in regular use: C/C++/Assembly/Ada/Fortran/Pascal. Now there's 100x more that people use professionally.
I always wondered what would happen if hardware engineers bothered to learn compiler theory. Maybe this could have been a solved problem decades ago.
I always wondered what would happen if hardware engineers bothered to learn compiler theory. Maybe this could have been a solved problem decades ago.
This is a pretty heavy handed statement -- there are plenty of "hardware engineers" who know plenty about compiler theory and/or have contributed significantly to it. A similarly flippant comment might be "if software engineers only understood hardware better we might have smartphones that last a month on a charge and never crash".
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.
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.
> Until the "industry" values hardware
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.
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.
I won't get into a debate about semantics, but even your employer is a prime example -- Xilinx profit margin per device is staggering by semiconductor standards but they won't pay what they could. The market doesn't always make that dictation, the company does.
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.
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.
Big software companies create and open source stuff which makes them more productive.
Why doesn't this dynamic work in hardware?
Wouldn't "valuing hardware" improve their competitiveness?
Why doesn't this dynamic work in hardware?
Wouldn't "valuing hardware" improve their competitiveness?
Well... no.
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 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.
> "if software engineers only understood hardware better we might have smartphones that last a month on a charge and never crash".
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.
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.
Your example about Bjarne says it all -- it was financially more in his interest to leave academia / standards comittee / "hardcore work" for something more financially lucarative.
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.
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.
[deleted]
This is really a list of the survivors. Tcl was big in the early 1990's, and Objective-C was around on NeXT and other boxes. Perl was rapidly becoming the glue that holds the web together. Lisp was embedded into a lot of programs, as it is now for extensibility. It's also overstating Fortran's role, which is much like todays niche.
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.
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.
> Not a ton of Haskell or SML inspired new languages.
"The Rust Reference: Influences" includes SML and Haskell.
https://doc.rust-lang.org/reference/influences.html
"The Rust Reference: Influences" includes SML and Haskell.
https://doc.rust-lang.org/reference/influences.html
You mean if compiler theorists learned about parallel processing...
> It sucks, but it’s everywhere and tied into everything.
meh lots of places aren't actually programming system verilog - they're using python/perl to generate it. that's not the same thing.
meh lots of places aren't actually programming system verilog - they're using python/perl to generate it. that's not the same thing.
Mangling the quote about regexes…
http://regex.info/blog/2006-09-15/247
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.
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.
i'll hop on the dismissive bandwagon but not for the same reason as everyone else: not a single one of these HDLs ever (ever) amount to more than perl scripts.
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...).
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...).
That's because in order to turn your "design" into an ASIC or an FPGA, you need to go from whatever high-level language (insert new-HDL-du-jour) into a netlist compatible with your physical part.
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.
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.
> The only scalable/vendor/device-neutral way to do that is to back-end your "new" HDL with Verilog/SystemVerilog/VHDL
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).
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).
LLVM/GCC target fixed ISA devices. Even GPUs can be represented in this paradigm of having a core set of instructions and registers for SIMD/SMT. What FPGA or random ASIC could LLVM front-end? How do you go from LLVM-IR to something that can live in an FPGA?
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 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?
> LLVM/GCC target fixed ISA devices. Even GPUs can be represented in this paradigm of having a core set of instructions and registers for SIMD/SMT. What FPGA or random ASIC could LLVM front-end? How do you go from LLVM-IR to something that can live in an FPGA?
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.
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.
Chisel does emit FIRRTL. Which can be made into a bitstream directly by Yosys.
for a software analogy, a lot of programming languages compile to C; that doesn't make them perl scripts!
> that doesn't make them perl scripts!
but it doesn't make them compilers either :shrug:
but it doesn't make them compilers either :shrug:
of course it does! what else would you call something like chicken scheme [https://call-cc.org/], ats [https://ats-lang.sourceforge.net/], or ghc [https://www.haskell.org/ghc/]? they are not "scripts", they are full-blown compilers that happen to use C as their compilation target, and then leverage C compilers to generate code for a variety of architecures. it's a very sensible way to do things.
Umm, everyone calls them transpilers?
transpilers are a subset of compilers though. they span the gamut from things like coffeescript that do fairly simple syntax transformations, to full fledged languages whose compilation target happens to be a high level language like C or javascript, but which otherwise implement most of what you would expect in a "compiler".
ghc doesn't target C since 7.0. the other two i couldn't be bothered to care even less about. when you can point to a production grade """compiler""" that targets C (instead of emitting ir or asm directly) then i'll be happy to discuss the merits/virtues of source to source translation instead of compilation.
I highly recommend looking into Clash as an alternate HDL. It's a GHC Haskell backend - exceedingly cool.
And there's a book: "Retrocomputing in Clash"
And there's a book: "Retrocomputing in Clash"
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.