[sram_ctrl] Consider refactoring tlul_adapter_sram

[msfschaffner]

This module has grown quite a bit over time and seems a bit difficult to read and debug by now.
Also, the byte write logic inside tlul_sram_byte needs additional request FIFOs which could potentially be consolidated with the rest of the tlul_adapter_sram FIFOs if we were to refactor this module.

In addition to the above, also consider creating different wrapper versions of the module to simplify the parameter usage.
Currently there are too many parameters controlling whether integrity is checked, generated or passed through. This makes usage of tlul_adapter_sram error prone, as was observed in #9406

[tjaychen]

i actually specifically chose to separate those instead of combining them.
If we need to insert stalls in the adapter sram protocol, it actually creates a lot of complexity on the existing logic handling.

it seems cleaner to separate them by function.

[msfschaffner]

ok, I see. the reason why I brought up the consolidation above is that I had to add another FIFO to keep the a_size inside tlul_sram_byte in #7218, which makes it somewhat redundant with the request FIFO in tlul_adapter_sram (this was needed to return the correct a_size in case of byte writes, since the tl_sram_i write response is currently always indicating full word writes due to the read modify write operation). I was therefore thinking that maybe we can move the gasket to the SRAM side such that this additional req FIFO is not necessary anymore.

this is not critical however, and more meant as a cleanup task if we have time.

[tjaychen]

yeah let's think about it... so originally i split it out because the FIFO's inside tlul_adapter_sram deposited an entry once it was accepted by sram. The problem with the sram read modified write is that I need to accept the entry, but also change the back pressuring scheme such that it will deposit the entry even if sram side had not accepted the transaction (because we're are still in the middle of writing the last one).

Thinking about it more, it probably does make sense to see how we can merge this better. I think mainly the tlul->sram handling will need to be tweaked a bit to de-couple acceptance of sram transaction and tlul transaction.

[andreaskurth]

Triaged for sram_ctrl, keeping Type:FutureRelease Not relevant to currently planned releases/milestones as potential RTL refactoring in a future release.