Performance depends on various factors
The compression ratio and decompression speed of emCompress are dependent on various factors and may vary in each case.
The main speed factors are:
- The data to be compressed
- The data size and redundancy
- The compression codec
- The decompression workspace size
The amount of ROM that the embedded compression solution emCompress is using for decompression, varies with the codec selected. The table below measures the total ROM required for a single decoder, including all supporting functions and excluding integrity checks on the target device.
Some of the codecs share common code. Hence, if your compressed bitstreams only use DEFLATE, the amount of ROM required is easily read off from the table. If you are using more than one codec in your application, the amount of ROM is less than the sum of the used codecs.
Adding a table-driven CRC32 integrity check adds about 1.1 KB of code to the total emCompress ROM requirement. The following table lists the ROM requirements per codec.
The amount of RAM that emCompress uses is under complete control as it is specified at compression time. Typically, 2KB of temporary RAM for decompression already yield good compression ratios, but even without temporary RAM, good compression ratios can be achieved in many cases. No static RAM is required, stack usage is well below 512 bytes.
Decompressing and Processing Data
emCompress features two decompression functions.
The first one is decompression into memory. The complete data is decompressed and stored in a user-provided memory buffer. Although the buffer can be temporary, this requires to have enough free memory for the complete uncompressed data and the workspace. Decompression into memory can for example be useful for dynamic firmware images. The second function is decompression in streamed mode. emCompress will use a small temporary buffer whose size is set by the user when compressing. Once a fragment of data is decompressed and the buffer is filled, the user-provided output function is called and the next buffer filled again with the next fragment. Sreamed decompression is particularly effective for programming FPGAs or serving web content. To process our bitstream and send it to the FPGA, we do not have to do this in one go. So we can choose decompression in streamed mode and send the data fragment by fragment in the output function. We do not have to have free RAM for the complete decompressed bitstream (112 kByte) and can simply pass our output function FPGA_SendData() to the decompressor. To see how this is done and how easy emCompress is to use, look at the example application below. Decompression is not as fast as copying data or calling an output function directly, but for large data, which is processed once in a while, like a one-time setup of the FPGA while booting, the advantage of less space is more important than the time taken to decompress. The emCompress codecs are highly optimized to achieve fast speeds. Like the compression ratio, the decompression speed is dependent on various factors, like the data to be decompressed, the chosen codec and the temporary buffer size, and can vary. We decompressed our bitstream and calculated a checksum in the output function (without sending data to the FPGA) in 36 ms.