Power and other implementation considerations

Look at what can be done in the style guide to encourage low power design and prevent other potential implementation issues, as a couple of examples:

1. Flop resets/enables

To get decent power usage it's essential that flops are clocked gated and in a way that results in correct clock gate implementation. The style guide could insist all flops are written with an enable in a particular style unless there is a justification for it not to have one. As a related point it could insist flops only have resets if they actually require them

logic       data_valid_q, data_valid_d;
logic [7:0] data_q, data_d;
logic       data_en

always @(posedge clk_i or negedge rst_ni) begin
  if(~rst_ni) begin
    data_valid_q <= 1'b0;
  end else begin
    data_valid_q <= data_valid_d;
  end
end

always @(posedge clk_i) begin
  if(data_en) begin
    data_q <= data_d;
  end
end

2. Feedthroughs on IO

We may want to discourage feedthrough IO paths (input connected to output only via combinational logic) on top-level blocks unless they have been justified. The reason being these can lead to timing issues, as paths to top-level block IO may already to be long, with feedthroughs you'll join two long paths together so at the very least they need to be highlighted in documentation so users of the IP are aware of the potential issues when integrating.

Review the existing style guide and its treatment of flop resets, enables, and top-level IO paths. Define the intended guidance and scope for low-power design, reset usage, clock gating, and feedthroughs, then document the agreed recommendations and any required justifications.