[RTL] Pinmux jtag muxing

[gautschimi]

The jtag tck and trst were muxed with a combinatorial process. This can potentially lead to glitches on the clock lines and lead to failures during jtag transactions. e.g. mess up the jtag statemachine. This could be an explanation for some of the CI failures we see (e.g. the errors described in this issue #29555). We need to observe CI a bit to see if it really helps.

The fix is:

• only mux tms and tdi (data signals) in the combinatorial process
• Add a single bit Flop for each muxed jtag (rv, lc, dft) to disable the clock and reset with an AND gate

This fix is similar to the fix that has been done for the bkdr loader (f5668d8)

Security:

• TCK, and TRSTN are now gated with a single bit register which makes it easier to for fault injection to reenable the jtag clock. But TMS, TDI, TDO are still gated or muxed the same way. Hence, I think the level of security is the same.

[gautschimi]

see #29555

[glaserf]

Thanks for this PR, this could indeed be a smoking gun, very nice catch! I'll yet have to review the changes in detail, but one comment in regards to LINT: The earlgrey chiplevel check fails with

E   CLOCK_DRIVER:   pinmux_jtag_buf.sv:18       'tck_gated' is driven by instance 'u_prim_and2_tck' of module 'prim_and2', and used as a clock 'tck_i' at dmi_jtag_tap.sv:104

Even though you added a waiver to pinmux (which acts on this message but a different signal/net). This therefore either needs to be adapted or extended.

[vogelpi]

Thanks @gautschimi , this looks good to me.

We should also also discuss this with partners before merging. About the security aspect: if really needed, we could also add a consistency check for the 3 added flops to only allow for a mismatch during one clock cycle and wire that up with the fatal alert of pinmux.

[gautschimi]

ok all tests have passed with this bitstream. not so bad.

Locally I still see flaky tests with sram execution. but I think that is another problem