Major Tools
Other Tools
General Info

Lightweightlibrary for writing multiple parallel Verilator testbench drivers?

Added by Udi Finkelstein 9 months ago

I want to write a testbench for a large SV RTL codebase. The code is currently simulated via a Verilog testbench running multiple independent drivers and monitors using fork/join. So far all the Verilator testbenches I've seen were sequential single tasks, but the testbench I need to write can be expressed much more clearly by multiple independent threads, each spanning multiple verilator clock cycles. Current code verilog testbench code is styled similar to this fictional bus driver/monitor code:

bus <= addr[7:0];
@(posedge clk);
bus <= addr[15:8];
@(posedge clk);
bus <= data[7:0];
@(posedge clk);
while (~i_valid)
  @(posedge clk);
datain <= busin;

I need to have multiple , parallel drivers of this type spawned at arbitrary clock cycles (and each driver may be spwaned multiple times along the simulation).

I could probably break the code into pieces and force it into a single thread, but it would be ugly and hard to maintain: Each driver would need to be converted into an FSM, and become less clear.

Anyone has a recommendation for a multithreaded/coroutine library to make this easier, or even a nice example showing this?

I guess I could write the top in SystemC, but other than the fact that I've never used SystemC before, I'm afraid of adding too much overhead in terms of performance.

thanks, Udi

Replies (1)

RE: Lightweightlibrary for writing multiple parallel Verilator testbench drivers? - Added by Wilson Snyder 9 months ago

Which language are you asking about writing these in?

If C++, then I'd use C++11 threads.

If Verilog, then using a thread library is the least of your problems, as Verilator won't understand how to handle these.

If your constructs all look relatively the same, similar to the code you posted, you could either preprocess or extend verilator to automatically convert them to FSMs. (FSMs will be easier to get working and result in much faster code than forking threads on one core. (Plus if you want multiCPUs then Verilator can then multithread the output itself with better knowledge of the whole design.) ) Obviously the community would like to see improvements in this, so your investment would be appreciated.