[ast, entropy_src] Reducing idle power

[vogelpi]

Description

ES measurements indicate that the power consumption of Earl Grey in idle mode is non-ideal. One possible reason for this could be in the interaction of AST and ENTROPY_SRC.

Currently, the documentation of ENTROPY_SRC states that once the esfinal FIFO becomes full (which is the case when the chip is idle), the SHA3 conditioner isn't run anymore and entropy is dropped at the input of the conditioner to save power. However, this isn't true. The conditioner is run even if the esfinal FIFO is full and entropy is dropped between the conditioner and the esfinal FIFO.

One other potential problem here is that previously, the noise source inside AST was disabled once the hardware pipeline inside ENTROPY_SRC generated backpressure. This could help against high idle power consumption but there are two issues with it: 1) in case of the esfinal FIFO gets full, the backpressure doesn't reach the front of the pipeline, i.e., the noise source is not disabled, 2) we had to rework this anyway for PROD because it's not spec compliant (whenever the noise source is turned on again, startup health tests need to be performed).

What we could do for PROD is to ensure ENTROPY_SRC can be disabled/enabled without disabling/enabling the full entropy complex (because that's more time consuming) or without dropping the content of the esfinal FIFO. Then, software could explicitly switch off ENTROPY_SRC and hence the noise source in AST to save power.

Does this sound reasonable to you @zi-v , @moidx ? Do you maybe have other and better ideas?

[zi-v]

I think it is OK to disable ES and AST RNG without disabling the subsystem. It may even be OK to keep entropy seeds on the side and inject them back into the system when needed. But as you mentioned, any stalling of the AST RNG or the health tests must be followed by a startup test.

[zi-v]

BTW, do we really need the HW conditioner? If it is acceptable to suck the data from the observe FIFO and push it by software to the CSRNG, we can reduce both gate-count and power consumption.

[jettr]

@vsukhoml as FYI

[vsukhoml]

Related issues #22293

[vogelpi]

Sorry @zi-v , I completely forgot to get back to you as a second issue got opened where most of the discussion happened. Apologies!

Thanks for your feedback. I think at this point we try to avoid further big RTL changes if possible. Changing the esfinal FIFO clearing would be doable but removing the conditioner (while having big area impact) feels like a very disruptive change at this point. It also makes the hardware block as such less attractive and I haven't been involved in this block from the beginning, thus don't know all the background. I wouldn't feel comfortable to remove it.

I am now closing this issue to continue the discussion in #22293.