seldridge

> Could even have a crack at toy HDL in the form of the fixed SystemVerilog with a decent type system solution I proposed above using CIRCT as an IR...

This is the exact type of activity that CIRCT is trying to make easier! There are both enough core hardware dialects that new languages (generator-style embedded domain specific languages or actual languages) can be quickly built as well as the flexibility of MLIR to define _new_ dialects that represent the constructs and type system of the language you are trying to build while still inter-operating with or lowering to existing dialects.

This was the kind of thing that didn't work well with Chisel's FIRRTL IR as it was very closely coupled to Chisel and it's opinions. Now FIRRTL is just another CIRCT dialect and, even if you're not using Chisel and FIRRTL, you're benefitting from the shared development of the core hardware dialects and SystemVerilog emission that Chisel designs rely on.

Yes. There's two common types of modules with different behavior here: `Module` and `RawModule`. The former has implicit clock and reset ports. The latter has no implicit clock and reset. All design can be done with the latter, just a bit more verbosely---all clock and reset ports need to be defined and anytime a construct that needs a clock or reset is used (e.g., a register), it would need to be wrapped in a `withClock`/`withReset`/`withClockAndReset`.

It gives you a hardware testing environment with system calls for reasonable amounts of wall clock time.

If you're simulating actual hardware, e.g., a Verilog description of a RISC-V microprocessor compiled to a cycle-accurate simulation with Verilator, your simulation rate is going to be ~10KHz. You can write useful tests with the Proxy Kernel (or something like it) that run in ~1 million instructions (minutes of wall clock time) while still getting full system calls like printf. However, booting Linux is out of the question (days of wall clock time). Running bare metal is useful, too, but you don't have system calls there.

If you're doing fast RISC-V virtualization, like on QEMU, or doing emulation on an FPGA, you're running at >1MHz and running a "normal kernel" like Linux is totally tractable. However, it would be foolhardy to expect to jump from hardware design to immediately booting Linux.

(Sorry! Just saw this!)

Polymorphism makes it way easier to build hardware that can handle any possible data type. Things like queues and arbiters beg for type parameters (you should be able to enqueue any data). Without polymorphism you can make something parameterized by data width (and then flatten/reconstruct the data), but it's janky and you lose any concept of type safety (as you're "casting" to a collection of bits and then back).

There was some interesting work out of the University of Washington [^1] to build a "standard template library" using SystemVerilog. Polymorphism was identified as one of the shortcomings that made this difficult (Section 5: "A Wishlist for SystemVerilog"). [^2]

[^1]: https://github.com/bespoke-silicon-group/basejump_stl [^2]: http://cseweb.ucsd.edu/~mbtaylor/papers/BaseJump_STL_DAC_Sli...

The MIPS Open ISA project was actually shut down after only a year. [^1]

POWER has technically only been "open" for a little under a year. OpenPOWER was always a thing, but this used to mean that companies could participate in the ISA development process and then pay license fees to build a chip. This changed last year when POWER went royalty-free (like RISC-V).

The real defniition of "open" is can you answer the following questions in the negative:

  - Do I need to pay someone for a license to implement the ISA?
  - Is the ISA patent-unencumbered?

RISC-V was the only game in town for a long time and thereby attracted large companies (including NVIDIA) and startups that were interested in building their own microprocessors, but didn't want to pay license fees or get sued into oblivion.

[^1]: https://www.hackster.io/news/wave-computing-closes-its-mips-...

> These are not programming languages, they are hardware definition languages.

There's a subtle point in that Verilog/SystemVerilog and VHDL are also just not powerful languages. While parametric, they lack polymorphism, object oriented programming (excluding SV simulation-only constructs), functional programming, etc.

Your point about the abstraction being different is well taken---hardware description languages describe circuits and programming languages describe programs. However, it's exceedingly unfortunate that the industry is stuck in a rut of such weak languages and trying to explain that weakness to hardware engineers, who haven't seen anything else, runs into the "Blub paradox" (e.g., a programmer who only knows assembly can't evaluate the benefits of C++). [^1]

[^1]: http://www.paulgraham.com/avg.html

There is an open PR adding support for the OpenROAD tools [^1]. So, there should be a flow that uses open source VLSI tools eventually.

The Google 130nm library is still filling a huge gap as all the open PDKs up to this point were "fake" educational libraries, e.g., FreePDK [^2]. You can run them through the a VLSI flow, but you can't tape them out.

[^1]: https://github.com/ucb-bar/hammer/pull/584

[^2]: https://www.eda.ncsu.edu/wiki/FreePDK

I'm one of the Chisel devs.

My biased view is that iterative development with Chisel, to the point of functional verification, is going to be faster than in a traditional RTL language primarily because you have a robust unit testing framework for Scala (Scalatest) and a library for testing Chisel hardware, ChiselTest [^1]. Basically, adopting test driven development is zero-cost---most Chisel users are writing tests as they're designing hardware.

Note that there are existing options that help bridge this gap for Verilog/VHDL like VUnit [^2] and cocotb [^3].

For libraries, there's multiple levels. The Chisel standard library is providing basic hardware modules, e.g., queues, counters, arbiters, delay pipes, and pseudo-random number generators, as well as common interfaces, e.g., valid and ready/valid. Then there's an IP contributions repo (motivated by something like the old tensorflow contrib package) where people can add third-party larger IP [^4]. Then there's the level of standalone large IP built using Chisel that you can use like the Rocket Chip RISC-V SoC generator [^5], an OpenPOWER microprocessor [^6], or a systolic array machine learning accelerator [^7].

There are comparable efforts for building standard libraries in SystemVerilog, notably BaseJump STL [^8], though SystemVerilog's limited parameterization and lack of parametric polymorphism limit what's possible. You can also find lots of larger IP ready to use in traditional languages, e.g., a RISC-V core [^9]. Just because the user base of traditional languages is larger, you'll likely find more IP in those languages.

[^1]: https://github.com/ucb-bar/chisel-testers2

[^2]: https://vunit.github.io/

[^3]: https://docs.cocotb.org/en/latest/

[^4]: https://github.com/freechipsproject/ip-contributions

[^5]: https://github.com/chipsalliance/rocket-chip

[^6]: https://github.com/antonblanchard/chiselwatt

[^7]: https://github.com/ucb-bar/gemmini

[^8]: https://github.com/bespoke-silicon-group/basejump_stl

[^9]: https://github.com/openhwgroup/cva6

And if this is interesting, Tom gave a great talk at the 2018 Chisel Community Conference on his experiences at that time: https://youtu.be/x_fzoxGpZ_g

Thanks for your question.

There are some different design decisions between Chisel and Clash (and one or the other may work better for you!). Chisel is an embedded domain specific language in Scala that uses added hardware primitives to build a circuit graph and emit FIRRTL IR. Clash is a Haskell derivative that (in my limited understanding) reads a Haskell program, but interprets it using hardware semantics, eventually emitting Verilog. They are both hardware description languages and not HLS (c-to-gates).

The Chisel ecosystem is larger, currently. This is primarily due to UC Berkeley/SiFive projects (Rocket Chip RISC-V SoC generator, BOOM out-of-order processor, Hwacha vector accelerator, etc.).

One meta-difference is FIRRTL. Chisel/FIRRTL is trying to be a hardware compiler framework, analogous to LLVM, but for circuits. Chisel is only the front-end. You can interface other front-ends with or write your own front-end for FIRRTL (currently Yosys can target FIRRTL IT for Verilog -> FIRRTL IR). You then have a simple circuit IR to Target, but get access to all the existing FIRRTL transforms and have a path to Verilog for FPGA/ASIC. Relatedly, you can inject custom FIRRTL transforms into the FIRRTL compiler (one example being to add run-time fault injectors: https://github.com/IBM/chiffre).

All that said... Host language matters. If you're comfortable with Haskell (or Python), use what works! And for new/existing languages, targeting FIRRTL IR is an option.

More resources:

- https://clash-lang.readthedocs.io/en/latest/faq.html

- https://stackoverflow.com/q/27472473/3870549

For non-BRAM/SRAM primitives that you explicitly want to use, your best bet would be a blackbox. However, for memory, Chisel has built in memory hardware types `Mem` (synchronous write/asynchronous read) and `SyncReadMem` (synchronous write/synchronous read). A read or a write access to these infer a port.

On the FIRRTL side, there's a dedicated pass `ReplSeqMems` that will replace sequential memories with a blackbox and configuration file. The intent here is that the configuration file (describing info like width, depth, number of ports, etc.) can then be used as input to an SRAM generator.

For FPGAS, (and I may be wrong here), I think that without `ReplSeqMems`, when using `SyncReadMem`, things will automatically get inferred to BRAM for Xilinx tools. However, the same approach to `ReplSeqMems` could be used to replace memories with the correct template for a specific FPGA vendor tool.

Thanks for looking into Chisel!

Great question! However, this is an incredibly difficult question to answer as it relies on comparing language power. Paul Graham's "Beating the Averages" essay gets into this with the "Blub Paradox" [^1]. (tl;dr: a programmer versed in one programming language can evaluate less powerful languages, but not more powerful languages.)

The FIR filter example shown is parametric. Verilog is also parametric. However, Chisel, because it's embedded in Scala, gives you other programming paradigms/features that Verilog/VHDL do not have (or vendor tools do not support): object oriented programming, functional programming, parametric polymorphism, first class function support, etc.

The example of the front page could, instead of taking a `Seq[UInt]`, take a type parameter and be parametric for an arbitrary Chisel datatype (`UInt`, `SInt`, `FixedPoint`, etc.). Something like this just isn't possible with Verilog/VHDL. Analogously, Python and assembly both can describe for loops, but there are better dimensions for comparison.

Problematically, if shown advanced features like parametric polymorphism too early (e.g., on the front page of the website) potential users will get confused and turn away. If shown an example too simple, but recognizable, users will see no benefits. Alternatively, Chisel does address SystemVerilog pain points. Michael Taylor does a nice job of elucidating these in Section 5 of [^2].

As this question comes up a lot, I've tried to iterate on an answer on SO which may also be a useful read [^3].

If you have any suggestions on better ways to get this across, any feedback is welcome, too.

[^1]: http://www.paulgraham.com/avg.html

[^2]: http://cseweb.ucsd.edu/~mbtaylor/papers/Taylor_DAC_BaseJump_...

[^3]: https://stackoverflow.com/questions/53007782/what-benefits-d...

One of the Chisel/FIRRTL devs here available to answer any questions.

tl;dr: Chisel/FIRRTL is trying to be "LLVM for circuits".

Concretely, Chisel is a domain specific language for describing hardware in Scala. The Chisel front-end generates circuit IR (Flexible Intermediate Representation for RTL/FIRRTL), FIRRTL IR is then transformed/customized by the middle-end FIRRTL compiler, and finally emitted via a Verilog backend (and then fed into FPGA/ASIC tooling).

It's not High Level Synthesis, just powerful hardware description. You get all the features of Scala (object-oriented programming, functional programming, first class functions, parametric polymorphism) to write programs that generate circuits. Sadly, the last 50 years of software engineering is traditionally not available to hardware designers in classic languages like Verilog or VHDL. Chisel/FIRRTL is one solution to that.

We just released Chisel 3.2 and FIRRTL 1.2 which was a massive update. Notable additions include:

- Asynchronous Reset/Reset Inference: https://github.com/freechipsproject/chisel3/pull/1011

- BoringUtils (synthesizable cross module references): https://github.com/freechipsproject/chisel3/pull/718

- Strongly Typed Enums: https://github.com/freechipsproject/chisel3/pull/892

- Refactor of Chisel and FIRRTL as Stages of Phases: https://github.com/freechipsproject/firrtl/pull/1005 (and others)

- Aspect Oriented Programming: https://github.com/freechipsproject/chisel3/pull/1077

- Lots of documentation improvements: new website, dramatically increased Scaladoc

Going forward, we're trying to get the release cadence up and are pushing to make the verification problem easier. Others have mentioned Testers2 which is one effort in that area. A code coverage/assertion library is another effort.

Thanks for taking a look at Chisel and FIRRTL!

(Coming from a Chisel/FIRRTL dev...) Couple of clarifying comments:

CDE[^1] is really a Rocket Chip[^2] specific design decision meant to suit the configuration needs of system-on-chip generation (or: it's a Scala library which actually doesn't depend on Chisel and could be useful in unrelated projects). Also, SiFive should have fixed the issues with exceptions a long while ago (stack traces are still a thing, though).

Chisel gets a lot of criticism due to the (necessary) complexities of Rocket Chip. However, don't let that dissuade you from using it for a separate digital design project. None of the Rocket Chip complexity comes into play there.

Compilation time is something that we really care about and are seeking to make better. Minute-long Verilog generation times are something you would only see for mammoth design like Rocket Chip (generating MBs of Verilog). Nonetheless, we have some ideas on how to improve this via actual optimizations or meta-optimizations like grouping compiler transformations together that are safe to do so.

We also are really trying to make the Verification easier. One of these is effort on better testing via "Testers2"[^3] (name is TBD). The second is on improving the readability of the generated Verilog, e.g., emission of case statements [^4], emission of else-if[^5] (now supported!), etc. If you have suggestions we'd be happy to take a look (code examples of "I got this, but I'd like that" would be a huge plus, too!).

Regardless, thanks for taking the time to check it out.

[^1]: https://github.com/chipsalliance/api-config-chipsalliance

[^2]: https://github.com/chipsalliance/rocket-chip

[^3]: https://github.com/ucb-bar/chisel-testers2

[^4]: https://github.com/freechipsproject/chisel3/issues/1198

[^5]: https://github.com/freechipsproject/firrtl/pull/1204

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

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

[3] https://fires.im/

If you're interested in playing with Chisel, the "Chisel Bootcamp" is now hosted on Binder meaning you can run through a fair amount of learning content in a browser [1,2].

As a longer, elaborating point: Chisel is much closer to the LLVM compiler infrastructure project than a new hardware description language. Chisel is a front end targeting the FIRRTL circuit IR. There's a FIRRTL compiler that optimizes the IR with built-in and user-added transforms. A Verilog emitter then takes "lowered" FIRRTL and emits Verilog.

Consequently, Chisel is the tip of the iceberg on top of which the Edge TPU was built. The speakers in the video mention this explicitly when explaining the "Chisel Learning Curve" slide and doing automated CSR insertion.

As a further elaboration, Chisel is pedantically not High Level Synthesis (HLS). You write parameterized circuit generators not an algorithm that is optimized to Verilog.

[1] https://mybinder.org/v2/gh/freechipsproject/chisel-bootcamp/...

[2] https://github.com/freechipsproject/chisel-bootcamp

The author doesn't have this correct. Chisel is a domain specific language for hardware written in Scala that emits Verilog in Chisel2 or an intermediate representation of RTL (FRRITL) in Chisel3 which is then compiled in an LLVM-like fashion (passes that transform the FIRRTL) to Verilog.

SystemVerilog has all sorts of nice object-oriented features, but you can't use any of them for synthesizable code as you're dependent on the tool vendors supporting useful, yet complex things (e.g., classes, inheritance). Chisel avoids this whole problem by giving you access to extremely useful programming features (e.g., classes, functional programming) while still maintaining compatibility with whatever your ASIC/FPGA toolflow is.

The really cool thing is that existing implementations of RISC-V microprocessors, like what Berkeley provides, rocket (https://github.com/ucb-bar/rocket) and boom (https://github.com/ucb-bar/riscv-boom), and lowRISC uses and modifies have a dedicated accelerator socket.

We've have good luck developing software/hardware infrastructure for machine learning accelerators and interfacing an example multilayer perceptron backend with this infrastructure (with Linux integration ongoing). This work (shameless plug: https://github.com/bu-icsg/xfiles-dana) may provide a starting point, examples, or general guidance for developing machine learning or other accelerators in this space.

But, I can't overemphasize how the ongoing work at Berkeley and lowRISC have facilitated this process.