How do I stack trace info in the case of SystemVerilog+C DPI calls?

Question

I have a situation where I have 2 C functions. These C functions have many error checking scenarios where I use a exit(1) to cop out. A million places in system verilog code calls these 2 C functions via DPI calls.

I used execinfo.h and backtrace() functions in my C routines but the stack trace info displays the C function but above that it just shows some random vcs_exe.sim.1234_1.so as the main caller function.

I even tried looking for this vcs_exe.sim.1234.so in the published area but it does not point to any known Sv file.

So, how can I get the caller non-C/SV function when stack trace is being displayed?

I want to try some of the ideas put here. Will update as to what happens — user3662733, Aug 14 '17 at 15:12

Tudor Timi · Answer 1 · 2017-08-07T09:50:23.180

Ideally, your simulator would have a guide showing you how to do this. This might involve changing stuff in your build script to allow for the extra visibility. The vendor's support department should be able to help you if you can't find anything about this in the manual.

If your tool doesn't allow this, you could try implementing something by yourself. If your DPI method is context you can use the svScope concept to figure out the caller info. I haven't tested it, but it should be something like:

svScope scope;
scope = svGetScope();

char *fileName, *lineNumber;
scope.svGetCallerInfo(fileName, lineNumber);

This assumes that svGetCallerInfo(...) returned true, which I guess it should for context DPI methods.

score 0 · Answer 2 · answered Aug 07 '17 at 14:15

The way it worked for me with vcs was to call an exported function which would call the $stack in its turn. It works for me with 'default' and 'pure' binding in this example.

import "DPI-C" context function void testStack();

export "DPI-C" function printStack;

function void printStack;
   $display("====%m=====");

   $stack;
endfunction

module dpis;
   sub sub();
endmodule // dpis

module sub;
   initial
     testStack();
endmodule // sub

class Test;
   function void test;
      testStack();
   endfunction // test
endclass // Abc

program abc;
   Test a = new;
   initial
     a.test();
endprogram // abc

and 'c':

#include <svdpi.h>

extern void pringStack();

void testStack() {
    svScope scope;
    scope = svGetScopeFromName("$unit");
    svSetScope(scope);
    printStack();
}

and the result looks like this:

====$unit::printStack=====
#0 in printStack at dpis.sv:9
#1 in DPI function
#2 in dpis.sub
====$unit::printStack=====
#0 in printStack at dpis.sv:9
#1 in DPI function
#2 in <protected code>
#3 in abc at dpis.sv:30
#4 in abc

So, it gives some information about the location either as a module instance path or as a file/linenum.

this works kind of for me... it says printstack cant be found but it defintiely tells which sv file called it...but this is a great place to start and explore..thank u — user3662733, Oct 25 '17 at 20:14

score 0 · Answer 3 · answered Aug 13 '17 at 06:11

0

How about change the C code so that it won't exit(1), instead it just print an error message and return to the SV-domain gracefully?

What you need to debug the problem is set a break point at the line that prints out the error message, then step you way back to the SV-domain in the simulator. Voila! Now not only you know which SV class object calls the C-DPI, you can see the local variables of the SV class object to help diagnosis the problem.

answered Aug 13 '17 at 06:11

hevangel

95
5

That wouldnt work as these fail in a regression and I wanted the stack trace dumped by the regression run to give me a clue as to which SV function is the offending one. – user3662733 Aug 14 '17 at 15:11

How do I stack trace info in the case of SystemVerilog+C DPI calls?

3 Answers3