VCS can not handle the way the mask_t is defined for specific instances. Since the mask_t and the data_t need the same width anyway, and the tools have problems with this call, I propose we just reuse the data_t directly.
Furthermore, I would argue that we should use a width parameter instead of a type parameter for data_t in the future. This requires an interface change, but the current implementation could run into problems if the data_t is defined as a multidimensional array. On line 369, we loop over all bits in data_t, which only works for 1D vectors or packed structs, afaik. We could also just flatten the data_t inside the module to avoid changing the interface. @andreaskurth What do you think?
VCS can not handle the way the
mask_tis defined for specific instances. Since themask_tand thedata_tneed the same width anyway, and the tools have problems with this call, I propose we just reuse thedata_tdirectly.Furthermore, I would argue that we should use a width parameter instead of a type parameter for
data_tin the future. This requires an interface change, but the current implementation could run into problems if thedata_tis defined as a multidimensional array. On line 369, we loop over all bits indata_t, which only works for 1D vectors or packed structs, afaik. We could also just flatten thedata_tinside the module to avoid changing the interface. @andreaskurth What do you think?An example where the tool encounters problems is the
axi_riscv_atomics/axi_riscv_lrsc/i_write_in_flight_queuemodule. Themask_tinferred by VCS is only 5 bits if thedata_tis 49 bits.