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.