coregenerator bram in synplify pro error

Rather than actually answer the question, can I suggest that you infer BRAM rather than go through that complicated process? As a bonus, inferred BRAM simulates much faster. You would infer BRAM something like:

architecture synth of pp_ram is

constant MEM_DEPTH : integer := 2**AWIDTH; type mem_array is array(0 to MEM_DEPTH-1) of std_logic_vector(DWIDTH-1 downto 0); signal ram : mem_array; signal rd_addr_ram : unsigned(AWIDTH-1 downto 0);

signal ADDRA : unsigned(AWIDTH-1 downto 0); signal ADDRB : unsigned(AWIDTH-1 downto 0); signal DIA : std_logic_vector(DWIDTH-1 downto 0); signal DOB : std_logic_vector(DWIDTH-1 downto 0);

begin -- infer block RAM wr_p: process(CLKI) begin if rising_edge(CLKI) then if WE = '1' then ram(to_integer(ADDRA))

Using coregen definitely does not result in optimization during PAR (or MAP for that matter). When Synplify (or any synthesis tool) creates the edif file that will be used by the Xilinx tools, it puts primitives in there including BRAMs if they are correctly inferred in your code. It is useful to check the log file of the synthesis tool to verify that the expected number of BRAMs were inferred. If not, that might point to something you did wrong when inferring them.

Thanks, I will try that and see.

Err, not necessarily a good idea.

For example, inferring a ROM wide enough to need both data buses and the parity bits can cause three BRAMs to be used instead of one; to be fair, ISE 9.2 improved on 7.1 in my test case, only inferring twice as many BRAMS as necessary.

However, initialising the ROM data using functions caused elaboration to take significant time (of the order of hours for a couple of thousand elements) and

9.2 took twice as long as 7.1. I had to place an assert per memory location to reassure me it was doing anything at all. There is some n^2 algorithm involved; you could see it slow down, and doubling the ROM size quadrupled execution time. I don't know if this has been fixed in 10.1 yet.

But it's a lovely idea when it actually works.

(Incidentally, according to the resulting webcase, the "something I did wrong while inferring them" was ... inferring them. And the suggested instantiation template glossed over the problem of initialisation entirely.)

Synplify probably handles BRAM inference much better; just be aware that relying on it limits portability.

- Brian

time.

relying

Another limitation I have heard is that you can't infer dual port ram of differing port widths.

-Jeff

Or with differnt clocks. (OK, they may get inferred, but not efficiently.)

JTW

I prefer to infer multiple BRAMs, and simply wire them up to have a different input/output width, at the possible cost of a few extra BRAMs and a small amount of logic. This cost disappears if you are creating a memory that is big enough that you need the extra BRAMs anyway.

If I don't want to waste the BRAMs, I prefer to directly instantiate the BRAM, rather than use coregen.

... not to mention the extra value inherent in portable code.

-- Mike Treseler

I'm not sure what you mean. I infer BRAMs with different read/write clocks all the time. It works fine. And the example I gave showed the use of different clocks.

The specifc issue I had a few years back was using BRAMs with one port write-only, and the other port read with a simultaneous write to clear. Synplify doubled the required amount of BRAMs.

JTW