Hi all. Did anyone use some OpenRAM macros in MPW-6 and had their design working correctly? It looks like in the temporal logic monitor design (https://github.com/progirep/temporal_runtime_monitor_for_caravel/) that uses two OpenRAM macros, writing to the OpenRAMs doesn't work correctly. All of the ICs that I got back and tried so far had different memory cells that were able to retain their data and it looks like some cells have their content coupled on some ICs, but not on others, so I'm not sure if it could be the writing logic that is incorrect. Once the SRAM content stabilizes, the MPW-6 implementation appears to work correctly...on what is stored in the SRAMs then.

@Ruediger Ehlers maybe this is a good question for #openram.

We just got our MPW6 delievered today

Just FYI, I tested my RISC-V SoC on MPW-8 (https://github.com/mole99/leosoc-sky130), which has several of the 2kbyte SRAM macros, and it works up to 20 MHz (hardened for 40MHz, but maybe I did something wrong) and fails after that. I tried to set a higher core voltage (1.9V) but that didn't seem to make a difference in my case. Unfortunately, I can't really test the SRAM in isolation, so it may well be something else. I just wanted to add this as a data point. Thanks for your work on OpenRAM by the way 🙌️

Hi Matthew. Thanks for your answer first of all. Generation of the control signals is in a big if block because the component has two modes: it either accepts write-through and read requests from the Wishbone bus or the module is in computing mode, in which the SRAMs are actually used for something productive, and the component does not access bus accesses. Within each mode, there is also a case split on what is currently happening. Depending on the mode, addrA0 and other signals are driven differently. While it's quite difficult to tell, I believe that the address signal is not the problem and capturing the output of the SRAM is also not the problem. The reason for saying this is that I build a test program running on a caravel that accepts read and write accesses via UART, and on the host PC I built a small hex editor program accessing the UART port. The design has two SRAMs (1kb and 2kb, both with 32-bit wide data busses), and both are mapped into the address space by the design (when the core functionality of the design idles). When reading from the SRAM with this test program setup, the data read stays consistent between complete reads of the memories if not writing to the memory (screenshot 1 shows how the memory content could look after booting up the system without a write - the data will stay the same after refreshing the view with the memory content). However, if I write to the memories, then some bits flip early and I've also observed that some bits only flip after a few seconds (so that the flip only becomes visible after a few successive total read-outs of the memory). The problem occurs on both the 1kb and 2kb SRAMs. The different ICs that I got shipped seem to behave differently regarding which bits flip.

I have a 1kb openram on mpw6 and tested it successfully