Proposal: allow the FMA addend to be in either `src_fmt_i` or `dst_fmt_i` about cvfpu HOT 5 OPEN

Hi @michael-platzer

I prefer solution 2 as it doesn't change top level as well as T-Head FDIV/FSQRT interfaces.

Regards,
Pascal.

from cvfpu.

Hi,

as you say, nothing fundamentally prevents using a separate format for each of the operands, and you nicely point out why we didn't need to do it so far when designing the unit.
While less general, I also like option 2 as it keeps the changes internal to the FMA module (which itself becomes more general) and doesn't introduce [even more] configurability to the whole unit where it's not needed in most cases. Specialized architectures can still use direct instances of the FMA block if they require a more specific configuration.

Cheers,
Steve

from cvfpu.

Thanks for the feedback @pascalgouedo and @stmach! In that case I will move forward with option 2 and add a new operation for the add with operands of the same FP type.

Specialized architectures can still use direct instances of the FMA block if they require a more specific configuration.

Should I then add a new port add_fmt_i for the addend format to the FMA block, and assign as follows in all instantiations of the FMA?

    .add_fmt_i ( op_i == fpnew_pkg::ADDW ? src_fmt_i : dst_fmt_i )

That would allow specialized architectures to have even more freedom when directly instantiating the FMA block. Or should the format of the addend rather be decided within the FMA block?

from cvfpu.

I think an extra port on the multiformat FMA and the necessary changes for assigning it in the instantiating block is worth the effort to keep some generality on one hand, and conceptually not mingle formats and operations too much in the execution unit (basically the format used in the execution unit itself should just be decided by the format port itself).

Secondly, just a personal nit on naming: I would probably name the new port src2_fmt or similar (since it's just the format of the second source operand port), as with src_fmt and add_fmt there are kind of two separate nomenclatures (the addend is also a source after all) - I see that it was not very clean to begin with, as one of the source operands used the destination format in the past.
Consider renaming the format ports either

• src01_fmt & src2_fmt (or just src and src2 without the 01); or
• mul_fmt & add_fmt, but that clashes with the use of src and dst in the rest of the project.

(in case you want to go fully generic crazy, you could make each operand format independent and have src_fmt be an array of length 3 with one format for each operand - but that's not really something that's necessary at this point)

from cvfpu.

I think an extra port on the multiformat FMA and the necessary changes for assigning it in the instantiating block is worth the effort to keep some generality on one hand, and conceptually not mingle formats and operations too much in the execution unit (basically the format used in the execution unit itself should just be decided by the format port itself).

Alright, I agree that this sounds like a reasonable tradeoff.

Secondly, just a personal nit on naming: I would probably name the new port src2_fmt or similar (since it's just the format of the second source operand port), as with src_fmt and add_fmt there are kind of two separate nomenclatures

Good point!

• src01_fmt & src2_fmt (or just src and src2 without the 01);

I went with this approach and renamed the new port to src2_fmt_i. Updated my PR (#114) accordingly.

from cvfpu.