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?
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
... 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
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.
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
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 :)))
@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
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............
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 ;-)
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).
FvMdon'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.
That's O.K. so far but obviously didn't answer my question. I was referring to your previously point that using the dual compressed image scheme might fail one day if the design grows incrementally. I'm not talking about junk code but well considered logic that can't be easily reduced. In Cyclone III compression metrics, I'm quite sure that 72% will be hardly reached, MAX 10 is effectively Cyclone III/IV logic core, but may be the expectable compression factor size of a "full" design is different though.
why is that O.K? you do not have even slightest pity to me :) .why can't altera be filled? my boss has a project that fills 115 000lcell cyclone IV. he has 24 separate high speed streams of wide buses that smashes into the fpga simultaneously; and all of them have their own separate processing tracts, each takes tens and tens of modules. and all of them are interconnected.pipeline registers only, exceed 5000. plus our devices have multiple motherboards positioned on top of each other (with separation of course) with single central processor fpga on each and lots of other IC s in surrounding areas.so quite a logic is dedicated to inter-IC and inter-motherboard communication. control section, and automatic recovery system(in case if remote update or something else goes wrong). he uses an fpga as if it was a set of multiple ICs under a single package. and MAX10 is a tiny puppy that can be filled easily. you see, some companies can not plan ahead how much logic will be enough. many companies take on building version 2.0 right after 1.0 touches the market. and that 2.0 drags all the circuits that were already implemented in the previous version. years of work add up, module after module, creating a huuuge monster that compiles for many hours. and in the end, ...there is no end. then it will be 3.0, 4.0 and so on. in such environment no logic resource is ever enough. and companies do not want to retrace their motherboards and hook onto higher capacity fpgas, it is too time consuming and expensive for them. that is why they are forced to try and stick as much logic as possible into the already soldered fpgas; and adding Doughterboards,additional motherboards and similar crapness. there in no such thing as well planned project in their work.
The 10M08 device’s onchip flash can be partitioned into the following:CFM0: 143360 Bytes CFM1 + CFM2 : 143360 Bytes = 1120Kb UFM0 + UFM1 : 32768 Bytes = 256Kb And depending on your configuration mode (Quartus Menu Assignment/Device/Device and Pin Options/Configuration/Configuration mode), the CFM1 + CFM2 could be used as either configuration memory or user flash memory. That’s why you have the number of 256 Kb or (256Kb + 1146880 Kb = 1376Kb) --- Quote Start --- 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? --- Quote End ---