Dual port RAM synchronisation

[Altera_Forum]

Sorry if this post is in the wrong group. 

 We have a system where a NIOS application communicates with a PC-104 style board via dual port RAM.  Some of our tests indicate that if the NIOS is writing to the ram at exactly the same time the PC-104 reads the same location, we sometimes get 'partial reads'.   For example, if the NIOS writes 0x81 to RAM, it is possible the PC will read 0x80, then a few cycles later, will read 0x81.  Our hardware guys (who designed the boards) say this is possible, but make out it's a software problem because we shouldn't be reading/writing to the same locations at the same time!  Firstly, can anyone give any more insight to the problem (is there really no synchronisation on dual port ram), and perhaps some pointers as to how to solve it?

[Altera_Forum]

Well, its both of your problems. The rams have no synchronisation in them, it is up to you (well, probably the guys who wrote the firmware) to come up with a method of synchronisation. This would usually take the form of an interrupt. An easy way is to set a couple of memory locations to be the interrup drivers, so both ends can interrupt each other - and then you only perform a read when you've been interrupted. This helps stop you reading the ram so much, as you should only read it when there is something new to read.

[Altera_Forum]

I assume that because its a PC104 system, the dual port ram is connected to PCI?

[Altera_Forum]

--- Quote Start ---  I assume that because its a PC104 system, the dual port ram is connected to PCI?  --- Quote End ---    Correct. Is it (I believe) a non-bus master PLX chip.

[Altera_Forum]

--- Quote Start ---  Correct. Is it (I believe) a non-bus master PLX chip.  --- Quote End ---  Then you are in luck.  The PLX chips normally have doorbell registers/interrupts for implemented an interlocked protocol. See page 7:  http://www.ovro.caltech.edu/~dwh/correlator/pdf/cobra_driver.pdf (http://www.ovro.caltech.edu/%7edwh/correlator/pdf/cobra_driver.pdf)  That interlock acts as a mutex for access to the shared resource.  The key to understanding how this sort of protocol works, is to think of the protocol handshake in terms of transmitter-empty and receiver-ready interrupts.  The "character" being protected by this protocol can be multiple characters. In this example, the character is stored in a mailbox in the PLX chip. In the real driver, multiple mutexes are used, and protect different regions in shared SDRAM.  Cheers, Dave