The rumour I heard was this: The problem with Chisel was that (at least in the past) the Chisel compiler did not preserve port structure well. So if you had a Chisel file that translated to 80M LoCs Verilog, then verified the 80M Verilog (which is very expensive), then made a tiny change to the source Chisel, the resulting new Verilog uses different port names even for the parts that were not affected by the change. (To quip: the (old?) Chisel compiler was a bit of a hash function ...) So you have to re-verify the whole 80M of Verilog. That is prohibitively expensive, compared to only reverifying the parts that truely need to change. The high verification costs forced by this problem were rumoured to nearly have sank a company.

This is a compiler problem, not a Chisel language problem. I was told that the compiler problem has been fixed since. But I did not check this.

> the future of SiFive is unclear

What is that supposed to mean? The future of Intel is unclear. The future of Arm is unclear. The future of Tesla is unclear. The future of Boeing is unclear. That's just life in a highly competitive industry.

> Choosing another language is pretty much impossible, unless you translate it to either SystemVerilog or VHDL.

?? Which of course is exactly what Chisel has always done. Do you even know anything about it?

> If you do that, then it is hard to justify using another language instead of writing directly in SystemVerilog or VHDL.

No it is not.

Chisel enables much more abstraction than Verilog, enabling you to design not just a single CPU core but a family with very different characteristics. Diplomacy simply has no analog in the Verilog world.

Chisel, FIRRTL, CIRCT enable the same kind of optimisations on RTL as GCC or LLVM do for C code. In fact CIRCT is built on LLVM. You can emit Verilog that is optimised for different hardware technologies, including different PDKs, or FPGA vs ASIC, in a way that is completely impossible with Verilog.