GSoC’21 Week 3: More Cores

Adithya Sunil
2 min readJun 27, 2021


The last post stopped at the process and core files. This time I’ll talk a little bit about verilator and the testbenches.

Verilator is an open-source tool that converts Verilog code to its cycle-accurate behavioural model in C++ or SystemC. It does not simply convert the code, but it also compiles the code into much faster-optimized models, which are in turn wrapped inside C++ or SystemC modules.

Why Verilator?

Verilator models execute 10 times faster than standalone SystemC and 100 times faster than interpreted Verilog simulators like Icarus Verilog on a single thread. Multi-threading yields another 2–10x speedup.

Verilog is similar or has better performance than the closed-source simulators used in the industry. Verilator being open-sourced provides the best cycles/dollar as you only need to spend on the computes and not licenses.

Verilator testbenches

Verilator is very unforgiving in terms of non-synthesizable code blocks. To be able to use testbenches with verilator, they will have to be synthesizable. Commonly used shortcuts in Verilog testbenches such as manual delay elements cannot be present when working with verilator.

In addition to the SystemVerilog testbench, we will have to write a C++/SystemC wrapper file that instantiates the verilated models. C++ compilers then compile these C++/SystemC files. The resulting executable performs the design simulation.

Week-3 updates

  • Created core files for all bsg_mem, bsg_cache, bsg_dataflow and bsg_async modules with lint targets.
  • Ported testbenches for bsg_misc to work with verilator.

Next week

  • Finish porting testbenches for bsg_mem.
  • Create core files for remaining modules



Adithya Sunil

GSoC Student Developer @ FOSSi || Undergraduate Researcher @ CVEST, IIIT-H