Power and other implementation considerations

[GregAC]

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.

[asb]

CC @sjgitty @mdhayter @tjaychen

[mdhayter]

Is that intended as a single example? If so would it be better to replace data_en with data_valid_d in the second always block?

I suspect that this will be objected to by the verification folks because of X propagation on data_q after reset. At least I got code review feedback to include the reset path in places like your second always block to prevent reset-time Xs. Other than that, I'd only put reset where it is actually needed.

[sjgitty]

1. Flops reset/enables

My two pence is that we should encourage flop enables, but I'm not sure
we want to encourage the removal of reset in those cases. Concerned about
the X propagation.

Noting that your example doesn't have the use of data_en in the first example.
Also not sure we want to "insist" as much as encourage. But overall I am very
much a fan of encouraging clock gating.

2. Feedthroughs on IO

I'm not sure this is a style guide issue, more of a design best practice. There are
cases where you'll want feedthroughs on some modules, but agreed that it should
be avoided. There are times in low-speed design where you can really take advantage
of the longer clock cycles and passthrough more than otherwise. So I would think
this becomes a per-design guideline rather than a style guide requirement.

[tjaychen]

i'm very much in agreement on having style guide recommendations on flop enables. I've been bitten many times around counters that endlessly clock. This might be a bit too far fetched right now..but do we want to consider also putting a lower bound on number of bits where this is required? I've seen a number of flows where if the bit length is < X, they don't enforce auto clock gate since the overhead logic might cost more. This is probably very technology / library dependent, so maybe just a note there needs to be flexibility would be good. On a similar note, maybe we also want to have guidelines around not asserting the CS or equivalent lines to memory needlessly etc.

…

On Sat, Oct 19, 2019 at 10:00 PM Scott Johnson ***@***.***> wrote: 1. Flops reset/enables My two pence is that we should encourage flop enables, but I'm not sure we want to encourage the removal of reset in those cases. Concerned about the X propagation. Noting that your example doesn't have the use of data_en in the first example. Also not sure we want to "insist" as much as encourage. But overall I am very much a fan of encouraging clock gating. 1. Feedthroughs on IO I'm not sure this is a style guide issue, more of a design best practice. There are cases where you'll want feedthroughs on some modules, but agreed that it should be avoided. There are times in low-speed design where you can really take advantage of the longer clock cycles and passthrough more than otherwise. So I would think this becomes a per-design guideline rather than a style guide requirement. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#10?email_source=notifications&email_token=AAH2RSTDR2UJR2D6BQKWY7LQPPQV7A5CNFSM4JCEJPAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBYCNXY#issuecomment-544220895>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAH2RSQUTQVXC5OAPYERYC3QPPQV7ANCNFSM4JCEJPAA> .

[tomeroberts]

I'd agree with the guidelines on flop resets and enables, and agree that it should be an encouragement rather than mandatory. Perhaps suggest the "standard" >= 3 flops justifies an enable.

My personal view is that the design should reset as little as possible, since a reset flop is ~2x the size of a non-reset flop in some technologies. If X's are propagating and causing (real) DV issues / LEC problems etc. then the design is broken and needs further qualification (or resets), if not then there's no problem.