[chip-test] chip_sw_rv_core_ibex_alerts

[sriyerg]

Test point name

chip_sw_rv_core_ibex_alerts

Host side component

SystemVerilog + Rust

OpenTitanTool infrastructure implemented

Yes

Silicon Validation (SiVal)

Yes

Emulation targets

• [ ] None
• [ ] CW310
• [ ] Hyperdebug + CW310

Contact person

@gregac

Checklist

Please fill out this checklist as items are completed. Link to PRs and issues as appropriate.

• [ ] Check if existing test covers most or all of this testpoint (if so, either extend said test to cover all points, or skip the next 3 checkboxes)
• [ ] Device-side (C) component developed
• [ ] Bazel build rules developed
• [ ] Host-side component developed
• [ ] Test added to dvsim nightly regression (and passing at time of checking)
• [ ] For SiVal test cases, test is running relevant FPGA or silicon regression

Note that this testplan entry seeks to cover all alerts signaled at ibex_top and at rv_core_ibex levels.

estimate 16

[GregAC]

estimate range 8 - 16

[moidx]

The test can be simplified to one alert trigger/injection. The condition can be added to the existing alert test top-level: chip_sw_all_escalation_resets

[johngt]

Assigning to @GregAC to forward assign to someone else as appropriate.

[GregAC]

@moidx @msfschaffner if I've understood the triaging correctly we've decided we're happy with chip_sw_all_escalation_alerts demonstrating alerts from Ibex so we don't need this test (which effectively tries all possible Ibex alert triggers that aren't covered elsewhere) for M2.5.1?

I would note chip_sw_all_escalation_alerts won't cover the ibex core itself triggering an alert (with the alert outputs on ibex_top), though one of the alerts triggered is the same as the alert triggered by ibex major alerts (TopEarlgreyAlertIdRvCoreIbexFatalHwErr). So we might want this test to check triggering that alert from an ibex internal source, though this is already covered by the chip_sw_rv_core_ibex_lockstep_glitch test.

The lockstep test is effectively an sv only test in the software it runs does no specific alert checking (it's just the AES smoketest). So in particular we won't be waiting for a reset, checking error codes etc. Though as chip_sw_all_escalation_alerts checks those, chip_sw_rv_core_ibex_lockstep_glitch ensures internal errors trigger alerts and the Ibex testbench is checking alerts are happening for individual scenarios (in terms of the alert being signalled at ibex_top) I think that's sufficient coverage for M2.5.1?

[msfschaffner]

Thanks @GregAC - I agree. What we basically wanted to ensure is that internal fatal alerts are correctly wired up into the system, and the coverage overlap between chip_sw_rv_core_ibex_lockstep_glitch and chip_sw_all_escalation_alerts - though not end-to-end - ensures that this is actually the case.

I am fine with moving this to M2.5.2.

[GregAC]

Discussed during triage meeting, we're happy with the coverage provided by existing tests so this won't be done for M2.5.2. It should be considered for V3.

[vogelpi]

I suggest de-prioritizing this test. The countermeasures of interest can only be exercised using FI equipment and this has been done using a separate test environment during pentesting.

[GregAC]

I agree, I had thought I'd bumped it down to P3 a week or so ago, not entirely sure how it ended up at P1

[andreaskurth]

By @vogelpi: We can check if we can extend the lockstep DV test to also cover this, but then it should be removed from the SiVal testplan. That should be part of V3 work, though.