Low latency decompressor

Abstract

The invention relates to a low latency decompressor. An example method of low latency decompression includes receiving a data read request to read data stored in a memory in a compressed storage format; and in response to receiving a data read request, accessing the compressed data sequence, dividing the compressed data sequence into three separate streams for parallel processing, the three separate streams including (i) a text stream, (ii) a historical cache stream, and (iii) a historical buffer stream, for each data sequence in the text stream, determining a text decompression block offset for the data sequence, for each data sequence in the historical buffer stream, a decompression block offset for each data sequence in the historical buffer stream is determined using one or more historical cache pointers associated with the data sequence, and for each data sequence in the historical buffer stream, a decompression block offset is determined via the historical buffer, and generate a data output in response to the data read request.

Description

[0001] Cross-reference of related applications

[0002] This application claims the benefit of U.S. Provisional Application No. 63 / 657,103, filed June 6, 2024. The entire disclosure of that application is incorporated herein by reference. Technical Field

[0003] This disclosure relates to low-latency decompressors. Background Technology

[0004] The background description provided herein is intended to generally present the context of this disclosure. The work of the currently named inventors, to the extent described in the background section and in aspects that may not otherwise be described as prior art at the time of filing, is neither expressly nor impliedly acknowledged as prior art to this disclosure.

[0005] Data can be stored in memory in a compressed format to save storage space, such as the LZ4 compression format, where repeating patterns in the data are encoded as matches. In a series of compressed data sequences, matches are encoded using the match length and relative offset associated with previous data. Summary of the Invention

[0006] An example of a low-latency decompression method includes: receiving a data read request to read data stored in a memory in a compressed storage format; and in response to receiving the data read request, accessing a compressed data sequence corresponding to the data stored in the compressed storage format, dividing the compressed data sequence into three separate streams for parallel processing, the three separate streams including: (i) a literal stream, (ii) a history cache stream, and (iii) a history buffer stream; for each data sequence in the literal stream, determining a literal decompression block offset for the data sequence, and writing decompressed output data from the data sequence to a combined buffer; for each data sequence in the history cache stream, determining a decompression block offset using one or more history cache pointers associated with the data sequence, and writing decompressed output data from the data sequence to the combined buffer; for each data sequence in the history buffer stream, determining the decompression block offset via a history buffer, and writing decompressed output data from the data sequence to the combined buffer, and generating data output in response to the data read request based at least in part on data stored in the combined buffer.

[0007] In some examples, a literal stream comprises a sequence of raw bytes containing data without back reference pointers, a history cache stream comprises a sequence of data containing back reference pointers less than a specified threshold number of bytes preceding the first byte of the data sequence, and a history buffer stream comprises a sequence of data containing back reference pointers greater than a specified threshold number of bytes preceding the first byte of the data sequence.

[0008] In some examples, for each data sequence in the text stream, determining the text decompression block offset of the data sequence includes processing the raw bytes of the data in a path from the combined buffer to the data output.

[0009] In some examples, the method includes updating a history buffer that includes decompressed block offsets, wherein determining the decompressed block offsets via the history buffer includes reading one or more decompressed block offsets from the history buffer.

[0010] In some examples, the method includes maintaining a history cache of bytes associated with a sequence of data from the history cache stream, wherein generating data output includes merging data from the history cache with a processed sequence of data from the literal stream and the history buffer stream.

[0011] In some examples, the method includes: identifying one or more relative history pointers associated with each individual data sequence in the historical cache stream; and resolving each of the one or more relative history pointers to an absolute pointer, the absolute pointer referencing a data byte preceding the first byte of the individual data sequence.

[0012] In some examples, resolving each of one or more relative history pointers involves resolving the different pointers in one or more relative history pointers at different clock cycles while processing the history cache stream.

[0013] In some examples, parsing each of the one or more relative history pointers includes parsing all of the one or more relative history pointers associated with a separate data sequence in less than or equal to eight clock cycles.

[0014] In some examples, the method includes: allocating a data sequence to a historical cache stream in response to a reverse reference pointer of the data sequence being less than a specified threshold number of bytes preceding the first byte of the data sequence; and allocating the data sequence to a historical cache stream in response to a reverse reference pointer of the data sequence being greater than a specified threshold number of bytes preceding the first byte of the data sequence.

[0015] In some examples, the specified threshold byte count is 128 bytes preceding the first byte of the data sequence. In some examples, each of the literal stream, history cache stream, and history buffer stream is allocated guaranteed write bandwidth to the combined buffer. In some examples, the combined buffer comprises at least sixteen memories, and each of the at least sixteen memories comprises at least seven write ports.

[0016] In some examples, the method includes maintaining a history cache of bytes associated with a sequence of data from a history cache stream, wherein the history cache includes a multiplexer for selecting any byte in the history cache.

[0017] In some examples, for each of the at least sixteen memories, at least one of the at least seven write ports is configured to write data from a literal stream, at least two of the at least seven write ports are configured to write data from a history cache stream, and at least four of the at least seven write ports are configured to write data from a history buffer stream.

[0018] In some examples, the compressed data sequence is stored in memory in LZ4 compression format. In some examples, the combined buffer includes at least one of a multi-port trigger data structure or a latch array data structure. In some examples, generating data output includes generating data output at an output rate of at least 30 gigabytes per second.

[0019] An exemplary low-latency decompressor includes: a memory configured to store data in a compressed storage format; a combination buffer configured to store decompressed block offsets associated with a data sequence; a history buffer configured to store bytes associated with a data sequence for reading during processing of a history buffer stream; a history cache configured to store bytes associated with a data sequence from a history cache stream; and at least one processor configured to receive a data read request to read data stored in the memory, and in response to the data read request, access a compressed data sequence stored in the memory and corresponding to the data read request, and divide the compressed data sequence into three separate streams for parallel processing, the three separate streams including a text stream, a history cache stream, and the history buffer stream. The historical cache stream, for each data sequence in the text stream, determines a text decompression block offset for the data sequence and writes decompressed output data from the data sequence into a combined buffer. For each data sequence in the historical cache stream, it uses one or more historical cache pointers associated with the data sequence to determine a decompression block offset and writes decompressed output data from the data sequence into the combined buffer. For each data sequence in the historical cache stream, it determines the decompression block offset via the historical cache and writes decompressed output data from the data sequence into the combined buffer, and generates data output in response to the data read request based at least in part on the data stored in the combined buffer.

[0020] In some examples, a literal stream comprises a sequence of raw bytes containing data without back reference pointers, a history cache stream comprises a sequence of data containing back reference pointers less than a specified threshold number of bytes preceding the first byte of the data sequence, and a history buffer stream comprises a sequence of data containing back reference pointers greater than a specified threshold number of bytes preceding the first byte of the data sequence.

[0021] In some examples, for each data sequence in the text stream, determining the text decompression block offset for the data sequence includes processing the raw bytes of the data in a path through the combined buffer to the data output.

[0022] In some examples, the at least one processor is configured to update a history buffer including decompressed block offsets, wherein determining the decompressed block offsets via the history buffer includes reading one or more decompressed block offsets from the history buffer, and maintaining a history cache of bytes associated with a data sequence from the history cache stream, wherein generating the data output includes merging data from the history cache with a processed data sequence from the text stream and the history buffer stream.

[0023] In some examples, the at least one processor is configured to identify one or more relative history pointers associated with each individual data sequence in the history cache stream, and to resolve each of the one or more relative history pointers to an absolute pointer that references a data byte preceding the first byte of the individual data sequence.

[0024] In some examples, the at least one processor is configured to assign a data sequence to the historical cache stream in response to a reverse reference pointer of the data sequence being less than a specified threshold number of bytes preceding the first byte of the data sequence, and

[0025] In response to a specified threshold number of bytes preceding the first byte of the data sequence in the reverse reference pointer of the data sequence, the data sequence is allocated to the history buffer stream.

[0026] In some examples, the combined buffer includes at least sixteen memories, each of which includes at least seven write ports, the history cache includes a multiplexer for selecting any byte in the history cache, and the combined buffer includes at least one of a multi-port trigger data structure or a latch array data structure.

[0027] In some examples, the compressed data sequence is stored in memory in LZ4 compression format, and generating data output includes generating data output at an output rate of at least 30 gigabytes per second.

[0028] Other areas of application of this disclosure will become apparent from the detailed description, claims, and accompanying drawings. The detailed description and specific embodiments are for illustrative purposes only and are not intended to limit the scope of this disclosure. Attached Figure Description

[0029] Figure 1 This is a block diagram of an exemplary low-latency decompressor.

[0030] Figure 2 This is a flowchart illustrating an exemplary process for decompressing stored data in response to a data read request.

[0031] Figure 3 This is a block diagram of an example sequence of compressed data, including text blocks and matching offset blocks.

[0032] Figure 4 It is a block diagram of an example sequence of compressed data, including pointers to other blocks within the compressed data sequence.

[0033] Figure 5It is a block diagram of an example sequence of compressed data bytes that are already in the history and bytes that are not directly referenced from the history.

[0034] Figure 6 This is a flowchart illustrating an example process for decompressing data via a parallel stream that includes a text stream, a history cache stream, and a history buffer stream.

[0035] Figure 7 This is a flowchart illustrating an example process for resolving relative history pointers to decompress stored data.

[0036] In the accompanying drawings, reference numerals may be used repeatedly to identify similar and / or identical elements. Detailed Implementation

[0037] Data can be stored in memory in a compressed format to save storage space, such as LZ4 compression, where repeating patterns in the data are encoded as matches. In a series of compressed data sequences, matches are encoded using a match length and relative offset associated with previous data. Some software decompressors are configured to traverse the encoding format and reconstruct the original file byte by byte. Some hardware decompressors can be configured to process more than one byte at a time, but cannot process more than one match at a time in a compressed data sequence.

[0038] In some examples, low-latency decompressors are configured to achieve high parallelism when decompressing input data streams stored in compressed data formats such as LZ4 compression. For example, a compressed data sequence may be split into three separate streams for processing: a literal stream of the compressed data sequence that does not include any lookup pointers, a history buffer stream of the compressed data sequence that includes lookup pointers that can be read from a history buffer of bytes (e.g., when the reverse reference pointer is greater than a threshold number of bytes preceding the first byte of the data sequence), and a history cache stream of the compressed data sequence that includes lookup pointers processed using the history cache (e.g., when the reverse reference pointer is less than a threshold number of bytes preceding the first byte of the data sequence).

[0039] Different data structures within a low-latency decompressor can have numerous access ports to facilitate a high level of parallelism when processing different streams of compressed data sequences. History caches can be configured to resolve history cache pointers, including pointers to earlier bytes within the same output word, with reduced or minimal latency. For example, a low-latency decompressor can achieve high average and peak output rates, such as at least 19.2 gigabytes per second once the input pipeline is filled, at least 36.9 gigabytes per second after the input pipeline is filled, at least 30.3 gigabytes per second if input pipeline latency is included in the processing time (e.g., for a 4-kilobyte output file), and a peak output rate of at least 38.4 gigabytes per second, etc. Other example embodiments may include other output rates.

[0040] Figure 1 This is a block diagram of an example low-latency decompressor 100. The low-latency decompressor 100 includes a parsing module 102 configured to parse a compressed data sequence at its input. For example, the parsing module 102 may be configured to read compressed input data stored in memory in LZ4 compression format and parse the compressed data sequence into three parallel processing streams.

[0041] The text processing stream 104 can be configured to process a sequence of text data that does not contain any reference pointers to other data blocks in the same or other data sequences. For example, the text processing stream 104 can be configured to process the raw bytes of the data and store the decompressed blocks in the combination buffer 110.

[0042] The history cache processing stream 106 can be configured to process data sequences that include reference pointers less than a threshold number of bytes preceding the first byte of the data sequence. For example, if the input data sequence includes pointers less than 128 bytes preceding the first byte of the input data sequence (or, in other examples, a threshold of more or less bytes), the history cache 116 can be used to process the input data sequence because the data block referenced by the pointers is not yet available in the history buffer 118.

[0043] The history buffer processing stream 108 can be configured to process data sequences that include reference pointers greater than a threshold number of bytes preceding the first byte of the data sequence. For example, if the input data sequence includes a pointer greater than 128 bytes preceding the first byte of the input data sequence (or a threshold of more or less than 128 bytes in other examples), the input data sequence can be processed by reading data from a block already stored in the history buffer 118 referenced by the pointer.

[0044] The combined buffer 110 can be configured to receive decompressed data blocks from the text processing stream 104, the history cache processing stream 106, and the history buffer processing stream 108. For example, each of the text processing stream 104, the history cache processing stream 106, and the history buffer processing stream 108 can be configured to move the data sequence forward independently of each other. Each of the text processing stream 104, the history cache processing stream 106, and the history buffer processing stream 108 can determine the correct decompressed block offset for its output data and then write the output data into the combined buffer 110.

[0045] Data structures within the low-latency decompressor can utilize multi-port trigger arrays, latch arrays, etc., to provide higher throughput, increased parallelism, and lower latency (e.g., compared to random access memory at high clock frequencies). The combined buffer 110 can be write-intensive, while history structures such as history cache 116 and history buffer 118 are read-intensive.

[0046] In some examples, the combined buffer 110 may contain sixteen memory banks, each with seven write ports (e.g., one byte wide) to define a massively parallel write structure. In addition to the seven write ports, each memory bank may include one read port. The history buffer 118 may include two memory banks, each with two 16-byte wide read ports and one write port.

[0047] History cache 116 may include a 16-byte-wide write port and 16 read ports, each 1 byte wide, to define a massively parallel read structure. For example, history cache 116 may operate similarly to a 144:1 multiplexer to allow selection of any byte within history cache 116. Other examples may include more or fewer memory banks, more or fewer read and write ports, more or fewer bytes per read or write, etc., for each of the combined buffers 110, history buffer 118, and history cache 116.

[0048] Different write ports of the combined buffer 110 can be assigned to receive data from different of the text processing stream 104, the history cache processing stream 106, and the history buffer processing stream 108. In an example of the combined buffer 110 having 16 separate 1-byte-wide trigger arrays, each trigger array has 7 write ports, one of which can assist the text processing stream 104, two of which can be assigned to the history cache processing stream 106, and four of which can be assigned to the history buffer processing stream 108.

[0049] The text processing stream 104 and the history cache processing stream 106 can be divided into 16 independent single-byte channels, each with dedicated write bandwidth into its corresponding combined buffer channel (lane). This facilitates per-byte channel addressing to simplify data round-robin. Each history buffer read response channel can be assigned its own port. For example, allowing each read channel to write up to 16 bytes of matching data to the combined buffer 110 with arbitrary data round-robin can allow for very fast execution of long matches. This can be useful if the sequence following a long match is a short match that requires more processing time.

[0050] While the text processing stream 104 and the history cache processing stream 106 can be easily pipelined, the processing within the combination buffer 110, the history cache pointer resolution module 112, and the history cache data merging 114 can be completed within a timeframe determined by the capacity of the history cache 116. For example, the more pipeline stages added outside of the text processing stream 104 and the history cache processing stream 106, the deeper the history cache 116 needs to be to cover the additional latency. Fast resolution of the final pointer in the history cache pointer resolution module 112 may be important because the history cache 116 cannot be arbitrarily deepened without reducing the clock frequency.

[0051] Regarding the history cache processing stream 106, within each individual sequence, each relative history pointer can be resolved to an absolute pointer, which points to the data byte preceding the first byte of the sequence. In the history cache pointer resolution module 112, worst-case pointer resolution in the most time-sensitive parts of the design can be simplified. Instead of resolving pointers byte-by-byte, the only remaining uncertainty can be across sequences. In some examples, each sequence can be at least four bytes long, thus allowing the entire sixteen-byte output to be resolved with a small number of iterations.

[0052] For example, the history cache pointer resolution module 112 can be configured to use one or more layers of iterative mathematics to resolve relative pointers to resolve any remaining pointers across multiple data sequences (e.g., multiple data sequences in an LZ4 compressed format that include relative pointers). Because LZ4 sequences can be as small as 4 bytes, for example, a 16-byte output bus, the history cache pointer resolution module 112 can be configured to resolve up to four cross-sequence references in each tick of the output data.

[0053] Figure 2This is a flowchart illustrating an exemplary process for decompressing stored data in response to a data read request. At 204, the process begins by receiving raw data to be written to memory in a storage device. At 208, the process performs a compression operation on the raw data. For example, the raw data may be compressed into an LZ4 compression format.

[0054] At 212, the process stores compressed data in memory. Then, at 216, the process waits to receive a data read request associated with the stored compressed data. Once a data read request is received at 216, at 220, the process performs a decompression operation on the stored data. Then, in response to the received read request, the decompressed data is returned at 224.

[0055] While some compression / decompression algorithms focus on storage optimization and are implemented in software (e.g., GZIP, ZLIB, etc.), there is increasing interest in high-speed, low-latency compression / decompression for storage devices, memory expansion, and networking. For example, decompression rates can exceed 200 Gbps per engine. In these cases, simpler algorithms may suffice, such as the LZ4 data compression format for storing compressed data. For instance, Iliad is a CXL memory expander product where compressed data is stored in DRAM, while expanded data is stored in a last-level cache.

[0056] Figure 3 This is a block diagram of example sequence 300 of compressed data, including text blocks and matching offset blocks. The LZ4 data compression format is a simple byte-oriented dictionary algorithm and is part of the LZ77 family. The LZ4 data compression format is designed to provide a good trade-off between speed and compression ratio. For example, the LZ4 compression format does not require Huffman or arithmetic coding after a history search.

[0057] A compressed block consists of a series of LZ4 sequences, each sequence describing a set of “texts” (which can have a minimum length of zero bytes) and matches (which can have a minimum length of four bytes). Figure 3 The diagram illustrates a text block 302 with a length of four bits and a matching block 304 with a length of four bits. Text block 302 and matching block 304 can define token bytes. Figure 3 Example sequence 300 includes a literal byte 306 with an eight-bit length, another literal byte 310 with an eight-bit length, and a matching offset 312 with a sixteen-bit length.

[0058] Figure 4This is a block diagram of an example sequence 400 of compressed data, including pointers to other blocks within the compressed data sequence. In some examples, the LZ4 algorithm may not output decompressed data until it finds the first match. The algorithm can produce potentially short four-byte matches, which are difficult to process quickly. The algorithm may need to iteratively parse the compressed data stream byte by byte. For literal lengths greater than 14, or match lengths greater than 18, the length can be extended to 255 using bytes other than the token. This may be a simple scheme for software loops, but may produce undesirable ripple for hardware processing.

[0059] In example sequence 400, the number of literals is 0xF + ​​0xFF + 0x3 = 273 bytes. For example, the first literal block 402, the second literal block 406, and the third literal block can be added together to specify the number of bytes. Matching block 404 is located between the first literal block 402 and the second literal block 406.

[0060] Example sequence 400 includes a match offset of 418. The match length is 0x4 + 0xF + ​​0xFF + 0xFF + 0x6 = 535 bytes. For example, the first match offset block 420, the second match offset block 422, and the third match offset block 424 can be located after match offset 418.

[0061] Figure 5 This is a block diagram of an example sequence 500 of compressed data bytes already in the history and bytes not directly referenced from the history. The history-based algorithm allows for a match length greater than the match offset. When receiving the sequence, some data may not be directly available in the history, which could introduce another ripple problem to be addressed.

[0062] In example sequence 500, when the sequence is received, bytes 502, 504, 506, and 508 are already in the history. History write pointer matching can be processed as returning three bytes of length five. In example sequence 500, the last bytes 516 and 518 can be directly referenced from the history. Figure 3 , 4 The design challenges in the example sequences of 5 and 6 can be addressed using the example hardware processing architectures described here, such as... Figure 1 The low-latency decompressor 100.

[0063] Figure 6 This is a flowchart illustrating an example process for decompressing data via a parallel stream comprising a text stream, a history cache stream, and a history buffer stream. At 604, the process begins by receiving a read request for stored compressed data. At 608, the process accesses a sequence of compressed data in memory corresponding to the received data read request.

[0064] In 612, the process splits the compressed sequence into three separate streams for parallel processing. For example, as described above, the compressed data sequence can be separated (e.g., parsed) into a text processing stream, a history cache processing stream, and a history buffer processing stream.

[0065] At 616, the process determines whether a text stream block is being processed. If so, the process proceeds to 620 to determine the text decompression block offset for the text block. If the data sequence at 616 is not a text stream block, the process at 624 determines whether the input data sequence is a historical cache stream sequence.

[0066] If the input data sequence at 624 is a history cache stream sequence, the process proceeds to 628 to determine the decompression block offset using the history cache pointer. At 624, if the input data sequence does not belong to the history cache processing stream, then at 632, the process uses the history buffer to determine the decompression block offset. Based on parsing the input data sequence of compressed data into the corresponding text processing stream, history cache processing stream, or history buffer processing stream, steps 616, 624, and 632 can operate independently and in parallel.

[0067] At 636, the process writes the decompressed output data to a combination buffer, such as combination buffer 110. Writing the decompressed output data to the combination buffer may include writing data to a dedicated write port of the combination buffer assigned to each data processing stream. At 640, the process returns the decompressed data in response to a data read request.

[0068] Figure 7 This is a flowchart illustrating an example process for resolving relative history pointers to decompress stored data. At 704, the process receives a first individual sequence from the history cache processing stream. At 708, the process identifies the relative history pointers for the individual sequence.

[0069] At 712, the process resolves each relative history pointer to an absolute history pointer, which references a data byte preceding the first byte of a separate data sequence. For example, the history cache pointer resolution module can be configured at 712 to use one or more layers of iterative mathematics to resolve relative pointers to resolve any remaining pointers across multiple data sequences (e.g., multiple data sequences in an LZ4 compressed format that include relative pointers). Because LZ4 sequences can be as small as 4 bytes, for example, a 16-byte output bus, the history cache pointer resolution module can be configured to resolve up to four cross-sequence references in each tick of the output data.

[0070] At 716, the process determines whether any sequences remain in the historical cache data processing stream. If an input sequence of unprocessed compressed data still exists at 716, control proceeds to 720 to receive the next individual sequence in the historical cache processing stream, and processing returns to 708 to identify the relative historical pointer of the next received individual sequence. Once all data sequences in the historical cache processing stream have been processed at 716, processing proceeds to 724 to return the decompressed data in response to a data read request.

[0071] The foregoing description is merely illustrative in nature and is in no way intended to limit this disclosure, its application, or use. The broad teachings of this disclosure can be implemented in various forms. Therefore, although this disclosure includes specific examples, its true scope should not be limited thereto, as other modifications will become apparent upon examination of the accompanying drawings, specification, and appended claims. It should be understood that one or more steps within the method may be performed in a different order (or simultaneously) without altering the principles of this disclosure. Furthermore, although each embodiment has been described above as having certain features, any one or more of those features described with respect to any embodiment of this disclosure may be implemented in and / or combined with features of any other embodiment, even if such combinations are not explicitly described. In other words, the described embodiments are not mutually exclusive, and substitutions of one or more embodiments for each other remain within the scope of this disclosure.

[0072] Various terms are used to describe spatial and functional relationships between elements (e.g., between modules, circuit elements, semiconductor layers, etc.), including “connection,” “joint,” “coupled,” “adjacent,” “closely adjacent,” “above,” “under,” and “set.” Unless explicitly described as “direct,” when describing a relationship between first and second elements in the foregoing disclosure, the relationship can be a direct relationship in which no other intermediary element exists between the first and second elements, or an indirect relationship (spatial or functional) in which one or more intermediary elements exist between the first and second elements. As used herein, the phrase at least one of A, B, and C should be interpreted as indicating a logic of non-exclusive OR (A or B or C) and should not be interpreted as indicating “at least one of A, at least one of B, and at least one of C.”

[0073] In the accompanying drawings, the direction of the arrows, as indicated by the arrows, typically represents the flow of information (e.g., data or instructions) of interest. For example, when elements A and B exchange various information, but the information sent from element A to element B is relevant to the illustration, the arrow may point from element A to element B. This unidirectional arrow does not imply that no other information is sent from element B to element A. Furthermore, regarding the information sent from element A to element B, element B may send a request for said information to element A or receive confirmation of said information.

[0074] In this application, including the following definitions, the term "module" or "controller" may be replaced by the term "circuit". The term "module" may refer to, or include, a subset of, the following: application-specific integrated circuits (ASICs); digital, analog, or mixed-signal analog / digital discrete circuits; digital, analog, or mixed-signal analog / digital integrated circuits; combinational logic circuits; field-programmable gate arrays (FPGAs); processor circuitry (shared, dedicated, or grouped) that executes code; memory circuitry (shared, dedicated, or grouped) that stores code executed by the processor circuitry; other suitable hardware components that provide the aforementioned functionality; or combinations of some or all of the above, such as in a system-on-a-chip.

[0075] The module may include one or more interface circuits. In some examples, the interface circuits may include wired or wireless interfaces connected to a local area network (LAN), the Internet, a wide area network (WAN), or a combination thereof. The functionality of any given module of this disclosure can be distributed among multiple modules connected via the interface circuits. For example, multiple modules can allow for load balancing. In another example, a server (also referred to as a remote or cloud) module may perform certain functions on behalf of a client module.

[0076] As described above, the term "code" can include software, firmware, and / or microcode, and can refer to programs, routines, functions, classes, data structures, and / or objects. The term "shared processor circuitry" includes a single processor circuitry that executes some or all of the code from multiple modules. The term "group processor circuitry" covers processor circuitry that, in combination with additional processor circuitry, executes some or all of the code from one or more modules. Reference to multiple processor circuitry includes multiple processor circuitry on a discrete die, multiple processor circuitry on a single die, multiple cores of a single processor circuitry, multiple threads of a single processor circuitry, or a combination of the above. The term "shared memory circuitry" includes a single memory circuitry that stores some or all of the code from multiple modules. The term "group memory circuitry" includes memory circuitry that, in combination with additional memory, stores some or all of the code from one or more modules.

[0077] The term "storage circuit" is a subset of the term "computer-readable medium." As used herein, the term "computer-readable medium" does not include transient electrical or electromagnetic signals propagating through a medium (e.g., on a carrier wave); therefore, the term "computer-readable medium" can be considered tangible and non-transitory. Non-limiting examples of non-transitory tangible computer-readable media include non-volatile memory circuits (e.g., flash memory circuits, erasable programmable read-only memory circuits, or mask read-only memory circuits), volatile memory circuits (e.g., static random access memory circuits or dynamic random access memory circuits), magnetic storage media (e.g., analog or digital magnetic tape or hard disk drives), and optical storage media (e.g., CDs, DVDs, or Blu-ray discs).

[0078] In this application, device elements described as having specific attributes or performing specific operations are specifically configured to have those specific attributes and perform those specific operations. Specifically, the description of an element performing an action means that the element is configured to perform the action. The configuration of an element may include programming the element, for example by encoding instructions on a non-transient, tangible, computer-readable medium associated with the element.

[0079] The apparatus and methods described in this application can be implemented, in part or in whole, by a special-purpose computer created by configuring a general-purpose computer to perform one or more specific functions contained in a computer program. The aforementioned functional blocks, flowchart components, and other elements serve as software specifications that can be translated into a computer program through the routine work of a skilled technician or programmer.

[0080] A computer program includes processor-executable instructions stored on at least one non-transient tangible computer-readable medium. A computer program may also include or depend on stored data. A computer program may include a basic input / output system (BIOS) for interacting with the hardware of a special-purpose computer, device drivers for interacting with specific devices of the special-purpose computer, one or more operating systems, user applications, background services, background applications, etc.

[0081] The computer program may include: (i) descriptive text to be parsed, such as HTML (Hypertext Markup Language), XML (Extensible Markup Language), or JSON (JavaScript Object Notation); (ii) composite code; (iii) object code generated from source code by a compiler; (iv) source code for execution by an interpreter; and (v) source code for compilation and execution by a just-in-time compiler, etc. As an example only, source code may be from languages ​​including C, C++, C#, Objective-C, Swift, Haskell, Go, SQL, R, Lisp, etc. Fortran, Perl, Pascal, Curl, OCaml, HTML5 (Hypertext Markup Language, Fifth Revision), Ada, ASP (Active Server Pages), PHP (PHP: Hypertext Preprocessor), Scala, Eiffel, Smalltalk, Erlang, Ruby, Visual Lua, MATLAB, SIMULINK and

Claims

1. A low-latency decompression method, the method comprising: Receive data read requests to read data stored in memory in a compressed storage format; as well as In response to receiving the data read request, Access the compressed data sequence corresponding to the data stored in the said compressed storage format. The compressed data sequence is divided into three separate streams for parallel processing, the three separate streams being (i) a text stream, (ii) a history cache stream, and (iii) a history buffer stream. For each data sequence in the text stream, a text decompression block offset for the data sequence is determined, and the decompressed output data from the data sequence is written into a combination buffer. For each data sequence in the historical cache stream, one or more historical cache pointers associated with the data sequence are used to determine the decompression block offset, and the decompressed output data from the data sequence is written into the combined buffer. For each data sequence in the history buffer stream, the decompression block offset is determined via the history buffer, and the decompressed output data from the data sequence is written into the combined buffer. Data output in response to the data read request is generated, at least in part based on the data stored in the combined buffer.

2. The method according to claim 1, wherein: The text stream includes a data sequence, which comprises raw bytes of data without a reverse reference pointer; The historical cache stream includes a data sequence, and the data sequence includes a reverse reference pointer that is less than a specified threshold number of bytes preceding the first byte of the data sequence; as well as The history buffer stream includes a data sequence, and the data sequence includes a reverse reference pointer that is greater than the specified threshold number of bytes preceding the first byte of the data sequence.

3. The method according to claim 1, wherein, For each data sequence in the text stream, the text decompression block offset for the data sequence is determined, including the raw bytes of the data processed in a path from the combined buffer to the data output.

4. The method of claim 3, further comprising updating a history buffer including decompressed block offsets, wherein determining the decompressed block offsets via the history buffer includes reading one or more decompressed block offsets from the history buffer.

5. The method of claim 4, further comprising maintaining a history cache of bytes associated with the data sequence from the history cache stream, wherein generating the data output includes merging data from the history cache with the processed data sequence from the text stream and the history buffer stream.

6. The method of claim 1, further comprising, for each individual data sequence in the historical cache stream: Identify one or more relative history pointers associated with the single data sequence; and Each of the one or more relative history pointers is resolved to an absolute pointer, the absolute pointer referencing the data byte preceding the first byte of the individual data sequence.

7. The method according to claim 6, wherein, Parsing each of the one or more relative history pointers includes parsing the different pointers in the one or more relative history pointers at different clock cycles during the processing of the history cache stream.

8. The method of claim 7, wherein parsing each of the one or more relative history pointers comprises parsing all relative history pointers of the one or more relative history pointers associated with the individual data sequence in less than or equal to eight clock cycles.

9. The method of claim 1, further comprising: In response to a reverse reference pointer of the data sequence being less than a specified threshold number of bytes preceding the first byte of the data sequence, the data sequence is allocated to the historical cache stream; as well as In response to the reverse reference pointer of the data sequence being greater than the specified threshold number of bytes preceding the first byte of the data sequence, the data sequence is allocated to the history buffer stream.

10. The method according to claim 9, wherein, The specified threshold number of bytes is the 128 bytes preceding the first byte of the data sequence.

11. The method according to claim 1, wherein, Each of the text stream, the history cache stream, and the history buffer stream is allocated guaranteed write bandwidth to the combined buffer.

12. The method according to claim 10, wherein: The combined buffer includes at least sixteen memories; and Each of the at least sixteen memories includes at least seven write ports.

13. The method of claim 12, further comprising maintaining a history cache of bytes associated with a data sequence from the history cache stream, wherein the history cache includes a multiplexer for selecting any byte in the history cache.

14. The method of claim 12, wherein for each of the at least sixteen memories: At least one of the at least seven write ports is configured to write data from the text stream; At least two of the at least seven write ports are configured to write data from the historical cache stream; and At least four of the at least seven write ports are configured to write data from the history buffer stream.

15. The method according to claim 1, wherein, The compressed data sequence is stored in memory in LZ4 compression format.

16. The method according to claim 1, wherein, The combined buffer includes at least one of a multi-port trigger data structure or a latch array data structure.

17. The method according to claim 1, wherein, Generating the data output includes generating the data output at an output rate of at least 30 gigabytes per second.

18. A low-latency decompressor, comprising: The memory is configured to store data in a compressed storage format; A combined buffer is configured to store decompressed block offsets associated with a data sequence; A history buffer is configured to store bytes associated with a data sequence for reading during the processing of the history buffer stream; The history cache is configured to store bytes associated with a sequence of data from the history cache stream; as well as At least one processor is configured to receive a data read request to read data stored in the memory, and in response to the data read request, Access the compressed data sequence stored in the memory that corresponds to the data read request. The compressed data sequence is divided into three separate streams for parallel processing, the three separate streams being a text stream, a history cache stream, and a history cache stream. For each data sequence in the text stream, a text decompression block offset for the data sequence is determined, and the decompressed output data from the data sequence is written into a combination buffer. For each data sequence in the historical cache stream, one or more historical cache pointers associated with the data sequence are used to determine the decompression block offset, and the decompressed output data from the data sequence is written into the combined cache. For each data sequence in the history buffer stream, the decompression block offset is determined via the history buffer, and the decompressed data output from the data sequence is written into the combined buffer. Data output in response to the data read request is generated, at least in part based on the data stored in the combined buffer.

19. The low-latency decompressor according to claim 18, wherein: The text stream includes a data sequence, which comprises raw bytes of data without a reverse reference pointer; The historical cache stream includes a data sequence, and the data sequence includes a reverse reference pointer that is less than a specified threshold number of bytes preceding the first byte of the data sequence; as well as The history buffer stream includes a data sequence, the data sequence including a reverse reference pointer to a specified threshold number of bytes preceding the first byte of the data sequence.

20. The low-latency decompressor according to claim 18, wherein, For each data sequence in the text stream, the text decompression block offset for the data sequence is determined, including the raw bytes of the data processed in a path from the combined buffer to the data output.

21. The low-latency decompressor according to claim 20, wherein, The at least one processor is configured to: The update includes a history buffer for decompressed block offsets, wherein determining the decompressed block offset via the history buffer includes reading one or more decompressed block offsets from the history buffer; and Maintaining a history cache of bytes associated with the data sequence from the history cache stream, wherein generating the data output includes merging the data from the history cache with the processed data sequence from the text stream and the history buffer stream.

22. The low-latency decompressor according to claim 18, wherein, The at least one processor is configured for each individual data sequence in the historical cache stream: Identify one or more relative history pointers associated with the single data sequence; and Each of the one or more relative history pointers is resolved to an absolute pointer, the absolute pointer referencing the data byte preceding the first byte of the individual data sequence.

23. The low-latency decompressor according to claim 18, wherein, The at least one processor is configured to: In response to the reverse reference pointer of the data sequence being less than a specified threshold number of bytes before the first byte of the data sequence, the data sequence is allocated to the historical cache stream; as well as In response to the reverse reference pointer of the data sequence being greater than the specified threshold number of bytes preceding the first byte of the data sequence, the data sequence is allocated to the history buffer stream.

24. The low-latency decompressor according to claim 18, wherein: The combined buffer includes at least sixteen memories; Each of the at least sixteen memories includes at least seven write ports; The history cache includes a multiplexer for selecting any byte in the history cache; and The combined buffer includes at least one of a multi-port trigger data structure or a latch array data structure.

25. The low-latency decompressor according to claim 18, wherein: The compressed data sequence is stored in memory in LZ4 compression format; and Generating the data output includes generating the data output at an output rate of at least 30 gigabytes per second.

Images