Simulation is typically the functional verification workhorse, catching most of the bugs in a design. As multi-die systems have become more mainstream, chipmakers have created approaches to tackle the typical steps in the development process. The size of multi-die systems makes them too large to simulate in one run, so many chipmakers have opted for a divide-and-conquer approach. However, this manual approach has entailed writing scripts, and putting the results together from multiple runs can be time consuming and error prone. In addition, the methodology typically doesn’t allow for reuse.
Distributed simulation technology supports multiple participating executables without any restrictions on the identity of the executables. In other words, the same simulation executable (simv) could be run N times, with different simvs, or some mix as needed. It supports the interconnection for both register-transfer level (RTL) and the testbench and yields better performance compared to an approach with monolithic executables. While an in-house solution could take weeks to set up, distributed simulation can be up and running in just a few days and requires fewer memory resources, saving the costs tied to large-capacity hosts and farm machines.
The way that distributed simulation works is fairly straightforward. Users partition their simulation into multiple executables. For the compilation, each simv is compiled with an additional switch. A runtime configuration file specifies which RTL and testbench portions to connect. During the run:
- The simv instances, which are essentially monolithic SoCs, can be launched independently in any order, passing specific options as switches
- A leader simv, which utilizes a separate switch, controls the simulation and does the heavy lifting
- The leader simv invokes a separate server process to control the communication
- All of the results are fed into a single executable at the end of the run, providing a single view of the simulation results