ROM instantiation question

Problems keeping instantiated ROM in Xilinx XST.

Say I have a rom named rom16x16. It consists of 16 - 16x1 ROM primitive instantiations from the xilinx library.

How do I force xilinx to keep this ? The code is being combined into only one ROM (even though I have "init'd" the ROMS to different values.

I tried using "keep heirarchy" under synthesis properties but that was a no go. I'm at a loss as to what to do here. I do need the roms to be separate (rather than a 64 byte rom) because I need to use them in parallel for my particular application. Also, I took the basic rom16x16 and instantiated 4 components as rom16x16, rom16x16_2, rom16x16_3, rom16x16_4, and I am also using them as "RAM" for now just for simulation/rough design size purposes. I will stick in the actual 16x16 RAM units next. Spartan 3 is the chip architecture. Webpack XST 6.2 is the sythesis engine.

Thanks! D

code follows:

************** rom0: rom_16x16 port map(coef_rom0_out(15 downto 0), addr); coef_rom0_out(17 downto 16) a(1), A2 => a(2), A3 => a(3) );

U2: rom16x1 generic map(x"1C") port map (O => o(2), A0 => a(0), A1 => a(1), A2 => a(2), A3 => a(3) );

U3: rom16x1 generic map(x"4") port map (O => o(3), A0 => a(0), A1 => a(1), A2 => a(2), A3 => a(3) );

U4: rom16x1 generic map(x"17") port map (O => o(4), A0 => a(0), A1 => a(1), A2 => a(2), A3 => a(3) );

U5: rom16x1 generic map(x"0") port map (O => o(5), A0 => a(0), A1 => a(1), A2 => a(2), A3 => a(3) );

U6: rom16x1 generic map(x"0") port map (O => o(6), A0 => a(0), A1 => a(1), A2 => a(2), A3 => a(3) );

U7: rom16x1 generic map(x"0") port map (O => o(7), A0 => a(0), A1 => a(1), A2 => a(2), A3 => a(3) );

U8: rom16x1 generic map(x"0") port map (O => o(8), A0 => a(0), A1 => a(1), A2 => a(2), A3 => a(3) );

U9: rom16x1 generic map(x"0") port map (O => o(9), A0 => a(0), A1 => a(1), A2 => a(2), A3 => a(3) );

U10: rom16x1 generic map(x"0") port map (O => o(10), A0 => a(0), A1 => a(1), A2 => a(2), A3 => a(3) );

U11: rom16x1 generic map(x"0") port map (O => o(11), A0 => a(0), A1 => a(1), A2 => a(2), A3 => a(3) );

U12: rom16x1 generic map(x"0") port map (O => o(12), A0 => a(0), A1 => a(1), A2 => a(2), A3 => a(3) );

U13: rom16x1 generic map(x"0") port map (O => o(13), A0 => a(0), A1 => a(1), A2 => a(2), A3 => a(3) );

U14: rom16x1 generic map(x"0") port map (O => o(14), A0 => a(0), A1 => a(1), A2 => a(2), A3 => a(3) );

U15: rom16x1 generic map(x"0") port map (O => o(15), A0 => a(0), A1 => a(1), A2 => a(2), A3 => a(3) );

end xilinx;

**********************
Reply to
D
Loading thread data ...

My guess at fixing this would be to either remove the ROM16X1 component declaration or you can add the attribute:

attribute BOX_TYPE of ROM16X1 : component is "PRIMITIVE";

Better for you to just remove and not use the component declaration as it is not necessary and if you mis-declare it, can cause it not to work properly. The component declaration you have does mis-declare a ROM16X1 as the generic should be a bit_vector and named INIT not init_val bu the fact you named it rom_16x1 rather than rom16x1 means that that declaration is meaningless any ways.

Also, the INIT attribute needs to be a 4-digit hex value (16-bits) not

2-digit (8-bits). I also suggest simulating this as it might help you localize the problem better if these suggestions do not work.

-- Brian

Reply to
Brian Philofsky

Thanks for your response Brian, I eventually found out that it wasn't an actual problem with the ROM (you were completely right about the component declaration, a good on my part, but as you mentioned the primitive didn't actually needed to be included because I already had the unisim declaration). The problem was in the fact that in the higher level heirarchy instantiation, I had used a c++ program to generate some of the code and mistakenly kept pointing the output of the ROM's to the same output (signal) name, so they all got collapsed into one by the tools. Live and learn. It's been a while for me. And I had seen the BOX_TYPE attribute before, a long time ago. Probably in the xilinx answer database :) . Anyway thanks again.

-D

Reply to
D

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.