How to do DPI-C "import declaration" in UVM where the arguments passed to the DPI are dynamic arrays?

UVM
,
1

I am trying to import a DPI-C which should take dynamic array as an argument. The DPI would get the array size only in run-time.

For example sth like this:

package dpi_pkg;

import “DPI-C” void my_function(int arr);

endpackage

class my_env extends uvm_env;

…

task run_phase();
int m_arr=new[100];

my_function(m_arr);

endtask

endclass

With the above implementation, my simulation is crashing with a segmentation fault. The simulator is DVE from synopsys.

Could anyone possibly show me the way out?

Thanks in advance.
-Cheers
Rupesh

2

In reply to RB87:

Most tools will generate the correct header file for use in your DPI code. Please refer to your tool documentation or contact your vendor support team for additional assistance.

3

In reply to cgales:
May be I did not explain the question well. The header is there and the implementation is working fine when I give the static size to the array arguments. The problem arises when the import declaration has dynamic array argument.

The argument that is passed to the DPI is defined to be of a certain size prior to calling the DPI. This seems not OK to the tool and hence the segmentation fault.

How to approach this scenario where the size of the array argument is known only during run-time? The DPI implementation in C has pointer argument. sth like:

void my_function(int *arr).

4

In reply to RB87:

When you use more complex datatypes, such as an unbounded array, you need to use specific DPI datatypes. In this case, you will need to use svOpenArrayHandle.

As I mentioned, tools will typically generate the C function prototype required to handle these functions. In this case, to match your DPI import, you will get:

void my_function(const svOpenArrayHandle arr);

5

In reply to cgales:
Thanks for the response @cgales. I have come across the solution that you mentioned while doing a little google search. Is there any work around if I do not have privilege of making change to the C implementation?

6

In reply to RB87:

Make a C wrapper around the C code you cannot modify.

7

In reply to dave_59:

Thanks Dave!! I can definitely do that!!!