Why does infer Quartus so many M10k blocks in this case?

By default Quartus will use one block per data bit to improve performance. Using 4 blocks will infer some logic on the address bits to select which M10K to use, and this will result in a slightly lower FMAX than using 9 blocks in 1-bit mode.

If you use the RAM megafunction, you can define the maximum block depth parameter that will tell quartus how to organize the memory blocks. Have a look here (http://www.altera.com/literature/ug/ug_ram_rom.pdf) on page 3-9 to see how it is used. I don't know if you can also define it in a synthesis attribute though, you may have to use the megafunction instead.

Daixiwen: Thanks a lot for the detailed explanation and the pointers. Finally the behaviour observed makes sence.

Unfortunately documentation is very sparse regarding this issue, in some older PDF I found the required hint - the maximum depth can be passed by attribute:

type mem_array is array (0 to mem_size-1) of std_logic_vector (dwidth-1 downto 0);

attribute max_depth : integer;

attribute max_depth of ram : variable is 1024;

Update: Although "maxdepth = 1024" solved the issue for the most critical parts, I still see the issue described in the first post on other places (where I also added the maxdepth attribute).

E.g. I have defined simple dual-ported memory with 3648 8-bit elements and maxdepth=1024, which should use 4 M10K blocks.

Quartus inferres implementations using 4 (as expected), 6 and 8 M10k blocks for different instatances.

I don't have any clue how/why Quartus determines when to use more then 4 blocks - as all blocks are similar configured.

I get the following message for a 4, 6, and 8 M10K inferrenced ram - which seem to have as far as I can see all the same configuration:

8M10K:

Info (276029): Inferred altsyncram megafunction from the following design logic: "census:mycensus|census_leftInputBuf_lineBuffer_1:leftInputBuf_lineBuffer_9_U|census_leftInputBuf_lineBuffer_1_ram:census_leftInputBuf_lineBuffer_1_ram_U|ram_rtl_0"

Info (286033): Parameter OPERATION_MODE set to DUAL_PORT

Info (286033): Parameter WIDTH_A set to 8

Info (286033): Parameter WIDTHAD_A set to 12

Info (286033): Parameter NUMWORDS_A set to 3648

Info (286033): Parameter MAXIMUM_DEPTH set to 1024

Info (286033): Parameter WIDTH_B set to 8

Info (286033): Parameter WIDTHAD_B set to 12

Info (286033): Parameter NUMWORDS_B set to 3648

Info (286033): Parameter ADDRESS_ACLR_A set to NONE

Info (286033): Parameter OUTDATA_REG_B set to UNREGISTERED

Info (286033): Parameter ADDRESS_ACLR_B set to NONE

Info (286033): Parameter OUTDATA_ACLR_B set to NONE

Info (286033): Parameter ADDRESS_REG_B set to CLOCK0

Info (286033): Parameter INDATA_ACLR_A set to NONE

Info (286033): Parameter WRCONTROL_ACLR_A set to NONE

Info (286033): Parameter INIT_FILE set to db/census.ram0_census_leftInputBuf_lineBuffer_1_ram_3eb21b1e.hdl.mif

Info (286033): Parameter RDCONTROL_REG_B set to CLOCK0

6 M10K:

Info (276029): Inferred altsyncram megafunction from the following design logic: "census:mycensus|census_leftInputBuf_lineBuffer_1:leftInputBuf_lineBuffer_10_U|census_leftInputBuf_lineBuffer_1_ram:census_leftInputBuf_lineBuffer_1_ram_U|ram_rtl_0"

Info (286033): Parameter OPERATION_MODE set to DUAL_PORT

Info (286033): Parameter WIDTH_A set to 8

Info (286033): Parameter WIDTHAD_A set to 12

Info (286033): Parameter NUMWORDS_A set to 3648

Info (286033): Parameter MAXIMUM_DEPTH set to 1024

Info (286033): Parameter WIDTH_B set to 8

Info (286033): Parameter WIDTHAD_B set to 12

Info (286033): Parameter NUMWORDS_B set to 3648

Info (286033): Parameter ADDRESS_ACLR_A set to NONE

Info (286033): Parameter OUTDATA_REG_B set to UNREGISTERED

Info (286033): Parameter ADDRESS_ACLR_B set to NONE

Info (286033): Parameter OUTDATA_ACLR_B set to NONE

Info (286033): Parameter ADDRESS_REG_B set to CLOCK0

Info (286033): Parameter INDATA_ACLR_A set to NONE

Info (286033): Parameter WRCONTROL_ACLR_A set to NONE

Info (286033): Parameter INIT_FILE set to db/census.ram0_census_leftInputBuf_lineBuffer_1_ram_3eb21b1e.hdl.mif

Info (286033): Parameter RDCONTROL_REG_B set to CLOCK0

4 M10K:

Info (276029): Inferred altsyncram megafunction from the following design logic: "census:mycensus|census_leftInputBuf_lineBuffer_1:leftInputBuf_lineBuffer_8_U|census_leftInputBuf_lineBuffer_1_ram:census_leftInputBuf_lineBuffer_1_ram_U|ram_rtl_0"

Info (286033): Parameter OPERATION_MODE set to DUAL_PORT

Info (286033): Parameter WIDTH_A set to 8

Info (286033): Parameter WIDTHAD_A set to 12

Info (286033): Parameter NUMWORDS_A set to 3648

Info (286033): Parameter MAXIMUM_DEPTH set to 1024

Info (286033): Parameter WIDTH_B set to 8

Info (286033): Parameter WIDTHAD_B set to 12

Info (286033): Parameter NUMWORDS_B set to 3648

Info (286033): Parameter ADDRESS_ACLR_A set to NONE

Info (286033): Parameter OUTDATA_REG_B set to UNREGISTERED

Info (286033): Parameter ADDRESS_ACLR_B set to NONE

Info (286033): Parameter OUTDATA_ACLR_B set to NONE

Info (286033): Parameter ADDRESS_REG_B set to CLOCK0

Info (286033): Parameter INDATA_ACLR_A set to NONE

Info (286033): Parameter WRCONTROL_ACLR_A set to NONE

Info (286033): Parameter INIT_FILE set to db/census.ram0_census_leftInputBuf_lineBuffer_1_ram_3eb21b1e.hdl.mif

Info (286033): Parameter RDCONTROL_REG_B set to CLOCK0

Are you actually running out of memory blocks?

It might just be that more blocks are being used in order to make it easier to meet the timings?

(I don't know if such changes can be made that late on though.)