Dual-port BlockRAM "write first" puzzler...

The setup: Virtex ( >= 2 ) Dual-port BlockRAM configured with both ports in "Write first" mode. Both ports have the same (global) clock and the same address, with Enable tied high, so they are both always reading.

Part 1: Cycle 0- (init value) WE to port A, with DI = 0. Cycle 1- (change value) WE to port A, with DI = 1. Cycle 2- (cycle 1 results) Output A is 1 because it is in write first mode and 1 was written in cycle 1. What is value at output B during cycle 2? a) 0 because port B is not being written to, and reflects the value it would have read if there was no activity on port A. b) 1 because port A is in write first mode, and the activity on port A interferes with port B. c) x Don't do this, the result is indeterminate.

Part 2: same as part 1, with A and B switched Cycle 0- (init value) WE to port B, with DI = 0. Cycle 1- (change value) WE to port B, with DI = 1. Cycle 2- Value at output B is 1 because it is in write first mode and 1 was written in cycle 1. What is the value at output A during cycle 2? a) 0 ... b) 1 ... c) x ... I said don't do this!!!

I'm hoping the answer to both Part 1 and Part 2 is a), because it simplifies a 2-D 5x5 Gaussian filter I'm putting together (eliminates muxes and registers external to the RAM, and this is going into an already very tight design).

Peter tells me c) for both (I think).

Meanwhile, XST user guide gives DPRAM inferring VHDL which sims a result of b) for Part 1, and a result of a) for Part 2.

My first instinct is to trust Peter, but the fact that the XST user guide gives deterministic code gives me pause.

So I put it to the group, hoping someone has actually used this setup and has some definite answer. I'm a day away from coding up a test circuit to find out what the silicon really does, but if anyone knows of anyplace where operation in this scenario might be documented, it would save me a few hours. Thanks all, Just John

Reply to
JustJohn
Loading thread data ...

John, as I e-mailed you privately, the Virtex-5 user guide tells you clearly "don't do that". And that same reasoning also applies to the older parts. The two write mechanisms in the two port controllers may be very similar, but they are separate entities, and they may disagree in the timing, pehaps only by picoseconds, but that's enough. In order to do what you want to do, you have to stagger the clocks. BTW: This problem only occurs when both ports use the same address, and one of them writes. Will the other port red the old or the new data? I am convinced that this is really undefined. You may be lucky and it works your way, but I would not bet on it. Peter Alfke

Reply to
Peter Alfke

Sorry for my mis-understanding Peter, You said look at the V5 docs, and I didn't. I'll take more time before going to the group next time.

Not possible in this case, the operation has to be symmetric on both ports.

Yes sir, got that. It turns out that I can re-arrange access ordering to keep the addresses different, operate both ports in read first mode, use the En pins instead of tying them high, still avoid the external muxes/registers, keep the same latency/throughput, and the only overhead is the logic to drive the En pin ( Will the other port red the old or the new data? I am convinced that

What threw me was that the XST DPRAM inference code simulated predictably, in a manner that was inconsistent with the actual circuitry. The whole point of synthesis from simulated code is that the results match. This is one of those cases where they don't. Rare, but it happens.

Thanks again for your time, and for bumping me back onto the right path.

John L. Smith

Reply to
JustJohn

Hello,

I always thought that the BRAM write-first mode was implemented as a bypass of the data store local to the bram port, and that the writes to the underlying data store were always synchronous on both ports, thus leading to a sure A result on both of these questions...

Probably because this is the simplest modelling of the BRAM behaviour with synchronous logic, but I guess things are a bit more complicated in the real world...

JB

Reply to
jbnote

I wrote a very detailed description of how the various modes of writing and reading of the block RAMs occurs with details of the way activity on one port affects the other port depending on the write mode. You can find it here:

formatting link

I hope this helps you.

=================== Philip Freidin snipped-for-privacy@fpga-faq.org Host for

formatting link

Reply to
Philip Freidin

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.