Project

General

Profile

[logo] 
 
Home
About/Contact
Major Tools
  Dinotrace
  Verilator
  Verilog-mode
  Verilog-Perl
Other Tools
  IPC::Locker
  Parallel::Forker
  Voneline
General Info
  Papers

Change in DPI generation

Added by Eric Mejdrich over 2 years ago

All, I am seeing a change in generation of DPI function calls between the version of Verilator that I use (3.906) and latest.

Here is a trivial DPI function example:

export "DPI-C" function d_bfm_write_ignore_default_load;
function void d_bfm_write_ignore_default_load(integer i0);
   ignore_default_load = i0[0];
endfunction

Here is what the DPI call prototype is with latest:

static void d_bfm_write_ignore_default_load(const svLogicVecVal* i0);

With Older (3.906):

static void    d_bfm_write_ignore_default_load(int i0);

Building .a I also see a series of pointer cast(?) warnings that arn't present on 3.906 on some of my DPI code:

    Vtox_tc_cl2_tb__Syms.cpp:5644:444: warning: converting from ?void (Vtox_tc_cl2_tb_lsu_ddat_ary__P40_PB40::*)(Vtox_tc_cl2_tb__Syms*, IData, WData (&)[16]) {aka void (Vtox_tc_cl2_tb_lsu_ddat_ary__P40_PB40::*)(Vtox_tc_cl2_tb__Syms*, unsigned int, unsigned int (&)[16])}? to ?void*? [-Wpmf-conversions]
 tox_tc_cl2__c_l2_0__tc__xu__lsu__lsu_dcache0__lsu_ddat__lsu_ddat_ary_top__gen_intlv__BRA__7__KET____DOT__gen_way__BRA__0__KET____DOT__ddat_ary));
                                                                                                                                               ^
Vtox_tc_cl2_tb__Syms.cpp:5645:444: warning: converting from ?void (Vtox_tc_cl2_tb_lsu_ddat_ary__P40_PB40::*)(Vtox_tc_cl2_tb__Syms*, IData, WData (&)[16]) {aka void (Vtox_tc_cl2_tb_lsu_ddat_ary__P40_PB40::*)(Vtox_tc_cl2_tb__Syms*, unsigned int, unsigned int (&)[16])}? to ?void*? [-Wpmf-conversions]
 tox_tc_cl2__c_l2_0__tc__xu__lsu__lsu_dcache0__lsu_ddat__lsu_ddat_ary_top__gen_intlv__BRA__7__KET____DOT__gen_way__BRA__1__KET____DOT__ddat_ary));

I have many many hundreds of DPI calls and seeing the behaviour of many of them changed between 3.906 and latest. Is this expected? Did I miss a command line option during Verilation?

Thanks for any guidance, --Eric


Replies (3)

RE: Change in DPI generation - Added by Wilson Snyder over 2 years ago

The new version was changed to match the standards and other simulators.

An "integer" is a 4-state construct, therefore in it is properly passed as a svLogicVecVal.

If you want old behavior, instead declare it as an "int".

So I think it works right now, but if you have DPI examples that run on another simulator (e.g. declare the "C" arguments differently from Verilator), please file a bug and we'll look at it.

RE: Change in DPI generation - Added by Eric Mejdrich over 2 years ago

Ok, understood and thanks. On the DPI compilation warnings I have narrowed it down to the following:

When this signal is tagged as Verilator Public the warning is produced (and usage of the DPI call that accesses array_q causes a core).

   logic    [pWidth-1:0]                  array_q[pDepth]/*verilator public*/;

In file included from Vtox_tc_cl2_tb__ALLsup.cpp:5:0:
Vtox_tc_cl2_tb__Syms.cpp: In constructor ‘Vtox_tc_cl2_tb__Syms::Vtox_tc_cl2_tb__Syms(Vtox_tc_cl2_tb*, const char*)’:
Vtox_tc_cl2_tb__Syms.cpp:2461:0: warning: converting from ‘void (Vtox_tc_cl2_tb_l2c_dir_array__pi1::*)(Vtox_tc_cl2_tb__Syms*, IData, IData&) {aka void (Vtox_tc_cl2_tb_l2c_dir_array__pi1::*)(Vtox_tc_cl2_tb__Syms*, unsigned int, unsigned int&)}’ to ‘void*’ [-Wpmf-conversions]
  __Vscope_tox_tc_cl2_tb__tox_tc_cl2__c_l2_0__l2c__l2c_directory__gen_ways__BRA__0__KET____dir_way.exportInsert(__Vfinal,"dpi_l2c_dir_array_get_en
 ^

When /*verilator public*/ is removed the warning goes away and the DPI call works normally. This is a bit of a bummer as in some cases either in-situ access directly or use DPI. Can be worked around, but wanted to bubble this up in case it turns out to be something that wants to be looked at.

Thanks, e

RE: Change in DPI generation - Added by Wilson Snyder over 2 years ago

I can look at this, but can't see what's obviously broken. You need to file a bug with a test_regress style standalone test showing the issue (please see the manual for the format). Thanks.

    (1-3/3)