Xilinx ISE Synthesize of ROM

[peter.kampmann]

Hi,

I have to store a large amount of coefficients in my FPGA for
multiplication:

type coefficient is array(12 downto 0) of signed(17 downto 0);

type coefficients is array(179 downto 0) of coefficient;

constant coefficientsArray : coefficients :=
(("100000000001010010","100000000101001110","000001100101010110",
"000011011101000011","110000011110011010","110001111011011000",
"010110100011101111","001011110111000110","100100000010011111",
"100001000001001001","000000000101111111","000000000000101110",
"100000000000000001"), .... );

So I expect this to be synthesizes into 180 ROMs consisting of 13
17-Bit values.
I assumed that I can store these values in my Virtex 2 Pro XC30 using
the 2,048 kb of Block RAM.

Unfortunately, this design together with the multiplication part needs
153% of the fpga space.
For testing puposes I reduced the coefficientsArray to 6 and get a
synthesis result of about 54% of the fpga.
Using the option in Synthesize->XST in Xilinx ISE for ROM Style = Block
gives no improvement.

So here are my questions
Is it possible to get the design I expect? Meaning 180 ROMS in Block
RAM? Each clock cycle, I need 169 of these values. Or this task not
possible for this fpga?
Until now I hope Xilinx ISE infers these ROMS into Block ROM, but I do
not know if this is the case, the synthesis report mentions the
instantiation of ROMs as follows:

Found 256x6-bit ROM for signal <$rom0001>.
Found 256x6-bit ROM for signal <$rom0002>.
Found 256x6-bit ROM for signal <$rom0003>.
Found 256x6-bit ROM for signal <$rom0004>.
Found 256x12-bit ROM for signal <$rom0005>.
Found 256x6-bit ROM for signal <$rom0006>.
Found 256x3-bit ROM for signal <$rom0007>.
Found 256x6-bit ROM for signal <$rom0008>.
Found 256x3-bit ROM for signal <$rom0009>.
Found 256x6-bit ROM for signal <$rom0010>.
Found 256x12-bit ROM for signal <$rom0011>

It seems that instantation of ROMs via CoreGen is not preferable, as
far as I understand the CoreGen instantiation, I have to instantiate
180 Coregen ROMs because each ROM has a different content?

Hope you can help me and give me some suggestions how I can get these
ROMs packed into the fpga.

Thanks in advance and regards,
Peter

 

[peter.kampmann]

Just found out that the XC2VP30 has 136 Block RAMs with 18Kb each.
As you can use the Block RAM as dual port RAM, it should be possible to
store
my 180 ROMs consisting of 221 bits each (13*17 bits).

But how to instantiate it? I looked via the FPGA Editor into my design
and the BRAMs seem to be empty...

Regards,
Peter

 

[Benjamin Todd]

Hold on, are you sure you're describing the memory in a way which is
compatible with the operation of a RAM?
Like - you read it using an address, line by line? and that the size of each
stored element is the same?
The synthesis tool will only do what it can with what it's given!

You should describe this array as a ROM, with address and possibly an FSM
for reading it - then your synthesiser has a chance of making it fit into a
block ram. (i.e. make a component in vhdl called my_rom which has input and
output ports that operate in a way compatible both with your project, AND
with instantiation in a block ram.)

Good luck!
Ben

 

[jacko]

hi

seems like your 2D array is not linear (1D-RAM)

either make 1 array, and use high bits for 1 of 180 (8 bits) or use two
rams, with one performing indirection. a la 68K microcode saving
technique, using unique states wide RAM indexed by state number narrow
address, comming out of state needed RAM.

if you need all in one cycle i think you need some kind of mega RAM
width, and not implemented in ram block. => clock speed needs to be
lowered, or get a bigger chip, or have a massive external DRAM array.

cheers.

 

[Hendrik]

Altera has a "Recommended HDL Coding Styles" chapter in its Quartus
Handbook (www.altera.com/literature/hb/qts/qts_qii51007.pdf). There is
an explanation how to infer ROM from HDL code.
I suppose this will also work for Xilinx ISE.

Regards,
Hendrik.

 

[peter.kampmann]

Thanks for your replies,

as you mentioned I studied the various templates to infer ROMs so that
the ISE
can recongnize them. Now I have my ROM instantiated in Block RAM.

Now I'll try to find out how to infer dual port ROMs in Block RAM.

Regards,
Peter

 

[peter.kampmann]

Thanks for your replies,

as you mentioned, I studied the various templates to infer ROMs so that
the ISE
can recongnize them. Now I have my ROM instantiated in Block RAM.

Now I'll try to find out how to infer dual port ROMs in Block RAM.

Regards,
Peter

 

[Benjamin Todd]

Excellent - I'm pleased you managed, but one quick question - how come you
need a dual-port ROM? I figure dual port is good for read /write... but read
/ read? Interesting.
Ben

 

[Brian Drummond]

Excellent - I'm pleased you managed, but one quick question - how come you
need a dual-port ROM? I figure dual port is good for read /write... but read
/ read? Interesting.

It's a good technique for doubling the number of read ports (e.g. for
filter coefficients) available. If you need small ROMs the two ports can
act as completely independent ROMs mapped into different areas within
the same BlockRam.

- Brian

 

[peter.kampmann]

It's a good technique for doubling the number of read ports (e.g. for
filter coefficients) available. If you need small ROMs the two ports can
act as completely independent ROMs mapped into different areas within
the same BlockRam.

That's why I need them. I have 180 arrays consisting of 13 17-Bit
values. But there are only 136 BRAMs on my board. So I just "half" them
and I've now theoretically space for 272 of my Arrays.

The Dual Port BRAM can be designed be using a dual port BRAM and just
set the we input constantly to zero (if active high).

Regards,
Peter

 

[Benjamin Todd]

Ah, thanks for that. I guess provided your coefficients are compatible with
the two halves then it makes sense to share them.

 

[Benjamin Todd]

Ah, thanks for that. I guess provided your coefficients are compatible
with the two halves then it makes sense to share them.

or indeed making more effective use of the blockram, even if the
coefficients aren't shared

 

[KJ]

It's a good technique for doubling the number of read ports (e.g. for
filter coefficients) available. If you need small ROMs the two ports can
act as completely independent ROMs mapped into different areas within
the same BlockRam.

Are you assuming that the Xilinx software doesn't have enough smarts to
combine several small ROMs into a single BlockRam? Or is this a known
limitation that you just have to code around (i..e by making a single dual
port ROM when what your design intended was two smaller ROMs).

In other words, if you had simply coded the "180 arrays consisting of..."
(as you mentioned in a later post) as being 180 single port ROMs the fitter
'should' be able to partition the BlockRam usage to fit them all into the
136 that are available. The 'Brand A' software seems to do a good job of
parsing things into available memory of different sizes, so I'm wondering
why the 'Brand X' software wouldn't as well....unless like I said, you're
making an assumption that isn't necessary or desirable.

Where is Peter Alfke when you need him?

KJ

 

[peter.kampmann]

Are you assuming that the Xilinx software doesn't have enough smarts to
combine several small ROMs into a single BlockRam? Or is this a known
limitation that you just have to code around (i..e by making a single dual
port ROM when what your design intended was two smaller ROMs).

Well, I'm not assuming it I made the experience that this does not
fit
First, I implemented the 180 array consisting of, the "brand X"
Software recognizes that
I want to instantiate ROMs but they were mapped into LUTs.
Of course, it is possible that the software will map single port roms
into a dual port block rom, I have not tried it.

Regards,
Peter