As extensively discussed in #922, Calyx often defaults unassigned values to zero. The verilog backend has some optimizations for @data ports that is able to optimize these assignments away, but I argue we need to be more aggressive with taking advantage of undefined behavior to remove zero assignments. This is mostly motivated by my discovery that these additional assignments can easily impact the maximum frequency of a given design. Each of these assignments can also add 1-2 LUTs in area which adds up quickly.
Essentially this optimization should make the default value of guards 'x whenever possible. One possible way to do this is to mark as many primitives with @data as possible. I'm not really sure what determines whether a primitive can be marked @data. We should also think about whether we can be more careful about not generating default zero assignment during FSM generation when they're not needed.
As extensively discussed in #922, Calyx often defaults unassigned values to zero. The verilog backend has some optimizations for
@dataports that is able to optimize these assignments away, but I argue we need to be more aggressive with taking advantage of undefined behavior to remove zero assignments. This is mostly motivated by my discovery that these additional assignments can easily impact the maximum frequency of a given design. Each of these assignments can also add 1-2 LUTs in area which adds up quickly.Essentially this optimization should make the default value of guards
'xwhenever possible. One possible way to do this is to mark as many primitives with@dataas possible. I'm not really sure what determines whether a primitive can be marked@data. We should also think about whether we can be more careful about not generating default zero assignment during FSM generation when they're not needed.