Continue to Site

Welcome to

Welcome to our site! is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

[moved] read and write the same address in SRAM

Not open for further replies.


Member level 5
Oct 19, 2013
Reaction score
Trophy points
Activity points

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?

Last edited:

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.

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.

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.

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.

Not open for further replies.

Part and Inventory Search

Welcome to