1
\$\begingroup\$

Page 39 of UG161 talks about compression/decompression and implies that either bitgen or prom compression can be used to shorten the config bit stream size. Most importantly I need to know whether, when using the bitgen compression option this means that I need to use the CLKOUT pin for FPGA configuration as described by UG161 pg 62.

Originally I was trying to load 2 revisions of my design onto one PROM device, however Impact reported that the bit file was too big. After using the bitgen compression option, my bit file was smaller and 2 designs were able to fit on the PROM. However, the Xilinx documentation is unclear as to whether using the bitgen option means that I must use the PROM CLKOUT or not, as pg 39 seems to imply there is a difference between this and PROM compression.

UG161 can be found here http://www.xilinx.com/support/documentation/user_guides/ug161.pdf

I am working with Spartan-6 series XC6SLX45T FPGA and XCF16P PROM if that helps. The tools I'm using are Xilinx ISE 13.4, both the command line and IMPACT.

\$\endgroup\$
  • \$\begingroup\$ You might want to link to the document you are referring to \$\endgroup\$ – PlasmaHH Mar 15 '17 at 22:55
  • \$\begingroup\$ You should also tell us what FPGA family you're working with. \$\endgroup\$ – duskwuff Mar 15 '17 at 23:37
0
\$\begingroup\$

It seems like PROM compression is intended for FPGAs that do not support bitstream compression.

When PROM compression is used, the bitstream will be decompressed in the PROM before being sent to the FPGA. In this case, the PROM does the 'heavy lifting' of decompressing the bitstream, and it takes the same amount of time to shift out the compressed bitstream as it would for an uncompressed bitstream. You're also restricted to using Xilinx configuration PROMs that support decompression. Encrypted bitstreams cannot be compressed with PROM compression as encryption will scramble any parts that could have been compressed.

When bitstream compression is used, the bitstream will be decompressed at the FPGA. In this case, the PROM operates normally, and the FPGA does the 'heavy lifting' of decompressing the bitstream, and you do get a load time advantage as fewer bits get transferred over the relatively slow serial link from the PROM. In this case, you can use any configuration flash chip as you don't need the specialized decompression functionality. I believe bitstream compression can also be used on encrypted bitstreams as the compression can be applied before encryption, though this will definitely be device-dependent (seems to be supported on Virtex 6 and 7 series, but not on Spartan 6).

The thing to note is that so long as you don't use PROM compression, the PROM can't tell the difference between a compressed bitstream and a normal bitstream, so you don't need to follow any of the design guidelines specifically for PROM compression.

tl;dr: only use PROM compression if the FPGA does not support bitstream compression; bitstream compression at the FPGA is a more flexible and more powerful option.

\$\endgroup\$
  • \$\begingroup\$ Thanks for the reply, can you point me to a reference source to verify this or is this what you have inferred from reading UG161 or personal experience? \$\endgroup\$ – Billy M Mar 16 '17 at 0:03
  • \$\begingroup\$ Personal experience, but more from reading lots of Xilinx documentation than actually using compressed bitstreams. \$\endgroup\$ – alex.forencich Mar 16 '17 at 0:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.