Forum Discussion
MAX10 Flash Memory specifications
There is some inconsistency between the various MAX10 documents and what Quartus states for the amount of User Flash Memory (UFM) that's available.
As an example, I've been looking at the 10M08DAF484C8GES, which is used in Arrow's BeMicroMAX10. According to the MAX10 overview, the 10M08 has 1376Kb of UFM (though a footnote states that this is the combined User and Configuration Flash Memory). This is also what the MAX10 Flash Memory User Guide states. However, both Arrow and Mouser state that the UFM is only 256Kb. Further, when you select the device in Quartus, it states that the UFM is 2496Kb (actually, 2555904 bits). As it happens, this somewhat lines up with the Flash Memory User Guide, which states that the Configuration Flash Memory is 2240Kb. If you add the 256Kb that Arrow and Mouser state, you end up with the 2496Kb that Quartus states. So, which is correct and which isn't?13 Replies
- Altera_Forum
Honored Contributor
in the ordering code 10M08DAF484C8GES you see DA on sixth and seventh position describing special key features of the device. this is one of 6 possible variations of max 10, which goes like this:
MAX 10M08 ________________ USER FLASH BITS SC single supply, compact features 262144 bits SF single supply, flash features 2555904 bits SA single supply, analog features 2555904 bits DC dual supply, compact features same as SC DF dual supply, flash features same as SF DA dual supply, analog features same as SA - Altera_Forum
Honored Contributor
... and it depends on the configuration mode that you are currently using.
I'm using the same board with dual compressed images, and as UFM and CFM share the same space I have only 256kBits of UFM available. Best regards, tfranke https://www.alteraforum.com/forum/attachment.php?attachmentid=13162 - Altera_Forum
Honored Contributor
uuhu, and if you configure it in "Single compressed image" mode you will have 1376 Kbites of UFM under your command. but i don't see real reason why to use compressed mode. because sooner or later your project will fill the MAX10 and you will have to write full sized configuration file.
- Altera_Forum
Honored Contributor
Really?
So you think that at some point in the design process there is a likely chance that the compressed image will not fit into CFM 0 block any more? Thinking forward that implies that the "dual compressed image" mode where the images are stored at fixed locations (start at CFM0 and CFM1 respectively) cannot safely be used? And as there is no "dual UNcompressed image" mode available this means that remote updates should not be done on Max 10 devices at all? I've never read about such limitations which would severly impact my own current design. Best regards, tfranke - Altera_Forum
Honored Contributor
Dude, you have no idea about limitations of altera products. they reveal themselves only in the middle of a project. altera advertises it's strengths not it's weaknesses. this is part for marketing strategy. and that is why intel bought it for 14 Billion $$$ (correct me if i'm mistaken with the exact numbers).
yes there is a possibility that your project will not fit in CFM0 alone. but it is up to you really. you see: if you know, that your MAX 10, will be filed up only partially; then there is no reason to worry. but if you don't know that, and there is a possibility that in the end MAX10 will be filled to it's maximum(or close to it's maximum.it also counts as maximum) your programming file will swell up and will no longer be Compressed. Dual uncompressed is not supported. and yes, it raises questions about remote update. but i suspect there is some workaround there.... i guess... join up this discussion for further information: http://www.alteraforum.com/forum/showthread.php?t=54045 there is another danger into all of this. what if in the middle of your project,it becomes clear that you will need flash memory initialization? that also changes your configuration settings and sets UFM sector count to 2. (instead of 3, as in case of single uncompressed image). it is all well described in https://www.altera.com/en_us/pdfs/literature/hb/max-10/ug_m10_ufm.pdf page 5 table 2-2 you must also be careful while selecting the device. because one and a same model may have several "variants". for example: SC : Single supply - compact features SA : Single supply - analog and flash features with RSU option DC Dual supply - compact features DF Dual supply - flash features with RSU option DA Dual supply - analog and flash features with RSU option as described in https://www.altera.com/en_us/pdfs/literature/hb/max-10/m10_overview.pdf page 4 danger is hidden in a way that "SC" variant for example, does not supports: Dual compressed images,Single uncompressed image with memory initialization, and Single compressed image with memory initialization -modes AT ALL! this is also clearly(but reluctantly) stated in the above flash guide document on page 5, table 2-3 what else would you like to know dear sir? :)))) do your homework :) dig deep into datasheets before asking for help :))))))))) this is part of your work, and responsibility. maaan i'm a jerk :))) - Altera_Forum
Honored Contributor
@Ilik:
To make it short: I think I've done my homework, that's why I've selected the DA option without any need for future flash initalization. The only information I don't know where to get is how much of the FPGA I can use before I run into problems as the image cannot be compressed any more to fit into CFM0 space. Is there any information available that points out some figures like "its getting complicated after reaching 90% logic, memor or interconnect usage" or something like that? Datasheets? AppNotes? Unfortunately the links you provided do not contain such information... As I've planned a migration path I will use the biggest FPGA during development and maybe reduce size later depending on how full the FPGA gets. Thanks for help, tfranke - Altera_Forum
Honored Contributor
the size of programming file will change based on your fpga usage.datasheets can not predict how much fpga you have used.and they did not bother to set up a table for 50% used scenario, 60%.. and so on. so trial and error is i guess all that is left to us. or i am mistaken and there is some hidden way/tool that will help to solve this problem. never worked on it and i don't know. try checking programming file size, and compare it to CFM0 capacity. if something delete some logic gates, recompile and recheck. ...i guess............
- Altera_Forum
Honored Contributor
Ok, will keep an eye on it.
And in case of negative fit then hopefully there is some logic left which can be deleted without affecting needed functionality ;-) - Altera_Forum
Honored Contributor
Beyond the theoretical possibility to exceed the 72 % compression factor which is essential for the M08 dual compressed image scheme, what's compression you're presently experiencing? With Cyclone III, I never managed to reach even 60 % with a brim-full design (99% logic utilization).
- Altera_Forum
Honored Contributor
FvM
don't say.... my boss reached 95% by he's junk code and threw the project at me to clean up he's garbage. i feel more like working in cleaning service rather than engineering. in addition he promised bonus on my salary if i would make it fast. cleaned it up earlier than scheduled and got 0 bonus. so... :))) lol.... i'm "used and abused" all the time.