[moved] read and write the same address in SRAM

[zhangljz]

Hi,

I have a design that will use a dual-port SRAM that allows me to read and write simultaneously. But during the running, it may read and write the same address at the same time.
For me, as long as the read and write data are not crap, it doesn't matter if it is the old or new one. Will the crap occurs in the conflict ?

I don't have the database from the foundry until now, but I have to write the code to use this SRAM.

DO I need to avoid this conflict, or not?


Thanks

 

[erikl]

There are different types of dual-port SRAMs (DPS), those with internal logic to avoid simultaneous read & write at the same address, and those where this is achieved by a µP via semaphores. Some types of DPSs (e.g. non-volatile SRAMs) first delete the address content before they write the new word. In such case - if no prevention is provided against simultaneous read & write at the same address - one could run the risk of reading false data.

If the foundry doc doesn't provide the corresponding info, you would have to ask them.

 

[zhangljz]

Hi, Erikl,

If DPS has no such prevention mechanism, is it common to write code by ourselves to detect the conflict and stop the write operation, only allow the read, because the write can be controlled by 'write_en' signal, while read doesn't have this kind of control.

 

[erikl]

Sure, this is a possible and good method, if you don't mind the write latency. But before I'd try to get the info from the foundry - or try it myself by simultaneous read & write at the same address.

 

[Warpspeed]

The more usual way to overcome this is by introducing wait states into software as already suggested.

Another way might be to latch one or both data streams, delaying it for a very short period by using a different clocking phase.
If you are sneaky, it may be possible to avoid asynchronous timing conflicts that way with hardware.
You can then interleave your asynchronous reads and writes so they cannot clash.