Issues with SV structs in both Questa & Xcelium (some is probably a tool bug, but others are cocotb bug)

[jshaker000]

I was having issues running Questa 2020.2 and 2022.2 to read or write from system verilog structs declared as wires that have arrays under them.

To that end I made a 'test_quest_vpi' test case with a simple vpi.c and test_quest_vpi.sv.

Its also possible to see these kinds of error by running a cocotb bench and modifying the nets that I named. I beleive that the simplified VPI code runs similarly to what the cocotb code is doing because I get essentially the same seg crash

# calling vpi_get_value(0xec2302c0, &{vpiBinStrVal, {0}}) ... ** Fatal: (SIGSEGV) Bad handle or reference.

I already opened a ticket with Siemens about this but I wanted to let the broader community know.

I also noticed that in VpiImpl.cpp that there is no case vpiPackedArrayNet: under either static gpi_objtype_t to_gpi_objtype or *VpiImpl::create_gpi_obj_from_handle and that might be an additional issue in the cocotb code base itself, but my minimal example shows that there are atleast some issues with Questa in general.

test_questa_vpi.zip

[jshaker000]

This shows the VpiImpl.cpp issue, you can see that its dying probably because of the missing case statement before it gets to where my vpi sim breaks. In fact this attached code dies in both Xcelium and in Questa if the lines I commented are uncommented

test_questa_vpi_cocotb.zip

[marlonjames]

If you run cocotb with environment variable COCOTB_LOG_LEVEL=DEBUG, you should get more verbose logging of the VPI layer.

[jshaker000]

For the test_quest_vpi_cocotb.zip, with COCOTB_LOG_LEVEL=DEBUG, I get

#      0.00ns DEBUG    cocotb.gpi                                GpiCommon.cpp:314  in __gpi_get_handle_by_name        Checking if in_wire_struct_array is native through implementation VPI
#      0.00ns DEBUG    cocotb.gpi                                  VpiImpl.cpp:235  in create_gpi_obj_from_handle      VPI: Not able to map type vpiPackedArrayNet(693) to object.
#      0.00ns DEBUG    cocotb.gpi                                  VpiImpl.cpp:307  in native_check_create             Unable to fetch object test_questa_vpi.in_wire_struct_array
#      0.00ns DEBUG    cocotb.gpi                                GpiCommon.cpp:372  in gpi_get_handle_by_name          Failed to find a handle named in_wire_struct_array via any registered implementation
#      0.00ns DEBUG    cocotb.gpi                                gpi_embed.cpp:310  in embed_sim_init                  _initialise_testbench successful
#      0.00ns DEBUG    cocotb.gpi                                gpi_embed.cpp:327  in embed_sim_init                  Returning to simulator
#      0.00ns DEBUG    cocotb.gpi                                 GpiCbHdl.cpp:96   in run_callback                    Generic run_callback
#      0.00ns DEBUG    cocotb.gpi                          simulatormodule.cpp:186  in handle_gpi_callback             Returning to Python
#      0.00ns ERROR    cocotb.regression                         regression.py:396  in _score_test                     Test Failed: my_test (result was AttributeError)

and as I said, I think it is because of the missing line in the case statement that I showed above.

[marlonjames]

Regarding VPI, I'm sure that it has incomplete support. We would welcome a PR to add vpiPackedArrayNet support.

[G-ram]

To clarify this, syntaxes in verilog like input data_t [1:0] test where data_t is

typedef struct packed {
     logic a;
     logic b;
} data_t;

is not yet supported?