[alert_handler] D2(S) Signoff

[msfschaffner]

Description

Ensure D2(S) signoff criteria are still maintained (this is not a focus area block).

[andreaskurth]

Commits since Earlgrey-ES tapeout

$ git log Earlgrey-M2.5.2-RC0..HEAD --oneline hw/top_earlgrey/ip_autogen/alert_handler

ab4b36f [ipgen,rstmgr] Fix paths to rstmgr in md files
5639924 Revert "[edn] Move prim_edn_req out of prim"
c721c51 [rtl, prim] Add 'commit' functionality to prim_count
61a237e [util/reggen] reverse order of substruct generation
4a9a881 [topgen] Pass topname key/value pair to ipgen
3b4e36e [edn] Move prim_edn_req out of prim
de31bdf [reggen] Remove the devmode input
975a6eb [adc_ctrl,dv] Tidy up access to intr_state in env_cfg files
ca2b62b [dv, testplan] Replace descr by desc for consistency
3b94957 [alert_handler,sival] Add feature list to alert_handler data
1b16ca2 [reggen] Add mubi support SWAccess that sets/clears a reg
59f8142 [doc] Moved badges over to using hosted images
7688e71 [reggen] Add initial support for version and cip_id hjson fields
fbd888e Revert "[reggen] Add CIP_IDs and bump all major versions"
0ba10b3 [reggen] Add CIP_IDs and bump all major versions
2c6d825 [alert_handler] Convert theory of operation to template

Issues closed since the Earlgrey-ES tapeout

https://github.com/lowRISC/opentitan/issues?q=is%3Aissue+is%3Aclosed+closed%3A%3E2023-06-27+alert_handler

• [clkmgr] V2(S) Signoff #21024
  --> signoff of another IP
• [clkmgr] D2(S) Signoff #20989
  --> signoff of another IP
• [script/alert_handler] generated files maintain a stable API #17755
  --> cleanup of TODO comment in code
• [dv/cdc] Enable CDC instrumentation in all ips #16689
  --> catch-all issue; the one relevant for this IP is [dv/cdc] Enable cdc instrumentation for alert_handler #18070 (below)
• [alert_handler] Improve ping timer ID selection mechanism #15720
  --> decided to not implement
• [chip/fpga] FPGA only tests to run through all counters in alert_handler #15458
  --> no longer needed
• [kmac] SCA hardening follow-up tasks #12323
  --> no action required for this IP
• [alert_handler] Meta Issue tracking alert handler opens #6675
  --> catch-all issue; only remaining open is [sw] Document software guidance on logging of alerts and events #6547, which is planned for M3

None of these issues should block D2(S) signoff of this IP.

Currently open issues

https://github.com/lowRISC/opentitan/issues?q=is%3Aissue+is%3Aopen+alert_handler

• [chip-test] chip_sw_alert_handler_entropy #21474
  --> SiVal test involving this IP
• [chip-test] chip_sw_all_escalation_resets #21473
  --> SiVal test involving this IP
• [chip-test] chip_sw_alert_handler_escalation_nmi_reset #21472
  --> SiVal test involving this IP
• [chip-test] chip_sw_alert_handler_escalations #21471
  --> SiVal test involving this IP
• [alert_handler] V2(S) Signoff #21028
  --> V2(S) signoff of this IP
• [alert_handler] D2(S) Signoff #20993
  --> this issue
• [rstmgr] D2(S) Signoff #20991
  --> signoff of another IP
• [ignore, sival] test_locked_all_tests #20197
  --> "fake" issue, to be ignored
• [sival] prod_all_tests #20194
  --> catch-all issue for SiVal tests, some of which involve this IP
• [bazel,otp_ctrl] OWNER_SW_CFG_ROM_ALERT_DIGEST_* values are hardcoded #19505
  --> build system issue
• [opentitantool] Document generation and check of alert_handler_regs.rs in CI #19501
  --> OTT issue
• [dv/cip] Handle random CDC delays inside prim_alert_sender in DV #18796
  --> DV issue involving this IP; planned for M4
• [dv/cdc] Enable cdc instrumentation for alert_handler #18070
  --> DV issue involving this IP; planned for M5
• [dv/alert_handler] remove chip level CSR exclusion for loc_alert_cause #17754
  --> DV issue involving this IP; planned for M5
• [dv/alert_handler] Functional coverage 100% #17361
  --> DV issue involving this IP; planned for M5
• [doc] Add human-readable names and descriptions to remaining blocks #17307
  --> general documentation improvement involving this IP
• [doc,alert_handler] Need program guide for alert_hander_config #16894
  --> documentation issue for this IP; planned for M4
• [keymgr/kmac] how kmac should send kmac_data_i.error #16792
  --> mentions this IP but lists no opens related to it
• [dv] More targetted FI testing for hardened FSMs and coverage #16572
  --> mentions this IP but lists no opens related to it
• [chip, dv, cov] Address low coverage of alert_dump and crashdump signals #15427
  --> mentions this IP but lists no opens related to it
• [chip/prim_esc_receiver] check if prim_esc_receiver is out-of-sync #14887
  --> DV issue involving this IP; planned for M5
• [tracking] Use ipgen to produce templated IPs #8440
  --> mentions this IP but lists no opens related to it
• [all] interrupt consolidation #3421
  --> mentions this IP but lists no opens related to it
• [alert_handler] adapt a generic model in DV to handle async #3275
  --> DV issue involving this IP; planned for M5
• [topgen] Remove duplicated license headers from autogen files #2929
  --> no longer relevant for this IP (I just updated that issue)
• [topgen] topgen flow #2083
  --> topgen issue planned for a future release; not critical for this IP or its integration

None of these issues should block D2(S) signoff of this IP.

Summary

The following commits changed alert_handler's RTL (from git log --oneline Earlgrey-M2.5.2-RC0..HEAD -- hw/top_earlgrey/ip_autogen/alert_handler/rtl):
5639924 Revert "[edn] Move prim_edn_req out of prim"
c721c51 [rtl, prim] Add 'commit' functionality to prim_count
61a237e [util/reggen] reverse order of substruct generation
3b4e36e [edn] Move prim_edn_req out of prim
de31bdf [reggen] Remove the devmode input
1b16ca2 [reggen] Add mubi support SWAccess that sets/clears a reg
fbd888e Revert "[reggen] Add CIP_IDs and bump all major versions"
0ba10b3 [reggen] Add CIP_IDs and bump all major versions
However, none of them changes the behavior of alert_handler. Thus, documentation and DV environment don't have to be updated.

There are currently no TODOs in alert_handler's RTL.

Checklist

alert_handler has been signed off at D3 before

✔️ No behavioral changes were made.
✔️ No features were added.
✔️ No TODOs exist in RTL code.
✔️ The lint flow is clean.
➖ There is no CDC or RDC flow at the block level.
✔️ I have reviewed the RTL changes in the commits above.
➖ There is no synthesis flow at the block level.
✔️ No SW-visible changes were made.
✔️ There are currently no "Won't Fix" bugs or "Errata".

Conclusion

I think alert_handler still fulfills the D2S signoff criteria. Is there a reason we don't directly sign it off at D3?

[andreaskurth]

@msfschaffner: Can you PTAL at this signoff analysis? TIA!

[msfschaffner]

Thanks for the analysis @andreaskurth.

The idea for this exercise was to double check that the IP fulfills the PROD.M2 exit criteria which is D2S/V2S.

Given that there were no changes, and that the Hjson still claims D3, I am fine with leaving it at D3:

opentitan/hw/ip_templates/alert_handler/data/alert_handler.hjson.tpl

Lines 18 to 22 in 2714197

	version: "1.0.0",
	life_stage: "L1",
	design_stage: "D3",
	verification_stage: "V2S",
	dif_stage: "S2",