Question summary: Can I successfully share a Xilinx dual-port BRAM between two PowerPC data-OCM's where it is possible to write and read the same location at the same time without corrupting the data? (by different processors from different ports of the BRAM) I don't care if the read returns the old data or the new data from the write, but I want the read results to be deterministic and repeatable without corrupting the write.
The (lengthy) details:
I have an XC2VP30 FPGA with two PPC 405 processors. In an EDK project, I am trying to use the data-side OCM port on each processor to connect to a dual-port BRAM. This BRAM will be used as a common scratchpad that is accessible from both processors.
The problem I experience is best demonstrated in a simple producer/consumer software program. PowerPC #1 is the producer and writes each BRAM location with 1 of 13 pre-determined 32-bit values. It runs in a tight loop and repeatedly fills the memory.
PowerPC #2 is the consumer and repeatedly reads each BRAM location in a tight loop. If the value it reads is not one of the 13 pre-determined values that could be written, an error has occurred.**Because each processor loops forever and runs different code of different lengths, it is possible for PowerPC #1 to be writing the same address at the same time that PowerPC #2 is attempting to read it from the opposite memory port.**
The BRAM is 8kB in size. Out of 1 million BRAM reads, approximately 10-20 have invalid results that should not appear anywhere in memory. These errors are randomly distributed through the entire test length and do not cluster at the beginning or end. Immediately re-reading that error location a second time will typically read a correct value, but not always. (Sometimes we can read for a hundred times without getting a legit value, at least until PPC #1 loops around and re-writes that location again). I interpret this to mean that *most* of the time, just the read is corrupted, but that*sometimes* the write itself failed to fully update the memory.
In the VII-Pro Users Guide, I see there are specifications regarding writing and reading to the same address in a dual-port BRAM at the same time. Our PowerPCs (300 MHz) and data-OCM interfaces (100MHz) are all rising-edge aligned and would seem to be vulnerable to this situation.
I tried changing the BRAM write mode from "WRITE_FIRST" to "READ_FIRST" via a UCF constraint in hopes of getting legitimate reads out of the second port. The error behavior improved slightly but was still present. I verified that the constraint was successfully applied in the FPGA Editor.
I also tried running both OCM ports (or both Power PC's) on inverted clocks so they were out of phase. Unfortunately, we want both processors to share the same PLB bus, so this technique is also not possible.** In the error tests, both the instruction and data caches are on in both processors and are set to only cache the PLB-based BRAM, not the scratchpad in question. However, if I turn the data cache completely *OFF* for both processors (but leave the I-cache on), then no errors are reported. We can run the test for hours. Too bad we need that cache for a real system, although there's not really much data to cache in the test program. We have played for hours with different PPC instructions to make the memory guarded, enforce in-order execution, flush the cache (even though the OCM is supposedly not cached), and have had zero luck. **
In the FPGA editor, the scratchpad BRAM blocks (4 of them) are perfectly placed in between the two processors, not shoved to a far-off corner of the chip or anything like that.
I guess my question is: Has anyone ever successfully shared a BRAM between two PowerPC data-OCM's where it is possible to write and read the same location at the same time? I would be perfectly happy if the read produced the old value at that location and not the new value. (Which is what I thought changing the write mode to READ_FIRST would produce).