Constant function under generate

[mole99]

Hello!

When I enable a certain feature of the cv32e40x core by setting DBG_NUM_TRIGGERS to a value greater than 0, it seems that the code generated by sv2v has some issues that are discovered when running verilator in --lint-only mode:

%Error: cv32e40x_top.v:6940:32: Constant function may not be declared under generate (IEEE 1800-2023 13.4.3)
                              : ... note: In instance 'cv32e40x_top'
 6940 |      function automatic [31:0] sv2v_cast_9D931;

And indeed, the sv2v_cast_9D931 function is inside a generate block.

You can find the converted file here: cv32e40x_top.zip

Maybe this is already enough to find the root cause, if not, please let me know and I will prepare the source files to reproduce the issue. Thanks!

[zachjs]

Thank you for filing this issue! These constant functions within generate blocks are a useful conversion trick for sv2v. It may be possible to avoid them, but for most purposes, they work fine. Most commercial simulators support them. iverilog and yosys do, too.

I'm surprised verilator opts for an error rather than a warning here. The desired semantics are clear, and verilator used to support them. (Indeed, it supported them when I implemented this functionality in 16a13ee915144f8eaa3dd4933517ffe873e60479!) See https://github.com/verilator/verilator/issues/3103. What do you think?

[mole99]

Thanks for looking at this!

My obvious solution would be to move those three constant functions outside the generate block to the others, since they all seem to have unique IDs. But I don't know if that is feasible to implement in sv2v. Doing this change manually (and by passing -Wno-WIDTHEXPAND -Wno-WIDTHTRUNC -Wno-UNOPTFLAT -Wno-BLKANDNBLK) verilator is happy and produces no errors or warnings whatsoever.

I guess verilator throws an error because the LRM prohibits declaring a constant function inside a generate block as stated in https://github.com/verilator/verilator/issues/3103 Whether that really makes sense is a whole other question, but I guess we can't argue with the LRM...