Add automated linking for Verilator

[quark17]

BSC can automate the linking of a Verilog simulation for a number of simulators. We should add Verilator to that list:

bsc -e topMod -verilog -vsim verilator

Basic support will require two things: (1) a new script called bsc_build_vsim_verilator in src/exec/ and (2) a verilator_main.cpp file (added somewhere in the repo) to perform the function that src/Verilog/main.v does for most other Verilog simulators.

Adding support for a new simulator is usually as simple as adding a new script in src/exec/ with a name starting with bsc_build_vsim_ and followed by the name of the simulator. The BSC executable does not contain any information specific to the simulator. BSC merely calls the appropriate script, using arguments to pass generic information about the design. The script contains all the knowledge about how to link the simulator, given that generic info. It should be possible to copy one of the existing scripts and change it for the specifics of Verilator.

The one wrinkle is that Verilog needs a top-level C++ file, which most simulators do not. For most simulators, we link the user's design with a main.v file that instantiates the design, provides a clock and reset, and turns on VCD dumping (if directed by plusargs). This file is provided in the release and can instantiate any module (by using preprocessor macros to insert the user's specific module name etc). For Verilator, we will need to a "verilator_main.cpp" that does the same thing -- instantiates a model (as specified by preprocessor macro), provides the clock and reset, enables VCD or tracing, etc. I'm not sure where this file would live. Perhaps we create a new directory Verilog.Verilator and put it there; or just in Verilog; or some new place for simulator files; or something else. This file doesn't need to be written from scratch but can be adapted from an existing file for the Bluespec RISC-V processors [link].

There's actually a second wrinkle: If a BSV design contains foreign function calls, BSC will generate VPI functions (wrapped around the imported C functions), and the scripts are responsible for linking those VPI functions into the simulator. Verilator does not support all of VPI that BSC uses (see issue #169 ), so a first version of the script may have to give an error if VPI files are provided. Although it may be possible for the script to auto-generate equivalent DPI imports.

[jahofmann]

Instead of supporting each simulator directly in BSC the project could use a tool like Cocotb which does the heavy lifting.

Then there would be only one top level Python file for all simulators.