[hmac] Implementation of wider digest & configurable key length

[gdessouky]

This brings the implementation of the wider digest size and configurable key length for HMAC (issue #20968). This should allow the HMAC IP to compute SHA-2 and keyed HMAC using either SHA-256, SHA-384 or SHA-512. This also allows configuring the key length to one of the supported 128-bit/256-bit/384-bit/512-bit/1024-bit. If a key length larger than the block size (which is twice the digest length) of a configured mode is picked, this gets capped to the block size, i.e., if 1024-bit key is selected with SHA-256, this will get capped at 512-bit to simplify the HW implementation. When a larger key length is required, the SW is expected to manage this by hashing the key and then supplying that hashed key to the HW.

SW usage requires additionally configuring the digest size and key length required - DIFs will need to be modified accordingly. Unsupported key lengths and digest sizes are not handled or tested at the moment; most conservative/correct approach is to not proceed with the operation and flag an error, and leave the digest CSRs untouched.

This PR also brings changes to the DV environment to provide preliminary support for the extended features and to pass the basic smoke test. I haven't modified other tests yet, and definitely don't see the full regression tests running without extending them all appropriately.

Note that this will need to be merged together with the save & restore implementation in PR #21307 and tested again to pass basic smoke.

Follow-up PRs needed:

• [ ] update documentation and programmer's guide
• [ ] update DIFs
• [ ] update HMAC version number
• [ ] handle unsupported digest size and key length configuration: flag an error and leave digest CSRs retaining previous digest. These are not dealt with at the moment in the RTL and DV.
• [ ] 1 or 2 DV checks/assertions trigger issues which I have commented them for now (labelled with TODO); I believe they are FIFO status issues that have come up because of the integration of the HMAC core with the 32-bit wrapper for the wider SHA-384/512 engine, and will need DV adaptations.
• [ ] extend DV support for the rest of the existing tests
• [ ] extend testplan to test new cases; e.g., supply unsupported digest size or key length configuration, configuration changes during runtime, etc.

[gdessouky]

After aligning with @andreaskurth, it's more ideal if we would merge this only after we confirm that original functionality (mode 256) hasn't been broken; this requires extending support to the full regression tests to pass for SHA-2 256.

[gdessouky]

I've force-pushed after rebasing and integrating with the save & restore changes in https://github.com/lowRISC/opentitan/pull/21307, and getting all block-level tests pass at 100% still. All do now, except hmac_stress_all_with_rand_reset at 7.50%, which is a V3 test, and I need to look more closely into it. I think this can wait after M2.

Thanks @vogelpi for your RTL review! I'll be addressing your comments in the next forced push, but want to try and get a first RTL implementation merged in.

I'll need to update the DIFs to pass the TLTs exercised in CI.

[andreaskurth]

We're working on fixing the failing CI checks. Essentially make -C hw is missing and some patches to SW using HMAC. Once this is concluded, what I think should minimally be changed before we can merge this is:

• [x] Change the MSG_LENGTH CSRs back to 2x32 bit
• [x] Decrease the address skip before MSG_FIFO.
• [x] Rebase on master to resolve conflict in hmac_core.sv (related to empty FIFO status).

All other opens, I think, can be addressed in follow-up PRs, and we should create issues to track them (after we have merged this PR).