SECDED errors from the SRAM can not be signalled for ReadModifyWrite operations.

Nobody has claimed this yet.

As stated in [sonata-system/vendor/lowrisc_ip/ip/tlul/rtl/tlul_adapter_sram.sv](https://github.com/lowRISC/sonata-system/tree/main/vendor/lowrisc_ip/ip/tlul/rtl/tlul_adapter_sram.sv) the SRAM adapter does not wait for a response from the SRAM before sending able the d_valid for write operations, see lines 474-477:
```
// interleaved. So, to make it in-order (even TL-UL allows out-of-order
// responses), storing the request is necessary. And if the read entry
// is write op, it is safe to return the response right away. If it is
// read reqeust, then D response is waiting until read data arrives.
```
But for SRAM's with RMW, required for byte writing to a ECC protected SRAM for instance, the SRAM can signal a Double-Error-Dectect error on a write operation.

The current implementation, does not wait for the SRAM to return **rvalid_i/rerror_i** on write operations before sending the d_valid on the TL interface, so any SECDED error on a RMW operation will be lost.

My suggestion is to require **rvalid_i** assertion before sending **d_valid** on write operations.

Start in vendor/lowrisc_ip/ip/tlul/rtl/tlul_adapter_sram.sv around lines 474-477 and trace how write operations handle rvalid_i/rerror_i before asserting TL d_valid. Compare the documented behavior with the ReadModifyWrite case and determine how SECDED errors are propagated. Done means write responses do not lose SRAM errors and the TL interface reports them correctly.

Written by the indexing model from the issue text.