I saw another post that said you could use the raw binary to know how big your image really is, but that the POF is sized to the device. What if you are using a family that doesn't support generating an RBF? Is there any way to find out how much room your compressed image is taking up in the CFM of a 10M08, for example? Is it guaranteed to only occupy CFM0, thereby leaving CFM2 and CFM1 free? How can you tell?
If you refer to Table 1 (https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/hb/max-10/ug_m10_ufm.pdf#pa...):
For 10M08 device:
Flash & analog variants:
If you have a look at Table 2 above, is you want to maximize the UFM, you can choose single compressed image.
The maximum possible value UFM is = (UFM1 + UFM0 + CFM2 + CFM0) x 16
The maximum possible value UFM is = (8 + 8 + 41 + 29) x 16
= 1376 Kb
If you have a look at Table 3 above, is you want to maximize the UFM, you can choose single compressed image.
The maximum possible value UFM is = (UFM1 + UFM0) x 16
The maximum possible value UFM is = (8 + 8) x 16
= 256 Kb
For CFM0, depend on how much size you want to use.
CFM0 have 70 page. Thus maximum size for cfm0 is:
70 x 16 = 1120Kb.
Sorry, as I’m re-reading my question, I realize how poorly worded it was that I asked “how much space it takes up” – which led to the datasheet answer which I already had access to and isn’t what I really am looking for. My .pof file sizes are 321,800, according to my operating system, for either a target 10M04 or a 10M08, and regardless of my use of memory initialization files, regardless of my selection of “generate compressed bitstream” in device options, etc. Clearly a file that is 321,800 bytes (321.8KByte) is not fitting in a memory that is 2,240Kbit. Therefore, the compression that is going on is hidden / obscured from the designer. My problem is that I have a customer requirement that I not exceed 50% utilization of the memory store. Mathematically, I can’t prove that to them with these numbers. Is there any way to get the compressed image size in bits or bytes to satisfy my customer requirement? Thanks!
Also, on the illustration in Table 2, I don’t see how the uncompressed image size (321.8KB *8b/B = 2574.4Kb) fits in any of these configurations:
CFM0 = 70 pages * 16Kb = 1120Kb (supposedly fits a single compressed image)
CFM0 + CFM1 = 70+29 = 99 pages * 16Kb = 1584Kb (supposedly fits a single uncompressed image)
CFM0 + CFM1 + CFM2 = 70+29+41 = 140 pages * 16Kb = 2240Kb (supposedly fits a single uncompressed image with memory initialization)
.pof file is the combination of UFM + CFM (UFM0 + UFM1 + CFM1 +CFM2)
thus for device :
10M04 = (8+41+29+70) * 16 = 2368Kb = 296KB
10M08 = (8+8+41+29+70) * 16 = 2496Kb = 312KB
Therefore, you 321.8KB .pof file will not fit into 10M04 or 10M08.
I curious about your 321.8KB .pof file. May I know how you generate this file? the .pof file generated bigger than device memory.
Is it in your design you select other device (i.e. 10M50) and convert .pof file, Then, you try to fix this design into 10M04/10M08 device?
The file is generated out of Quartus Prime Lite Edition 18.1, targeting device 10M08SAU16917P. We have been programming it into this device for well over 6 months now. I am looking to understand how the compression part works, since the file size does not reflect any compression and certainly exceeds the space.
To understand the Compress/Decompress algorithm, it is a low level explanation (confidential information). I can't explain to you since it is a confidential info.
The compression ratio for the configuration image should be at least 30% for the device to be able store two configuration images. However, the compression ratio is the design dependent (30% reduction size -- some people can fit into internal flash & some people can fit into the internal flash).