6 ms·

Can you recommend some resources on chisel? I've been an ASIC/FPGA designer for 20 years. We mostly do VHDL and SystemVerilog for design, and SystemVerilog for

Can you recommend some resources on chisel? I've been an ASIC/FPGA designer for 20 years. We mostly do VHDL and SystemVerilog for design, and SystemVerilog for verification. I've only heard about chisel briefly, used in reference to a risc design I think. I've considered making a lisp like language for design on a few occasions. But maybe chisel solves the pain points?

aseipp 10y ago
Chisel is the language used to describe the RISC-V Rocket core, which is the current primary RISC-V implementation and reference (with real, synthesized boards coming out of it). > I've considered making a lisp like language for design on a few occasions. But maybe chisel solves the pain points? To be honest, I've only been doing FPGA design for a few weeks but, like: basically anything is better than VHDL/Verilog IMO. :) Personally, I prefer CLaSH as opposed to Chisel. (Chisel is a DSL built using Scala - Clash is actually a compiler, not a DSL, from Haskell to Hardware. I think CLaSH conceptually is very nice.) But honestly it really does seem to me that anything is a vast improvement over the current languages, for the most part. Your life is simply vastly improved by being able to do things like use a REPL in Scala/Haskell, or having cosimulation support in your toolchains (so you can run your designs as cycle-accurate software simulations, with no code changes, before doing synthesis). Even then -- the intuition to use, or build something like Lisp isn't necessarily misplaced! Hardware description and functional programming share some interesting commonalities, it seems.
- blackguardx 10y ago
  The key to learning HDL is to understand that it isn't software. There are no instructions to a state machine. You are describing the functionality of the state machine itself.
  - aseipp 10y ago
    Not to sound rude, but what are you addressing with this statement? I've been doing functional programming for over a decade; I'm quite familiar with the concept of declarative programming, so circuits were not a big leap from this point (one of the many ways in which FP nicely dovetails with hardware design.) My point wasn't really about state machines or whatever. Languages like Verilog and VHDL are absolutely terrible at things like abstraction capabilities. You don't have modules, you don't have a REPL, you don't have any kind of abstraction facilities almost at all, on top of the languages being ridiculously verbose. They sit in some bizarre uncanny valley where anything takes a surprising amount of code to write, yet is terrible in terms of reuse, modularity, understandability, etc. Example: A few weeks ago I ran into a case where I couldn't easily wrap a cell library primitive by wrapping it in a Verilog module, and then re-use that module a few times. The primitive was a PLL on my board. Oops, can't do that -- because the synthesis toolchain disliked a module around the PLL primitive, as the primitive had some arguments which were required to be constants (despite the fact all call sites to the wrapping module had constant arguments). So I had to use a Verilog macro which generated a Verilog module, and I had to instantiate that macro like 10 times to 10 different modules, each one corresponding to a different clock speed, with no reuse outside of a Macro. Because some parameters had to be constant. If Verilog metaprogramming wasn't just a rip off of C macros, it might not be so terrible. But shit like this is just tedious. I can't even do things like use higher order functions, or strong typing capabilities, or things like leverage a real module system (with boundary and abstraction capabilities) -- even when I am completely in control of their use and completely understand how they will synthesize. Tools like REPLs vastly improve time-to-iterate with an interactive environment. Cosimulation being a primary feature of these tools means I generally get fairly accurate software simulations directly from my HDL itself, independent of any EDA toolchain etc. The languages are just bad languages. Can you get work done in them? Yes, and everybody does. Do they accurately reflect the fact you're declaratively describing a hardware circuit? Yes. That doesn't mean Verilog/VHDL, as languages, aren't objectively terrible. I understand why this is. The cost models associated with these tools -- and process -- are fundamentally different (for hardware, it's not about "determinism" like software programmers care about -- but things like MTTF, lead time, and optimizing around that), and Verilog is really a small portion of the overall lifecycle of developing a chip (you still need post-synth testing, possibly do gate-level debugging, post-synth modifications, on-board testing, etc). And tools like Clash/Chisel are not perfect by any means, and I still have plenty of slack to pick up by myself, nonetheless. The languages are still bad, despite all that.
    - blackguardx 10y ago
      I think we are approaching this from opposite perspectives. I've been doing FPGA development for 10 years and am an EE. C was the first programming language that I learned over 20 years ago as a teenager. I've only very recently been learning high-level languages and associated abstractions. A lot of the trouble with FPGA development in my opinion isn't the HDL, but the toolchains themselves. I haven't met anyone that likes FPGA toolchains. Things like PLL instantiation problems are likely to do with the tool and not the language. A lot of people (I'm not saying this is you) coming from a software background tend to approach FPGAs as if it were a software problem. They seem very similar, after all. You write some code into a window, hit a button, and bam, you have some functionality. To some extent, I think it leads them to tend to shove a square peg in a round hole. Just like there are programming paradigms governing software design, there paradigms governing FPGA design as well. Trying to force certain abstractions can lead to headache. Abstractions are very important in any design process, be it analog hardware, digital hardware, software, bridge design, etc. Software tends to favor abstractions because they are powerful, but also very cheap. One can afford to waste some CPU cycles if it reduces development time and the occurrence of bugs. In FPGA and ASIC design, abstractions are just as important but one can't afford to waste clock speed or chip area to get it. FPGAs are expensive and ASICs even more so. The design paradigms of HDL exist for that reason, as frustrating as they may be. In a sense, I've just grown accustomed to Verilog's warts. I was appalled at the FPGA development process when I first started but at this point I just take it for granted. I think thing will get better but it will take time. Even so, I think that it is best to stick with Verilog/VHDL for the time being. Just like if one wanted to web development, one would have to learn javascript, which is also considered terrible.
      - ZenoArrow 10y ago
        > "Even so, I think that it is best to stick with Verilog/VHDL for the time being." If you do it for your job, perhaps. However, if you're a hobbyist, that doesn't make as much sense. As a hobbyist you have the luxury of being able to use the tools you like the best. In any case, FPGA design shouldn't be closely coupled to any one language, they're just a tool that allows you to express the design you have in mind. If Clash or Chisel can help you express that design more succinctly and clearly than the competition, there's no need to stick to the other tools. The need only exists for professionals, as changing to languages with lower market share carries risk.
aseipp 10y ago
Also, just to answer your actual question: If you're going to use a language like Chisel or Clash, I'd probably recommend you at least have working familiarity with the languages they're based in -- e.g. Scala or Haskell (or Python for MyHDL, or whatever). Start there, learn some of the fundamentals, and you'll be more equipped to start describing actual hardware. If you've been doing VHDL/Verilog for 20 years, but haven't done FP/software, then some things will probably seem obvious, while others may be harder to initially understand (e.g. designs in Scala or Haskell are going to heavily leverage abstractions present in the base language, so familiarity with them helps). Generally, these tools are going to expect some level of familiarity with the base language, and most of the material around them is going to be rooted on that assumption. So if you've never done FP, or Scala, or Haskell, it'll likely be more difficult. Although I don't think its insurmountable. I've been thinking recently it might be fun to write an article introducing Clash from a hardware design perspective, for people without prior Haskell/FP/etc experience. It certainly seems there isn't much material out there along these lines, IMO.
- DigitalJack 10y ago
  I've never done anything with Scala. I've learned some Haskell, and I liked what I learned. Lisp seems to be where I've settled in my programming. Mostly clojure, but I've been working through some common lisp as the JVM is a pain point for me. Inspite of all the libraries and ecosystem it enables. I think I will perhaps continue with my idea of a lisp based hardware design language, as Scala is very definitely not appealing to me. I will take a look at clash though as Haskell was very compelling. Thanks
kevinnk 10y ago
I'll take the contrarian point of view and say that it's probably not worth it to invest a lot of time into Chisel at the moment. There's a lot of pain points around things outside of the "application logic" like clocking and synchronization. I've also heard that gate level debugging is a pain, but I haven't actually gotten that far in a Chisel project yet. The language definitely seems interesting but it's probably not ready for prime time just yet. If you're interested in a higher level hardware language, I'd highly recommend MyHDL or PyMTL. Both are much closer to Verilog (for better or worse) and give you higher level semantics.
- webaholic 10y ago
  You do know that there are CPU cores out there which were written in chisel? It's true that it is still in the growing phase, but investing time to learn it will definitely pay off.
  - kevinnk 10y ago
    Yep, I worked on one :) My personal belief is that time spent learning Chisel would probably be better spent learning MyHDL, but I will concede that I could be completely wrong; I just thought it might be worth it to add a counterweight to the pro-chisle/clash comments already posted.

aseipp 10y ago

Chisel is the language used to describe the RISC-V Rocket core, which is the current primary RISC-V implementation and reference (with real, synthesized boards coming out of it). > I've considered making a lisp like language for design on a few occasions. But maybe chisel solves the pain points? To be honest, I've only been doing FPGA design for a few weeks but, like: basically anything is better than VHDL/Verilog IMO. :) Personally, I prefer CLaSH as opposed to Chisel. (Chisel is a DSL built using Scala - Clash is actually a compiler, not a DSL, from Haskell to Hardware. I think CLaSH conceptually is very nice.) But honestly it really does seem to me that anything is a vast improvement over the current languages, for the most part. Your life is simply vastly improved by being able to do things like use a REPL in Scala/Haskell, or having cosimulation support in your toolchains (so you can run your designs as cycle-accurate software simulations, with no code changes, before doing synthesis). Even then -- the intuition to use, or build something like Lisp isn't necessarily misplaced! Hardware description and functional programming share some interesting commonalities, it seems.

blackguardx 10y ago
The key to learning HDL is to understand that it isn't software. There are no instructions to a state machine. You are describing the functionality of the state machine itself.
- aseipp 10y ago
  Not to sound rude, but what are you addressing with this statement? I've been doing functional programming for over a decade; I'm quite familiar with the concept of declarative programming, so circuits were not a big leap from this point (one of the many ways in which FP nicely dovetails with hardware design.) My point wasn't really about state machines or whatever. Languages like Verilog and VHDL are absolutely terrible at things like abstraction capabilities. You don't have modules, you don't have a REPL, you don't have any kind of abstraction facilities almost at all, on top of the languages being ridiculously verbose. They sit in some bizarre uncanny valley where anything takes a surprising amount of code to write, yet is terrible in terms of reuse, modularity, understandability, etc. Example: A few weeks ago I ran into a case where I couldn't easily wrap a cell library primitive by wrapping it in a Verilog module, and then re-use that module a few times. The primitive was a PLL on my board. Oops, can't do that -- because the synthesis toolchain disliked a module around the PLL primitive, as the primitive had some arguments which were required to be constants (despite the fact all call sites to the wrapping module had constant arguments). So I had to use a Verilog macro which generated a Verilog module, and I had to instantiate that macro like 10 times to 10 different modules, each one corresponding to a different clock speed, with no reuse outside of a Macro. Because some parameters had to be constant. If Verilog metaprogramming wasn't just a rip off of C macros, it might not be so terrible. But shit like this is just tedious. I can't even do things like use higher order functions, or strong typing capabilities, or things like leverage a real module system (with boundary and abstraction capabilities) -- even when I am completely in control of their use and completely understand how they will synthesize. Tools like REPLs vastly improve time-to-iterate with an interactive environment. Cosimulation being a primary feature of these tools means I generally get fairly accurate software simulations directly from my HDL itself, independent of any EDA toolchain etc. The languages are just bad languages. Can you get work done in them? Yes, and everybody does. Do they accurately reflect the fact you're declaratively describing a hardware circuit? Yes. That doesn't mean Verilog/VHDL, as languages, aren't objectively terrible. I understand why this is. The cost models associated with these tools -- and process -- are fundamentally different (for hardware, it's not about "determinism" like software programmers care about -- but things like MTTF, lead time, and optimizing around that), and Verilog is really a small portion of the overall lifecycle of developing a chip (you still need post-synth testing, possibly do gate-level debugging, post-synth modifications, on-board testing, etc). And tools like Clash/Chisel are not perfect by any means, and I still have plenty of slack to pick up by myself, nonetheless. The languages are still bad, despite all that.
  - blackguardx 10y ago
    I think we are approaching this from opposite perspectives. I've been doing FPGA development for 10 years and am an EE. C was the first programming language that I learned over 20 years ago as a teenager. I've only very recently been learning high-level languages and associated abstractions. A lot of the trouble with FPGA development in my opinion isn't the HDL, but the toolchains themselves. I haven't met anyone that likes FPGA toolchains. Things like PLL instantiation problems are likely to do with the tool and not the language. A lot of people (I'm not saying this is you) coming from a software background tend to approach FPGAs as if it were a software problem. They seem very similar, after all. You write some code into a window, hit a button, and bam, you have some functionality. To some extent, I think it leads them to tend to shove a square peg in a round hole. Just like there are programming paradigms governing software design, there paradigms governing FPGA design as well. Trying to force certain abstractions can lead to headache. Abstractions are very important in any design process, be it analog hardware, digital hardware, software, bridge design, etc. Software tends to favor abstractions because they are powerful, but also very cheap. One can afford to waste some CPU cycles if it reduces development time and the occurrence of bugs. In FPGA and ASIC design, abstractions are just as important but one can't afford to waste clock speed or chip area to get it. FPGAs are expensive and ASICs even more so. The design paradigms of HDL exist for that reason, as frustrating as they may be. In a sense, I've just grown accustomed to Verilog's warts. I was appalled at the FPGA development process when I first started but at this point I just take it for granted. I think thing will get better but it will take time. Even so, I think that it is best to stick with Verilog/VHDL for the time being. Just like if one wanted to web development, one would have to learn javascript, which is also considered terrible.
    - ZenoArrow 10y ago
      > "Even so, I think that it is best to stick with Verilog/VHDL for the time being." If you do it for your job, perhaps. However, if you're a hobbyist, that doesn't make as much sense. As a hobbyist you have the luxury of being able to use the tools you like the best. In any case, FPGA design shouldn't be closely coupled to any one language, they're just a tool that allows you to express the design you have in mind. If Clash or Chisel can help you express that design more succinctly and clearly than the competition, there's no need to stick to the other tools. The need only exists for professionals, as changing to languages with lower market share carries risk.

aseipp 10y ago

Also, just to answer your actual question: If you're going to use a language like Chisel or Clash, I'd probably recommend you at least have working familiarity with the languages they're based in -- e.g. Scala or Haskell (or Python for MyHDL, or whatever). Start there, learn some of the fundamentals, and you'll be more equipped to start describing actual hardware. If you've been doing VHDL/Verilog for 20 years, but haven't done FP/software, then some things will probably seem obvious, while others may be harder to initially understand (e.g. designs in Scala or Haskell are going to heavily leverage abstractions present in the base language, so familiarity with them helps). Generally, these tools are going to expect some level of familiarity with the base language, and most of the material around them is going to be rooted on that assumption. So if you've never done FP, or Scala, or Haskell, it'll likely be more difficult. Although I don't think its insurmountable. I've been thinking recently it might be fun to write an article introducing Clash from a hardware design perspective, for people without prior Haskell/FP/etc experience. It certainly seems there isn't much material out there along these lines, IMO.

DigitalJack 10y ago
I've never done anything with Scala. I've learned some Haskell, and I liked what I learned. Lisp seems to be where I've settled in my programming. Mostly clojure, but I've been working through some common lisp as the JVM is a pain point for me. Inspite of all the libraries and ecosystem it enables. I think I will perhaps continue with my idea of a lisp based hardware design language, as Scala is very definitely not appealing to me. I will take a look at clash though as Haskell was very compelling. Thanks

kevinnk 10y ago

I'll take the contrarian point of view and say that it's probably not worth it to invest a lot of time into Chisel at the moment. There's a lot of pain points around things outside of the "application logic" like clocking and synchronization. I've also heard that gate level debugging is a pain, but I haven't actually gotten that far in a Chisel project yet. The language definitely seems interesting but it's probably not ready for prime time just yet. If you're interested in a higher level hardware language, I'd highly recommend MyHDL or PyMTL. Both are much closer to Verilog (for better or worse) and give you higher level semantics.

webaholic 10y ago
You do know that there are CPU cores out there which were written in chisel? It's true that it is still in the growing phase, but investing time to learn it will definitely pay off.
- kevinnk 10y ago
  Yep, I worked on one :) My personal belief is that time spent learning Chisel would probably be better spent learning MyHDL, but I will concede that I could be completely wrong; I just thought it might be worth it to add a counterweight to the pro-chisle/clash comments already posted.