[entropy_src] Power Management Improvements

[martin-lueker]

This issue is a follow up to PR #14391, which removed some unverifiable behaviors from the entropy_src, one such behavior was a return to Idle if there was no room for further outputs.

This leads to questions about how to prevent unnecessary power usage in this block, as there is no need to generate conditioned outputs if those seeds will not be used.

This is not the only power consideration employed by this block. There is also a pair of req/ack ports cs_aes_halt_req/ack which interact with the top-level design to limit the activity of the SHA3 conditioning engine in certain cases: notably when the AES block is also running. This serves to prevent large spikes in power. Similar optimizations can be also made to prevent the SHA engine from operating when the entropy_src's esfinal FIFO is full. Some care must be taken however to do this in a way that is verifiable.

Sending the SM back to Idle if the receiving FIFO is full causes problems for verification, as various SM states use different amounts of input entropy when creating the output seed. (The Startup phase uses two health-test windows worth of data, whereas the Continuous phase uses only one.) This is fine for verification if these transitions can be anticipated in verification. However, the FIFO overflow condition is not something that can be predicted reliably.

One option for future power management would be to use the same Req/Ack handshake mechanism for power management in this case: A SHA seed would be processed only if both the top-level handshake satisfied and the esfinal FIFO has room. This could for instance be done very easily if there were a "consensus" primitive to wait for acks from multiple sources.

[vogelpi]

FutureRelease sounds right for this issue.

[vogelpi]

Further stalling the entropy pipeline by not running the conditioner due to a full esfinal FIFO may be problematic. It must be ensured that if entropy is dropped, it is dropped in a spec compliant way. The easiest solution for now is to disable entropy source and re-enable it. This will also disable/re-enable the potentially power hungry RNG in AST and we can guarantee that the startup health checks are repeated after re-enabling. This is a must after re-enabling the RNG.