[entropy_complex] Corner case tests at the chip level

[msfschaffner]

This issue captures recommended tests and associated questions that came up in the V2 meeting for EDN:

• There is probably a need for an entropy stress test at the system level. Current list of entropy consumers in the system:

  • AES
  • KMAC
  • OTBN
  • Keymgr
  • Ibex
  • Alert Handler (ping timer)
  • OTP Ctrl (background check timer)

  This test may end up looking very similar to parts of the power virus workload (maybe we can make this part of the same test?) [top] Provide list of desired vectors for power estimation #9297

• Do we need to cover special corner cases around sleep entry to assess EDN interfaces crossing CDCs? I.e., enter / exit low power state while an EDN fetch is ongoing in one or more entropy consumers? (Note: since there are no entropy consumers on the AON domain, deep sleep scenarios where power is turned off may be less interesting than light sleep where clocks are gated).

• Is there a need for a max latency test accross the individual entropy blocks / the entire entropy subsystem? For the latter, would it even be possible to bound the req -> ack latency accross the entire subsystem? If the answer is yes to any of these questions, how do we derive the thresholds?

If we decide to add any of the tests above, need to make sure these are reflected in the testplan.

estimate 16

[martin-lueker]

Hi Everyone, I'm reviewing Entropy_complex issues. This one has not seen much traffic since it was opened. Are there any updates?

[cdgori]

Just looking at those, I think the stress test will be needed for sure.

The CDC/sleep-wake part might be handled by some of the other ongoing CDC testing, not sure. If not then it seems like general cross-module testing of clock gating behavior is desirable. (Maybe this is more a "full chip" test than an "entropy complex" test though?)

I can argue that the max latency could be deferred (substantially or indefinitely) as long as we are doing boot entropy tests at the full-chip level. But I don't remember the context of why we considered/wanted that test?

[msfschaffner]

Agreed that the CDC/sleep-wake part may already be handled as part of the existing tests and CDC tooling.

For the stress test, the max load test may actually suffice, since it exercises the entropy complex quite heavily: #14814 (comment)

As for the max latency test - this came up as a question, but as you say this may not be needed if we have tests for critical functionality such as a boot entropy test. @moidx @tjaychen @alphan WDYT?

[tjaychen]

@cindychip @eunchan
For the max latency, we should double check whether kmac enforces that check in hardware.
I think it does, which is why we had a kmac timeout test I believe. That's the primary case to worry about here I think.

[alphan]

As for the max latency test - this came up as a question, but as you say this may not be needed if we have tests for critical functionality such as a boot entropy test. @moidx @tjaychen @alphan WDYT?

We have something in our todo list to make sure the boot mode entropy will be enough for ROM. Is this what you are referring to?

[tjaychen]

@msfschaffner and i talked through this today.
We believe the major points in this test can be covered by the power virus test and Nuvoton tests.
We do need to add one test in M3 to check the upper limit of secure boot, but we don't believe that needs to be M2 gating.

Let me know if anyone objects, otherwise we will drop this to M3 at the end of day tomorrow.

[zi-v]

I agree

[alphan]

@msfschaffner and i talked through this today. We believe the major points in this test can be covered by the power virus test and Nuvoton tests. We do need to add one test in M3 to check the upper limit of secure boot, but we don't believe that needs to be M2 gating.

Let me know if anyone objects, otherwise we will drop this to M3 at the end of day tomorrow.

SGTM

[GregAC]

Triaged for otbn I think it's worth considering an entropy stress test for M2.5

[vogelpi]

Triaged for entropy_src. I agree that we want this for M2.5.

[GregAC]

Triaged for rv_core_ibex same conclusion as above

[andreaskurth]

Triaged for edn and csrng, agree.

For the system-level entropy stress test, maybe parts of the chip_sw_power_max_load test could be reused (see #14814 for the state of its implementation).

[marnovandermaas]

I will track the effort of this for M2.5 in the EDN block:

estimate 16

[msfschaffner]

Discussed with @moidx. We are closing this issue since profiling the boot times can be done more accurately with real silicon samples using existing ROM E2E tests that have already been developed. The same tests could be inspected in simulation as well.