[rv_core_ibex,RAM] Setup violation from the RAMs

[meisnere]

Description

Opening an issue with the email content.

"
The issue here seems to be that the address from the instruction side port on Ibex somehow factors into the grant signal going back to the data side port on Ibex via the xbar and sram_ctrl.
I suspect this is something to fix in the xbar or maybe the sram_ctrl. The grant is telling the data side whether or not its request is accepted and whilst it's reasonable for this to factor in other requests (i.e. from the instruction side port) it'd be preferable if it didn't factor in the address.
I think I can understand why, if the instruction side is fetching from SRAM and the data side is reading from something else (e.g. a device) they could both proceed. However as we're also aiming for single cycle response this gives us the huge paths we're seeing in this report.

A few possibilities here, one would be not factor the address in at all to the grant (so the xbar would disallow two simultaneous requests even if they could physically both be dealt with together). Another would be to use some static priority scheme that understands the instruction port can only access parts of the system. So data port can only get a grant if the instruction port is also requesting access at the same time if the data side isn't going to sram or flash or ROM.
Another would be to add a register stage to the instruction side request. The single cycle access time is critical for performance on the data side only as there's no cache where we do have an icache on the instruction side.

We may also be able to get the instruction address and request out earlier from Ibex. We'd still have this big long path but chopped down just enough to meet timing!

Really we should look at both, as the Ibex only fix will be a good improvement to Ibex and it'd be good to reduce the feedthroughs our xbar introduces.
"

@GregAC @arnonsha

[msfschaffner]

This setup violation may be partially addressed by removal of the diffusion layer in the SRAM scrambling devices (#20855).
We should wait for another PD run before optimizing things in this area since any change will likely be architectural and have performance impact.

[msfschaffner]

Triaging this into M4.
We addressed this partially by removing the S&P layer in the SRAM scrambling circuits and are now waiting for new synthesis results, which we likely won't get before M2.

[andreaskurth]

@GregAC: To check if this is covered in #22462. If it is, this can be closed.

[GregAC]

I've reviewed the original timing reports and yes this is covered by #22462