Microsoft Technology Licensing, LLC

Michael J Erickson

Derek E Gladding

Amar Vattakandy

Robert W Havlik

Data compression schemes may indicate the length of the compressed data block in a header or in the compressed data itself. If the start and end of the data block are known before the decoding process has completed by the decoding stage, a header processing stage can 'skip ahead' to the start of the next block to begin processing the header of the next block while the current block is still being decoded. Thus, the header processing stage and the decoding stage are operated concurrently. If the end of the compressed block is indicated in the compressed data itself the end of the data block is not known until the end of the compressed data block is reached. For these types of compressed data blocks, the header processing stage waits until the decoding stage finishes with the preceding block before processing the header of the current block.

Multi-format pipelined hardware decompressor

Decompressing sliding window compressed data requires reference to previously decompressed character sequences. Previously decompressed data is stored in a history buffer to satisfy these 'back references.' As each decompressed/decoded character is emitted, it is stored in this history buffer. Thus, for each decompressed character that is emitted, the history buffer may need to be accessed at least twice&#x2014;once to retrieve the backreference, and once to store the emitted character. A pipeline architecture is disclosed that stores decompressed characters in a write queue that coalesces eight or more emitted characters before they are stored in the history buffer memory. This reduces collisions between accessing the history buffer memory to retrieve the backreferences and the storing of the emitted character. This also allows the use of a single-ported memory which is less expensive than a multi-ported memory.

Pipelined decompression of sliding window compressed data

In some data compression algorithms and/or standards, the compressed data comprises variable length symbols. A set of parallel decoders speculatively decode/decompress a window (i.e., sub-block) of data. Each of the decoders attempts to decode/decompress a symbol that starts at a different location in the compressed data block. Once the decoders have finished decoding a symbol (or determined that a valid symbol does not begin at the beginning of the window assigned to that decoder), a symbol strider selects the decoder outputs corresponding to valid symbols. The symbol strider successively selects decoder outputs based on the size of the previous symbols that were found to be valid. When the next valid symbol begins outside the current window, its location is stored to indicate the location of the next valid symbol in a subsequent window.

Multi-symbol, multi-format, parallel symbol decoder for hardware decompression engines

To decompress encoded data, a Huffman code tree stored in a data header may need to be decompressed and rebuilt. A bit length histogram table is used in a hardware design to more efficiently decompress the Huffman code tree. The bit length histogram table relates each bit length used by the Canonical Huffman Code (CHC) symbols to a corresponding number of symbols in the encoding that have that bit length. Performing decompression using bit length histogram table allows part of the Huffman tree decompression to be performed in a single pass.

Growing community of inventors

Fort Collins, CO, United States of America

Michael J Erickson