[spi_device] SPI Device SRAM does not support byte-writes or read access

[amit-kumarh]

Description

Non-word writes to the SPI Device SRAM cause a store fault. We can write unaligned data by manually masking the bits, but in the a0 revision, there doesn't appear to be read access to the egress buffer, so this would require maintaining a shadow copy of the SRAM. See the Rust code below for an example to reproduce.

const SPI_DEVICE_BASE_ADDR: usize = 0x40050000;
const MAILBOX_RAW_ADDRESS: usize = SPI_DEVICE_BASE_ADDR + 0x1000 + 0x800;
const MAILBOX_SIZE: usize = 1024;

fn reset_mailbox(&self) {
        // SAFETY: reference to mailbox destroyed on function end
        unsafe { slice::from_raw_parts_mut(MAILBOX_RAW_ADDRESS as *mut _, MAILBOX_SIZE) }.fill(0);
        fence();
}

[a-will]

This was an oversight, and it actually isn't a limitation of the SRAM itself. Instead, the TL-UL frontend is forbidding sub-word writes due to...

https://github.com/lowRISC/opentitan/blob/bff93a06f5e569270c56ec08db723722de9da805/hw/ip/spi_device/data/spi_device.hjson#L1560

There is some downstream logic to check for issues, though, and this miss was deemed acceptable for A0 (not qualifying for ECO).

Write-only access is intentional, however, for compatibility with different tech libraries. True dual-port SRAMs aren't always supported, and the emulations often don't work well for modules with complex timing / CDC like this one.