Hi John,> Forgive me if this has been asked before, but does anybody have > comments or links to simple methods of compressing/decompressing > Xilinx configuration bitstreams?Can't help you on the Xilinx front, but many of Altera's newest chips (Cyclone, Stratix II) support on-the-fly decompression of the bitstream. The Quartus software compresses the bitstream which is then programmed into the device using pretty much any of the many methods of programming available, and the chip's configuration controller will decompress the bitstream that it sees. This typically achieves a 1.9-2.3:1 compression ratio, depending on the device utilization, RAM contents and such. Some of our programming devices also can decompress bitstreams on-the-fly, allowing bitstream compression for other chip families that do not support decompression internally. See the Configuration Handbook Volume 2 (http://www.altera.com/literature/hb/cfg/cfg_volume2.pdf) for a detailed description of device programming and compression options. Regards, Paul Leventis Altera Corp.
compressing Xilinx bitstreams
Started by ●June 17, 2004
Reply by ●June 17, 20042004-06-17
Reply by ●June 17, 20042004-06-17
Paul Leventis (at home) wrote:> Hi John, > > >>Forgive me if this has been asked before, but does anybody have >>comments or links to simple methods of compressing/decompressing >>Xilinx configuration bitstreams? > > > Can't help you on the Xilinx front, but many of Altera's newest chips > (Cyclone, Stratix II) support on-the-fly decompression of the bitstream. > The Quartus software compresses the bitstream which is then programmed into > the device using pretty much any of the many methods of programming > available, and the chip's configuration controller will decompress the > bitstream that it sees. This typically achieves a 1.9-2.3:1 compression > ratio, depending on the device utilization, RAM contents and such.<Snip> Has anyone taken the simple step of run ZIP on some Altera compressed files, to see how much more compression is possible ? -jg
Reply by ●June 18, 20042004-06-18
On Thu, 17 Jun 2004 22:09:31 GMT, "Clark Pope" <cepope@mindspring.com> wrote:>The bit generation tool has an option to compress the .bit file. I use this >when I'm loading over JTAG to save time. I assume Xilinx has info on in >system programming with a compressed .bit file.This 'compression' merely merges identical frames. The probability of getting identical frames in a well utilised FPGA isn't very high, so this doesn't result in much reduction in file size. Some experiments I did a few years ago (on Virtex-E and Virtex-2 files) indicated that the this compression made subsequent compression by tools such as gzip *worse*. It is, however, the only way to speed up JTAG loading. Regards, Allan.
Reply by ●June 18, 20042004-06-18
Jim Granville <no.spam@designtools.co.nz> wrote in message> We did some work with Run length compression, which is > very simple (simple enough to code into CPLD), but has medium > compression gains. ISTR about half the gains of ZIP ?Interesting. A student of mine did the same as a semester project. The goal was to find a compression method simple enough that the logic to programm an FPGA from a NOR-Flash would fit into an XC9536. For XC4K FPGAs he was very successfull. He achieved a compression in the range of 50% to 65% size compared to the original with runlength encoding of 1s only. This is almost as good as zip. The Virtex family seems to use it's configuration bits a lot more efficiently. (encoded switch configurations ?). He could not find any simple solution for those. Kolja Sulimma
Reply by ●June 18, 20042004-06-18
Kolja Sulimma wrote:> Jim Granville <no.spam@designtools.co.nz> wrote in message > >> We did some work with Run length compression, which is >>very simple (simple enough to code into CPLD), but has medium >>compression gains. ISTR about half the gains of ZIP ? > > > Interesting. A student of mine did the same as a semester project. > The goal was to find a compression method simple enough that the logic > to programm an FPGA from a NOR-Flash would fit into an XC9536. > > For XC4K FPGAs he was very successfull. He achieved a compression in > the range of 50% to 65% size compared to the original with runlength > encoding of 1s only. > This is almost as good as zip. > > The Virtex family seems to use it's configuration bits a lot more > efficiently. (encoded switch configurations ?). He could not find any > simple solution for those.Maybe you could have allowed him to also use a 9572 ( or XC2C64) ? If there was a big change between families, it sounds like Xilinx followed the same path, and did a simple reduction in bit-encode with some small RLC - after all, a 9536 level resource will be miniscule in a FPGA.
Reply by ●June 18, 20042004-06-18
While this doesn't exactly answer your question, the new Xilinx XCFP serial PROMs support storage of compressed bitstream data. The data is compressed when you translate to the PROM format and the PROM does the decompression before delivery to the FPGA. http://www.xilinx.com/bvdocs/publications/ds123.pdf John Larkin wrote:>Forgive me if this has been asked before, but does anybody have >comments or links to simple methods of compressing/decompressing >Xilinx configuration bitstreams? I've been perusing a few of my .rbt >files, and they have long bunches of 1s and 0s (interestingly, >different designs seem to have more 1s, others mostly 0s.) I'd think >that something very simple might achieve pretty serious (as, maybe >2:1-ish) compression without a lot of runtime complexity. We generally >run a uP from EPROM, with the uP code and the packed Xilinx config >stuff in the same eprom, with the uP bit-banging the Xilinx FPGA at >powerup time. So a simple decompressor would be nice. > >I did google for this... haven't found much. > >Thanks, > >John > > >
Reply by ●June 19, 20042004-06-19
> >Forgive me if this has been asked before, but does anybody have > >comments or links to simple methods of compressing/decompressing > >Xilinx configuration bitstreams? I've been perusing a few of my .rbtMy application uses a 128Kb flash micro (M16C) to program a SpartanIIE-100 in slave parallel mode. Back "then", external serial config. memory price was outrageusly high. Besides, by keeping all inside the main micro, I now can remote upgrade my FPGA code very very easily. To free some more Kb for a new requirement, I compressed the bit-stream with a simple LZW implementation, and decompressed on the fly before sending to FPGA. Here are some results from a real design. Starting from uncompressed design BIN file: CAMERA.BIN: 107980 bytes LZW compression with different "dictionary table" bit length: BIT SIZE 10 73853 11 63283 12 61442 13 58012 14 56803 Same design, but BIN file has been compressed by ISE: CAMERA_COMP.BIN 97944 (what I was using before; leaved 30 Kb for my app. code) After LZW compression: BIT SIZE 10 73475 11 65442 12 62865 13 58795 14 57687 As expected, you get slightly better results starting from uncompressed BIN stream, when using simple compression algorithms. Even after adding code decompression, I saved tens of flash Kb to implement more features at no cost. Initial configuration has slowed down, of course: before I was pumping out data to FPGA as fast as possible with string move assembly instructions. Now I have to decompress on the fly. Times stays in the hundreds of ms range, tough. RAM USAGE during decompression: from bit width of string table, you define the table size this way (smaller prime number larger than 2^bits): BITS TABLE SIZE 14 18041 13 9029 12 5021 11 2053 <= 10 1031 During decompression, you will need 3*TABLE_SIZE bytes + a decode buffer; decode buffer size can be in the 2000-4000 bytes range. Yes, it's big. But...given that FPGA programming is the first thing I do at startup, I can use up to all the M16C RAM available; after FPGA programming, all that ram is available again for my code. Even much less, with some checks during compression. I used a slightly modified version of the code for LZW compression published by Mark. Nelson on DDJ, Oct. 89. Google found a copy of the article here: http://www.dogma.net/markn/articles/lzw/lzw.htm Please, post your results if you tested for have different implementations!
Reply by ●June 19, 20042004-06-19
"John Larkin" <jjlarkin@highSNIPlandTHIStechPLEASEnology.com> escribi� en el mensaje news:hh34d0tud78se5vqejirkc2bvufbd8io3d@4ax.com...> > Forgive me if this has been asked before, but does anybody have > comments or links to simple methods of compressing/decompressing > Xilinx configuration bitstreams? I've been perusing a few of my .rbt > files, and they have long bunches of 1s and 0s (interestingly, > different designs seem to have more 1s, others mostly 0s.) I'd think > that something very simple might achieve pretty serious (as, maybe > 2:1-ish) compression without a lot of runtime complexity. We generally > run a uP from EPROM, with the uP code and the packed Xilinx config > stuff in the same eprom, with the uP bit-banging the Xilinx FPGA at > powerup time. So a simple decompressor would be nice. > > I did google for this... haven't found much. >try searching for RLE (run length encoding) that's the encoding used for .PCX graphic files> Thanks, > > John >
Reply by ●June 19, 20042004-06-19
John Larkin <jjlarkin@highSNIPlandTHIStechPLEASEnology.com> wrote:> >Forgive me if this has been asked before, but does anybody have >comments or links to simple methods of compressing/decompressing >Xilinx configuration bitstreams? I've been perusing a few of my .rbt >files, and they have long bunches of 1s and 0s (interestingly, >different designs seem to have more 1s, others mostly 0s.) I'd think >that something very simple might achieve pretty serious (as, maybe >2:1-ish) compression without a lot of runtime complexity. We generally >run a uP from EPROM, with the uP code and the packed Xilinx config >stuff in the same eprom, with the uP bit-banging the Xilinx FPGA at >powerup time. So a simple decompressor would be nice. > >I did google for this... haven't found much.Tried it but found the files aren't reduced in size much and more important, the software required to decompress the file eats away all the savings for a 400k device. In other words: Unless you have more than around half a million gates of configuration data, it's not worth it. -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nl
Reply by ●June 19, 20042004-06-19
On Sat, 19 Jun 2004 15:27:40 GMT, nico@puntnl.niks (Nico Coesel) wrote:>John Larkin <jjlarkin@highSNIPlandTHIStechPLEASEnology.com> wrote: > >> >>Forgive me if this has been asked before, but does anybody have >>comments or links to simple methods of compressing/decompressing >>Xilinx configuration bitstreams? I've been perusing a few of my .rbt >>files, and they have long bunches of 1s and 0s (interestingly, >>different designs seem to have more 1s, others mostly 0s.) I'd think >>that something very simple might achieve pretty serious (as, maybe >>2:1-ish) compression without a lot of runtime complexity. We generally >>run a uP from EPROM, with the uP code and the packed Xilinx config >>stuff in the same eprom, with the uP bit-banging the Xilinx FPGA at >>powerup time. So a simple decompressor would be nice. >> >>I did google for this... haven't found much. > >Tried it but found the files aren't reduced in size much and more >important, the software required to decompress the file eats away all >the savings for a 400k device. In other words: Unless you have more >than around half a million gates of configuration data, it's not worth >it.OK, bear with me on this. Here's a piece of a .rbt for a Spartan XL... 01111111111111111111111111111111111111111111111111111111111011111111111111111111111111110111111110111111011111111110111111110101011101111110111111011111111111111111110011111111111111111111111111111111111111111111111111111110101 01111111111111111111111111111111111111111111111111111111111111111111111111111101111111111111111111111111110111111101111111111111111110111111111111110111111111111011111101111111111111111111111111111111111111111111111111111110011 01111111111111111111111111111111111111111111111111111100011111111111111111101111111100111111110011111111111111011101111111111100111011110011111011111111111111111111111110110111001111111111111111111111110111111011111111111111011 01111111111111111111111111111111111111111111111111111111011111111111111111101111111101011111111110011111111111111100111111111111011111111101111111111111111111110111101111111111110111111111111111111111111111111111111111111111110 01111111111111111111111111111111111111111111110111111111111111111111111111111111111111111111111011111111111111111011010111111110011111111011111111111011111011111011110101111111000111111111011111111111101111111111111110101101111 00111111111111111111111111111111111111111111000111111111111111111111111111111111111111111111111111111111110111111111110110111111011111111111111111111101111111111111111101111111110111111100011111111111111111111111111101101100000 01111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111110111111111101110111101011111111111111111111111111111111111111101111111101111111111111111111111111111111111111110111111100 00011111111111111111111111111111111111111111111111111111111100111111011111111111001111110110101111001111111101111111111111001111111100111111111001111101101011110110011111101010111101111111111111111111111010111100111111111111000 01101011111111111111111111111111111111111111111111111111111110101111111111111111101011111110011110111111110101001110111111101011011100111111111010010111001111110110101101111111111111111111111111111111110011111101111111010100111 01111011111111111111111111111111111111111111111111111111111111111111011111111111111111110111111111111111110110111111111111101011011111111111111111111101111111111111111101111111111101111111111111111111111111111111111111011111010 01101111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111110011111111111111111111111111111111111111111001111111111111111110111111111111111111111111111111111111111111111111100111110011000 01111111111111111111111111111111111111111111111111111111111011111111101111111110111111111011111111101111011110111111111110111101111001101111101111111110101011111011010111101111111110111111101111111111111111111110111111110100011 01101111111111111111111111111111111111111111111011111111111111111111111111111111111111111111111111111111111101011010111111111111110111101111111111111101011011111111111111011110111111111111111111111111111111111111111111111110101 00111100111111111111111111111111111111111111111011111111110100111111100011111101001111111000111111111111111110101011111101101011110010011111011011111111101011110110101111010001111110111111111111111111111111111101111100111110111 Where there are lots of 1's. Other hunks of this file are almost all 1's. So what we need is a not-very-general compression scheme, with the only "dictionary" entry being "the following is a hunk of 1's". So the decompressor could be very simple. Interestingly, this is for a Spartan 2: 00000000000001001000000000000000 00000000000000000000000000000000 00000000000100100000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000001001000000000000000 00000000000000000000000000000000 00000000000100100100000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000001001100000000000000 00000000000000000000000000000000 11111111000100110000000100000100 00000000010001000000000000010000 00000000000001110100100000000000 11010100000000000011010000000000 00000001000000000000000000001000 00111111110001000000000000000000 Which has long runs of zeroes! Just eyeballing these files, it looks like something very simple could get at least a 2:1 squash factor. John
