You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The $macc is an efficient representation for when you have a bunch of bits from addends and multiplication partial products to add together. It is implemented with $fa cells to reduce the words until just two remain, and then a final add ($alu) to get the final answer. (It also creates the initial partial products for multiplies.)
There can be cases where the user doesn't want the final add. Maybe they are accumulating a value every cycle, and to reduce the critical path, they want to do the accumulation in redundant representation.
I suppose the main problem is, how would you represent this in Verilog other than by direct instantiation of this new $macc variant? And direct instantiation of $macc is of course challenging due to the CONFIG encoding. A more behavioral expression would be something like
{sum_0, sum_1} = $redundant_representation( a * b + c * d + e + f );
...but of course we don't want to start designing our own Verilog variant.
Anyway, just wondering if you'd thought at all about this.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
The $macc is an efficient representation for when you have a bunch of bits from addends and multiplication partial products to add together. It is implemented with $fa cells to reduce the words until just two remain, and then a final add ($alu) to get the final answer. (It also creates the initial partial products for multiplies.)
There can be cases where the user doesn't want the final add. Maybe they are accumulating a value every cycle, and to reduce the critical path, they want to do the accumulation in redundant representation.
I suppose the main problem is, how would you represent this in Verilog other than by direct instantiation of this new $macc variant? And direct instantiation of $macc is of course challenging due to the CONFIG encoding. A more behavioral expression would be something like
...but of course we don't want to start designing our own Verilog variant.
Anyway, just wondering if you'd thought at all about this.
Beta Was this translation helpful? Give feedback.
All reactions