Do you mean the RTL or the lit driver. In both cases, as little as necessary. We will, I suspect, want/need to run RTL level tests (with simulation constructs) for the integration testing for all the flows (e.g. handshake -> firrtl -> rtl/sv).
Yes and no. There are ways to run simulations with only verilator but they are very inconvenient for some classes of tests.
SystemVerilog is very good at (and originally designed for) cycle level simulation. It can easily handle driving signals and evaluating the outputs in parallel. With Verilator, all that needs to be done via the C++ API in software. And said testing driver software not portable to any other simulator. For any tests which need to have cycle-level awareness, Verilog is inconvenient. As you get higher up in functionality and abstraction, Verilator becomes more convenient.
When you get to the point where you’re only testing functionality, ESI’s cosimulation will come in handy. It provides an untimed, high-level interface to modules so you ignore the cycle-level interactions at the edges. It will eventually allow you to integrate into the application which is actually using the accelerator using the same API.
You could also imagine some hybrid of the two: using simulation constructs at the low-level to check the cycle-level signaling and cosim to drive the simulation and verify the results. Looks like verilator is beginning to support
asserts which could cover this use-case. I don’t know how much we’d do this in the circt integration tests though – this is more something users could want to do.
Either way, we’re definitely going to want a way to run SystemVerilog tests with simulation constructs.