chiseltest

Chisel is not HLS. It is a Scala library that lets you generate circuits on an RTL abstraction level. That means that you explicitly define every state element like registers and memories. But you can generate N registers inside a loop (or a map/foreach) instead of only 1 at a time. In HLS the compiler needs to somehow infer your registers and memories. That said, I think one of the problems the google team was struggling with is that in traditional HW development there is design and a separate verification team. The design team bought into Chisel since it would let them generate hardware more quickly, but the verification team just tried to apply their traditional verification methods on the _generated_ Verilog. This is almost like trying to test the assembly that a C++ compiler generates instead of trying to test the C++ program since a

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

I used Chisel to make a relatively simple memory encryption engine AXI component for FPGA. In my experience, the typedness and composability of Modules makes it significantly more productive than directly writing Verilog. There's an escape hatch, too: interfacing with vendored IP and hard macros is straightforwrd using `BlackBox` (DI is useful for mocking these in tests). My only wish is that Scala properly supported macros. One of my favorite components of the ecosystem is https://github.com/ucb-bar/chisel-testers2, which replaces the peekpoke tester and makes it easier to test asynchronous IO.

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