Command processor with multiple string copy engines for decompression systems

Abstract

An electronic device for decompressing compressed data to recreate original data includes a first string copy engine and a second string copy engine. The first string copy engine processes a first string copy command by retrieving a first string from the recreated original data and appending the first string to the recreated original data. The second string copy engine processes the second string copy command by checking whether the second string copy command has a dependency on the first string, and if so, halting further processing of the second string copy command until the first string copy engine appends a corresponding portion of the first string to the recreated original data. The second string copy engine processes the second string copy command by retrieving a second string from the recreated original data and appending the second string to the recreated original data.

Description

[Background technology]

[0001] (Related Technology) Some electronic devices perform operations to compress data, such as user or system files, flows or sequences of data, etc. These electronic devices may compress data to reduce the size of the data to allow for more efficient storage of the data in memory, transmission of the data between electronic devices over a network, etc. For example, electronic devices may use a dictionary coding standard, such as Lempel Ziv-77 (LZ77), LZ78, or Lempel-Ziv-Welch (LZW), to generate compressed data from the original data.

[0002] Although compressing data may improve the efficiency of data storage and processing, the compressed data must be decompressed before it can be used in many operations. That is, before performing such operations, the electronic device must perform operations to undo the effects of the compression operation, and therefore restore or recreate (regenerate) the original data. In many electronic devices, software (i.e., software routines, application programs, etc.) is used to decompress the compressed data. Using software to decompress compressed data typically requires a general-purpose processor, such as a central processing unit (CPU), to perform numerous decompression operations and associated memory accesses. The large number of decompression operations and memory accesses makes using software for decompression inefficient. [Brief description of the drawings]

[0003] [Figure 1] FIG. 2 is a block diagram illustrating compressed data, according to some embodiments. [Diagram 2] FIG. 1 is a block diagram illustrating a literal write command in accordance with some embodiments. [Diagram 3] FIG. 11 is a block diagram illustrating a copy string command, according to some embodiments. [Figure 4] FIG. 1 is a block diagram illustrating an electronic device according to some embodiments. [Diagram 5] FIG. 2 is a block diagram illustrating a decompression subsystem, according to some embodiments. [Figure 6] FIG. 2 is a block diagram illustrating a command processor, according to some embodiments. [Figure 7] FIG. 2 is a block diagram illustrating lines from the scratch array and corresponding byte valid indicators in accordance with some embodiments. [Figure 8] 4 is a flowchart illustrating a process for decompressing compressed input data in accordance with some embodiments. [Figure 9] 1 is a flowchart illustrating a process for storing re-created original data in a scratch array and a history buffer according to some embodiments. [Figure 10] 1 is a flowchart illustrating a process for checking dependencies on a string copy command in accordance with some embodiments. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0004] Throughout the drawings and the description, like numbers refer to identical drawing elements.

[0005] The following description is presented to enable any person skilled in the art to make and use the described embodiments, and is provided in the context of a particular application and its requirements. Various modifications to the described embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments and applications. Thus, the described embodiments are not limited to the embodiments shown, but are to be accorded the widest scope consistent with the principles and features disclosed herein.

[0006] (term) In the following description, various terms are used to describe the embodiments. The following is a simplified and brief summary of one of these terms. Please note that the terms may have important additional aspects that are not listed here for clarity and conciseness, and thus the description is not intended to limit the terms.

[0007] Functional Block: A functional block refers to a group, collection, and / or set of one or more interrelated circuit elements, such as integrated circuit elements, discrete circuit elements, etc. The circuit elements are "interrelated" in that they share at least one attribute. For example, the interrelated circuit elements may be contained within, fabricated on, or otherwise coupled to a particular integrated circuit chip or portion thereof, may participate in performing a certain function (e.g., a computational or processing function, a memory function, etc.), may be controlled by a common control element and / or a common clock, etc. A functional block may include any number of circuit elements, from a single circuit element (e.g., a single integrated circuit logic gate) to millions or billions of circuit elements (e.g., integrated circuit memory).

[0008] (Compressed data) In the described embodiments, operations are performed on and with compressed data. In general, compressed data is the output of one or more compression and / or other operations on original data, resulting in at least a portion of the original data being replaced with commands and / or other values ​​that can be used to recreate the original data. In the described embodiments, various types of data may be compressed, including user or system files (e.g., audio and / or video files, document files, executable files, operating system files, etc.), flows or sequences of data (e.g., audio and / or video data flows, sequences of data received over a network interface, etc.), data captured from sensors (e.g., cameras and / or microphones, thermometers, vibration sensors, etc.), etc. In the described embodiments, a number of compression standards, algorithms or formats, or combinations thereof, may be used to compress the data, including dictionary coding standards such as Lempel Ziv-77 (LZ77), LZ78, Lempel-Ziv-Welch (LZW), etc.

[0009] As used herein, the terms "compressed data" and "compression" apply broadly to operations on original data that result in at least a portion of the original data being replaced by commands and / or other values ​​that can be used to recreate the original data. As noted above, these operations may include various coding standards, algorithms, formats, or combinations thereof. Thus, these terms should not be construed as being limited solely to operations such as dictionary coding compression or other operations that may be considered "compression" operations.

[0010] FIG. 1 is a block diagram illustrating compressed data, according to some embodiments. As shown in FIG. 1, compressed data 100 may be or may be included in a file, a flow or sequence of data, etc., and includes a set (i.e., a series, sequence, etc.) of commands 102. Generally, each command in commands 102 includes, identifies, and / or references information that can be used to obtain and / or generate a string, also called a "symbol" (i.e., bits, letters, numbers, etc.), which is added to the original data recreated during the decompression operation. In some embodiments, each command includes a set of bits configured to represent and / or identify information that can be used to obtain and / or generate the string for that command. In some embodiments, information within a command refers to a reference to information outside the command (e.g., information about another source from where the command value is obtained, information used in a calculation related to the command, a table, record, or other data structure, etc.).

[0011] In some embodiments, the commands include a write literal command and a copy string command. Figure 2 is a block diagram illustrating a write literal command 200, according to some embodiments. The write literal command 200 includes a command identifier (CMD) that, when processed by the decompression subsystem, causes the decompression subsystem to obtain a literal (LITERAL) of a specified length (LENGTH) (e.g., in bits, bytes, etc.) and append the literal to the recreated original data. (Though shown in Figure 2 as part of the write literal command 200, in some embodiments the literal may be stored separately, such as in another portion or block of the compressed data 100.) For the example of Figure 1, the L1 write literal command causes the decompression subsystem to obtain the first byte of the string (e.g., the letter A) and append the first byte of the string to the recreated output data. As used herein, "append" refers to a given string being added to the end of a sequence of previously recreated original data (recreated using a command not shown in FIG. 2) or used as the first string of newly recreated data (if the command is the first command in the compressed data). Continuing with the example of FIG. 1, the L2-L5 literal write commands cause the second through fifth one-byte strings (e.g., characters B, C, D, E) to be taken and appended to the recreated original data in the corresponding positions.

[0012] FIG. 3 is a block diagram illustrating a string copy command 300, according to some embodiments. The string copy command 300 includes a command identifier (CMD) that, when processed by the decompressor subsystem, causes the decompressor subsystem to retrieve a string of a specified length (e.g., in bits, bytes, etc.) from a distance (DISTANCE) (e.g., in bits, bytes, etc.) back to the previously recreated original data and append the data to the recreated original data. In general, the string copy command allows the decompressor subsystem to copy strings of various lengths (perhaps from a minimum to a maximum string length) from the previously recreated original data first and append the copies of the strings to the end of the recreated original data. For the example of FIG. 1, the S1 string copy command causes the decompressor subsystem to copy a string containing a combination of literals appended to the recreated original data by the literal write commands L2 and L3, back three bytes to the previously recreated original data (i.e., B and C), and append the copied string to the recreated original data (following the literal appended to the recreated data by the literal write command L4). After processing the S1 Copy String command, the recreated original data appears as ABCDBC. The S2 Copy String command causes the decompression subsystem to obtain a copy of the string containing the L4 literal and the S1 string (i.e., DBC) and append a copy of the string to the recreated original data. After processing the S2 Copy String command, the recreated original data appears as ABCDBCEDBC. The S3 Copy String command causes the decompression subsystem to obtain a copy of the string containing the L5 literal and the S2 string (i.e., EDBC) and append a copy of the string to the recreated original data. After processing the S3 Copy String command, the recreated original data appears as ABCDBCEDBCEDBC. As can be seen from the example in Figure 1, both the literal and the previous string can be copied and appended to the recreated original data using the Copy String command, either alone or in combination.

[0013] Although a particular sequence of commands is shown in the compressed data 100, in some embodiments, a different sequence and / or type of commands may be included in the compressed data. Generally, the compressed data 100 includes sufficient commands to enable the operations described herein. Additionally, while various fields and information are shown to be included in the write literal command 200 and the copy string command 300, in some embodiments, the write literal command 200 and the copy string command 300 include different and / or differently organized information. Generally, the write literal command 200 and the copy string command 300 include sufficient information to enable the operations described herein. Also, while one-byte literals are used as an example in describing FIG. 1, in some embodiments, literals of other lengths may be used. For example, in some embodiments, literals are permitted to be up to two bytes. Additionally, in some embodiments, a minimum string length is used in the copy string command according to a compression standard, algorithm, format, or combination thereof, and / or for other reasons. For example, in some embodiments, the minimum string length is three bytes (and thus the shortest string allowed is three bytes).

[0014] In some embodiments, the string copy command is defined by a limited amount of recreated original data and is therefore permitted to copy strings from a "dictionary" that contains it. In these embodiments, there is a limit as to how far back into the recreated original data a string can go before it is no longer part of the string copy command's dictionary. For example, in some embodiments, the dictionary contains a sliding window of 32kB, 1kB, or another amount of previously recreated original data. In other words, assuming a 64kB dictionary, only strings from within the most recently generated 64kB of recreated original data can be retrieved to process the string copy command, even if there is more than 64kB of previously recreated original data.

[0015] In some embodiments, during a compression operation, the electronic device generates compressed data (e.g., compressed data 100) from the original data by passing through the original data in sections using a sliding window (e.g., a 32 kB sliding window) and determining a dictionary for each section that includes data in that section. The electronic device then generates, for each section of compressed data, a series of write literal commands that append unique string literal values ​​to the recreated original data, and / or copy string commands that take copies of strings from the previously recreated original data (i.e., the dictionary) and append the copies of the strings to the recreated original data. In some embodiments, and as described above, during a decompression operation, commands are taken from the compressed data and used to recreate the original data using the same dictionary / sliding window / section.

[0016] (overview) In the described embodiment, the electronic device includes a decompression subsystem functional block that performs operations to decompress the compressed data to recreate the original data from which the compressed data was generated. The decompression subsystem includes a command processor functional block that performs operations to process commands, such as a literal write command and a string copy command, to recreate the original data. The command processor includes two or more separate string copy engine functional blocks that enable the command processor to execute two or more string copy operations substantially in parallel (i.e., wholly or partially simultaneously). Thus, the described embodiment can efficiently generate strings when processing string copy commands to decompress the compressed data. Because the string copy commands may copy strings from the recreated original data that are appended to the original data recreated by a previous string copy command, there may be dependencies between two or more string copy commands that are executing substantially in parallel in two or more string copy engines. Thus, the command processor also includes a mechanism to ensure that dependencies between string copy commands are properly handled by two or more separate string copy engines.

[0017] In a described embodiment, the data is compressed using a dictionary coding standard (e.g., LZ77, LZ78, etc.), and the string copy operation can take copies of strings from the previously recreated original data that are longer than a specified minimum length and append the copies of the strings to the recreated original data. For example, the string copy command S1 in FIG. 1 copies the string BC from the previously recreated original data and appends the string to the recreated original data. In some embodiments, the string copy operation is limited to a particular block or portion of the previously recreated data, sometimes called a "dictionary," from which to take strings. For example, in some embodiments, a sliding window of K bytes (e.g., 32 kB, 1 kB, etc.) is used as the dictionary, meaning that strings can only be copied back K bytes in the recreated original data. In some embodiments, the command processor includes mechanisms for locally storing copies of strings that are currently in the dictionary. These mechanisms include a scratch array and a history buffer, where strings are stored in N byte lines (e.g., 32 byte lines, 50 byte lines, etc.). The scratch array, which stores only a few lines (e.g., 4, 6, etc.) of the N byte lines last written to the recreated original data, is implemented using sequential logic storage elements (e.g., flip-flops, latches, etc.) that are more directly coupled to the string copy engine. Thus, the string copy engine can quickly copy bytes from the strings stored in the N byte lines of the scratch array, e.g., in just one cycle of the control clock. The history buffer, which stores the remaining N byte lines (e.g., 1020, 1200, etc.), is implemented using memory elements (e.g., synchronous random access (SRAM) memory elements, dynamic random access memory (DRAM) elements, etc.). Copying strings from the N byte lines of the history buffer is slower than copying strings from the scratch array (e.g., 6 cycles of the control clock), but is faster than using a remote memory, such as the main memory of the electronic device, to store and copy the N byte lines from the dictionary.

[0018] In some embodiments, during operation, when a literal value from processing a literal write command or a copied string from processing a string copy command is appended to the recreated original data, the recreated original data flows from the scratch array to the history buffer and then to the main memory of the electronic device. In other words, when a literal value or string is appended to the recreated original data by the command processor, the command processor stores individual bytes of the literal value or string in one or more N-byte lines of the scratch array. When an N-byte line of the scratch array becomes full, the command processor moves (or "migrates") bytes of the recreated original data from one or more N-byte lines of the scratch array to an available N-byte line in the history buffer in first-in-first-out order. Moving a line out of the scratch array frees one or more N-byte lines in the scratch array to store a subsequent literal value or copied string generated by the command processor. When an N-byte line of the history buffer becomes full, the command processor moves (or "migrates") bytes of the recreated original data from one or more of the N-byte lines of the history buffer to memory in first-in, first-out order. This frees up one or more N-byte lines in the history buffer to store bytes of recreated original data received from the scratch array. In some embodiments, the N-byte lines are copied from the history buffer to memory immediately (thus, these embodiments do not wait for the history buffer to fill before writing the lines to memory), but are retained in the history buffer until they are overwritten by other N-byte lines when the history buffer becomes full of N-byte lines. These embodiments may avoid complications that arise from memory system busy states or other delays in moving lines from the history buffer to memory.

[0019] In some embodiments, as the reconstructed original data flows or progresses through the scratch array and the history buffer to the memory, a tracking mechanism is used to track (1) the number of N-byte lines that have been moved from the scratch array to the history buffer, and (2) the number of bytes of the scratch array that currently store valid data. The tracking mechanism includes a line counter that stores a line count indicating the number of N-byte lines of reconstructed original data that have been moved from the scratch array to the history buffer. As each N-byte line is moved from the scratch array to the history buffer, the line counter increments the line count. Thus, the line count indicates the total number of N-byte lines of previously reconstructed original data that are currently stored in the history buffer and memory. The tracking mechanism also includes a byte valid tracker that stores a set of byte valid indicators, one of the byte valid indicators associated with each byte of the N-byte lines of the scratch array. As the reconstructed original data is written to each byte of the scratch array, the command processor sets the corresponding byte's valid indicator to indicate that valid reconstructed original data is present in the byte. Once the reconstructed data has been moved from the scratch array to the history buffer, the command processor clears the corresponding byte valid indicator to indicate that no valid reconstructed original data is present at the byte (and thus the byte is empty, invalid, etc.).

[0020] As described above, dependencies can arise between string copy commands. In general, string copy commands can be executed in substantial parallelism, and thus dependencies arise because a string copy command may copy strings that were appended to the recreated original data by an earlier string copy command and / or a literal write command that has not yet completed processing. A "direct" dependency occurs when a string copy command copies from the recreated original data a string that was appended to the recreated original data by an earlier string copy command. An "indirect" dependency occurs when a string copy command copies from the recreated original data a string that was appended to the recreated original data by a literal write command that stopped while the earlier string copy command completed processing (thus the string copy command indirectly depends on the earlier string copy command).

[0021] The above tracking mechanism is used to ensure that dependencies between string copy commands are handled properly. The string copy engine uses the line count to quickly determine whether the string to be copied from the specified distance of the original data recreated by the string copy command exists in the history buffer and / or scratch array, and therefore whether there is an unresolved dependency between the string copy command and a previous string copy command. The string copy engine also uses the byte valid indicator in the byte valid array to ensure that dependencies are handled properly. More specifically, assuming the line count indicates that an adequate number of lines exist in the scratch array and history buffer, the string copy engine uses the byte valid indicator to determine whether the string to be copied from the scratch array by the string copy command exists and is ready to be copied from the scratch array.

[0022] By using a hardware decompression subsystem in conjunction with a command processor that includes a string copy engine for processing two or more string copy commands substantially in parallel, the described embodiments efficiently and quickly perform decompression operations using hardware that existing devices execute using software. The decompression subsystem is faster and more efficient (e.g., requires fewer memory accesses, uses less power, etc.) than using software entities to perform the same operations. Furthermore, using line count and byte valid indicators, the described embodiments can efficiently detect and process dependencies between string copy commands, which allows for the string copy commands to be processed substantially in parallel in the string copy engine. The use of the decompression subsystem frees up other functional blocks (e.g., processing subsystem, etc.) in the electronic device to perform other operations. Thus, the decompression subsystem improves the overall performance of the electronic device, which in turn improves user satisfaction.

[0023] (Electronic Devices) Figure 4 is a block diagram illustrating an electronic device 400, according to some embodiments. As shown in Figure 4, the electronic device 400 includes a processor 402 and a memory 404. The processor 402 is a functional block that performs calculations, decompression, and other operations in the electronic device 400. The processor 402 includes a processing subsystem 406 and a decompression subsystem 408. The processing subsystem 406 includes one or more functional blocks, such as a central processing unit (CPU) core, a graphics processing unit (GPU) core, an embedded processor, and / or an application specific integrated circuit (ASIC) that performs general purpose calculations, decompression, and other operations.

[0024] The decompression subsystem 408 is a functional block that performs operations to decompress compressed input data. In general, the decompression subsystem 408 receives as input compressed input data generated based on the original data and returns as output a string (or symbol), such as a sequence of one or more bits, letters, numbers, etc., to recreate the original data. Based on the configuration of internal elements within the decompression subsystem 408 (e.g., several separate string copy engines and / or command buffers within the decompression subsystem 408), the decompression subsystem 408 generates up to a specified number of strings per period (e.g., two strings per clock cycle, three strings per 333 ps, etc.) from a block of compressed data. The decompression subsystem 408 is described in more detail below.

[0025] The memory 404 is a functional block that performs memory (e.g., main memory) operations in the electronic device 400. The memory 404 includes memory circuitry (i.e., storage elements, access elements, etc.) for storing data and instructions used by the functional blocks of the electronic device 400, and control circuitry for handling access (e.g., read, write, check, delete, invalidate, etc.) of the data and instructions in the memory circuitry. The memory circuitry in the memory 404 includes computer-readable memory circuitry such as fourth generation double data rate synchronous dynamic random access memory (DDR4 SDRAM), static random access memory (SRAM), or a combination thereof.

[0026] Electronic device 400 is shown with a particular number and configuration of elements (e.g., functional blocks and devices, such as processor 402, memory 404, etc.). However, electronic device 400 is simplified for purposes of explanation. In some embodiments, a different number or configuration of elements are present in electronic device 400. For example, electronic device 400 may include a power subsystem, a display, etc. In general, electronic device 400 includes sufficient elements to perform the operations described herein.

[0027] 2, the decompression subsystem 408 is shown as being included in the processor 402, in some embodiments the decompression subsystem 408 is a separate and / or stand-alone functional block. For example, the decompression subsystem 408 may be implemented (by itself or with supporting circuit elements and functional blocks) in a stand-alone integrated circuit chip or the like. In general, in the described embodiments, the decompression subsystem 408 is suitably located in the electronic device 400 and performs the operations described herein.

[0028] Electronic device 400 may be or may be included in any electronic device that performs data decompression or other operations. For example, electronic device 400 may be or may be included in electronic devices such as a desktop computer, a laptop computer, a wearable electronic device, a tablet computer, a smartphone, a server, an artificial intelligence device, a virtual or augmented reality device, a network appliance, a toy, an audiovisual device, a home appliance, a controller, a vehicle, and / or combinations thereof.

[0029] (Decompression Subsystem) In the described embodiment, the decompression subsystem of the electronic device performs operations to decompress the compressed input data, i.e., to recreate the original data from which the compressed input data was generated. FIG. 5 is a block diagram illustrating the decompression subsystem 408, according to some embodiments. As shown in FIG. 5, the decompression subsystem 408 includes a command generator 500 and a command processor 502. The command generator 500 is a functional block that performs operations to extract commands 506 and literals 508 from the compressed input data 504 and provide the commands 506 and literals 508 to the command processor 502. The command processor 502 is a functional block that performs operations to process the commands 506 and literals 508 received from the command generator 500 to generate corresponding strings or symbols of the recreated original data 510 that are provided to a receiving entity (e.g., the processing subsystem 406, the memory 404, the network subsystem, the sensor subsystem, etc.).

[0030] During operation, the command generator 500 receives compressed input data 504 from a source entity (e.g., the processing subsystem 406, the memory 404, the networking subsystem, an IO device, etc.). The compressed input data 504 is or includes a sequence or flow of bits having information for generating, obtaining, and / or retrieving commands 506 and literals 508. For example, in some embodiments, the compressed input data 504 is structured similarly to the compressed data 100. The command generator 500 then performs operations to generate, obtain, and / or retrieve commands 506 and literals 508 from the compressed input data 504. In other words, the command generator 500 processes the compressed input data 504 to extract commands 506 and literals 508 from the compressed input data 504 or otherwise generate, obtain, or retrieve commands 506 and literals 508.

[0031] In some embodiments, for each literal write command or string copy command, command generator 500 finds a command identifier in compressed input data 504, such as in the first position of compressed input data 504 or in a specified set of bits at the beginning of each command in compressed input data 504. Based on the type of command indicated by the command identifier, command generator 500 extracts the remaining information of the command from compressed input data 504. For example, in the case of a literal write command (e.g., literal write command 200), in some embodiments, command processor 502 determines that the command identifier identifies the command as a literal write command (e.g., includes a specified configuration of bits). Command processor 502 then extracts or obtains from subsequent bits of compressed input data 504 the length of the literal and the string or symbol of the literal itself (which may be one or more bytes, up to a specified limit). Command generator 500 then communicates command 506 and literals 508 (if any) to command processor 502, e.g., via one or more parallel or serial communication signal lines or paths. For example, assuming the command is a string copy command 300, command generator 500 communicates indicators to command processor 502 indicating that the command is a string copy command, the distance back to the original data recreated from where the string is to be copied (e.g., number of bits or bytes, a number to calculate the number of bits or bytes, an offset, etc.), and the length of the string (e.g., number of bits or bytes, a number to calculate the number of bits or bytes, an offset, etc.).

[0032] In some embodiments, the command generator 500 calculates or determines an address or location where the recreated raw data provided by the literal write command or string copy command will be stored. For example, in some embodiments, the command generator 500 keeps a running record of the bytes of recreated raw data output by the command processor 502 and uses the running record to determine the address or location where the first byte written by a given command will be stored. In these embodiments, the command generator 500 may tag or otherwise provide the address or location of the first byte to the command processor 502 for use thereby. For example, the command generator 500 may provide an identifier for the particular byte, a number for calculating the particular byte, an offset, etc. The command generator 500 may use the address or location for operations such as determining whether there are any dependencies that have not yet been resolved for a given string copy command, etc.

[0033] In some embodiments, the command generator 500 performs other operations to generate, obtain, and / or retrieve the commands 506 and literals 508 based on the compressed input data 504 and / or other information. For example, in some embodiments, after being compressed using a dictionary coding standard, the compressed data is encoded using a coding standard such as a prefix coding standard (e.g., Huffman coding). In these embodiments, the command generator 500 decodes the compressed input data 504 before generating, obtaining, and / or retrieving the commands. In general, the command generator 500 can perform any number of operations to resolve the commands 506 and literals 508 for communication with the command processor 502.

[0034] Upon receiving the commands 506 and literals 508 from the command generator 500, the command processor 502 performs operations to process the commands 506 and literals 508. FIG. 6 is a block diagram illustrating the command processor 502, according to some embodiments. As shown in FIG. 6, the command processor 502 includes a command buffer 600, a number of string copy engines 602, a scratch array 604, and a history buffer 606. The command buffer 600 is a functional block that recognizes each command processed as a literal write command or a string copy command and performs operations to either process the command locally or forward the command to a string copy engine for processing therein. For example, the command buffer 600 can receive a command type signal or indicator from the command generator 500 via a dedicated signal line, via one or more bits on a serial or parallel signal line, or the like, and determine whether the command is a literal write command or a string copy command based thereon.

[0035] If the command is a literal write command, in some embodiments, the command buffer 600 processes the command locally (i.e., processes the command itself). To process the literal write command, the command buffer 600 generates a literal write request (REQ) 608 based on the command 506 and literal 508, and the above execution history of the recreated original data. The command buffer 600 then forwards the literal write request 608 along with the literal data and an address (DATA / ADDR) 610 to the scratch array 604. The literal write request 608 is a signal, message, or other request that causes the scratch array 604 to store a byte of literal data (recall that this could be one or more bytes) of the recreated original data starting at the byte identified by the address (absolute or relative address or byte position of the recreated original data).

[0036] In general, to "store" the literal in the recreated original data starting at the byte identified by the address, the literal must be appended to the recreated original data that exists (or will exist) after executing the command prior to the literal write command. In other words, the literal is added to the end of the recreated original data generated by the previous command. Note that in some embodiments, some or all of the previous command may still be being processed (such as in the string copy engine 602), and thus the literal may be added to the recreated original data at the specified location (storage element of scratch array 604), while leaving other / previous locations free to store the literal or string generated by the previous command. In other words, the literal from the literal write command may be written to the recreated original data in any order, at the appropriate locations.

[0037] If the command is a string copy command, the command buffer 600 forwards information for processing the string copy command to the string copy engine 602 for processing therein. For this operation, the command buffer 600 selects from among the multiple string copy engines the string copy engine 602 to which the string copy command is forwarded for processing. For example, in some embodiments, the command buffer 600 selects string copy engines in a round robin pattern to process distinct string copy commands from a sequence of string copy commands. As another example, in some embodiments, the command buffer 600 selects a string copy engine as a string copy engine becomes available to process distinct string copy commands from a sequence of string copy commands. In these embodiments, a given string copy engine can process two or more consecutive string copy commands substantially in parallel with another string copy engine that processes only one string copy command.

[0038] When forwarding a string copy command to a string copy engine 602, the command buffer 600 forwards various separate items of information used to process the string copy command. As shown in FIG. 6, the information items include a string command 612, a distance 614, a length 616, and an address 618 to the selected string copy engine 602. The string command 612 includes one or more bits that notify the string copy engine that a string copy command is waiting to be processed (thus causing the string copy engine to process the string copy command). In some embodiments, each string copy engine 602 has a separate string command 612 (e.g., connected to a dedicated signal line, etc.), so that the command buffer 600 can forward a signal on the string command 612 to notify that particular string copy engine 602 that a string copy command is waiting to be processed. The distance 614 is an identification of the number of bits, bytes, etc., back to the original data previously recreated where the string to be copied is located. The length 616 represents the length of the string to be copied in bits, bytes, etc. Address 618 identifies the location in the recreated original data where the string is to be stored (absolute or relative address or byte position in the recreated original data) calculated by command generator 500 using the re-created original data execution log described above. Based on the value received from command buffer 600, string copy engine 602 generates a string write request 620. String copy engine 602 then forwards string write request 620 along with the string data and address (DATA / ADDR) 622 to scratch array 604. String write request 620 is a signal, message, or other request that causes scratch array 604 to store a byte-wise string of recreated original data (recall that this may be one or more bytes) starting at the byte identified by the address.

[0039] In general, to "store" a string in the recreated raw data starting at the byte identified by the address, the string needs to be appended to the recreated raw data that exists (or will exist) after executing the command prior to the string copy command. In other words, the string is added to the end of the recreated raw data generated by the previous command. Note that in some embodiments, some or all of the previous command may still be being processed (such as in the string copy engine 602), and thus the string may be added to the recreated raw data at the specified location (storage element of the scratch array 604), while other / previous locations remain free to store literals or strings generated by the previous command. In other words, the string from the string copy command can be written to the recreated raw data in any order, in the appropriate locations. An example of this can be seen in FIG. 7, which is a block diagram illustrating a scratch array line 700, according to some embodiments. In the example of FIG. 7, the recreated original data (ROD) is written to the first and third of four locations (e.g., bytes) of the scratch array line 700, but the second location (EMPTY) has not yet been written, and therefore the recreated original data in the third location is "appended" to the recreated original data that will ultimately be produced by the previous command.

[0040] Although not shown in FIG. 6, in some embodiments, a first-in-first-out buffer is disposed between the command buffer 600 and the scratch array 604. In these embodiments, instead of transferring the literal write requests 608 and the literal data and addresses 610 associated with the literal write commands directly to the scratch array 604, the command buffer 600 writes the literal write requests 608 and the literal data and addresses 610 of those literal write commands to a first-in-first-out buffer. The values ​​are held in the first-in-first-out buffer until the literal write requests are processed, and then released to the scratch array. In these embodiments, instead of holding the literal write commands while a preceding command (such as a longer string copy command) completes execution, the command buffer 600 can transfer the literal write requests 608 and the literal data and addresses 610 of those literal write commands to the first-in-first-out buffer and proceed with the subsequent command. For example, the command buffer 600 can process subsequent string copy commands and forward them to the string copy engine for processing therein. The subsequent string copy commands may stall while previous commands and literal write commands complete writing their scratch arrays, but the string copy engine gets a chance to continue reading the history buffer needed to process the subsequent string copy commands.

[0041] The scratch array 604 is a functional block that includes sequential logic storage elements (e.g., flip-flops, latches, etc.) for storing literals or strings (or symbols) transferred from the command buffer 600 and the string copy engine 602. The scratch array 604 is a fast access storage in which a small number of N-byte (e.g., 32-byte, 60-byte, etc.) lines of recreated original data are stored, allowing the strings stored therein to be quickly accessed when the string copy engine 602 processes a string copy command. The sequential logic storage elements in the scratch array 604 are located near the string copy engine 602 and are coupled to the string copy engine 602 by a relatively direct signal path. For example, in some embodiments, the sequential logic storage elements are proximate or adjacent to the string copy engine (or a string copy functional block included in the string copy engine) in the semiconductor layout in which the command processor is fabricated and coupled to the circuit via a relatively direct communication route in the semiconductor layout.

[0042] The particular number of N-byte lines of scratch array 604 is selected to allow string copy engine 602 to quickly utilize useful portions of the recreated original data, without scratch array 604 being too large (i.e., requiring too much layout area), consuming too much power, etc. For example, in some embodiments, a measured, estimated, or calculated profile of the number of bytes copied by string copy engine 602 is used (e.g., by a designer, etc.) to select the number of N-byte lines of scratch array 604. In some embodiments, scratch array 604 includes four, six, or another number of N-byte lines.

[0043] History buffer 606 is a functional block that includes memory elements (e.g., SRAM memory elements, DRAM memory elements, etc.) for storing literals and strings (or symbols) transferred from command buffer 600 and string copy engine 602. History buffer 606 is a slower access store (compared to scratch array 604) that stores a larger number of N-byte lines of reconstructed original data to allow string copy engine 602 to access the strings stored therein when processing string copy commands. In some embodiments, the number of N-byte lines included in history buffer 606 (and scratch array 604) is set based on the dictionary size of the dictionary coding standard used to generate compressed input data 504. For example, in these embodiments, assuming the dictionary size is 32 kB, the N-byte lines are 32 bytes in size, and scratch array 604 has four 32-byte lines, the history buffer has storage for 1020 separate 32-byte lines (i.e., out of a total of 1024 32-byte lines in the dictionary). The history buffer 606 typically contains a much larger portion of the N-byte lines in the dictionary than the scratch array 604 .

[0044] In operation, in some embodiments, as literal values ​​from processing a literal write command or copied strings from processing a string copy command are appended to the reconstructed original data, the reconstructed original data flows from scratch array 604 to history buffer 606 and then to memory 404. In other words, as literal values ​​or strings are appended to the reconstructed original data by command buffer 600 or string copy engine 602, respectively, scratch array 604 initially stores individual bytes of the literal value or string in one or more N byte lines of scratch array 604. As literals and strings continue to be appended to the reconstructed original data, the N byte lines of scratch array 604 eventually fill up. Once an N byte line is full, scratch array 604 moves bytes of the reconstructed original data from one or more N byte lines in scratch array 604 to an available N byte line in history buffer 606 in a first-in, first-out order. In other words, scratch array 604 “migrates” older reconstructed original data from scratch array 604 to history buffer 606 via write request 624 and write data 626. In this manner, moving bytes of reconstructed original data from an N byte line from scratch array 604 frees up one or more N byte lines in scratch array 604 for storing subsequent literal values ​​or copied strings generated by command buffer 600 or string copy engine 602. Once an N byte line in history buffer 606 is filled with the migrated reconstructed original data, history buffer 606 moves bytes of reconstructed original data from one or more N byte lines in history buffer 606 to memory 404 in first-in-first-out order. In other words, history buffer 606 “migrates” older reconstructed original data from history buffer 606 to memory 404 via write data 628. This frees up one or more N-byte lines in the history buffer 606 for storing bytes of reconstructed original data that are later received / migrated from the scratch array 604.

[0045] In some embodiments, the history buffer 606 does not wait until it is full before writing the N byte line to the memory 404. In these embodiments, the history buffer 606 copies the N byte line to the memory 404 as the N byte line is first migrated from the scratch array 604 to the history buffer 606 (i.e., in a manner similar to a write-through cache memory of an electronic device). However, the N byte line is retained in the history buffer 606 until enough subsequent N byte lines are written to the history buffer 606 to overwrite the N byte line. In other words, even though a copy of the N byte line is stored in the memory 404, the N byte line remains in the history buffer 606 and can be used as described herein until it is overwritten by subsequent data. In these embodiments, problems with writing the N byte line back to memory the moment the history buffer 606 becomes full (e.g., memory system busy conditions, etc.) can be avoided.

[0046] In some embodiments, the N-byte lines of reconstructed original data generated based on literal write commands and string copy commands closer to the end of the compressed data that are not pushed out of the scratch array and / or history buffer by subsequent reconstructed original data are processed using one or more data termination mechanisms. In general, the one or more data termination mechanisms ensure that all of the reconstructed original data is eventually stored in memory 404 and does not get stuck in scratch array 604 and / or history buffer 606. For example, in some embodiments, the reconstructed original data flows or advances through scratch array 604 and history buffer 606 based on the age or lifetime of the reconstructed original data in scratch array 604 and / or history buffer 606. In these embodiments, scratch array 604 and / or history buffer 606 automatically transition the data to history buffer 606 and memory 404, respectively, when the data reaches a predetermined age or lifetime. As another example, in some embodiments, the compressed data includes an "end of data" (or "end of file", etc.) character, command, symbol, etc. at or near the end of the compressed data (e.g., as the last character, command, symbol, etc.). The end of data character, command, symbol, etc. triggers the command processor 604 and / or history buffer 606 to automatically migrate data to the history buffer 606 and memory 404, respectively. In this manner, the reconstructed original data eventually flows or progresses to memory 404, despite being located at the end of the compressed data.

[0047] In some embodiments, the scratch array 604 and the history buffer 606 include mechanisms that allow for the determination of information about previously recreated original data. These mechanisms track information associated with the recreated original data that was generated when previous literal write commands and string copy commands were processed. In some embodiments, these mechanisms include a line counter 630 and a byte valid (BV) tracker 634. The line counter 630 is a functional block that performs operations to maintain a line count 632 that indicates the number of N-byte lines that have been migrated (to date) from the scratch array 604 to the history buffer 606 while processing literal write commands and string copy commands. As each N-byte line is moved / migrated from the scratch array 604 to the history buffer 606, the line counter 630 increments the line count 632. Thus, the line count 632 indicates the total number of N-byte lines of previously recreated original data currently stored in the history buffer 606 and memory 404 (and / or provided to another entity, such as the processing subsystem 406, a network interface, a sensor, etc.). In some embodiments, the line count 632 is stored in a memory element that is coupled to the string copy engine 602 by a relatively direct signal path and therefore can be quickly accessed by the string copy engine 602.

[0048] The byte valid tracker 634 is a functional block that performs operations to maintain a set of byte valid indicators (IND) 638 in a byte valid array 636. A separate byte valid indicator 638 in the byte valid array 636 is associated with each byte of the N byte line in the scratch array 604. As reconstructed original data is written to each byte of the scratch array 604, the byte valid tracker 634 sets the corresponding byte valid indicator 638 to indicate that valid reconstructed original data is present in the byte. When a byte of reconstructed data is moved / migrated from the scratch array 604 to the history buffer 606 (or a byte of the scratch array 604 is initialized, cleared, invalidated, etc.), the byte valid tracker 634 clears the corresponding byte valid indicator 638 to indicate that no valid reconstructed original data is present in the byte. An example of a byte valid indicator 638 is shown in FIG. 7. As shown in FIG. 7, an example scratch array line 700 of an N byte line from the scratch array 604 has valid data in the first and third bytes. The corresponding (i.e., first and third) byte valid indicators 638 in byte valid indicators 702, which are examples of byte valid indicators 638 from the byte valid array 636, are set to 1 if they indicate that the data in those bytes is valid, and are set to 0 otherwise. In some embodiments, the byte valid array 636 is located near the string copy engine 602, and the individual byte valid indicators 638 are coupled to the string copy engine 602 by a relatively direct signal path. Thus, the string copy engine 602 can quickly access the byte valid indicators 638 to determine whether the associated bytes contain valid reconstructed original data.

[0049] As noted above, dependencies (or as yet unresolved dependencies) can occur between string copy commands. A direct dependency occurs when a string copy command copies from the re-created source data a string that was appended to the re-created source data by an earlier string copy command. An indirect dependency occurs when a string copy command copies from the re-created source data a string that was appended to the re-created source data by a literal write command that stopped while the earlier string copy command completed its processing (thus the string copy command indirectly depends on the earlier string copy command).

[0050] String copy engine 602 uses line count 632 and byte valid array 636 to ensure that dependencies between string copy commands are properly handled. String copy engine 602 uses line count 632 to determine whether the string to be copied by the string copy command from a specified distance in the recreated original data exists in scratch array 604 and / or history buffer 606 (recall that the same multi-byte string can be stored in N byte lines in scratch array 604 and history buffer 606). For example, string copy engine 602 can compare the relative value of the distance from the string copy command to line count 632 and determine that an unresolved dependency exists if the difference is greater than a threshold. For example, assuming scratch array 604 holds four N-byte lines, if line count 632 indicates that four N-byte lines are present in history buffer 606, then the maximum number of complete N-byte lines present in scratch array 604 and history buffer 606 is eight (recall, however, that some of scratch array 604's N-byte lines may not yet hold valid data due to ongoing string copy commands and / or subsequent literal write commands). In this case, if a string copy command copies data from the tenth N-byte line, and thus the difference between distance and line count 632 is two, which is greater than threshold zero, string copy engine 602 determines that an unresolved dependency exists. In other words, fewer N-byte lines have been added to the recreated original data in scratch array 604 and / or history buffer 606 than would be necessary to allow some or all of the string of the string copy command to be copied from the recreated original data because a previous string copy command and / or literal write command has / has not completed processing. In this case, the previous copy string command and / or one or more write literal commands must be completed before the string copy engine 602 can continue processing the copy string command.Therefore, the string copy engine 602 temporarily stops processing the string copy command to allow processing of the previous string copy command and / or one or more literal write commands to complete before the string copy engine 602 proceeds with processing the string copy command.

[0051] The string copy engine 602 uses the byte valid indicators 638 to determine whether the string to be copied by the string copy command from the scratch array 604 is present and ready to be copied from the scratch array 604. In other words, a previous string copy command and / or literal write command has not yet written the necessary recreated original data to the scratch array 604, and therefore, certain bytes of the scratch array 604 may still be invalid. Thus, the string copy engine 602 checks whether the byte valid indicators indicate that the required data is present in bytes of the N byte line(s) of the scratch array 604. If the data is not yet present, the string copy engine 602 temporarily stops processing the string copy command to allow processing of the previous string copy command and / or one or more literal write commands to complete before the string copy engine 602 proceeds with processing the string copy command.

[0052] In some embodiments, the above checks of line count 632 and byte valid indicator 638 are performed as a pair, one following the other, as necessary. In these embodiments, when processing a string copy command, string copy engine 602 checks line count 632 as described above to ensure that a given N-byte line is in scratch array 604 (again, the N-byte line may not yet be completely written due to an ongoing string copy command and / or a subsequent literal write command). Then, if line count 632 indicates that a given N-byte line is present in scratch array 604, string copy engine 602 checks byte valid indicator 638 to ensure that the particular bytes of the N-byte line are present in scratch array 604. If any of these checks fail (i.e., indicating that the N byte line is not present in the scratch array 604 or that particular bytes are not yet present in the scratch array 604), the string copy engine 602 temporarily halts processing of the string copy command to allow processing of the previous string copy command and / or one or more literal write commands to complete before the string copy engine 602 proceeds with processing the string copy command.

[0053] After string copy engine 602 ensures that no unresolved dependencies will prevent processing of the string copy command, string copy engine 602 processes the string copy command. In general, processing of a string copy command involves retrieving a string (i.e., one or more bytes) of previously recreated original data from scratch array 604 and / or history buffer 606 and appending the string to the recreated original data. To retrieve the string, string copy engine 602 uses distance 614 to determine a location in scratch array 604 or history buffer 606 where the string copy should begin (e.g., the first byte to be read). String copy engine 602 also uses length 616 to determine the number of bytes of recreated original data to read from scratch array 604 and / or history buffer 606. Starting from a location in scratch array 604 or history buffer 606, string copy engine 602 then reads the number of bytes of recreated original data sequentially from scratch array and / or history buffer, e.g., via scratch data 640 and read data 642. For a read operation, the string copy engine 602 can directly read sequential logical storage elements in the scratch array 604, but performs a typical memory read operation to read memory elements in the history buffer 606 (e.g., an SRAM read operation if the history buffer 606 is implemented using SRAM or the like). To append a string to the reconstructed original data, the string copy engine 602 writes the string (i.e., bytes of the reconstructed original data read from the scratch array 604 and the history buffer 606) to a location in the scratch array 604 and / or the history buffer 606 identified by an address 618. Note that separate portions of a sufficiently long multi-byte string may be stored in the scratch array 604 and the history buffer 606, and thus portions of the string may be read and written from the scratch array 604 and the history buffer 606 as described above (i.e., data may be migrated from the scratch array 604 to the history buffer 606 to make space in the scratch array 604 for a longer string).

[0054] Although a particular number and configuration of functional blocks are illustrated in the decompression subsystem 408 and command processor 502 in FIGS. 5-7, in some embodiments, a different number and / or configuration of functional blocks are present in the decompression subsystem 408 and / or command processor 502. For example, in some embodiments, the command processor 502 includes two or more command buffers and / or three or more string copy engines, as illustrated using multiple blocks in FIG. 5. As another example, in some embodiments, the history buffer 606 is "virtualized," such that at least a portion of the original data recreated above as stored in the history buffer 606 is instead stored in memory 404. In these embodiments, writing the recreated original data to at least a portion of the history buffer 606 and reading the previously recreated original data therefrom includes performing a virtual history buffer access 644 in memory 404. It should be noted that virtualizing the history buffer 606 means that the history buffer 606 requires fewer memory elements and therefore can have a smaller layout size and use less power, even though access times to the reconstructed original data stored in memory 404 may increase.

[0055] (The process of decompressing compressed input data) In a described embodiment, a decompression subsystem (e.g., decompression subsystem 408), including a command generator and command processor (e.g., command generator 500 and command processor 502), performs operations to decompress compressed input data (e.g., compressed input data 504) to generate recreated original data (e.g., recreated original data 510). FIG. 8 is a flow chart illustrating a process for decompressing compressed input data, according to some embodiments. It should be noted that the operations illustrated in FIG. 8 are provided as general examples of operations performed by some embodiments. Operations performed by other embodiments include different operations, operations performed in a different order, and / or operations performed by different entities or functional blocks.

[0056] For the process illustrated in FIG. 8, it is assumed that the decompression subsystem receives the compressed input data from a source such as a file, a stream of data, etc. In other words, individual bits of the compressed input data are received by the decompression subsystem and can therefore be manipulated by the command generator and command processor of the decompression subsystem. In some embodiments, the decompression subsystem simply decompresses (and perhaps only decompresses) the compressed input data provided to the decompression subsystem by another entity (e.g., a processing subsystem, a memory) to generate a string for recreating the original data from which the compressed input data was created. In other words, in these embodiments, the decompression subsystem performs no operations other than outputting the recreated original data generated from the compressed input data provided to the decompression subsystem. However, in some embodiments, the decompression subsystem includes functional blocks for performing other operations, such as retrieving data from memory and / or other locations or entities (e.g., a processing subsystem, a network interface, an IO device, etc.), such as for storing the string of recreated original data in memory and / or for providing the string of recreated original data to other entities.

[0057] For the example of FIG. 8, the first string copy engine and the second string copy engine perform certain operations "substantially in parallel," in that these operations are performed at approximately the same time. This can be seen in FIG. 8 as parallel branches of the flowchart (i.e., a branch including steps 802-804 and a branch including steps 806-812). These operations are performed approximately simultaneously, in that the operations are performed simultaneously or approximately simultaneously (e.g., on successive cycles of the control clock in an embodiment having only one command buffer (e.g., command buffer 600), initiated on the same clock cycle in an embodiment with two or more command buffers, etc.). Additionally, although not shown in FIG. 8, the first string copy engine first checks for unresolved dependencies between the previous string copy command and the first string copy command (dependency checking is described in more detail with respect to FIG. 10). For the example of FIG. 8, it is assumed that no unresolved dependencies are found, and therefore the first string copy engine continues processing the first string copy command.

[0058] 8, the process begins when the command processor forwards a first string copy command to a first string copy engine and a second string copy command to a second string copy engine (step 800). For this operation, one or more command buffers in the command processor (e.g., command buffer 600) receive information (e.g., distance 614, length 616, and address 618) for processing each of the first and second string copy commands from a command generator (e.g., command generator 500). The one or more command buffers then forward the appropriate information to the first string copy engine for processing the first string copy command and to the second string copy engine for processing the second string copy command.

[0059] Upon receiving the first string copy command, the first string copy engine retrieves the first string from the recreated original data (step 802). In this operation, the first string copy engine determines, based on the distance, a location in a scratch array (e.g., scratch array 604) or history buffer (e.g., history buffer 606) from which to read the first string, and thus the particular recreated original data to retrieve for the first string. For example, the first string copy engine may use the distance to calculate a particular byte of an N-byte line of the scratch array or history buffer from which to begin reading the first string. The first string copy engine then sequentially reads one or more bytes of the first string from the scratch array and / or history buffer starting from a location in the scratch array or history buffer based on the length of the string. At the end of this operation, the first string copy engine has a copy of one or more bytes of the first string.

[0060] Next, the first string copy engine appends the first string to the recreated original data (step 804). In this operation, the first string copy engine writes individual bytes of the recreated original data, the first string, to locations in the scratch array starting from the location of the scratch array indicated by the address. Note that the first string copy command may write data to bytes in the scratch array beyond the current end of the recreated original data in the scratch array because one or more previous string copy commands and / or literal write commands may not have completed their respective writes to the scratch array. However, it may occur that the first string copy engine only appends the recreated original data to the end of the existing recreated original data for the append operation. Additionally, if the first string is sufficiently long and / or the scratch array is sufficiently full with previously recreated original data, the scratch array may migrate the recreated original data to the history buffer in a first-in-first-out order to free up one or more N-byte lines for the first string copy engine to continue writing the recreated original data to the scratch array.

[0061] Upon receiving the second string copy command, the second string copy engine checks for direct or indirect dependencies of the second string copy command on the first string (step 806). As described above, because the first string copy command and the second string copy command are executed substantially in parallel and the first string copy command has not yet written the recreated original data to the scratch array and / or the data has not yet been migrated from the scratch array to the history buffer where it is copied to the second string, direct or indirect dependencies that have not yet been resolved may arise. For this operation, the second string copy engine checks for these unresolved dependencies (dependency checking is described in more detail with respect to FIG. 10). If a direct or indirect dependency (i.e., an unresolved dependency) is found, the second string copy engine stops further processing of the second string copy command until the dependency is resolved (step 808). In this operation, the second string copy engine stops or delays processing the second string copy command until the first string copy command writes the portion of the first string required for the second string to the scratch array and / or history buffer.

[0062] The second string copy engine then obtains the second string from the recreated original data (step 810). In this operation (or previous dependency determination), the second string copy engine determines, based on the distance, a location in the scratch array or history buffer from which the second string is read, and thus the recreated original data to obtain for the second string. For example, the second string copy engine can use the distance to calculate a particular byte in an N-byte line of the scratch array or history buffer from which to begin reading the second string. The second string copy engine then sequentially reads one or more bytes of the second string from the scratch array and / or history buffer starting from a location in the scratch array or history buffer based on the length of the second string. At the end of this operation, the second string copy engine has a copy of one or more bytes of the second string.

[0063] The second string copy engine then appends the second string to the recreated original data (step 812). In this operation, the second string copy engine writes individual bytes of the recreated original data, the second string, to locations in the scratch array. Note that the second string copy command may write data to bytes in the scratch array beyond the current end of the recreated original data in the scratch array because one or more previous string copy commands and / or literal write commands may not have completed their respective writes to the string copy engine. However, it may occur that the second string copy engine only appends the recreated original data to the end of the existing recreated original data for the append operation. Furthermore, if the second string is sufficiently long and / or the scratch array is sufficiently full with previously recreated original data, the scratch array may migrate the recreated original data to the history buffer in a first-in-first-out order to free up one or more N-byte lines for the second string copy engine to continue writing recreated original data to the scratch array.

[0064] (The process of handling the scratch array and the recreated original data in the history buffer) In the described embodiment, the command buffer and string copy engines in the decompression subsystem write the recreated original data, i.e., literals and strings, to a scratch array and a history buffer, respectively. Once the recreated original data is written to the scratch array and history buffer, the data progresses or flows through the scratch array and history buffer to memory. FIG. 9 is a flowchart illustrating a process for storing the recreated original data in the scratch array and history buffer, according to some embodiments. It should be noted that the operations illustrated in FIG. 9 are provided as general examples of operations that may be performed by some embodiments. Operations performed by other embodiments include different operations, operations performed in a different order, and / or operations performed by different entities or functional blocks.

[0065] For the example of FIG. 9, the operations to move or migrate the data in the scratch array and / or history buffer are performed when the command buffer or string copy engine prepares to output bytes of the recreated original data. However, in some embodiments, the operations of FIG. 9 can be performed at any time. For example, in some embodiments, the operations of FIG. 9 are performed dynamically, such that as the recreated original data is written to a particular location in the scratch array and / or history buffer, the recreated original data is moved from other locations to prepare the other locations to receive the recreated original data. In this manner, the scratch array and / or history buffer are prepared to receive the recreated original data "on the fly." Generally, in the described embodiments, locations are made available to store bytes of the recreated original data in the scratch array and / or history buffer as needed. Also, although in the example of FIG. 9, the recreated original data is described as going or flowing to memory, this is merely an example. In some embodiments, the recreated original data goes or flows to another destination, such as a processing subsystem, a network interface, an IO device, etc. Note that once the compressed input data is decompressed, all of the reconstructed original data eventually travels or flows through the scratch array and history buffer to memory (or another entity), where the reconstructed original data is stored in memory for other operations, and the scratch array and history buffer are eventually emptied.

[0066] 9, the process begins when the command buffer or string copy engine prepares to output bytes of the recreated original data, step 900. For example, the command buffer may append a literal to the recreated original data, or the string copy command may append a string to the recreated original data.

[0067] Before the recreated original data can be written to the scratch array and / or history buffer, the decompression subsystem (e.g., controllers in or associated with the scratch array and / or history buffer) ensures that there is enough space in the scratch array and / or history buffer to store the data. For this operation, the decompression subsystem determines whether all N-byte lines in the scratch array are full (with previously recreated original data) (step 902). This may occur if previous literal write commands and / or string copy commands caused the command buffer and / or string copy engine to write enough data to the scratch array to fill a relatively small number of N-byte lines of the scratch array. Once all lines of the scratch array are full, the decompression subsystem determines whether all lines of the history buffer are full (step 904). Once all lines in the history buffer are full (step 904), the decompression subsystem moves or migrates bytes of data from one or more N-byte lines in the history buffer to memory (e.g., memory 404) to free up one or more N-byte lines in the history buffer (step 906). The decompressor subsystem moves or migrates bytes of data from one or more N byte lines in the scratch array to one or more N byte lines in the history buffer, step 908. At the end of this operation, sufficient space is available in the scratch array and / or history buffer to store the bytes of the reconstructed original data.

[0068] Next, the command buffer or string copy engine stores the byte of the reconstructed original data in the next byte of the given N byte line in the scratch array (step 910). In this operation, the command buffer or string copy engine stores the byte of the reconstructed original data in the given N byte line of the scratch array in order (recall that all reconstructed original data from the previous string copy command and / or the subsequent literal write command may not yet have been written to the previous byte of the N byte line, and thus the reconstructed original data is written to the N byte line "in order" from a particular position following one or more not yet valid bytes). If writing the byte to the given N byte line of the scratch array fills the given N byte line (step 912), i.e., if all the bytes of the given N byte line are full, the next N byte line of the scratch array is used as the given N byte line (step 914). In other words, when the given N byte line of the scratch array is full, the subsequent bytes of the reconstructed original data are written to the next N byte line of the scratch array. If there are no more bytes in the scratch array or history buffer to append to the recreated original data (i.e., all bytes of the recreated original data have been output by the command buffer or string copy engine) (step 916), the process ends. Otherwise, if there are more bytes of recreated original data (step 916), the process returns to step 902, where the scratch array and / or history buffer are checked to see if they are full (steps 902-908), after which the next byte is appended to the recreated original data (step 910).

[0069] (Process for checking dependencies) In described embodiments, string copy commands are checked for dependencies on strings written to the scratch array and / or history buffer by previous literal write commands and string copy commands. Figure 10 is a flow chart illustrating a process for checking dependencies on a string copy command, according to some embodiments. It should be noted that the operations illustrated in Figure 10 are provided as general examples of operations performed by some embodiments. Operations performed by other embodiments include different operations, operations performed in a different order, and / or operations performed by different entities or functional blocks.

[0070] The process of FIG. 10 begins when the functional blocks of the decompression subsystem maintain a record used to determine dependencies. More specifically, upon storing one or more bytes of the reconstructed original data into bytes of one or more N byte lines of the scratch array, a byte valid tracker (e.g., byte valid tracker 634) sets a byte valid indicator (e.g., byte valid indicator 638) associated with each of the one or more bytes to indicate that the associated byte stores reconstructed original data (step 1000). In this operation, the byte valid tracker sets the byte valid indicator in the byte valid array (e.g., byte valid array 636) to a value, such as 1, to indicate that the corresponding byte in the scratch array stores valid reconstructed original data. In addition, upon moving a byte of the reconstructed original data from the N byte line of the scratch array to the N byte line of the history buffer, a line counter (e.g., line counter 630) increments a line count indicating the number of N byte lines prepended to the reconstructed original data (step 1002). In this operation, as each N-byte line corresponding to the recreated original data is migrated from the scratch array to the history buffer, the line counter increments the line count, thereby updating the line count to maintain the number of N-byte lines present in the history buffer and memory (for lines migrated from the history buffer to memory).

[0071] The decompression subsystem then uses the records, i.e., the line count and the byte valid indicator, to determine whether there is a dependency on the string copy command that has not yet been resolved. In other words, the string copy engine (or another entity) uses the byte valid indicator and / or the line count to check for a direct or indirect dependency of the string copy command on a previous string of reconstructed original data (step 1004). In this operation, for a given string copy command, the string copy engine compares the distance and length of the previously obtained reconstructed original data string with the value of the line count to determine whether N byte lines containing the required data are present (or not) in the scratch array and / or history buffer. If the line count indicates that less reconstructed original data than necessary has been written to the scratch array and / or history buffer (and thus N byte lines are not yet present in the scratch array and / or history buffer), the string copy engine detects an unresolved dependency. Additionally, if the byte indicator indicates that bytes of reconstructed original data required by the string copy command are not yet present in the scratch array, the string copy engine detects an unresolved dependency. As described above, upon detecting an unresolved dependency, the string copy engine will halt processing of the string copy command so that any necessary recreated original data can be written to a scratch array and / or history buffer. In some embodiments, the suspension period is for a specified amount of time, such as until a particular byte is detected to be present (e.g., by periodically rechecking byte valid indicators and / or line counts, etc.), until the previous literal write command and / or string copy command is terminated, etc.

[0072] In some embodiments, at least one electronic device (e.g., electronic device 400) performs some or all of the operations described herein using code and / or data stored in a non-transitory computer-readable storage medium. More specifically, at least one electronic device reads the code and / or data from the computer-readable storage medium and executes the code and / or uses the data when performing the described operations. The computer-readable storage medium may be any device, medium, or combination thereof that stores code and / or data used by the electronic device. For example, the computer-readable storage medium may include, but is not limited to, volatile and / or non-volatile memory (e.g., flash memory, random access memory (e.g., eDRAM, RAM, SRAM, DRAM, DDR4 SDRAM, etc.), non-volatile RAM (e.g., phase change memory, ferroelectric memory, spin injection memory, magnetoresistive memory, etc.), read-only memory (ROM), and / or magnetic or optical storage media (e.g., disk drives, magnetic tapes, CDs, DVDs, etc.)).

[0073] In some embodiments, one or more hardware modules perform the operations described herein. For example, the hardware modules may include, but are not limited to, one or more processors / cores / central processing units (CPUs), application specific integrated circuits (ASICs) chips, neural network processors or accelerators, field programmable gate arrays (FPGAs), decompression and / or decoding subsystems, computational units, embedded processors, graphics processors (GPUs) / graphics cores, pipelines, accelerated processing units (APUs), functional blocks, controllers, accelerators, and / or other programmable logic devices. When such hardware modules are activated, the hardware modules perform some or all of the operations. In some embodiments, the hardware modules include one or more general purpose circuits configured to perform the operations by executing instructions (program code, firmware, etc.).

[0074] In some embodiments, data structures representing some or all of the structures and mechanisms described herein (e.g., electronic device 400 or portions thereof) are stored in a non-transitory computer-readable storage medium that includes a database or other data structure that can be read by the electronic device and used directly or indirectly to manufacture hardware including the structures and mechanisms. For example, the data structure may be a behavioral or register transfer level (RTL) description of the hardware functionality in a high-level design language (HDL) such as Verilog or VHDL. This description may be read by a synthesis tool, which may synthesize the description to generate a netlist from a synthesis library that includes a list of gates / circuit elements that represent the functionality of the hardware including the structures and mechanisms described above. The netlist may then be placed and routed to generate a data set that describes the geometry to apply to a mask. The mask may then be used in various semiconductor manufacturing steps to manufacture one or more semiconductor circuits (e.g., integrated circuits) corresponding to the structures and mechanisms described above. Alternatively, the database on the computer-accessible storage medium may be a netlist (with or without a synthesis library) or a data set, or a Graphics Data System (GDS) II data, as appropriate.

[0075] In this specification, variables or unspecified values ​​(i.e., general descriptions of values ​​without specific examples of values) are represented by letters such as N, M, and X. Although similar letters may be used in different places in this specification, the variables and unspecified values ​​in each case are not necessarily the same, i.e., there may be different variable amounts and values ​​for some or all of the general variables and unspecified values. In other words, N and any other letters used to represent variables and unspecified values ​​in this specification are not necessarily related to each other.

[0076] As used herein, the phrase "etc.," or "e.g.," is intended to indicate the equivalent of "and / or," i.e., "at least one" of the elements in the list with which the "e.g." is associated. For example, in the sentence "the electronic device performs a first operation, a second operation, etc.," the electronic device performs at least one of the first operation, the second operation, and other operations. Furthermore, the elements in the list with which the "e.g." is associated are merely examples from a series of examples, and at least some of the examples may not appear in some embodiments.

[0077] The foregoing descriptions of the embodiments have been presented for purposes of illustration and description only. They are not intended to be exhaustive or to limit the embodiments to the precise forms disclosed. Accordingly, numerous modifications and variations will be apparent to those skilled in the art. Moreover, the above disclosure is not intended to limit the embodiments. The scope of the embodiments is defined by the appended claims.

Claims

1. 1. An electronic device for decompressing compressed data to recreate the data from which the compressed data was derived, comprising: a scratch array arranged to store reconstructed original data, said reconstructed original data being created by processing at least one command to decompress said compressed data; a history buffer arranged to store said recreated original data; a first string copy engine; a second string copy engine; The first string copy engine comprises: Obtaining a first string from the recreated original data; appending the first string to the recreated original data; Process the first string copy command by The second string copy engine: checking whether a second string copy command has a direct dependency on the first string based on information in the scratch array and records indicating recreated original data currently stored in the history buffer, where the direct dependency occurs when the second string copy command takes bytes from the first string, and if there is a direct dependency, stopping further processing of the second string copy command until the first string copy engine appends a corresponding portion of the first string to the recreated original data; Obtaining a second string from the recreated original data; and appending the second string to the recreated original data; and processing the second string copy command by Electronic devices.

2. The second string copy engine, when processing the second string copy command, checking whether the second string copy command has an indirect dependency on the first string, which occurs when the second string copy command obtains one or more bytes from a literal that was appended to the recreated original data based on an intervening literal write command between the first string copy command and the second string copy command, and if there is an indirect dependency, halting further processing of the second string copy command until the literal is appended to the recreated original data. The electronic device of claim 1.

3. The scratch array according to claim 2, wherein the scratch array includes sequential logical storage elements for storing X distinct N-byte lines of the recreated original data; the history buffer includes memory elements for storing Y distinct N-byte lines of reconstructed original data, Y being a number greater than X; The electronic device of claim 1.

4. Adding a predetermined character string to the recreated original data when X number of N byte lines of the scratch array are full, moving previously reconstructed original data from one or more N byte lines of the scratch array to one or more N byte lines of the history buffer in first-in-first-out order to free up the one or more N byte lines of the scratch array for storing bytes of reconstructed original data from the given string; storing bytes of the predetermined string in order into bytes of the one or more N byte lines of the scratch array; The electronic device of claim 3.

5. Further comprising a memory; Adding the predetermined character string to the recreated original data when Y number of N-byte lines of said history buffer are full, moving previously reconstructed original data from one or more N-byte lines of said history buffer to said memory in first-in, first-out order to free up said one or more N-byte lines of said history buffer for storing bytes of reconstructed original data being moved from said scratch array to said history buffer.

5. The electronic device of claim 4.

6. a line counter that stores a line count, the line count indicating a number of N-byte lines previously appended to the recreated original data, and the line counter increments the line count when an N-byte line is moved from the scratch array to the history buffer; a byte valid tracker that stores byte valid indicators, the byte valid indicators including a byte valid indicator for each byte of the X number of N byte lines of the scratch array, each byte valid indicator indicating whether a corresponding byte of the scratch array currently stores valid reconstructed original data, the byte valid tracker setting a byte valid indicator when a byte of reconstructed original data is stored into the corresponding byte of the scratch array and clearing a byte valid indicator when a byte of reconstructed original data is moved from the corresponding byte in the scratch array to the history buffer.

5. The electronic device of claim 4.

7. The second string copy engine: if the line counter indicates that the number of lines currently stored in the scratch array and / or the history buffer is not large enough to contain the second string; or if the byte valid indicator indicates that one or more bytes of the second string are not already present in the scratch array, determining that the second string copy command has a dependency relationship; The electronic device of claim 6.

8. When processing a string copy command, obtaining a predetermined string from the recreated original data includes: determining a position in the scratch array or the history buffer using a distance obtained from the string copy command; using a string length obtained from the string copy command to determine the number of bytes of recreated original data to be read from the scratch array and / or the history buffer; reading said number of bytes of said recreated original data sequentially from said scratch array and / or said history buffer, starting from said location in said scratch array or said history buffer; The electronic device of claim 3.

9. the sequential logic storage elements of the scratch array include flip-flops and / or latches; the memory elements of the history buffer include static random access (SRAM) memory elements; The electronic device of claim 3.

10. A command processor is further provided, The command processor includes: Receiving a literal write command; Obtaining a literal value identified in the literal write command; appending the literal value to the recreated original data; The device is configured to: The addition includes: storing the literal value in one or more designated bytes of one or more N-byte lines of the scratch array, said storing including, when all X N-byte lines of the scratch array are full, moving bytes of recreated original data from the scratch array to the history buffer to free up the one or more N-byte lines of the scratch array. The electronic device of claim 3.

11. Further comprising at least one command generator; the at least one command generator receives a string copy command and forwards the string copy command to the first string copy engine and the second string copy engine for processing in a round robin manner. The electronic device of claim 1.

12. Further comprising at least one command generator; the at least one command generator receives a string copy command and forwards the string copy command to the first string copy engine and the second string copy engine for processing when each of the first string copy engine and the second string copy engine becomes available to process the string copy command. The electronic device of claim 1.

13. 1. In an electronic device comprising: a first string copy engine; a second string copy engine; a scratch array arranged to store recreated original data, said recreated original data being created by processing at least one command to decompress the compressed data; and a history buffer arranged to store said recreated original data, comprising: The first string copy engine, Obtaining a first string from the recreated original data; appending the first string to the recreated original data; processing a first string copy command by The second string copy engine, checking whether a second string copy command has a direct dependency on the first string based on information in the scratch array and records indicating recreated original data currently stored in the history buffer, where the direct dependency occurs when the second string copy command takes bytes from the first string, and if there is a direct dependency, stopping further processing of the second string copy command until the first string copy engine appends a corresponding portion of the first string to the recreated original data; Obtaining a second string from the recreated original data; and appending the second string to the recreated original data; and processing the second string copy command by method.

14. The second string copy engine processes the second string copy command, checking whether the second string copy command has an indirect dependency on the first string, where the indirect dependency occurs when the second string copy command obtains one or more bytes from a literal that was appended to the recreated original data based on an intervening literal write command between the first string copy command and the second string copy command, and if there is an indirect dependency, halting processing of the second string copy command until the literal is appended to the recreated original data.

14. The method of claim 13.

15. The scratch array according to claim 1, further comprising: sequential logical storage elements for storing X distinct N-byte lines of the reconstructed original data; the history buffer includes memory elements for storing Y distinct N-byte lines of reconstructed original data, Y being a number greater than X; Adding a predetermined character string to the recreated original data when X number of N byte lines of the scratch array are full, moving previously reconstructed original data from one or more N byte lines of the scratch array to one or more N byte lines of the history buffer in first-in-first-out order to free up the one or more N byte lines of the scratch array for storing bytes of reconstructed original data from the given string; storing bytes of the predetermined string in order into bytes of the one or more N byte lines of the scratch array; 14. The method of claim 13.

16. the electronic device comprises a memory; Adding a predetermined character string to the recreated original data when Y number of N-byte lines of said history buffer are full, moving previously reconstructed original data from one or more N-byte lines of said history buffer to said memory in first-in, first-out order to free up said one or more N-byte lines of said history buffer for storing bytes of reconstructed original data being moved from said scratch array to said history buffer.

16. The method of claim 15.

17. The electronic device comprises: a line counter that stores a line count, the line count indicating the number of N-byte lines previously appended to the recreated original data; a byte valid tracker storing byte valid indicators, the byte valid indicators including a byte valid indicator for each byte of X N-byte lines of the scratch array, each byte valid indicator indicating whether a corresponding byte of the scratch array currently stores valid reconstructed original data; The method comprises: when an N byte line is moved from the scratch array to the history buffer, the line counter increments the line count; said byte valid tracker setting a byte valid indicator when storing a byte of recreated original data into said corresponding byte of said scratch array; and when a byte of recreated original data is moved from the corresponding byte in the scratch array to the history buffer, the byte valid tracker clears a byte valid indicator.

16. The method of claim 15.

18. The second string copy engine, if the line counter indicates that the number of lines currently stored in the scratch array and / or the history buffer is not large enough to contain the second string; or if the byte valid indicator indicates that one or more bytes of the second string are not already present in the scratch array, determining that the second string copy command has a dependency relationship; 20. The method of claim 17.

19. The electronic device comprises: a scratch array including sequential logical storage elements for storing X distinct N-byte lines of the reconstructed original data; a history buffer including memory elements for storing Y distinct N-byte lines of the reconstructed original data, Y being a number greater than X; When processing a string copy command, obtaining a predetermined string from the recreated original data includes: determining a position in the scratch array or the history buffer using a distance obtained from the string copy command; using a string length obtained from the string copy command to determine the number of bytes of recreated original data to be read from the scratch array and / or the history buffer; reading said number of bytes of said recreated original data sequentially from said scratch array and / or said history buffer, starting from said location in said scratch array or said history buffer; 14. The method of claim 13.

20. The electronic device comprises: a scratch array including sequential logical storage elements for storing X distinct N-byte lines of the reconstructed original data; a history buffer including memory elements for storing Y distinct N-byte lines of the reconstructed original data, Y being a number greater than X; the sequential logic storage elements of the scratch array include flip-flops and / or latches; the history buffer memory elements include static random access (SRAM) memory elements; 14. The method of claim 13.

21. The electronic device comprises: A command processor; a scratch array including sequential logical storage elements for storing X distinct N-byte lines of the reconstructed original data; a history buffer including memory elements for storing Y distinct N-byte lines of the reconstructed original data, Y being a number greater than X; The method comprises: the command processor receiving a literal write command; the command processor obtaining a literal value identified in the literal write command; the command processor appending the literal value to the recreated original data; The addition includes: storing the literal value in one or more designated bytes of one or more N-byte lines of the scratch array, said storing including, when all X N-byte lines of the scratch array are full, moving bytes of recreated original data from the scratch array to the history buffer to free up the one or more N-byte lines of the scratch array.

16. The method of claim 15.

Images