Bug report: multifmt slice uses wrong FP width for third operand
Created by: michael-platzer
Hi,
the fpnew_opgroup_multifmt_slice uses the wrong FP width for the third operand.
AFAIK the third operand is only used by the ADDMUL opgroup, which expects that operands_i[0] and operands_i[1] have the FP format specified by src_fmt_i and operands_i[2] and the result have the FP format dst_fmt_i:
Accordingly, the fpnew_opgroup_multifmt_slice should use the width of FP format dst_fmt_i when assigning the individual elements of operands_i[2] to the lane instances. However, the width of src_fmt_i is used for all operands:
As a result, the third operand is incorrect for all lanes (except for the first lane), as shown in the following waveform. The first group of signals shows the src_fmt_i (which is FP16) and dst_fmt_i (which is FP32), as well as operands_i[0] (for reference) and operands_i[2] of the fpnew_opgroup_multifmt_slice. The elements of operands_i[0] which are 16 bits wide are correctly assigned to the individual fpnew_fma_multi instances (as seen in the signal groups below, which show the input operands of the first three instances). However, the elements of operands_i[2] which are 32 bits wide are not correctly assigned. The individual elements of these operands are surrounded by rectangles of different colors.
