I ran my Cyclone 3 design with and without compressed config filegeneration & 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 ?
*.sof files are never compressed, because compression isn't available for JTAG configuration download. Compression is used for *.rbf, *.pof or e.g. indirect JTAG programming files (*.jic). If you generate files with the programming file conversion tool, compression need to be enabled in the tool, the compression state of the input files doesn't matter.
Thanks for the info. I tried .pof & the size is 512KB, bigger than the original .sof. Then I tried .rbf & the size is 128KB. Terrific but .rbf does not seem compatible with the EPCS4. I'd like to use the EPCS4 for the small size. Any way to use active serial config + compressed file ?
use the Convert Programming Files dialogue to create a .jic file containing the .sof. you will be able to enable compression of the .sof using this tool
The .jic file is also 512KB. No advantage at all. This is a very screwy feature. compression or small flash chip but you can't have both.
The current design is Cyclone 3 using the EPCS4 flash. The next revisionis 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.
it looks like that device will fit in an EPC4 without compression, but you could use compression to make some additional space for user datatake a look at the generated .map file before and after compression, you can see the end address change
What I want is to fit 2 or more config files in the same flash & change thestarting self load address to point to 1 of the config files. Thus the need to compress & get at least 2 config files into the flash.
Ok, I see the uncompressed .jic ends at 368KB & the compressed .jic endsat 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.
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.
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. '
--- 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?
--- 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?
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.
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.
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 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?