[sram_ctrl/dv] Verify the MEM.READBACK feature #23322
Comments
|
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
added
the
Triage: deprioritize?
|
I suggest moving this to M6 / M7 as we have more important things to do right now. This issue involves quite some effort. |
|
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 |
andreaskurth
removed
the
Triage: deprioritize?
|
I have manually tested that the readback mechanism successfully detects a mismatch and triggers a fatal alert. More specifically, I have changed this comparison: opentitan/hw/ip/tlul/rtl/tlul_sram_byte.sv Line 156 in 1b56f19 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 xceliumI 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 unexpectedlyWhich is the expected behavior. |
This commit provides a new sec_cm_readback test that tests the SRAM readback FI countermeasure. In the test, a fault is injected during one of the read/write SRAM requests. The test checks, whether the expected alert fires. Closes lowRISC#23322. Signed-off-by: Pascal Nasahl <[email protected]>
This commit provides a new sec_cm_readback test that tests the SRAM readback FI countermeasure. In the test, a fault is injected during one of the read/write SRAM requests. The test checks, whether the expected alert fires. Closes lowRISC#23322. Signed-off-by: Pascal Nasahl <[email protected]>
This commit provides a new sec_cm_readback test that tests the SRAM readback FI countermeasure. In the test, a fault is injected during one of the read/write SRAM requests. The test checks, whether the expected alert fires. Closes lowRISC#23322. Signed-off-by: Pascal Nasahl <[email protected]>
This commit provides a new sec_cm_readback test that tests the SRAM readback FI countermeasure. In the test, a fault is injected during one of the read/write SRAM requests. The test checks, whether the expected alert fires. Closes lowRISC#23322. Signed-off-by: Pascal Nasahl <[email protected]>
This commit provides a new sec_cm_readback test that tests the SRAM readback FI countermeasure. In the test, a fault is injected during one of the read/write SRAM requests. The test checks, whether the expected alert fires. Closes lowRISC#23322. Signed-off-by: Pascal Nasahl <[email protected]>
This commit provides a new sec_cm_readback test that tests the SRAM readback FI countermeasure. In the test, a fault is injected during one of the read/write SRAM requests. The test checks, whether the expected alert fires. Closes lowRISC#23322. Signed-off-by: Pascal Nasahl <[email protected]>
This commit provides a new sec_cm_readback test that tests the SRAM readback FI countermeasure. In the test, a fault is injected during one of the read/write SRAM requests. The test checks, whether the expected alert fires. Closes lowRISC#23322. Signed-off-by: Pascal Nasahl <[email protected]>
This commit provides a new sec_cm_readback test that tests the SRAM readback FI countermeasure. In the test, a fault is injected during one of the read/write SRAM requests. The test checks, whether the expected alert fires. Closes #23322. Signed-off-by: Pascal Nasahl <[email protected]>
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.
The text was updated successfully, but these errors were encountered: