ROM is uninferred because MIF is not supported for the family.

[Altera_Forum]

I'm using Quartus Prime Lite 16.1 with a MAX 10 FPGA devel kit. I used the  

 Insert Temlplate -> VHDL -> Full Designs -> RAMs and ROM's -> Dual-Port ROM  to generate a sample VHDL code that should infer a ROM. The system functions as expected, but it is not inferring it in block memory. I get the following message:   Info (276013): RAM logic "DDS:DDS0|DDS_table:DDS_TABLE1|DDS_ROM" is uninferred because MIF is not supported for the selected family  Searching this forum, I tried adding things like:   attribute romstyle : string;  attribute romstyle of DDS_ROM : signal is "M9K";  or   attribute ramstyle : string;  attribute ramstyle of DDS_ROM : signal is "M9K";  and also setting the tools to infer regardless of the size. Nothing works.   But if I used the Megawizard to insert a ROM, it does in fact support MIF files, so that makes no sense. Also, if I look at the Tools -> Netlist -> RTL Viewer, it shows the following. It sure looks like it is inferring a RAM, but not ROM. What am I doing wrong?  http://www.alteraforum.com/forum/attachment.php?attachmentid=13054&stc=1

[Altera_Forum]

The RTL viewer is based directly off of your RTL code, not what the Fitter selects, so to verify that a block memory was used, you'd look at the Technology Map Viewer (Post-Fitting) instead.  

 Maybe you could post your code to see what may be going on here.  Steve

[Altera_Forum]

From the warning, id suggest using a .Mif is unsupported for inferred rams. You could use an initialisation function as per the code template you attached. Or use the wizard and use the generated code. The wizard files are different from inference and use the primitive blocks. You can instate then yourself there is a user guide for them here: 

 https://www.google.co.uk/url?sa=t&source=web&rct=j&url=https://www.altera.com/literature/ug/ug_ram.pdf&ved=0ahukewj10nzs_5jrahuve1akhszrcqwqfggamaa&usg=afqjcngyt_pyd_mnc5uaevxw_me9fwqedw&sig2=zgbyxf8gaa7vzj7ctuiayg

[Altera_Forum]

Steve, 

 Looked at the Technology Map Viewer post-fit as you suggested. It just shows a rats nest of flip-flops confirming that the ROM was placed in registers instead of block RAM.  https://www.alteraforum.com/forum/attachment.php?attachmentid=13062

[Altera_Forum]

Tricky, 

 Thanks for the suggestion. I had considered just instantiating an ALTSYNCH_RAM. Looking at the .vhd file created by the Wizards, it looks like I just need to include:  LIBRARY altera_mf; USE altera_mf.altera_mf_components.all;  and then there are alot of generics that specify the nature of the RAM. There is one for INIT_FILE:  http://quartushelp.altera.com/14.1/mergedprojects/hdl/mega/mega_file_altsynch_ram.htm  However, that does not really solve my problem. My goal was to have a parameterized DDS (see attached). The actual init function uses SIN() function from MATH.REAL library. I guess the tools create a MIF file for some device families. So I will still need an external program to create the MIF file for a particular set of parameters.

[Altera_Forum]

Found one more odditty. Synthesis (Quartus Prime Lite 16.1) is in fact generating a mif file (see attached) from my init_rom function; it just uses it to init the flip-flops instead of a block RAM. When I change the table generics, it generates the correct sine table in the file and the code functions correctly. Just not using RAM.

[Altera_Forum]

I see .mif are not allowed as attachments, so added .txt. It generates it in the projects db\ directory.

[Altera_Forum]

Success! Finally figured it out after trying to instantiate a ROM core and it still gave an error on mif file. Need to set 

 Assignments -> Device ... -> Device and Pin Options ... -> Configuration Mode   to   "Single Uncompressed Image with memory initialization (512 Kbits UFM)"  The "RAM Summary" now shows it initialized with the .mif file generated from my VHDL init_rom function.    NAME: DDS:DDS0|DDS_table:DDS_TABLE1|altsyncram:DDS_ROM_rtl_0|altsyncram_r271:auto_generated|ALTSYNCRAM  MIF: db/OmniProbeTop.ram0_DDS_table_3b02cb4d.hdl.mif  and post fit technology map seems to confirm:  https://www.alteraforum.com/forum/attachment.php?attachmentid=13065