infering a BRAM block for a dual ported ROM

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hi,

I have been trying to implementa a 256-deep, 8-bit wide ROM as a BRAM
in Xilinx Virtex 4 and Spartan 3(ISE7.1sp2). Prefering to have it
inferred instead of instantiating a macro, i wrote it out as a case
statement in verilog. ISE correctly infers a block RAM for it.

My problem is i want to do two simultaneous reads from the same ROM
(the reads are done on independent clocks). If i implement this as two
seperate case statements, even with the exact same data, ISE infers two
blockRAMs for them, leaving the second port of each unused.

always @ (posedge clk0)
begin
   case(addr0)
       8'h00: data0 = 8'h12;
       ....................
       8'hff: data0 = 8'h34;
   endcase
end

always @ (posedge clk1)
begin
   case(addr1)
       8'h00: data1 = 8'h12;
       ....................
       8'hff: data1 = 8'h34;
       //(exact same data as above)
   endcase
end


Is there a way i can write my verilog so that ISE can infer that i am
reading the same ROM, and infer a single, dual-ported RAM block?

I know i can work around it by instantiating a dualport BRAM, i was
just wondering if there was a way to have ISE infer it.



Any suggestions appreciated.

Thanks in Advance,

Abhishek


Re: infering a BRAM block for a dual ported ROM
Quoted text here. Click to load it

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:

http://groups.google.com/groups?q=infer+dual+port

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:

http://www.synplicity.com/literature/pdf/inferring_blockRAMs.pdf

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:

http://toolbox.xilinx.com/docsan/xilinx7/books/data/docs/xst/xst0027_5.html#wp422120

or http://tinyurl.com/dk55f

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:

http://toolbox.xilinx.com/docsan/xilinx7/books/data/docs/cgd/cgd0103_64.html#wp240143

or http://tinyurl.com/c9cru

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


Re: infering a BRAM block for a dual ported ROM

Quoted text here. Click to load it

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

Re: infering a BRAM block for a dual ported ROM

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.

Quoted text here. Click to load it
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


Re: infering a BRAM block for a dual ported ROM

Quoted text here. Click to load it

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 ;-).

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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

   Marc


Site Timeline