Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Valued Contributor III
1,991 Views

Config 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 ?
0 Kudos
22 Replies
Highlighted
Valued Contributor III

Re: Config compression makes no difference

*.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
Highlighted
Valued Contributor III

Re: Config compression makes no difference

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
Highlighted
Valued Contributor III

Re: Config compression makes no difference

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
Highlighted
Valued Contributor III

Re: Config compression makes no difference

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
Highlighted
Valued Contributor III

Re: Config compression makes no difference

you can have both. which device are you using?

0 Kudos
Highlighted
Valued Contributor III

Re: Config compression makes no difference

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
Highlighted
Valued Contributor III

Re: Config compression makes no difference

not family but device

0 Kudos
Highlighted
Valued Contributor III

Re: Config compression makes no difference

EP4CGX15 device

0 Kudos
Highlighted
Valued Contributor III

Re: Config compression makes no difference

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
Highlighted
Valued Contributor III

Re: Config compression makes no difference

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
Highlighted
Valued Contributor III

Re: Config compression makes no difference

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
Highlighted
Valued Contributor III

Re: Config compression makes no difference

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
Highlighted
Valued Contributor III

Re: Config compression makes no difference

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
Highlighted
Valued Contributor III

Re: Config compression makes no difference

 

--- 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
Highlighted
Valued Contributor III

Re: Config compression makes no difference

 

--- 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
Highlighted
Valued Contributor III

Re: Config compression makes no difference

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
Highlighted
Valued Contributor III

Re: Config compression makes no difference

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
Highlighted
Valued Contributor III

Re: Config compression makes no difference

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
Highlighted
Valued Contributor III

Re: Config compression makes no difference

 

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