Asynchronous BRAM input ?

Let me just explain what you functionally can do in a BRAM:

Read synchronously: all inputs (address and control) must be stable before the clock edge, data output appears after the clock edge. Write synchronously: all inputs (address, data, and control) must be stable before the clock edge. Even though you are writing, you are also reading. The data output appears after the clock edge: As a config. option that data output is either the "old" data at the addressed location, or it is the "new" data that you are just writing. (Read-before-write or write-before-read). You can also leave the outputs unaffected by the write operation.

I think the first option, read-before write, is the most interesting one. It lets you build shift registers in BRAMs, something that Altera touts as an important feature. Xilinx has had it for many years...

Obviously, you cannot do a read-modify-write on the same clock edge. Every operation is synchronous.

The two ports have independent clocks, addresses, data and controls, they only share the common data storage array.

Now you can figure out whether your design is inherently possible. Peter Alfke, Xilinx Applications ===================

...

Is "clock" connected to "clk" somewhere? You can't read-modify-write, but it should still map and not work correctly.

Alan Nishioka

Hi Thankyou Alfke and Nishioka for comments.... I found the mapping error is not comming from "BRAM" but something else trivial. Mapping error problem is now solved.

"Read - Modify - Write" can not be done in one cycle for single port memory. But, in dual port, it is possible to "Load from port A - Data processing - Store to port B" in one cycle, as far as different address is accesed by port A and B. (Hopefully) it is correct.

I do not think so. You said " in one clock cycle". You cannot read something on one c*ck edge, process the result, and write it back on the same clock edge. You have to use the next clock edge to write it back, but you can offset the other port address, so that you write the result back into the original location. That may be what you are thinking, and it effectively performs read-modify-write on every clock cycle. It's really a form of pipelining. Peter Alfke, Xilinx Applications.

Yes exactly. My goal is to have array C={1,2,3,4,5,6,7,8,9,10}, given two arrays X={1,3,5,7,9} and Y={2,4,6,8,10} in less than 15 cycles. I tried to do that in pipelined way (with single cycle throughput per element). I managed "address" asynchronously and could have 12 cycles in behaviral simulation. But implemented design is quite unstable. At this moment, what I could do was 22 cycles (with 2 cycles throughput per element). Anyway my wish is to have

cycle 1 : load x=1 cycle 2 : load y=2 cycle 3 : compare, store x=1, load x=3 cycle 4 : compare, store y=2, load y=4 cycle 5 : compare, store x=3, load x=5 cycle 6 : compare, store y=4, load y=6 cycle 7 : compare, store x=5, load x=7 cycle 8 : compare, store y=6, load y=8 cycle 9 : compare, store x=7, load x=9 cycle 10 : compare, store y=8, load y=10 cycle 11 : compare, store x=9 cycle 12 : compare, store y=10

I concluded (at this moment) that this is not possible :) Thankyou anyway.