Forum Discussion
Honored ContributorConfig compression makes no difference
I ran my Cyclone 3 design with and without compressed config file
generation & in both cases the .sof file came out to be 350KB. No change with compression. Did I miss some Quartus setting or do I just have an uncompressible design ? How much compression are people seeing ?22 Replies
Altera_ForumOk, I see the uncompressed .jic ends at 368KB & the compressed .jic ends
at 131KB, with the file size remaining fixed at 512KB for both cases. Thanks for the help. Is this info in any Altera app note ? I've read a number of pdfs and didn't see any of the info in this thread presented.- Altera_Forum
It should be.. somewhere. :)
- .SOF files are always the same size for a given FPGA device, because they're never compressed. - .POF files are always the same size for a given ROM device because they specify the contents of the entire ROM, even if it's blanks. Compression, however, lets you cram more stuff into a smaller ROM, as you just found out. - .JIC files are always the same size for a given FPGA and ROM combination due to the above. - .RBF files are the only ones that become smaller with compression, because they contain the raw compressed bitstream. - Altera_Forum
In my calculation, an EPCS4 image (4 MBit) has a size of 512 kB. The *.pof or *.jic file, although using compression, will be filled up with 0xff up to the image size.
So apparently, there's no problem at all. I guess, you didn't try yet to program the file to the EPCS4 device? P.S.: You didn't previously mention the intention of combining two images. This can be done in the programming file converter. The individual images must still fit to the device when blocked into pages. ' - Altera_Forum--- Quote Start --- is going to be the Cyclone 4 GX using the epcs4 flash. If I can't get compression to work, I'll have to move up to the next larger EPCS chip. --- Quote End --- --- Quote Start --- it looks like that device will fit in an epc4 without compression, but you could use compression to make some additional space for user data --- Quote End --- Are You talking about EPCS4 or EPC4?
- Altera_Forum--- Quote Start --- In my calculation, an EPCS4 image (4 MBit) has a size of 512 kB. The *.pof or *.jic file, although using compression, will be filled up with 0xff up to the image size. ' --- Quote End --- How much time will it take to load the content of EPCS4 into FPGA if payload is only ~2Mbit and the rest is filled up with 0xff ? The case is that EP4CGX22 is in "40 Mhz internal oscillator mode". There are to possible versions: 1). 4,000,000 bits x 25 ns / 1 bit = 100 ms 2). ~2,000,000 bits x 25 ns / 1 bit = ~50 ms 25 ns = 1/40MHz. Which one is correct? P.S. How to calculate decompression time by EP4CGX22?
- Altera_Forum
The latter is right, configuration bitstream load stops after the real data and a few terminating '1' s. Decompression takes place on the fly, there's no additional delay. Some configuration schemes, e.g. FPP are using a reduced bit rate to compensate the decompression overhead.
- Altera_Forum
Why the same project if targeted to EP4CGX150+EPCS128 results in larger *.pof then if targeted to EP4CGX22+EPCS4?
Larger means according to *.map file. - Altera_Forum
There are more cells in the EP4CGX150, so the uncompressed bitstream will be bigger, even if you aren't using most of them. As a result the compressed bitstream will be a bit bigger too.
- Altera_Forum--- Quote Start --- There are more cells in the EP4CGX150, so the uncompressed bitstream will be bigger, even if you aren't using most of them. As a result the compressed bitstream will be a bit bigger too. --- Quote End --- According to *.map file the *.pof and *.*.jic files for EP4CGX150+EPCS128 are 3 times bigger, then for EP4CGX22+EPCS4! Could it be such a big difference? As a result I cannot test the project targeted for a custom board with EP4CGX22+EPCS4 on Cyclone IV GX FPGA Development Kit which has EP4CGX150+EPCS128 because PCIe wake-up time is violated because *.pof and *.*.jic files for EP4CGX150+EPCS128 being too big.... Is there any workaround?
- Altera_Forum
It's probable that Quartus spreads the design in all the FPGA and as a result the configuration stream for the EP4CGX150 doesn't compress that good because you don't have big bunches of zeros all around. I don't know if there is any workaround to make the configuration time shorter...
