Interesting... We did all testing at 1.8. Perhaps there's a hold issue. It has a fairly large hold time so depending on the clock usage...

There are plenty of ways to pinpoint the issue. My script depended on a subroutine call that was nested in another subroutine call. Both calls had one 32-bit argument and a 32-bit return value. The outermost subroutine call always works; the innermost subroutine always fails with the argument being set to (or interpreted as) zero. I have not looked closely at the compiled code, but my best guess is that there is some address at which the failure occurs, probably at the boundary of an address bit. My test wasn't looking for this error, but there are plenty of ways to write a different test that can distinguish between a read and a write, or between address and data. Also, there is unique decode circuitry in the SoC handling the SRAM vs. the DFFRAM, so I cannot say for certain that the error is in the SRAM as opposed to any of the logic in the SoC unique to the SRAM access.

Let me know if the is something I can help with..

@Tim Edwards My expectation is failure mostly in SRAM write access as SRAM write phase uses positive edge of the clock to capture the data, Where are Read path uses negative edge to launch the data.

This is roughly accurate. The first half of the clock is precharge while the second half is write/read. The data/address is captured on input registers on the positive edge

@Matthew Guthaus Typical industry standard SRAM gives additional control port to adjust the write and read path delay. We need similar option in OpenRAM also.

@Dinesh A I've never seen this, can you elaborate?

If you see ARM Memory, They have additional compiler option to add "Extra Margin Adjustment: On/Off" and It added three bit port EMA* to adjust the Write and Read path delay. Similar control are available in Synposys artisan and Intel memory.