I really wanted to like Chisel but after using it for an actual chip design, I’ve realized it leaves a lot to be desired – mainly relating to speed and readability.
For starters, it doesn’t seem to scale well. For a moderately complex design, it takes on the order of several minutes to generate Verilog code. When trying to work in a tight iteration debug loop this very much hinders productivity. In addition, it tends to eat up memory, too.
This is more of a scala/sbt thing, but typically the Chisel verilog generator is run via sbt which seems to only be able to run one thing at a time, so generating multiple (independent) modules described in the same project is not parallelizable without some finagling.
One thing I’ve noticed is, in an effort to support stable flattening and unflattening bundles to bit-vectors, the Chisel frontend will spend a large amount of its time doing reflection to get (bundle) class member names and sorting them (This I found after running it through a profiler – I apologize I don’t have those results handy).
The standard config environment for Chisel, CDE, makes things hard to understand because configuration for a design isn’t all kept in one place, but might be partially modified at any point in the code. This negatively impacts readability because one has to dive through and essentially understand the run-time call-stack in order to properly assemble the configuration in their head to diagnose why a particular value is set a certain way. (Reminds me of CSS, actually).
Also, CDE is essentially a layered switch case statement, which means it has O(n) lookup time which is also a big perf hit. In addition, each layer that does not contain a value throws an exception which also impacts performance when a large number of config lookups are happening in a design.
(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