infering a BRAM block for a dual ported ROM

Howdy Abhishek,

You've asked an age-old question. The short answer is maybe, depending on the synthesis tool and if you can find the magic word. You'll notice from the numerous previous discussions that it is not exactly clear-cut on how to do it:

In general, the answer seems to be that doing anything more than one read and one write on a single BRAM can't be inferred reliably, although Synplify's latest literature seems to imply they can handle a bit more than that:

By searching the web or Xilinx's site, we find that Xilinx documents a recommended way to code up a dual-port RAM with independent read clocks for XST:

or

If you scroll down a little, you'll find ways to initialize the BRAM. I see that it says you can't infer the initialization in XST when using Verilog for some reason - you'll have to do so using the INIT_xx property in the .ucf file (or some other way). Hmmm... except that the constraints guide for INIT_xx does point out a way to initialize a BRAM in Verilog, so maybe it is just XST that can't:

or

As you can see, there isn't just one place to go to find the answer. The chances that these structures are portable across synthesis tools (much less device vendors) seems exceedingly low.

Good luck,

Marc

True. The advantage of using separate read and write ports is that you don't have to think about handling the case of simultaneous writes to the same address.

The reason synthesis punts on dual write ports is that the template model would have to exactly describe the BRAM arbitration scheme as well as the RAM array. Otherwise sim would not match synthesis in all cases.

The OP actually wants a ROM with two read ports. The choices are:

1. Instance the vendor dpram and tie off the write controls.
2. Infer two roms from the vendor template using a constant vector array. If you have BRAM to spare, this is the easy way out.

-- Mike Treseler

Thanks, Marc and Mike, for your responses.

Marc, practially all of those links you listed (some i had not found on my own, thanks again), talk about RAM, and write coherency etc. As i only need a ROM, these are non-issues for me.

Mike, your option "2" is what I am doing right now, and I do have BRAMs to spare so this is sufficient for now, as i am using the larger FPGA for prototyping, but the rest of my design is so small that just cause of the BRAM problem I will have to keep using this much more expensive FPGA. If i can use a dual proted BRAM, then i can use the smaller cheaper one.

I guess I can just go ahead and instantiate the BRAM blocks manually to solve that problem.

is there is no portable way to infer a dual ported ROM. Is this true for VHDL as well?

I was hoping that some newsgroup members who work at one of the synthesis tool-vendors would have some suggestions?

-Abhishek

Howdy Abhishek,

I was only attempting to find examples of inferred memories with two read ports. Just drop the write portion of the code, find a way to INIT_ the BRAM, and you *might* have an inferred dual-port ROM. Unless your syn tools decides you really wanted two single port ROM's ;-).

Depends on how you define portable, but in most senses of the word, probably not.

Indeed. Hopefully Ken McElvain will see this and add his Synplify take on it.

Marc