[rtl] Split data and ECC of the register file

[nasahlpa]

Until now, a single instance of the register file containing 32-bit data words and 7-bit ECC tags was used. While the input of the register file was driven by the main core, the output of the register file was distributed to the main and the shadow core.

In this PR, we are splitting up the data and ECC parts into two different register file instances:

1. This instance is driven by the main core and only operates on the 32-bit data words. The outputs (32-bit data words) are forwarded to the main and the shadow core.
2. This instance is driven by the shadow core and only operates on the 7-bit ECC words. The 7-bit ECC output is combined with the delayed 32-bit data output of the (1) RF instance. The shadow core uses ECC checkers to check if data and ECC (a) match and (b) are not manipulated using FI.

This helps us to save around 6 kGE of area.

[rswarbrick]

If I understand correctly, I've looked at some of this change already (where it looked good to me). The only differences since what I've already seen seem to be

• Removal of the dependencies on prim_onehot* in ibex_dv.f and syn_yosys.sh
• Removal of the mention of prim_onehot_check in integration.rst
• Removal of the code that disables some assertions that have been removed
• Removal of fcov that tracks rf_alert_major_internal (which has been removed)

That looks really sensible to me, but doesn't this leave dut.u_ibex_top.u_ibex_core.u_fcov_bind.rf_we_glitch_err undriven? I think it probably needs removing from the functional coverage interface and the coverage plan too?

[nasahlpa]

Thanks for the review, Rupert!

• I've removed dut.u_ibex_top.u_ibex_core.u_fcov_bind.rf_we_glitch_err
• Instead, I have added dut.u_ibex_top.u_ibex_core.u_fcov_bind.rf_glitch_err
• In that context, I have noticed that two RF glitch tests no longer worked - I have updated them in the last two commits

[vogelpi]

Thanks @nasahlpa , I've reviewed the RTL and it's identical to what I've reviewed before, LGTM!

[vogelpi]

I think this PR is good to go in. But maybe @rswarbrick wants to take another look? @nasahlpa can you confirm that you addressed all points raised by @rswarbrick in this comment #2364 (comment) please?

[nasahlpa]

Thanks for the review, Rupert!

• I've removed dut.u_ibex_top.u_ibex_core.u_fcov_bind.rf_we_glitch_err
• Instead, I have added dut.u_ibex_top.u_ibex_core.u_fcov_bind.rf_glitch_err
• In that context, I have noticed that two RF glitch tests no longer worked - I have updated them in the last two commits

Yes, I have addressed the comments as mentioned here.

[rswarbrick]

Looks good to me. Thanks, @nasahlpa, for replying to my questions (and sorry for not acking!)