> 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.
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.
> 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]
While there's plenty of room to improve a language like Verilog I fail to see how these paradigms would help me in RTL. What would polymorphism even look like in an environment without a concept of runtime? Can you elaborate and enlighten me?
Edit: Disclaimer, I'm well aware of the pros and cons of these paradigms in software development and use them plenty
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]
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.
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.
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
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.
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.
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.