SV DPI - C code that uses a shared lib

[Avigail Rodman]

Hi,

I'm trying to use a DPI-C function in my SV env (creating a dpi.so lib and running it using VCS):
"vcs -debug_all -full64 -sverilog -R file.sv dpi.so"
This works fine for "basic" C functions.

Now my "dpi.so" library contain a function that uses another shared library, say utils.so (The reason for using it, is that utils.so contains some functions I need to use, supplied by 3rd party, but the argument they accept are structs defined in C header file).

When I try compiling it I get the following error:

vcs -debug_all -full64 -sverilog -R file.sv  utils.so dpi.so

Compilation error:

/usr/bin/ld: warning: librdi_commoncwebtalk.so, needed by /opt/Xilinx/Vivado/2017.1/lib/lnx64.o/librdi_simulator_kernel.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: librdizlib.so, needed by /opt/Xilinx/Vivado/2017.1/lib/lnx64.o/librdi_simulator_kernel.so, not found (try using -rpath or -rpath-link)
/opt/Xilinx/Vivado/2017.1/lib/lnx64.o/librdi_simulator_kernel.so: undefined reference to `std::thread::_State::~_State()@GLIBCXX_3.4.22'
/opt/Xilinx/Vivado/2017.1/lib/lnx64.o/librdi_simulator_kernel.so: undefined reference to `uncompress'
/opt/Xilinx/Vivado/2017.1/lib/lnx64.o/librdi_simulator_kernel.so: undefined reference to `compress2'
/opt/Xilinx/Vivado/2017.1/lib/lnx64.o/librdi_simulator_kernel.so: undefined reference to `typeinfo for std::thread::_State@GLIBCXX_3.4.22'
/opt/Xilinx/Vivado/2017.1/lib/lnx64.o/librdi_simulator_kernel.so: undefined reference to `std::thread::_M_start_thread(std::unique_ptr<std::thread::_State, std::default_delete<std::thread::_State> >, void (*)())@GLIBCXX_3.4.22'
/opt/Xilinx/Vivado/2017.1/lib/lnx64.o/librdi_simulator_kernel.so: undefined reference to `IDT::WebTalk::send(char const*, IDT::WebTalk::ProductType)'
/opt/Xilinx/Vivado/2017.1/lib/lnx64.o/librdi_simulator_kernel.so: undefined reference to `IDT::WebTalk::add(char const*, char const*, IDT::WebTalk::SectionType)'
/opt/Xilinx/Vivado/2017.1/lib/lnx64.o/librdi_simulator_kernel.so: undefined reference to `IDT::WebTalk::internal()' 


when I try compiling for C++:

vcs -lstdc++ -cpp  -debug_all -full64 -sverilog -R file.sv  libIp_xfft_v9_0_bitacc_cmodel.so dpi.so 

I get the following:

make: full64: Command not found
Makefile:107: recipe for target 'product_timestamp' failed
make: [product_timestamp] Error 127 (ignored)
../simv up to date

Error-[EXEC_NEX] Cannot run executable
  Cannot run executable 'simv' ; either it does not exist or not executable.
  Use -o <exe_name> if different than simv. 

How can I compile a DPI when the C code uses another shared lib? Is it possible?

Thanks :)

[EDA Playground]

Hi Avigail,

Please could you post the URL of the playground that is causing this problem?

Matthew

[Avigail Rodman]

Hi Matthew,

I'm sorry, I guess this is the wrong forum to ask... But I do have a question regarding the "SystemVerilog TestBench Example code" in : https://www.edaplayground.com/x/3uBz .
The question is quite long, and I hope this is the correct place...

Im trying to create a new simple SV env with env, monitor, driver, generator etc. classes.

So the env is the parent class which instantiate all child classes, thus, the env.sv file includes all other files..

Can I have a handle from the child classes to the env class, even if they compile first?

This is some of the monitor.sv :

class monitor;
 
virtual general_if gen_vif;
config             cfg;
 
function new(virtual general_if gen_vif)
        this.gen_vif = gen_vif;
endfunction

and some of the env.sv file :

`include "monitor.sv"
class environment;
 
 
virtual general_if gen_vif;
config             cfg;
monitor            mon;
 
function new(virtual general_if gen_vif)
     cfg = new();
     mon = new(gen_vif);
     mon.cfg  	= cfg;
 
endfunction

Can I have a handle from the monitor to env?

One more thing, I cant import DPI from a class, so if the monitor needs to call a function "some_funtion()" from dpi_import module, how can I establish a handle in the monitor class to this dpi_import module??

This is some of the dpi_import.sv :

module dpi_import ();
	import "DPI" function void some_function_c ();
	function void some_function ();
                some_function_c();
	endfunction
endmodule

And How can I have a handle to dpi_modul?

Thanks a lot!!
I'm very new to SV and any help would be greatly appreciated.

[EDA Playground]

Hi Avigail,

> Can I have a handle from the child classes to the env class, even if they compile first?

You must declare a class before you use it. So, this is OK;

     class INNER;
       ...
     endclass

     class OUTER;
       INNER i;
       ...
     endclass

and this is not OK:

     class OUTER;
       INNER i;
       ...
     endclass

     class INNER;
       ...
     endclass

You would normally declare a class in a separate file (and then import that file into a package - see below). So, there is a compile order dependency - you would need to compile those files in the right order.

Sometimes you get a circular reference, eg:

     class C1;
       C2 c2;
       ...
     endclass

     class C2;
       C1 c1;
       ...
     endclass

This can be resolved with a so-called "forward type declaration":

    typedef class C2;

     class C1;
       C2 c2;
       ...
     endclass

     class C2;
       C1 c1;
       ...
     endclass

> One more thing, I cant import DPI from a class, so if the monitor needs to call a function "some_funtion()" from dpi_import module, how can I establish a handle in the monitor class to this dpi_import module??

You need to take care to import your C function into the scope where the class is declared. In the example you linked to, it looks like the classes are declared in what is called "compile unit scope", ie they are declared outside of any module, program, package etc So, you would need to import your DPI function into this scope.

I have put together an example which shows the calling of a DPI function from a class which is declared in compile unit scope: https://www.edaplayground.com/x/2aY6 . You can see the importing of the DPI function and the declaration of the class C both occur in compile unit scope.

Personally, I would recommend not declaring classes in compile unit scope; instead in a real verification environment, I would recommend declaring them in a package. A package is a scope in itself and so declaring classes there enables any naming clashes to be sorted out (eg two classes with the same name). In my example, you will see that I have commented out the including and importing of the package P from the file p.sv. (If you were to uncomment these lines, you would need to comment lines 4 to 9 in testbench.sv.)

I hope this helps,

Matthew