
Ask HN: FPGA/ASIC Designers: What Are Your Thoughts on Chisel? - FPGAhacker
Chisel came up on HN yesterday.  It&#x27;s a Scala based DSL for generating HDL.  I&#x27;ve looked at it briefly a couple times, and I don&#x27;t see the value prospect.  Perhaps it is because I don&#x27;t know Scala, and the idea of learning Scala to write in a Scala DSL to generate HDL does not seem worth while.<p>Don&#x27;t get me wrong, I feel the pain of chip design very strongly, but mostly on the verification side of the fence.  The design side of HDL, especially in systemverilog, just isn&#x27;t a big deal.  Verification, on the other hand, has a lot of room for improvement.<p>If you have used chisel &quot;in anger,&quot; what&#x27;s the big win for you?
======
seldridge
This is a surprisingly difficult concept to express... I've taken a stab at it
before on StackOverflow [1].

One angle is that Chisel (or some hardware DSL) gives you the ability to
access software engineering constructs that Verilog/SystemVerilog/VHDL do not
have. E.g., with Chisel or similar, you can use object oriented programming to
describe hardware. No synthesis vendor supports object oriented programming in
SystemVerilog as far as I'm aware, _even though the language has it_.
Unfortunately, this explanation of "language power" is exactly what Paul
Graham describes as "The Blub Paradox" in his "Beating the Averages" essay
that shows up on HN frequently [2]. Summarily, a standard C programmer
understands they can be more effective in C than assembly, but don't have the
requisite knowledge to see that C++ has advantages over C. A good Verilog
engineer likely has no exposure to Haskell and there's a huge skills gap
necessary for them to grok the utility of functional programming.

Relatedly, Chisel (or similar) is trying to describe highly parameterized
hardware generators _NOT_ one design point. If you want to hit one design
point and one design point only, then the advantage of using something that
supports a lot of parameterization may not be as beneficial.

Another angle is that Chisel and it's hardware IR FIRRTL forms a hardware
compiler stack. This let's you automate difficult processes that shouldn't be
hard, but are. One example is adding state snapshotting to a hardware design.
FireSim [3] lets you do this automatically because you can add transforms to
the FIRRTL compiler just like you can add transforms to the LLVM compiler. If
you want to do this with Perl and RegEx on Verilog it's intractable.

On verification... yes, this is a hard problem. A common criticism of hardware
DSLs is that they're solving the wrong problem of design and not verification.
However, most of the Chisel devs think that the verification problem may get
easier with the right software abstractions and a hackable hardware compiler.
Improvements to verification are a work-in-progress and the Chisel developers
are starting a working group related to this.

[1] [https://stackoverflow.com/questions/53007782/what-
benefits-d...](https://stackoverflow.com/questions/53007782/what-benefits-
does-chisel-offer-over-classic-hardware-description-languages)

[2] [http://www.paulgraham.com/avg.html](http://www.paulgraham.com/avg.html)

[3] [https://fires.im/](https://fires.im/)

