Finding FUN – DPI-C Recording C Variables in a Wave Database
Pandemic?
Cold freeze?
No Power?
Ugh. What a 12 months. And all that’s unfolded.
I’m looking for some fun. I don’t know about you.
Hmmm.
DPI-C! That’s the ticket.
Imaginary Day Dream Helmet engaged.
Problem Scenario: I have some C code which I’m using as a GOLDEN model in my testbench. There are bugs and behavior differences between the C and SystemVerilog RTL.
Proposed Solution: Use DPI-C to record C variables in the wave database alongside the RTL signals. Compare. Find the bug.
Wait. I can turn my Imaginary Day Dream Helmet off. DPI-C can record C variables by adding just a little bit of code.
Ok. Go.
The C Code
My GOLDEN C code model has an array with 3 dimensions. (See line 7). It is the critical data structure. That’s what we want to record. The C code is already “time-based” simply by calling back into SystemVerilog using the ‘tictoc(1)’ call on line 54, below. Each call to tictoc(N) waits for N clocks, where the clock is defined back in the SV module.
Simply add a single line – a call to a function named ‘record_data(data)’ (line 53). We’ll implement record_data() as an “export DPI-C” function back in the SV module.
Cost: Change our C code : “Add One Line” (Line 53 – The gold line below).
C Code:
...
7 typedef int data_t[3][3][3];
...
25
26 int
27 calculate_algorithm(data_t v) {
28 data_t data;
29
30 int value, xvalue;
31 int i, j, k;
32 int sort[100];
...
46 for (i = 0; i < 3; i++) {
47 for (j = 0; j < 3; j++) {
48 for (k = 0; k < 3; k++) {
49 value = v[i][j][k];
50 data[i][j][k] = value;
51 sort[value] = 1;
...
53 record_data(data);
54 tictoc(1);
55 }
56 }
57 }
...The SystemVerilog Code
The SystemVerilog variable ‘data’ is declared in our RTL module as a 3x3x3 array of 7 bits. That is the place we will “record the C variable”. (Line 56 below)
“Recording” happens on line 62, when record_data() gets called. The argument ‘i’ was pushed onto the stack in C (line 53 above), and is then passed to the SV record_data() implementation and “recorded” by being assigned to the variable named ‘data’ (line 62 below).
SystemVerilog Code:
49 export "DPI-C" task tictoc;
50 task tictoc(int times);
51 repeat (times)
52 @(posedge clk);
53 endtask
54
55 typedef bit [6:0] data_t [3][3][3];
56 data_t data;
57
58 import "DPI-C" context task calculate_algorithm(
59 inout data_t data);
60 export "DPI-C" function record_data;
61 function void record_data(input data_t i);
62 data = i;
63 endfunction
...
67 R_array r_array;
68
69 initial begin
...
76 if (r_array.randomize() == 0) begin
77 $display("Error: Randomize failed");
78 end
79 local_data = r_array.data;
80 $display("INFO: Starting %m.data=%p", local_data);
81 calculate_algorithm(local_data);
82 $display("INFO: Finished %m.data=%p", local_data);
...
86 endThat’s it.
Cost: Change our SystemVerilog Module. “Add a DPI-C export function and variable“. 5 lines total. (Lines 56 and 60-63 – The gold lines above).
The Story
The SystemVerilog module is calculating a fancy algorithm based on a randomized 3x3x3 array of integers. There is a C model which is the golden source. Our SystemVerilog has 10,000 instances of these calculators. Each instance starts its own C model thread with a call to ‘calculate_algorithm(data)’.
The C model makes calculations about the input data, and those calculations get recorded in the wave database. The RTL does the same. The results should match.
In the image below, we’ve zoomed in and are inspecting the 9995th calculator.
Finally, using our regular debug tools, we can compare the C variable memory with the RTL variable memory and find the mismatch (highlighted in RED below).
Conclusion
Total cost: Add 6 lines of code. (The gold lines above)
Total fun. Complete source code is available demonstrating this bit of FUN.
If you want to hear more about DPI-C, please consider attending this Virtual DVCON US 2021 Session – Tuesday, March 2, 3:00-5:00 – “Advanced Methodologies 1” for the paper “Making Your DPI-C Interface a Fast River of Data“
Happy Verifying!
