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

[Altera_Forum]

Hi, 

 For a Cyclone-V based designed I have defined a simple dual-ported ram in vhdl, with a data-width of 9-bits, 12-bit address width and 3648 elements (vhdl file attached). Using 9-bit elements to my understanding means each M10K block can contain 1K 9-bit elements (where the 10th bit stays unused). So with 3648 elements I would expect 4 M10K memory blocks to be used.  Any idea why Quartus infers 9 M10K blocks in this case?  Thank you in advance, Clemens

[Altera_Forum]

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.

[Altera_Forum]

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;

[Altera_Forum]

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

[Altera_Forum]

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