Invalid open array handle while passing an open array from c++ to system verilog

Hi,

I am trying to populate an array in c++ and pass it back to system verilog - that array is of the type shown below …

logic [15:0] pkt_data[64] - actually it is an open sized array, however when I try specifying that I get a error message (which is another one) that an unsized array cannot be passed through a DPI function.

Within my C++ code, I am using the “svPutLogicArrElem1VecVal” to actually populate the dynamic array and it is here that I am getting rapped in the knuckles with the following error message :-
** Error: (vsim-8504) An invalid open array handle (0xad876590) (type svOpenArrayHandle) was passed to the function ‘svPutLogicArrElemVecVal()’.

Time: 618135 ns Iteration: 1 Region: /uvm_pkg::uvm_task_phase::execute

So a couple of questions here,

  1. What exactly am I doing wrong in this case?
  2. Whenever you return data back to the System Verilog world from the c/c++ world - what should be the declaration of your ports in System Verilog world - output/ inout?

I can provide you with some more sample code should you need that to address this query.

This is not stopping simulation, however, I do get an error message.

Thanks and regards,
– Kartik.

You need to use an inout argument and allocate the open array on the SystemVerilog side first before calling your DPI C routine. You cannot allocate SystemVerilog dynamic types from the C side.

You need to show the DPI prototype in SystemVerilog, and you should be using the vlog switch -dpiheader dpi_header.h to generate a C header file that should be included in your C code. Then you will get a compile time check that your DPI code has been passed the proper argument types.

One more suggestion, unless you really need to handle 4-state data types or need to perform bit-by-bit manipulations of data, you should stick with C compatible data-types across the language boundary. It will be much more efficient as there no need to back and forth between canonical and simulator representations.

In reply to dave_59:

Hey Dave,

Thanks. I already have a DPI prototype in my System Verilog code and now I have declared this argument as an inout. What is happening then is that I get the following error message …

** Fatal: (SIGSEGV) Bad handle or reference.

I am compiling the entire C++ source code base (including the DPI functions in to uvm_dpi.so. As uvm_dpi.so is the UVM provided Shared Object library, we then provide a -gblso to vsim to include the uvm_dpi.so.

Shown below is the DPI function prototype …

import “DPI-C” function void seq_build_get_mxi_wpi_pkt (
pkt_t ptype,
output logic eop,
output logic first_pkt,
output logic last_pkt,
output logic [4:0] die_num,
output logic [31:0] buff_addr,
inout logic [15:0] pkt_data
)

And given below is the System Verilog call of this DPI function …

I construct the packet on the System Verilog side before I call the DPI function …

pkt_mod_req =new ();

seq_build_get_mxi_wpi_pkt (
pkt_mod_req.ptype,
pkt_mod_req.eop,
pkt_mod_req.first_pkt,
pkt_mod_req.last_pkt,
pkt_mod_req.die_num,
pkt_mod_req.buff_addr,
pkt_mod_req.data,
pkt_data_size
);

Further more on the C++ side I am trying to assign values in to this array and that is causing the afore mentioned error to occur.

Am I missing something here?

– Kartik.

In reply to kartik:

Your prototype has 7 arguments, and your actual call has 8 arguments, an extra pkt_data_size argument.

Assuming pkt_mod_req.data is declared as logic [15:0] data, then you need to do

pkt_mod_req.data = new[N]; before calling seq_build_get_mxi_wpi_pkt(), where N is large enough to hold the packet you want to write out.

In reply to dave_59:

Thank you so much Dave, the problem has been fixed. I initially tried having one more open array and doing a similar declaration as you have mentioned above. That fixed the issue, however when I was assigning that array to pkt_mode_req.data (in a for loop, using the pkt_data_size as a upper bound) pkt_mode_req.data still had Xs in all of its elements as a value (that was the initial value). However, I just changed the code as you have mentioned above and the Xs issue is also resolved.

I will focus on the other inputs - performance related ones and revisit my code.

Thanks again,
– Kartik.