Most of the time if you were to want to develop for an FPGA, you might turn to Verilog or VHDL. Both of these are quite capable, but they are also firmly rooted in languages that are old-fashioned by today’s standards. There have been quite a few attempts to treat those languages as an output to some other tool — either a higher-level language or a graphical tool. One recent effort is a toolchain that starts with Chisel.
The idea behind Chisel is to provide Scala with Verilog-like constructs. If you want, you can use it as a “super Verilog” taking advantage of classes and other features. However, Chisel also allows you to create generators that produce different output Verilog depending on how you call them. True, you can do some of this with Verilog modules, but it is much easier with Chisel. Chisel uses Firrtl to convert what you ask it to do into Verilog for different FPGA and ASIC targets.
If you read some of the links at the homepage, you’ll see that they acknowledge that you can do anything you could do in Chisel in straight Verilog. In fact, there are some features Chisel lacks so far, although you can always fallback to Verilog black boxes to overcome those problems. However, that’s like saying why use C++ instead of C or C instead of assembly language. Early C++ compilers emitted C, so absolutely you could do anything C++ does in C — it just wasn’t always very easy. Ditto for assembly language. Obviously, you can do anything and everything in assembly. But the higher-level abstractions can make you more productive.
You can learn Chisel even if you don’t know Scala, without installing any software at all. There are even some simulation-based verification tools available. Of course, it’s worth remembering that there are a host of similar competitors out there including SpinalHDL and MyHDL. Time will tell if any of these ever gain widespread adoption.
Which features do Chisel lack?
Mainly like all boutique language, Standardization.
I am trying to use Rocket-Chip from UCB and CHISEL to make open-source SOCs at work.
https://github.com/chipsalliance/rocket-chip
Learning scala now slowly. I am well versed in VHDL and Verilog and have been using them both for 20 years for FPGA designs.
Looks interesting. I have used VexRiscv with SpinalHDL once, and was easy to customize and modify it.
What are the minimum number of LUTs you need for Rocket? Smallest implementation on a Cyclone IV needs only 730 LUTs with VexRiscv. Couldn’t find much information about it for the Rocket implementation.
Why did you choose Chisel and not SpinalHDL?
Some examples would be useful in an introductory article like this.
Good luck.
Pass the generated code through any decent lint tool and enjoy all the errors…
Yep, done this, through Xilinx ISE, Quartus, some industry-proven ASIC synthesizers.
It works flawlessly, because the verilog they output is very basic.
Also, most of those tools (like SpinalHDL) can check for comb loops or cross-clock violations beforehand.
I really struggle to see the point of all these languages that pop up to try and replace the industry standards. What IS the point?
Verilog and VHDL aren’t hard to learn.
Agreed, though I also struggle to understand why it’s 2019 and we’re still all trying to use procedural language to describe what’s intrinsically a schematic. Seems like we should be at a point where doing designs could be done by graphically editing a schematic. Instead we have now have throngs of software-minded types coming to FPGAs and fundamentally misunderstanding what they’re doing. Who can blame them, when vhdl & verilog *look* like code?
This was the biggest hurdle I had to overcome when I started playing with FPGAs. As soon as I made that leap from “coding an algorithm” to “describing a circuit” the rest was straightforward.
You could do block diagram/schematic with the entry tools from FPGA or 3rd party EDA vendors. I have used them for top level block diagram to connect the (hierarchical) blocks together. The blocks themselves could be schematics, HDL, state machines diagram.
Full schematic capturing starts to get tricky for any non-trivial designs as you can be talking about tens or even hundreds of thousands CLB. Let’s say you can fit 50 gates on a schematic for 11×17 page, how many pages before you lose tracks of off page connections?
It’s a pain to keep track of he propagation delays/setup/hold timing if you are working at the gate level. (There is a big table for those in the databok.) What happens when you need to fit the design to a different chip with a different set of timing or run the design at different speeds? i.e. you might have to reorganize the levels of combinational logic in a pipeline. VHDL and Verilog allows the tool to organize the gates for timing constraints.
Good post.
The Cadence software tools, and I assume other tools. allow the definition of buses. That takes care of most of the difficulties in keeping track of connections.
But the whole point is that it can be described as code! So code it up. But absolutely granted, you need to know what you are doing. You need to solve problems differently, parallel thinking instead of serial thinking.
This is where your complaint misses the point. The parallel here would be for software developers to stop thinking in code, but think of bits or operands …
If you are more into python, nmigen and nmigen2 might be a good option too.
I would also mention Migen/nMigen to build digital logic using Python. nMigen is a complete rewrite of Migen and v0.1rc1 was just released. Migen is especially useful when used with the LiteX ecosystem to build SoCs and there is a wide range of peripherals available (DDR, Ethernet…).
I started using FPGAs when they became readily available in the late 80’s. Back then it was all schematic designs. I favored Altera as their design tools and compilers were fast (for that era) and schematics were easy to produce. In an effort to make schematic designs faster, the vendors began introducing “megafunctions” which was a way of using templates to create certain circuits like counters, instead of having to do a gates-and-flops design yourself. Eventually the HDLs were introduced, and the early implementations were not compelling. I stuck with schematics until such time that the HDLs were the better choice. Yes, a picture is worth a thousand words, and you can convey meaning in a well drawn schematic that you really can’t in code. A good schematic is a form of art. But, it is much slower to draw schematics than to grunt out steaming piles of code (happily stole that phrase from an old Dilbert comic), so HDLs won the day. Deservedly too. You can enter designs faster, and, perhaps more importantly, modify and fix designs more quickly with HDLs. Time is money. I guess everything old is new again, but as an old schematic fan, I wouldn’t go back. HDLs are MUCH easier for teams of designers to work with on common designs. HDLs are MUCH easier to port from Intel/Altera parts to Xilinx parts, and vice-versa. Very hard to do with schematics. Back in the day (1990) I prototyped a design in an Altera part using schematics. When I converted to ASIC, I had to re-enter the entire schematic design, page by page, by hand. I don’t want to go back to those “good olde days.” And this from someone who really loves schematics. I would use schematics to teach some early aspects of FPGA design when one is first learning. I would then compare and contrast them with HDLs to illustrate why we use HDLs. Perhaps because of my strong schematic background, I prefer Verilog because it is closer to schematics in my brain. I still think in schematics, draw sketches of circuits on paper, and use hand-drawn timing diagrams to define what my design is supposed to do. Then it is all HDL.
I’m surprised no one has come up with a Javascript to HDL scheme.