[keymgr_dpe, rtl] Introduce registers to read slot metadata

[rroth-lowrisc]

This PR introduces HW register which allows sw to read the metadata for each hw slot. It was aggreed in this RFC. The sw side will be implemented in a follow up PR.

This PR depends on:

• [keymgr] Remove in favor of keymgr_dpe #31161

Only the last 5 3 commits are relevant for this PR.

edit: prior to merge the commit marked [SQUASH_ME] must be squashed for a clean history.

[rroth-lowrisc]

Note: I will need the function extract_metadata_from_slot(...) later on in another PR too. To avoid code duplication I wrote a function (even if its called only once for now)

[gautschimi]

Thanks for this PR. It is mostly good. Just a few comments:

1. Instead of METADATA_LOW/HIGH we could call the registers SLOT_KEY_VERSION, SLOT_METADATA. But no strong opinion about it. What do you think?

2. are there any security concerns of exposing this information? If yes, do we need an option to disable this output? E.g. a regwen that just ties the info to 0.

3. I think at the moment we add around 300 registers for this block. half of them might get optimized away because they are constant 0. But I believe we can get rid of all of them by defining the registers to be external (in the slot). Would be worth to synthesize this.

4. Can we create a sw-issue to update the dif with this new functionality? (Maybe it already exists. in that case just link it)

[rroth-lowrisc]

Thanks @gautschimi for your review, I will take a look.

1. I prefer the solution with _HIGH / _LOW. SLOT_KEY_VERSION sounds like it doesn't belong to the metadata.
2. I talked about this with @nasahlpa. AFAIR reading from these register requires root access and if you manage to get root access you can do far worst than reading these register. But not having one and finding out afterwards that you would have needed one fells also a bit wrong. @nasahlpa What do you think about this?
3. Yes, I didn't know the hwext: "true" option
4. [keymgr_dpe, sw] Support metadata register in various driver #31356 introduces the feature in all drivers while [keymgr_dpe, rom/rom_ext] Verify boot_stage of UDS / CDI_0 / CDI_1 DPE context #31357 uses the feature in ROM

[gautschimi]

Thanks @gautschimi for your review, I will take a look.

1. I prefer the solution with `_HIGH` / `_LOW`. `SLOT_KEY_VERSION` sounds like it doesn't belong to the metadata.

2. I talked about this with @nasahlpa. AFAIR reading from these register requires root access and if you manage to get root access you can do far worst than reading these register. But not having one and finding out afterwards that you would have needed one fells also a bit wrong. @nasahlpa What do you think about this?

3. Yes, I didn't know the `hwext: "true"` option

4. [[keymgr_dpe, sw] Support metadata register in various driver #31356](https://github.com/lowRISC/opentitan/pull/31356) introduces the feature in all drivers while [[keymgr_dpe, rom/rom_ext] Verify `boot_stage` of UDS / CDI_0 / CDI_1 DPE context #31357](https://github.com/lowRISC/opentitan/pull/31357) uses the feature in `ROM`

The register names (1) are ok, let's leave them as they are.
Good that (2) was already discussed with @nasahlpa. For me either solution is fine.
Thanks, I've just reviewed the software PR (4):)

[andreaskurth]

Thanks @rroth-lowrisc for this PR! Exposing the slot metadata lets SW see each slot's boot stage again, and the change is small and in line with the RFC. Beyond the points @gautschimi already raised, I only have minor comments.

Am I right that nothing verifies the new registers yet? No sequence reads METADATA_*, the scoreboard handles them in its default branch ("isn't handled", no read check), and the testplan has no entry for them. The CSR tests pass locally, but they only cover reset values and RO behaviour. Could you open an issue to track this (e.g., linked to #30753)?

[rroth-lowrisc]

Thanks @rroth-lowrisc for this PR! Exposing the slot metadata lets SW see each slot's boot stage again, and the change is small and in line with the RFC. Beyond the points @gautschimi already raised, I only have minor comments.

Am I right that nothing verifies the new registers yet? No sequence reads METADATA_*, the scoreboard handles them in its default branch ("isn't handled", no read check), and the testplan has no entry for them. The CSR tests pass locally, but they only cover reset values and RO behaviour. Could you open an issue to track this (e.g., linked to #30753)?

Thanks for the review @andreaskurth - I implemented your suggestions and squashed the SQUASH_ME commits.
I opened issue #31512 to track the verification of these register.
PR #31357 uses this feature to verify the boot_stage for context derived in ROM / ROM_EXT

[andreaskurth]

LGTM, thanks @rroth-lowrisc!

[andreaskurth]

CHANGE AUTHORIZED: hw/top_earlgrey/ip/xbar_main/rtl/autogen/tl_main_pkg.sv
CHANGE AUTHORIZED: hw/top_earlgrey/rtl/autogen/top_earlgrey_pkg.sv

The new METADATA_LOW/METADATA_HIGH registers double the keymgr_dpe register space from 0x100 to 0x200, so topgen regenerated the crossbar address mask and the peripheral size. The base address is unchanged and the new range fits the existing 64 KiB peripheral slot.

[vogelpi]

CHANGE AUTHORIZED: hw/top_earlgrey/ip/xbar_main/rtl/autogen/tl_main_pkg.sv
CHANGE AUTHORIZED: hw/top_earlgrey/rtl/autogen/top_earlgrey_pkg.sv

The new METADATA_LOW/METADATA_HIGH registers double the keymgr_dpe register space from 0x100 to 0x200, so topgen regenerated the crossbar address mask and the peripheral size. The base address is unchanged and the new range fits the existing 64 KiB peripheral slot.