“MIF is not supported?” Yes it is!

2021-01-30

I’ve just bought a couple of the ridiculously cheap DECA MAX10 dev boards from Arrow and one of the first projects I attempted to port to it gave me an error message I wasn’t expecting:

Error (276003): Cannot convert all sets of registers into
RAM megafunctions when creating nodes. The resulting number
of registers remaining in design exceeds the number of
registers in the device...

Hmmm, OK, what’s going on here? For some reason the ROM in my project isn’t getting recognised and implemented as initialised block RAM – what gives?

Let’s look at the previous line in the flow messages:

Info (276013): RAM logic "VirtualToplevel:mytl|Dhrystone_rom:rom|ram"
is uninferred because MIF is not supported for the selected family

Ummmm… yes it is!

There are several variants of MAX10, and it’s true that the “Compact” variants (10MxxSC or 10MxxDC) don’t support RAM blocks with initial contents, however the DECA board has a 10M50DA part, which definitely does support RAM blocks with initial contents.

I remember running into this issue with my DE10-lite when I first bought it, but having solved the issue I promptly forgot about it! Having run into it a second time, I’m now documenting it (a) to remind myself for next time, and (b) in case it’s useful for anyone else:

It’s not the device that doesn’t support MIF, it’s the format of the programming file that’s generated by default. The MAX10 has some internal flash, some of which is available for user-applications, and to make as much of it available as possible, initial RAM contents is disabled by default. In Quartus’s “Assignments -> Device” dialog, the “Device and Pins…” dialog contains a “Configuration” page, where you can choose between several different configuration modes, and if you select one that allows Memory Initialisation, Quartus will once again allow block RAMs to be inferred for ROMs.

7 thoughts on ““MIF is not supported?” Yes it is!

  1. I tripped over that one few times already 😉
    So now using the MAX10, I always start thinking about the configuration of the FLASH first (boot/RAM/ROM, two blocks, etc.) and set it up at the beginning …

    • When I’m setting up a new project for a board I usually just copy a .qsf file from a previous project, so having solved the problem once I never ran into it again – until I bought a different board with the same FPGA on it!

  2. I had the same problem and I am using TCL based flow. To do the configuration via tcl script you need to add the following line:

    set_global_assignment -name INTERNAL_FLASH_UPDATE_MODE “SINGLE IMAGE WITH ERAM”

    Thank you for the original solution, Cheers!

    • Thanks for that – I’m moving slowly but surely away from the GUIs for both Altera/Intel and Xilinx parts, so this will definitely be useful.

Leave a Reply to Hans Baier Cancel reply

Your email address will not be published. Required fields are marked *