ucb-bar/berkeley-hardfloat

MulAddRecFN infinite loops in Chisel elaboration if called with the wrong inputs (expWidth, sigWidth)

Opened this issue · 0 comments

There needs to be some enforcement/requirements on the inputs into the hardfloat units (e.g., MulAddRecFN) to catch infinite loops during Chisel elaboration before they occur.

In my particular use-case, the order of the input parameters expWidth and sigWidth had swapped, so I was unknowingly setting expWidth = 52, sigWidth = 12. I am directly instantiating rocket.FPUFMAPipe, which also swapped these parameters, so I never noticed the changes made to hardfloat (the changes to the recoding units was less problematic, since the function name also changed).

I believe the particular infinite loop occurs within MulAddRecFN_postMul, but it's not immediately obvious how.