关于Chisel转VHDL/SystemVerilog及SystemC仿真的技术咨询

Great questions—these get to the core of Chisel's design priorities and the tradeoffs the team made when building its ecosystem. Let's break them down one by one:

1. Why doesn't Chisel prioritize VHDL/SystemVerilog conversion, especially given VHDL's popularity in regions like Europe? #

First, it's key to remember Chisel's origins: it was developed at UC Berkeley, where Verilog was the dominant language for both research and industry collaboration. The initial focus was on integrating seamlessly with the existing Verilog ecosystem—tools like Synopsys, Cadence, and open-source options like Verilator have decades of optimization for Verilog, making it a practical choice for targeting real-world hardware.

FIRRTL, the intermediate representation at Chisel's compilation core, was designed to be flexible enough to target multiple HDLs. In theory, a VHDL backend is entirely feasible, but the Chisel community has focused its resources on Verilog first because that's where the majority of user demand has been. Verilog's syntax and structural model align more closely with FIRRTL's low-level hardware representation, reducing conversion complexity compared to VHDL's stronger typing and more verbose structure.

That said, VHDL support isn't off the table entirely. Third-party projects and experimental backends have explored converting FIRRTL to VHDL, but they haven't reached the same maturity as the Verilog pipeline. As Chisel gains traction in regions where VHDL is preferred, we might see more investment here—but for now, the priority remains polishing the Verilog pipeline to meet industrial-grade requirements.

2. Why use a C++-based simulation model instead of SystemC? #

The choice boils down to three key factors: simulation speed, tool maturity, and alignment with Chisel's RTL-focused goals.

First, SystemC is primarily built for system-level modeling—higher-abstraction, mixed-signal, or software-hardware co-design scenarios. Chisel, by contrast, targets RTL-level hardware design, where the need is for fast, cycle-accurate simulation of large, detailed circuits. C++ simulation models (like those generated by Verilator, which is heavily integrated with Chisel) are optimized specifically for RTL execution, offering significantly faster speeds than SystemC for equivalent designs.

Second, the Chisel ecosystem already benefits from a robust toolchain built around C++/Verilator. Verilator has been around for over 20 years, supports massive designs, and integrates seamlessly with testbenches written in Scala (Chisel's host language) via C++ bindings. Adopting SystemC would require building an entirely new abstraction layer and tooling integration, diverting resources from the already high-performance existing pipeline.

Finally, SystemC has a steeper learning curve for hardware designers used to traditional HDLs, whereas C++ is more widely familiar across both hardware and software engineering circles. This makes it easier for teams to adopt Chisel without having to learn another specialized modeling language.

内容的提问来源于stack exchange，提问作者ARK91