[chip-level] chip_sw_sram_execution

[rswarbrick]

Test point name

chip_sw_sram_execution

Host side component

None

OpenTitanTool infrastructure implemented

None

Silicon Validation (SiVal)

None

Emulation Targets

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

Contact person

@rswarbrick

Checklist

• [ ] Cut down the existing sram_ctrl_execution_test.c to work in silicon: we expect to be in life-cycle state PROD, where SRAM execution is not allowed.
• [ ] Do any host-side component work needed. We expect Ibex to die when it tries to execute something it's not allowed to execute. Check that we support testing that on the host side.
• [ ] Update hjson test plan with the test name (so it shows up in the dashboard)
• [ ] Get test running on relevant FPGA or silicon regression

estimate 4

[jwnrt]

The current sram_ctrl_execution_test.c test:

1. Tries to execute before SRAM execution is enabled, causing an exception.
2. The expected exception is handled, and the test continues.
3. SRAM execution is enabled.
4. Positive case for executing from SRAM is tested.

This test is working on the FPGA with an OTP that allows SRAM execution. Without SRAM execution, parts 1 and 2 still pass, but enabling SRAM execution fails.

@rswarbrick do you think we need to handle the error thrown by step 3 and re-run steps 1 and 2 to ensure that trying to execute from SRAM still triggers the exception?

[rswarbrick]

Well, I guess that would be the super paranoid approach :-)

Can't we be a bit lazier though? Presumably, there's an "allow SRAM execution" config bit which starts out false. With an OTP that doesn't allow SRAM execution, does the config bit ever change? If not, maybe there's an easier test there?