[sram_ctrl,dv] Add sec_cm_mem_readback test #24699
Conversation
nasahlpa
force-pushed
the
sram_readback_verify
branch
3 times, most recently
from
dfa746b
to
ecbfec0
Compare
| addr_faulty = {addr[TL_AW-1:2], ~addr[1], addr[0]}; | ||
| `DV_CHECK(uvm_hdl_force(fi_path, addr_faulty)) | ||
| // Release the faulty signal after one clock cycle. | ||
| cfg.clk_rst_vif.wait_clks(1); |
There was a problem hiding this comment.
This should be cfg.clk_rst_vif.wait_n_clks(1);
In most cases, we force and release on the negative edge to not interfere with the DUT. The DUT evaluates the signals after the posedge.
| // TODO: add list of signals instead of using a single signal. Currently only | ||
| // the read or write address is faulted. |
There was a problem hiding this comment.
I think we should actually do this now as we're targeting V3 with this. But it doesn't need to be exhaustive of course. A couple of interesting signals are sufficient. The address is certainly one. Maybe also the write enable and the data?
I think we should also explain here that the list isn't exhaustive and that it doesn't need to be.
nasahlpa
force-pushed
the
sram_readback_verify
branch
from
ecbfec0
to
cc0cece
Compare
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]>
nasahlpa
force-pushed
the
sram_readback_verify
branch
from
cc0cece
to
8c05c3c
Compare
|
Thanks for your review @vogelpi and the offline discussion regarding |
vogelpi
added
the
ManuallyCherryPick:earlgrey_1.0.0
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.