Why do we choose the cocotb framework for verification

Initially, we used Verilator for verification; however, it did not support some of the Verilog features required by our specification model, which prompted us to switch to Synopsys VCS. Since we are an open-source project, Synopsys VCS was only a temporary solution. Our ultimate goal is to implement a fully open-source verification framework, along with an open-source verification model.

Directly using DPI-C for verification would tightly couple the test case and logic to the simulators, making migration and adaptability more difficult. To address this, we adopted the approach same as t1/difftest at master · chipsalliance/t1. This approach allows us to write Rust code that can interface with both Verilator and Synopsys VCS.

However, managing the versions of Rust, Cargo, and their dependencies presented significant challenges. We attempted to use Nix for package management, but it proved to be hard. For instance, whenever we modified Cargo.toml, we had to manually update the checksum and refresh dependencies — even during development when version consistency wasn’t critical. To make matters worse, working offline (which is common in IC development) introduced further difficulties. Without Intranet caching solution or package management for Nix, such as Sonatype Nexus for Maven, syncing dependencies between Intranet and Internet became cumbersome.

Compare with Verilog and Bluespec, Bluespec offers a more modern approach, where higher-level features won’t affect the lower-level Verilog compatibility. This decoupling ensures that Verilog artifacts are compatible with all Verilog tools, irrespective of how the higher layers are abstracted or reused. This is in contrast to directly using SystemVerilog for new features, which could lead to compatibility issues. By adopting Bluespec, we achieve better compatibility without sacrificing abstraction capabilities.

Our goal is to decouple test case and logic from simulators, as frequent switching between different simulators is often necessary to adapt to models from various vendors. For example, encrypted Verilog models from vendors are typically adapted to work with Synopsys VCS, Siemens Questa, or Cadence Xcelium. Although these models provide consistent interfaces, differences in encryption methods, Verilog versions, and implementation quirks often lead to tight coupling between the models and simulators. We plan to reimplement a set of open-source models in the future to enhance compatibility with all simulators, but for now, our focus is on decoupling the verification process. This would allow the reuse of the test case and logic across different tools, minimizing friction when switching between them.

cocotb is a framework empowering users to write VHDL and Verilog testbenches in Python. It provides a high-level API that simplifies interactions with the simulation environment, enabling users to write tests in a more intuitive and concise manner. It can be integrated with various simulation tools such as Synopsys VCS, Verilator, and others.

While commercial simulators like Synopsys VCS or Cadence Xcelium provide more comprehensive feature sets, cocotb preserves the crucial final step of seamless test case portability to open-source simulators like ICARUS Verilog or Verilator.