7 ms·

Veryl: A Modern Hardware Description Language

76 points by hasheddan 3y ago

polalavik 3y ago
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???”
- omgJustTest 3y ago
  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.
  - bb88 3y ago
    > 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.
    - duskwuff 3y ago
      > 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 https://platform.efabless.com/shuttles/MPW-8 Most of it uses the same languages, and many of the same tools, as FPGA design.
- stefanpie 3y ago
  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.html https://www.mathworks.com/discovery/high-level-synthesis.htm...
  - pclmulqdq 3y ago
    Matlab HLS is fantastic due to the restricted problem space. The C-to-hardware HLS stuff often has more mixed results.
ijuz 3y ago
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.
fpgamlirfanboy 3y ago
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...).
- zem 3y ago
  for a software analogy, a lot of programming languages compile to C; that doesn't make them perl scripts!
  - fpgamlirfanboy 3y ago
    > that doesn't make them perl scripts! but it doesn't make them compilers either :shrug:
    - zem 3y ago
      of course it does! what else would you call something like chicken scheme [https://call-cc.org/ https://call-cc.org/], ats [https://ats-lang.sourceforge.net/ https://ats-lang.sourceforge.net/], or ghc [https://www.haskell.org/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.
      - fpgamlirfanboy 3y ago
        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.
      - treflop 3y ago
kimmeld 3y ago
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.
- bb88 3y ago
  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.
  - vrinsd 3y 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.
    - anfilt 3y ago
      Despite how verbose it is, I honestly like working with VHDL more than Verilog.
whateveracct 3y ago
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"
dalance 3y ago
Hi, Im' developer of Veryl. So I'll try to write the answer to "why new HDL?". 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 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.
- fayalalebrun 3y ago
  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?
  - dalance 3y ago
    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.
  - gchadwick 3y ago

76 points by hasheddan 3y ago

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???”

omgJustTest 3y ago
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.
- bb88 3y ago
  > 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.
  - duskwuff 3y ago
    > 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 https://platform.efabless.com/shuttles/MPW-8 Most of it uses the same languages, and many of the same tools, as FPGA design.
stefanpie 3y ago
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.html https://www.mathworks.com/discovery/high-level-synthesis.htm...
- pclmulqdq 3y ago
  Matlab HLS is fantastic due to the restricted problem space. The C-to-hardware HLS stuff often has more mixed results.

ijuz 3y ago

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.

fpgamlirfanboy 3y ago

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...).

zem 3y ago
for a software analogy, a lot of programming languages compile to C; that doesn't make them perl scripts!
- fpgamlirfanboy 3y ago
  > that doesn't make them perl scripts! but it doesn't make them compilers either :shrug:
  - zem 3y ago
    of course it does! what else would you call something like chicken scheme [https://call-cc.org/ https://call-cc.org/], ats [https://ats-lang.sourceforge.net/ https://ats-lang.sourceforge.net/], or ghc [https://www.haskell.org/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.
    - fpgamlirfanboy 3y ago
      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.
    - treflop 3y ago

kimmeld 3y ago

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.

bb88 3y ago
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.
- vrinsd 3y 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.
  - anfilt 3y ago
    Despite how verbose it is, I honestly like working with VHDL more than Verilog.

whateveracct 3y ago

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"

dalance 3y ago

Hi, Im' developer of Veryl. So I'll try to write the answer to "why new HDL?". 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 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.

fayalalebrun 3y ago
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?
- dalance 3y ago
  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.
- gchadwick 3y ago