Hacker News new | ask | show | jobs
by seldridge 2434 days ago
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.

1 comments

How do Chisel/FIRRTL handle inference of built-in primitives like synchronous RAM blocks in FPGAs?

I have built my own HDL, which is basically "cleaner Verilog" and not a generator-style approach like Chisel, and gets compiled to Verilog. One big problem I had was how to describe RAM blocks with synchronous read/write ports, or even worse, RAM blocks with two independent ports which are both synchronous read/write (i.e. BlockRAM in Xilinx FPGAs).

My intention was to make the HDL more powerful than just providing BlockRAM as a built-in module that can be instantiated, because this way the "assignment" of the read/write port, which determines clock/enable logic, can be merged into other synchronous blocks using the same clock and enable signals (nested if-statements), thus be more readable. But I never found an easy way to "extract" the BlockRAM's output register and enable out of a statement block, short of writing a full primitive inference system myself (which I tried to avoid).

Without such extraction, I could only convert the statement to a Verilog statement and rely on the inference from Xilinx's tools. I ended up with "patterns" that the hardware developer has to use, very similar to Xilinx's primitive instantiation templates, which would be compiled to the appropriate patterns in Verilog. Naturally this takes several tries until Xilinx's tools recognize what I intended to build. In retrospect, providing built-in submodules would have been easier.

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.