[lc_ctrl] Study prod netlist when SecVolatileRawUnlockEn set to 0 to verify logic is removed

[msfschaffner]

Description

• [x] Make sure PROD chips disable SecVolatileRawUnlockEn (introduced as part of https://github.com/lowRISC/opentitan/issues/18246). this is addressed for top_earlgrey in #21320
• [x] add a negative test to block and chip-level #21320
• [x] update block-level DV environment to test both variants with volatile unlock and without #21320
• [x] examine the synthesized netlist to make sure the mechanism is compiled out.

[msfschaffner]

@andreaskurth @vogelpi FYI this will be important for PROD. We need to make sure the volatile unlock feature is removed.

[vogelpi]

I am now in contact with the PD team regarding this issue. I think it should be sufficient to check if the volatile_raw_unlock_success_q registers inside lc_ctrl_fsm.sv are there in the netlist or optimzied away.

[vogelpi]

I got feedback from @meisnere who checked the netlist and confirmed that:

• The string volatile_raw_unlock_success cannot be found in the netlist anymore, meaning there are also no FFs related to the volatile_raw_unlock_success_q signal.
• The volatile_raw_unlock_i input port of lc_ctrl_state_transition_0_0 (properly parameterized) is tied to constant 0.

This makes me feel reasonably confident that things are as they should be. I am ticking off the corresponding box above. The question is now whether we need to re-check this after RTL freeze?

[andreaskurth]

Thanks for checking this in the current netlist. To ensure that this keeps holding for the tapeout, I suggest we add this to the post-synthesis stage of the tapeout checklist.

[vogelpi]

This sounds good to me. We've taken a note to add this to the tapeout checklist and I am now closing the issue.

[msfschaffner]

Note that there is a TLT that checks whether this is behaving correctly (e.g. check that volatile unlock does not work). You could tell NT to run that on a GLS to be absolutely sure.