[ROM] consider checking FIFO depth before sending data to HMAC/KMAC interfaces

[moidx]

Description

In the past we had the assumption that any FIFO overflows would be prevented by stalling the bus. This is not an ideal behavior given that we could end up in a situation where incoming interrupts can cause deadlock scenarios.

Adding to the ROM milestone for initial triage.

[cfrantz]

Related: #23162: The ROM_EXT wants to use KMAC to seal the ownership configuration to the chip.

[moidx]

We are most likely dropping kmac from the ROM, and if we decide to keep it, it will be configured with software entropy to avoid system level hangs.

For hmac, the assumption we had from Z1 is that hmac would block the bus if the FIFO is at max capacity, and that hmac generally was faster than Ibex, so it was decided that there was no polling needed.

@gdessouky can you confirm that the hmac behavior will be the same for Earlgrey-PROD? Thanks

[gdessouky]

Yes, intended behavior is the same, and back pressure test does not fail, but will look into it more closely to confirm what the test exactly verifies. The intended behavior here is to make sure that the FIFO signals correctly when it is full, correct?

[gdessouky]

I've looked into the hmac_back_pressure test and can confirm that the IP blocks, i.e., does not receive new data, so long as the FIFO is full (except that it gets full now at 32 words not 16 words as previously), and that HMAC is still faster than Ibex+bus. @martin-velay can you also confirm this since you have been working with that test recently?

[martin-velay]

Actually I worked on the FIFO empty recently, and I am not familiar with the full part. But from I have heard/read is that indeed the Ibex is slower than the HMAC in general. If needed I can dig more on the back pressure ability, just let me know.

[cfrantz]

Because the HMAC engine is faster than the CPU, we don't believe this is an issue for the ROM.