Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
20641 Discussions

Config compression makes no difference

Altera_Forum
Honored Contributor II
2,615 Views

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 ?
0 Kudos
22 Replies
Altera_Forum
Honored Contributor II
545 Views

*.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.

0 Kudos
Altera_Forum
Honored Contributor II
545 Views

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 ?

0 Kudos
Altera_Forum
Honored Contributor II
545 Views

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

0 Kudos
Altera_Forum
Honored Contributor II
545 Views

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.

0 Kudos
Altera_Forum
Honored Contributor II
545 Views

you can have both. which device are you using?

0 Kudos
Altera_Forum
Honored Contributor II
545 Views

The current design is Cyclone 3 using the EPCS4 flash. The next revision 

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.
0 Kudos
Altera_Forum
Honored Contributor II
545 Views

not family but device

0 Kudos
Altera_Forum
Honored Contributor II
545 Views

EP4CGX15 device

0 Kudos
Altera_Forum
Honored Contributor II
545 Views

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 

 

take a look at the generated .map file before and after compression, you can see the end address change
0 Kudos
Altera_Forum
Honored Contributor II
545 Views

What I want is to fit 2 or more config files in the same flash & change the 

starting 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.
0 Kudos
Altera_Forum
Honored Contributor II
545 Views

Ok, 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.
0 Kudos
Altera_Forum
Honored Contributor II
545 Views

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.
0 Kudos
Altera_Forum
Honored Contributor II
545 Views

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.  

'
0 Kudos
Altera_Forum
Honored Contributor II
545 Views

 

--- 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?
0 Kudos
Altera_Forum
Honored Contributor II
545 Views

 

--- 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?
0 Kudos
Altera_Forum
Honored Contributor II
545 Views

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.

0 Kudos
Altera_Forum
Honored Contributor II
545 Views

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.
0 Kudos
Altera_Forum
Honored Contributor II
545 Views

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.

0 Kudos
Altera_Forum
Honored Contributor II
545 Views

 

--- 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?
0 Kudos
Altera_Forum
Honored Contributor II
472 Views

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...

0 Kudos
Reply