Simulating Arty A7 35 example in Vivado causes error due to hack in ibex_if_stage.sv

[epsilon537]

Observed Behavior

When I try to simulate the Arty A7-35 example in Vivado, I get an error message in elaborate.log:

ERROR: [XSIM 43-3409] Failed to compile generated C file xsim.dir/top_artya7_behav/obj/xsim_4.c.

Examination of xsim_4.c shows the following problem:

int gen_prefetch_buffer.simutil_get_scramble_key(svBitVecVal arg0[SV_PACKED_DATA_NELEMS(128)])
{...

That is not a valid function signature. This error can be traced back to the following snippet in ibex_if_stage,sv:

`ifndef SYNTHESIS
    // If we don't instantiate an icache and this is a simulation then we have a problem because the
    // simulator might discard the icache module entirely, including some DPI exports that it
    // implies. This then causes problems for linking against C++ testbench code that expected them.
    // As a slightly ugly hack, let's define the DPI functions here (the real versions are defined
    // in prim_util_get_scramble_params.svh)
    export "DPI-C" function simutil_get_scramble_key;
    export "DPI-C" function simutil_get_scramble_nonce;
    function automatic int simutil_get_scramble_key(output bit [127:0] val);
      return 0;
    endfunction
    function automatic int simutil_get_scramble_nonce(output bit [319:0] nonce);
      return 0;
    endfunction
`endif

If I disable this chunk of code, the simulation is working fine.

Expected Behavior

I would like to be able to simulate top_artya7 using Vivado.

Steps to reproduce the issue

1. make build-arty-35 program-arty
2. Open generated lowrisc_ibex_top_artya7_0.1.xpr in Vivado
3. Run Simulation

My Environment

Vivado 2021.2 Ubuntu WSL on Windows 11

Version of the Ibex source code:

git rev-parse HEAD 4ada605b6c5b287feebdb5620066b3f8b6495dc5

I did make some changes for simulation purposes but I verified that I get the same error on the unmodified codebase.

elaborate.log xsim_4.zip

[epsilon537]

I provided the wrong commit above. This is the correct one: efd289d

[a-will]

Note that this appears to be an xsim bug. It has added the generate block's name to the c_identifier, and this is incorrect. The standard says c_identifier must default to function_identifier for exported functions, so it must literally be simutil_get_scramble_key and simutil_get_scramble_nonce in these cases.

This particular block seems like something that would ideally be fixed up on the C side. ...but it can't be done in a non-simulator-specific way because of the linking style of DPI. As a workaround, perhaps we could try making the c_identifier explicit?