Power and other implementation considerations about style-guides HOT 5 OPEN

CC @sjgitty @mdhayter @tjaychen

from style-guides.

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.

from style-guides.

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.

from style-guides.

from style-guides.

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.

from style-guides.