[sram_ctrl/dv] Verify the MEM.READBACK feature

nasahlpa commented 5 months ago

Description

PR #23212 introduced the readback mode to the SRAM controller. However, currently, we do not test, whether this feature can mitigate bit flips introduced by FI.

vogelpi commented 5 months ago

This issue is about creating a sec_cm DV test for the readback feature. It would be nice to have but it will only cover a list of pre-defined signals fed into the test. What really counts for this feature is doing some kind of formal analysis, RTL simulation with automated FI or real FI on a chip / FPGA. All this seems out of scope for M5. I am thus assigning a lower priority to this one for now.

vogelpi commented 4 months ago

I suggest moving this to M6 / M7 as we have more important things to do right now. This issue involves quite some effort.

andreaskurth commented 4 months ago

Just discussed: We have high confidence in this feature, and this CM test would just check that the alerts are properly connected, which is also being checked in the netlist. --> M7

nasahlpa commented 4 months ago

I have manually tested that the readback mechanism successfully detects a mismatch and triggers a fatal alert.

More specifically, I have changed this comparison: https://github.com/lowRISC/opentitan/blob/1b56f197b49d5f597867561d0a153d2e7a985909/hw/ip/tlul/rtl/tlul_sram_byte.sv#L156 to:

assign rdback_chk_ok_unbuf = (rdback_data_exp_q == ~tl_sram_i.d_data);

When starting the SRAM smoketest with:

./util/dvsim/dvsim.py hw/ip/sram_ctrl/dv/sram_ctrl_main_sim_cfg.hjson -i sram_ctrl_smoke --fixed-seed 1234 -t xcelium

I get:

UVM_ERROR @ 578601207 ps: (cip_base_scoreboard.sv:242) [uvm_test_top.env.scoreboard] Check failed expected_alert[alert_name].expected == 1 (0 [0x0] vs 1 [0x1]) alert fatal_error triggered unexpectedly

Which is the expected behavior.

lowRISC / opentitan

[sram_ctrl/dv] Verify the MEM.READBACK feature #23322

Description