Command processor with multiple string copying engines for decompression systems

Abstract

An electronic device for decompressing compressed data to recreate the original data includes a first string copying engine and a second string copying engine. The first string copying engine processes a first string copying command by: obtaining a first string from the recreated original data; and appending the first string to the recreated original data. The second string copying engine processes a second string copying command by: checking the dependency of the second string copying command on the first string, and stopping further processing of the second string copying command when the dependency is found, until the first string copying engine appends the corresponding portion of the first string to the recreated original data. The second string copying engine processes the second string copying command by obtaining a second string from the recreated original data and appending the second string to the recreated original data.

Description

Technical Field

[0001] The present invention generally relates to electronic devices, and more particularly, to electronic devices and methods for decompressing compressed data to recreate the original data from which the compressed data was generated. Background Technology

[0002] Some electronic devices perform operations to compress data, such as user or system files, data streams, or sequences. Electronic devices can compress data to reduce its size, enabling more efficient storage in memory, facilitating data transfer between electronic devices over a network, and so on. For example, electronic devices can use dictionary encoding standards such as Lempel Ziv-77 (LZ77), LZ78, or Lempel-Ziv-Welch (LZW) to generate compressed data from raw data.

[0003] While data compression can improve the efficiency of storing and processing data, compressed data must be decompressed before it can be used for many operations. This means that before such operations can be performed, electronic devices must perform actions to reverse the effects of compression, and thus restore or recreate the original data. In many electronic devices, software (i.e., software routines, applications, etc.) is used to decompress compressed data. Decompressing compressed data using software typically requires a general-purpose processor, such as a central processing unit (CPU), to perform a large number of decompression operations and associated memory accesses. Due to the large number of decompression operations and memory accesses, decompression using software is inefficient. Summary of the Invention

[0004] According to the present invention, in the described embodiment, the electronic device includes a decompression subsystem functional block that performs operations for decompressing 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 for processing commands (such as text write commands and string copy commands) 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., completely or partially simultaneously). Therefore, the described embodiment can efficiently generate strings to decompress the compressed data when processing string copy commands. Since the string copy command can copy the strings appended to the recreated original data by previous string copy commands, dependencies can exist between the two or more string copy commands executed substantially in parallel in the two or more string copy engines. Therefore, the command processor also includes mechanisms for ensuring that dependencies between string copy commands are properly handled by the two or more separate string copy engines.

[0005] In some implementations, as the recreated original data flows through the register array and the history buffer to or forward to memory, a tracking mechanism is used to track the following: (1) the number of N-byte rows that have been moved from the register array to the history buffer, and (2) the bytes in the register array currently storing valid data. The tracking mechanism includes a row counter that stores a row count indicating the number of N-byte rows of the recreated original data that have been moved from the register array to the history buffer. The row counter increments the row count each time an N-byte row is moved from the register array to the history buffer. Therefore, the row count indicates the total number of N-byte rows of previously recreated original data currently stored in the history buffer and memory. The tracking mechanism also includes a byte validity tracker that stores a set of byte validity indicators, one of which is associated with each byte in an N-byte row in the register array. When the recreated original data is written to each byte in the register array, the command processor sets the corresponding byte validity indicator to indicate that valid recreated original data is present in that byte. When recreating data is moved from the register array to the history buffer, the command processor clears the corresponding byte validity indicator to indicate that there is no valid recreated original data in that byte (and therefore the byte is empty, invalid, etc.).

[0006] As mentioned above, dependencies can arise between string copy commands. Generally, dependencies occur because string copy commands can be executed largely in parallel, and therefore a string copy command can copy strings appended to the recreated original data by earlier string copy commands and / or text write commands that have not yet completed processing. A "direct" dependency occurs when a string copy command copies strings appended to the recreated original data by earlier string copy commands. An "indirect" dependency occurs when a string copy command copies strings appended to the recreated original data by text write commands that stopped processing when earlier string copy commands completed (and therefore the string copy command indirectly depends on earlier string copy commands).

[0007] The aforementioned tracking mechanism ensures that dependencies between string copy commands are handled appropriately. The string copy engine uses line counting to quickly determine if the string to be copied by the string copy command from the recreated original data at a specified distance back exists in the history buffer and / or scratchpad array, and therefore ensures that there are no unresolved dependencies between the string copy command and previous string copy commands. The string copy engine also uses byte validity indicators in the byte validity array to ensure proper handling of dependencies. More specifically, assuming the line count indicates that an appropriate number of lines exist in the scratchpad array and history buffer, the string copy engine uses byte validity indicators to determine if the string to be copied from the scratchpad array by the string copy command exists and is ready to be copied from the scratchpad array.

[0008] 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 implementation uses hardware to efficiently and quickly perform decompression operations that existing devices perform using software. Compared to performing the same operations using software entities, the decompression subsystem is faster and more efficient (e.g., requiring fewer memory accesses, using less power, etc.). Furthermore, by using line counting and byte validity indicators, the described implementation is able to efficiently detect and handle dependencies between string copy commands, enabling the substantially parallel processing of string copy commands within the string copy engine. Using the decompression subsystem frees up other functional blocks in the electronic device (e.g., processing subsystems, etc.) to perform other operations. Therefore, the decompression subsystem improves the overall performance of the electronic device, which in turn increases user satisfaction. Attached Figure Description

[0009] Figure 1 A block diagram illustrating compressed data according to some implementation schemes is presented.

[0010] Figure 2 A block diagram illustrating text writing commands according to some implementation schemes is presented.

[0011] Figure 3 A block diagram illustrating a string copy command according to some implementation schemes is presented.

[0012] Figure 4 A block diagram illustrating an electronic device according to some embodiments is presented.

[0013] Figure 5 A block diagram illustrating a decompression subsystem according to some implementation schemes is presented.

[0014] Figure 6 A block diagram illustrating a command processor according to some implementation schemes is presented.

[0015] Figure 7 A block diagram is presented illustrating rows from a register array and corresponding byte validity indicators according to some implementation schemes.

[0016] Figure 8 A flowchart illustrating a process for decompressing compressed input data according to some implementation schemes is presented.

[0017] Figure 9 A flowchart illustrating a process for storing recreated original data in a scratchpad array and a history buffer, according to some implementation schemes, is presented.

[0018] Figure 10 A flowchart illustrating a process for checking the dependencies of a string copy command according to some implementation schemes is presented.

[0019] Throughout the accompanying drawings and description, similar reference numerals refer to the same elements. Detailed Implementation

[0020] 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 apparent to those skilled in the art, and the general principles defined herein can be applied to other embodiments and applications. Therefore, the described embodiments are not limited to the embodiments shown, but are to be given the widest scope consistent with the principles and features disclosed herein.

[0021] the term

[0022] In the following description, various terms are used to describe the implementation scheme. The following is a simplified and general description of one of these terms. It should be noted that the term may have important additional aspects, which are not stated herein for clarity and brevity, and therefore this description is not intended to limit the terminology.

[0023] Functional Block: A functional block refers to a group, set, and / or collection of one or more interconnected circuit elements (such as integrated circuit elements, discrete circuit elements, etc.). Circuit elements are "interconnected" because they share at least one property. For example, interconnected circuit elements may be included in, fabricated on, or otherwise coupled to a particular integrated circuit chip or portion thereof, may participate in performing a given function (computing or processing function, memory function, etc.), may be controlled by a common control element and / or common block, 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., an integrated circuit memory).

[0024] Compressed data

[0025] In the described embodiments, operations are performed on compressed data and the compressed data is used to perform operations. Generally, compressed data is the output of one or more compression and / or other operations on original data, which cause at least some of the original data to be replaced by other values ​​that are commanded and / or can be used to recreate the original data. In the described embodiments, various types of data can be compressed, including user or system files (e.g., audio and / or video files, document files, executable files, operating system files, etc.), data streams or sequences (e.g., audio and / or video data streams, data sequences received via a network interface, etc.), data captured from sensors (e.g., cameras and / or microphones, thermometers, vibration sensors, etc.), etc. In the described embodiments, numerous compression standards, algorithms, or formats, or combinations thereof, can be used to compress data, including dictionary encoding standards such as Lempel Ziv-77 (LZ77), LZ78, or Lempel-Ziv-Welch (LZW).

[0026] As used herein, the terms “compressed data” and “compression” broadly apply to operations on raw data that result in at least some of the raw data being replaced by commands and / or other values ​​that can be used to recreate the raw data. As mentioned above, these operations include various encoding standards, algorithms, or formats, or combinations thereof. Therefore, these terms should not be interpreted as limited to operations such as dictionary-encoded compression and / or other operations that can sometimes be considered “compression” operations.

[0027] Figure 1 A block diagram illustrating compressed data according to some implementation schemes is presented. For example, in Figure 1 As can be seen, compressed data 100 includes a set of data 102 (i.e., series, sequences, etc.), which may be files, data streams, or sequences, or be included in files, data streams, or sequences. Generally, each command in command 102 includes, identifies, and / or refers to information that can be used to obtain and / or generate strings (i.e., bits, characters, numbers, etc.), also referred to as "symbols," which will be appended to the recreated original data during the decompression operation. In some embodiments, each command includes a set of bits organized to represent and / or identify the string that can be used to obtain and / or generate the command. In some embodiments, the information in a command refers to information outside the command itself, such as information about a separate source from which the command value is to be obtained, information that will be used for calculations associated with the command, references to tables, records, or other data structures, etc.

[0028] In some implementations, the commands include text writing commands and string copy commands. Figure 2 A block diagram illustrating a text write command 200 according to some embodiments is presented. The text write command 200 includes a command identifier (CMD) that, when processed in a decompression subsystem, causes the decompression subsystem to acquire a text (text) of a specified length (e.g., in bits, bytes, etc.) and append the text to the recreated original data. (Although shown as...) Figure 2 The text is written into part of command 200, but in some implementations, the text may be stored separately, such as in another part or block of compressed data 100. Figure 1 In the example above, the L1 literal write command causes the decompression subsystem to retrieve the first byte string, such as the character 'A', and append that first byte string to the recreated output data. The 'append' instruction, as used herein, adds a given string to the previously created raw data (using...). Figure 2 The command (not shown) is used to recreate the sequence at the end, or as the initial string in the newly recreated data (when the command is the first command in the compressed data). Continue Figure 1 In the example, the L2 to L5 literal write commands cause the second to fifth byte strings, such as the characters B, C, D, and E, to be retrieved and appended to the recreated original data at the corresponding positions.

[0029] Figure 3A block diagram illustrating a string copy command 300 according to some embodiments is presented. The string copy command 300 includes a command identifier (CMD) that, when processed by the decompression subsystem, causes the decompression subsystem to retrieve a string of a specified length (length, e.g., in bits, bytes, etc.) from the previously recreated original data, backwards at a distance (distance), and appends the data to the recreated original data. Generally, the string copy command enables the decompression subsystem to copy strings of various lengths (possibly from minimum to maximum string length) from previously created original data and append copies of the strings to the end of the recreated original data. For Figure 1 For example, the S1 string copy command causes the decompression subsystem to copy a string (i.e., B and C) consisting of a combination of text appended three bytes back from the previously recreated original data by the text write commands L2 and L3, and appends the copied string to the recreated original data (after the text appended to the recreated data by the text write command L4). After processing the S1 string copy command, the recreated original data is as follows: ABCDBC. The S2 string copy command causes the decompression subsystem to obtain a copy of the string consisting of the L4 text and the S1 string (i.e., DBC) and add the copy of the string to the recreated original data. After processing the S2 string copy command, the recreated original data is as follows: ABCDBCEDBC. The S3 string copy command causes the decompression subsystem to obtain a copy of the string consisting of the L5 text and the S2 string (i.e., EDBC) and add the copy of the string to the recreated original data. After processing the S3 string copy command, the recreated original data is as follows: ABCDBCEDBCEDBC. (The rest of the text appears to be a continuation of the previous sentence and can be left as is.) Figure 1 As seen in the example, the string copy command can be used to copy both the text and the previous string, individually or in combination, and append them to the recreated original data.

[0030] Although a specific sequence of commands is shown in compressed data 100, in some embodiments, the compressed data may include commands of different sequences and / or types. Generally, compressed data 100 includes sufficient commands to implement the operations described herein. Additionally, although various fields and information are shown as included in text write command 200 and string copy command 300, in some embodiments, text write command 200 and string copy command 300 include different information and / or information arranged differently. Generally, text write command 200 and string copy command 300 include sufficient information to implement the operations described herein. Furthermore, although in the description… Figure 1One-byte literals are used as examples, but literals of other lengths can be used. For example, in some implementations, literals up to two bytes are permitted. Additionally, in some implementations, a minimum string length is used for string copy commands based on a compression standard, algorithm, or format, or a combination thereof, and / or for other reasons. For example, in some implementations, the minimum string length is three bytes (and therefore, the shortest permitted string is three bytes).

[0031] In some implementations, string copy commands are permitted to copy strings from a "dictionary" defined by and therefore including a finite amount of recreated original data. In these implementations, for a string copy command, there are limitations on how far back in the recreated original data the string can be retrieved before it is no longer part of the dictionary. For example, in some implementations, the dictionary comprises a sliding window of previously recreated original data of 32kB, 1kB, or another amount. In other words, and assuming a 64kB dictionary, even in the case of more than 64kB of previously recreated original data, only the most recently generated 64kB of strings from the recreated original data can be retrieved for the string copy command.

[0032] In some implementations, during the compression operation, the electronic device generates compressed data (e.g., compressed data 100) from the original data by using a sliding window (e.g., a 32kB sliding window) to navigate through the original data in a segment and determining a dictionary for each segment that includes the data in that segment. As the compressed data for each segment, the electronic device then generates a sequence of text write commands that append text values ​​of unique strings to the recreated original data, and / or generates string copy commands that take a copy of the string from the previously recreated original data (i.e., the dictionary) and append the copy of the string to the recreated original data. In some implementations, and as described above, during the decompression operation, commands are retrieved from the compressed data and used to recreate the original data using the same dictionary / sliding window / segment.

[0033] Overview

[0034] In the described embodiment, the electronic device includes a decompression subsystem function block that performs operations to decompress compressed data to recreate the original data from which the compressed data was generated. The decompression subsystem includes a command processor function block that performs operations to process commands (such as text write commands and string copy commands) to recreate the original data. The command processor includes two or more separate string copy engine function blocks that enable the command processor to execute two or more string copy operations substantially in parallel (i.e., completely or partially simultaneously). Therefore, the described embodiment can efficiently generate strings to decompress compressed data when processing string copy commands. Since string copy commands can copy strings appended to the recreated original data by previous string copy commands, dependencies can exist between two or more string copy commands executed substantially in parallel in the two or more string copy engines. Therefore, the command processor also includes mechanisms to ensure that dependencies between string copy commands are properly handled by the two or more separate string copy engines.

[0035] In the described implementation, data compression is performed using a dictionary encoding standard (e.g., LZ77, LZ78, etc.), wherein a string copy operation obtains a copy of a string longer than a specified minimum length from the previously recreated original data and appends the copy of the string to the recreated original data. For example, Figure 1The string copy command S1 copies the string BC from the previously recreated original data and appends the string to the recreated original data. In some implementations, the string copy operation is limited to a specified block or portion of the previously recreated data used to retrieve the string, sometimes referred to as a "dictionary". For example, in some implementations, a K-byte sliding window (e.g., 32kB, 1kB, etc.) is used as the dictionary, meaning that the string can only be copied back up to K bytes from the recreated original data. In some implementations, the command processor includes mechanisms for locally storing copies of the strings currently in the dictionary. These mechanisms include register arrays and history buffers, where the strings are stored in N-byte rows (e.g., 32-byte rows, 50-byte rows, etc.). Register arrays that store only a few (e.g., 4, 6, etc.) of the N-byte rows most recently written to the recreated original data are implemented using sequential logic storage elements (e.g., flip-flops, latches, etc.) more directly coupled to the string engine. Thus, the string copy engine can quickly copy bytes of the string from the N-byte rows stored in the register array, for example, within a single cycle of the control clock. The history buffer, which stores the remainder of an N-byte line (e.g., 1020, 1200, etc.), is implemented using memory elements (e.g., synchronous random access memory (SRAM) elements, dynamic random access memory (DRAM) elements, etc.). Copying a string from an N-byte line in the history buffer is slower than copying a string from a scratchpad array (e.g., six cycles of the control clock), but faster than using remote memory (such as main memory in an electronic device) to store and copy N-byte lines from a dictionary.

[0036] In some implementations, during operation, the recreated original data flows from the register array to or advances to the history buffer and then into the main memory of the electronic device as text values ​​from processing text write commands or copied strings from processing string copy commands are appended to the recreated original data. In other words, as the command processor appends text values ​​or strings to the recreated original data, the command processor stores individual bytes of the text values ​​or strings into one or more N-byte rows in the register array. When the N-byte rows in the register array are full, the command processor moves (or “migrates”) bytes of the recreated original data from one or more N-byte rows in the register array to available N-byte rows in the history buffer in a first-in-first-out (FIFO) order. Moving rows from the register array frees up one or more N-byte rows in the register array for storing subsequent text values ​​or copied strings generated by the command processor. When the N-byte rows in the history buffer are full, the command processor moves (or “migrates”) bytes of the recreated original data from one or more N-byte rows in the history buffer to memory in a first-in-first-out (FIFO) order. This frees up one or more N-byte rows in the history buffer to store the recreated original data received from the scratchpad array. In some implementations, the N-byte rows are immediately copied from the history buffer to memory (and therefore these implementations do not wait for the history buffer to fill up before writing rows to memory), but are retained in the history buffer until they are overwritten by other N-byte rows when the history buffer is full. These implementations avoid the complexities caused by memory system overload or other delays in moving rows from the history buffer to memory.

[0037] In some implementations, as the recreated original data flows through the register array and the history buffer to or forward to memory, a tracking mechanism is used to track the following: (1) the number of N-byte rows that have been moved from the register array to the history buffer, and (2) the bytes in the register array currently storing valid data. The tracking mechanism includes a row counter that stores a row count indicating the number of N-byte rows of the recreated original data that have been moved from the register array to the history buffer. The row counter increments the row count each time an N-byte row is moved from the register array to the history buffer. Therefore, the row count indicates the total number of N-byte rows of previously recreated original data currently stored in the history buffer and memory. The tracking mechanism also includes a byte validity tracker that stores a set of byte validity indicators, one of which is associated with each byte in an N-byte row in the register array. When the recreated original data is written to each byte in the register array, the command processor sets the corresponding byte validity indicator to indicate that valid recreated original data is present in that byte. When recreating data is moved from the register array to the history buffer, the command processor clears the corresponding byte validity indicator to indicate that there is no valid recreated original data in that byte (and therefore the byte is empty, invalid, etc.).

[0038] As mentioned above, dependencies can arise between string copy commands. Generally, dependencies occur because string copy commands can be executed largely in parallel, and therefore a string copy command can copy strings appended to the recreated original data by earlier string copy commands and / or text write commands that have not yet completed processing. A "direct" dependency occurs when a string copy command copies strings appended to the recreated original data by earlier string copy commands. An "indirect" dependency occurs when a string copy command copies strings appended to the recreated original data by text write commands that stopped processing when earlier string copy commands completed (and therefore the string copy command indirectly depends on earlier string copy commands).

[0039] The aforementioned tracking mechanism ensures that dependencies between string copy commands are handled appropriately. The string copy engine uses line counting to quickly determine if the string to be copied by the string copy command from the recreated original data at a specified distance back exists in the history buffer and / or scratchpad array, and therefore ensures that there are no unresolved dependencies between the string copy command and previous string copy commands. The string copy engine also uses byte validity indicators in the byte validity array to ensure proper handling of dependencies. More specifically, assuming the line count indicates that an appropriate number of lines exist in the scratchpad array and history buffer, the string copy engine uses byte validity indicators to determine if the string to be copied from the scratchpad array by the string copy command exists and is ready to be copied from the scratchpad array.

[0040] 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 implementation uses hardware to efficiently and quickly perform decompression operations that existing devices perform using software. Compared to performing the same operations using software entities, the decompression subsystem is faster and more efficient (e.g., requiring fewer memory accesses, using less power, etc.). Furthermore, by using line counting and byte validity indicators, the described implementation is able to efficiently detect and handle dependencies between string copy commands, enabling the substantially parallel processing of string copy commands within the string copy engine. Using the decompression subsystem frees up other functional blocks in the electronic device (e.g., processing subsystems, etc.) to perform other operations. Therefore, the decompression subsystem improves the overall performance of the electronic device, which in turn increases user satisfaction.

[0041] Electronic devices

[0042] Figure 4 A block diagram illustrating an electronic device 400 according to some embodiments is presented. (See also...) Figure 4 As can be seen, electronic device 400 includes processor 402 and memory 404. Processor 402 is a functional block that performs calculations, decompression, and other operations in electronic device 400. Processor 402 includes processing subsystem 406 and decompression subsystem 408. Processing subsystem 406 includes one or more functional blocks that perform general-purpose calculations, decompression, and other operations, 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).

[0043] The decompression subsystem 408 is a function block that performs operations to decompress compressed input data. Generally, the decompression subsystem 408 takes compressed input data generated based on the original data as input and returns a string (or symbol) as output, which is a sequence of one or more bits, characters, numbers, etc., used to recreate the original data. Based on the arrangement of internal components within the decompression subsystem 408 (e.g., multiple separate string copying engines and / or command buffers within the decompression subsystem 408), the decompression subsystem 408 generates up to a specified number of strings from the blocks of compressed data in each time interval (e.g., two strings per clock cycle, three strings every 333 ps, etc.). The decompression subsystem 408 is described in more detail below.

[0044] Memory 404 is a functional block that performs operations on a memory (e.g., main memory) in electronic device 400. Memory 404 includes: memory circuitry (i.e., storage elements, access elements, etc.) for storing data and instructions for use by the functional blocks in electronic device 400; and control circuitry for handling access to data and instructions in the memory circuitry (e.g., reading, writing, checking, deleting, invalidating, etc.). The memory circuitry in 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 combinations thereof.

[0045] Electronic device 400 is shown using a specific number and arrangement of elements (e.g., functional blocks and devices such as processor 402, memory 404, etc.). However, for illustrative purposes, electronic device 400 is simplified. In some embodiments, electronic device 400 contains a different number or arrangement of elements. For example, electronic device 400 may include a power subsystem, a display, etc. Generally, electronic device 400 includes sufficient elements to perform the operations described herein.

[0046] Although the decompression subsystem 408 is in Figure 2 While shown as being included in processor 402, in some embodiments, the decompression subsystem 408 is a separate and / or independent functional block. For example, the decompression subsystem 408 may be implemented on a separate integrated circuit chip or the like (either independently or together with supporting circuit elements and functional blocks). Generally, in the described embodiments, the decompression subsystem 408 is suitably housed in electronic device 400 to enable the performance of the operations described herein.

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

[0048] decompression subsystem

[0049] In the described implementation, the decompression system in 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). Figure 5 A block diagram illustrating a decompression subsystem 408 according to some embodiments is presented. (See also...) Figure 5 As can be seen, the decompression subsystem 408 includes a command generator 500 and a command processor 502. The command generator 500 is a function block that performs operations to extract commands 506 and text 508 from the compressed input data 504 and provide the commands 506 and text 508 to the command processor 502. The command processor 502 is a function block that performs operations to process the commands 506 and text 508 received from the command generator 500 to generate corresponding strings or symbols for the recreated original data 510 provided to the receiving entity (e.g., processing subsystem 406, memory 404, network subsystem, sensor subsystem, etc.).

[0050] During operation, the command generator 500 receives compressed input data 504 from a source entity (e.g., processing subsystem 406, memory 404, network subsystem, I / O device, etc.). The compressed input data 504 is or includes a sequence or stream of bits having information for generating, acquiring, and / or retrieving commands 506 and text 508. For example, in some embodiments, the compressed input data 504 is arranged similarly to compressed input 100. The command generator 500 then performs operations for generating, acquiring, and / or retrieving commands 506 and text 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 text 508 from the compressed input data 504, or otherwise generates, acquires, or retrieves commands 506 and text 508.

[0051] In some implementations, for each text write command or string copy command, command generator 500 locates a command identifier in compressed input data 504, such as in a specified set of bits at an initial position in compressed input data 504 or 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, for a text write command (e.g., text write command 200), in some implementations, command processor 502 determines that the command identifier identifies the command as a text write command (e.g., including bits of a specified arrangement). Command processor 502 then extracts or obtains the length of the text and a string or symbol of the text itself (which may be one or more bytes up to a specified limit) from subsequent bits in compressed input data 504. Command generator 500 then transmits command 506 and text 508 (if any) to command processor 502, for example, via one or more parallel or serial communication signal lines or lines. For example, assuming the command is a string copy command 300, the command generator 500 conveys to the command processor 502 the instruction that the command is a string copy command, the distance back from the original data from which the string is copied (e.g., the number of bits or bytes, the number used to calculate the number of bits or bytes, the offset, etc.), and the length of the string (e.g., the number of bits or bytes, the number used to calculate the number of bits or bytes, the offset, etc.).

[0052] In some implementations, command generator 500 calculates or determines the address or location to store the recreated original data provided by a text write command or string copy command. For example, in some implementations, command generator 500 maintains a continuous record of bytes of the recreated original data that have been output by command processor 502 and uses this continuous record to determine the address or location to store the first byte to be written by a given command. In these implementations, command generator 500 may tag or otherwise provide the address or location of the first byte to command processor 502 for use. For example, command generator 500 may provide an identifier for the specific byte, a number for calculating the specific byte, an offset, etc. Command generator 502 may use this address or location for operations such as determining whether a given string copy command has unresolved dependencies.

[0053] In some implementations, the command generator 500 performs additional operations for generating, acquiring, and / or retrieving commands 506 and text 508 based on compressed input data 504 and / or other information. For example, in some implementations, the compressed data is encoded using an encoding standard (such as a prefix encoding standard, e.g., Huffman coding) after compression using a dictionary encoding standard. In these implementations, the command generator 500 decodes the compressed input data 504 before generating, acquiring, and / or retrieving commands. Generally, the command generator 500 can perform any number of operations for parsing commands 506 and text 508 to be conveyed to the command processor 502.

[0054] After receiving command 506 and text 508 from command generator 500, command processor 502 performs operations to process command 506 and text 508. Figure 6 A block diagram illustrating an command processor 502 according to some embodiments is presented. (See also...) Figure 6 As can be seen, the command processor 502 includes a command buffer 600, multiple string copy engines 602, a temporary register array 604, and a history buffer 606. The command buffer 600 is a function block that performs operations to identify each command to be processed as a text write command or a string copy command and process the command locally or forward the command to a string copy engine for processing therein. For example, the command buffer 600 may receive a command type signal or indicator via a dedicated signal line from the command generator 500, via one or more bits on a serial or parallel signal line, and determine based on this whether the command is a text write command or a string copy command.

[0055] When the command is a text write command, in some implementations, the command buffer 600 processes the command locally (i.e., processes the command itself). To process a text write command, the command buffer 600 generates a text write request (REQ) 608 based on the aforementioned continuous record of command 506, text 508, and the recreated original data. The command buffer 600 then forwards the text write request 608, along with the text data and address (data / address) 610, to the register array 604. The text write request 608 is a signal, message, or other request that causes the register array 604 to store text data (recall that the text data may be one or more bytes) in the bytes of the recreated original data, starting from the byte identified by that address (an absolute or relative address or byte position in the recreated original data).

[0056] Generally, "storing" text in the recreated original data, starting from the byte identified by that address, involves appending the text to the recreated original data that exists (or will exist) after the command preceding the text write command. In other words, text is added to the end of the recreated original data as generated by the previous command. It should be noted that in some embodiments, some or all of the previous commands may still be processed (in string copy engine 602, etc.), and thus text may be added to the recreated original data (in the storage elements in the register array 604) at a specified position, while other / previous positions are left blank for storing text or strings generated by the previous commands. In other words, text from the text write command can be written to the recreated original data out of order but in the appropriate position.

[0057] When 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. For this operation, the command buffer 600 selects the string copy engine 602 from a plurality of string copy engines to which it will forward the string copy command for processing. For example, in some embodiments, the command buffer 600 selects string copy engines in a cyclical pattern to process individual 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 when it becomes available to process individual 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.

[0058] When a string copy command is forwarded to the string copy engine 602, the command buffer 600 forwards various individual information items for processing the string copy command. For example, in Figure 6As can be seen, the information items include string command 612, distance 614, length 616, and address 618 to the selected string copying engine 602. String command 612 includes one or more bits that notify the string copying engine that the string copying command is waiting to be processed (and thus cause the string copying engine to process the string copying command). In some embodiments, each string copying engine 602 has a separate string command 612 (e.g., connected to a dedicated signal line, etc.), and therefore, command buffer 600 can forward signals on string command 612 to notify a specific string copying engine 602 that the string copying command is waiting to be processed. Distance 614 is an identifier of the number of bits, bytes, etc., back in the previously recreated original data where the string to be copied resides. Length 616 is a representation of the length of the string to be copied in bits, bytes, etc. Address 618 identifies the position in the recreated original data where the string is to be stored (an absolute or relative address or byte position in the recreated original data), which the command generator 500 calculates using the aforementioned continuous record of the recreated original data. Based on the value received from command buffer 600, string copy engine 602 generates string write request 620. String copy engine 602 then forwards string write request 620, along with string data and address (data / address) 622, to register array 604. String write request 620 is a signal, message, or other request that causes register array 604 to store the string (recall that the string can be one or more bytes) starting from the byte identified by that address in the bytes of the recreated original data.

[0059] Generally, "storing" a string in the recreated original data, starting from the byte identified by that address, involves appending the string to the recreated original data that exists (or will exist) after the command executed before the string copy command. In other words, the string is added to the end of the recreated original data as generated by the previous command. It should be noted that in some implementations, some or all of the previous commands may still be processed (in string copy engine 602, etc.), and therefore the string can be added to the recreated original data (in the storage elements in the register array 604) at a specified position, while other / previous positions are left blank for storing literals or strings generated by the previous commands. In other words, the string from the string copy command can be written to the recreated original data out of order but in the appropriate position. An example of this can be found in... Figure 7 As can be seen in the figure, this is a block diagram showing row 700 of a temporary register array according to some embodiments. For Figure 7In the example, the recreated original data (ROD) is written to the first and third of four positions (e.g., bytes) in row 700 of the scratchpad array, but the second position (empty) has not yet been written, and therefore the recreated original data in the third position has been "appended" to the recreated original data that will eventually be produced by the previous command.

[0060] although Figure 6 Not shown, but in some embodiments, a first-in-first-out (FIFO) buffer is located between command buffer 600 and register array 604. In these embodiments, instead of forwarding text write request 608 and the text data and address 610 associated with the text write command directly to register array 604, command buffer 600 writes text write request 608 and the text data and address 610 for these text write commands to the FIFO buffer. The values ​​are retained in the FIFO buffer until the text write request is processed and then released to the register array. In these embodiments, instead of retaining the text write command when a previous command (e.g., a longer string copy command, etc.) has completed execution, command buffer 600 may forward text write request 608 and the text data and address 610 for these text write commands to the FIFO buffer and continue with subsequent commands. For example, command buffer 600 may process a subsequent string copy command and forward it to a string copy engine for processing. Although subsequent string copy engines may stop when previous commands and text write commands have completed their writes to the register array, the string copy engine has the opportunity to continue processing any history buffer reads that subsequent string copy commands may need.

[0061] The register array 604 is a functional block comprising sequential logic storage elements (e.g., flip-flops, latches, etc.) for storing literals or strings (or symbols) forwarded from the command buffer 600 and the string copy engine 602. The register array 604 is a faster-access storage where a small number of N bytes (e.g., 32 lines, 60 bytes, etc.) of the recreated original data are stored so that the string copy engine 602 can quickly access the stored strings when processing string copy commands. The sequential logic storage elements in the storage array 604 are close to and coupled to the string copy engine 602 via relatively direct signal lines. For example, in some embodiments, the sequential logic storage elements are close to or adjacent to the string copy engine (or the string copy function block included in the string copy engine) in a semiconductor layout, where the command processor is fabricated and coupled to the circuit via relatively direct communication lines in the semiconductor layout.

[0062] Selecting a specific number of N-byte rows in the register array 604 to cause the useful portion of the original data to be quickly available to the string copy engine 602 without the register array 604 being excessively large (i.e., requiring too much layout area), consuming too much power, etc., is achieved. For example, in some embodiments, the number of N-byte rows in the register array 604 is selected using a profile (e.g., used by the designer, etc.) of the number of bytes to be measured, estimated, or calculated by the string copy engine 602. In some embodiments, the register array 604 includes four, six, or another number of N-byte rows.

[0063] 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) forwarded from command buffer 600 and string copy engine 602. History buffer 606 is a slower-access storage (relative to scratchpad array 604) that stores a large number of N-byte lines of the recreated original data so that string copy engine 602 can 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 scratchpad array 604) is set based on the dictionary size of the dictionary encoding standard used to generate compressed input data 504. For example, in these embodiments, assuming a dictionary size of 32kB, an N-byte line size of 32 bytes, and scratchpad array 604 having four 32-byte lines, the history buffer has storage for 1020 individual 32-byte lines (i.e., in a total of 1024 32-byte lines in the dictionary). The history buffer 606 typically has a larger portion of the N-byte row in the dictionary than the temporary register array 604.

[0064] During operation, in some implementations, the recreated original data flows from the register array 604 to or forwards to the history buffer 606 and then into the memory 404 as text values ​​from processing text write commands or copied strings from processing string copy commands are appended to the recreated original data. In other words, the register array 604 initially stores individual bytes of text values ​​or strings into one or more N-byte rows in the register array 604 as text values ​​or strings are appended to the recreated original data by the command buffer 600 or the string copy engine 602, respectively. As text and strings continue to be appended to the recreated original data, the N-byte rows in the register array 604 eventually become full. When the N-byte rows are full, the register array 604 moves bytes of the recreated original data from one or more N-byte rows in the register array 604 to the available N-byte rows in the history buffer 606 in a first-in-first-out order. In other words, the register array 604 "migrates" the old, recreated raw data from the register array 604 to the history buffer 606 via write request 624 and write data 626. This process moves bytes of the recreated raw data from N-byte rows of the register array 604, freeing up one or more N-byte rows in the register array 604 to store subsequent literal values ​​or copied strings generated by command buffer 600 or string copy engine 602. When the N-byte rows in the history buffer 606 become filled with migrated recreated raw data, the history buffer 606 moves bytes of the recreated raw data from one or more N-byte rows in the history buffer 606 to memory 404 in a first-in, first-out order. In other words, the history buffer 606 "migrates" the old, recreated raw data from the history buffer 606 to memory 404 via write data 628. This frees up one or more N-byte rows in the history buffer 606 to store subsequently received / migrated recreated raw data from the register array 604.

[0065] In some implementations, the history buffer 606 does not wait until it becomes full before writing the N-byte line to memory 404. In these implementations, the history buffer 606 copies the N-byte line to memory 404 because the N-byte line was initially migrated from scratch array 604 to history buffer 606 (i.e., in a manner similar to a write-through cache memory in an electronic device). However, the N-byte line is retained in history buffer 606 until enough subsequent N-byte lines have been written to it to overwrite the N-byte line. In other words, although a copy of the N-byte line is stored in memory 404, the N-byte line remains in history buffer 606 and is available as described herein until it is overwritten by subsequent data. In these implementations, the problem of writing the N-byte line back to memory when history buffer 606 is full (e.g., when the memory system is busy) is avoided.

[0066] In some implementations, one or more data end mechanisms are used to handle N-byte lines of recreated original data generated based on text write commands and string copy commands that are closer to the end of the compressed data that would otherwise be subsequently recreated and pushed out of the scratchpad array and / or history buffer. Generally, one or more data end mechanisms ensure that all recreated original data is ultimately stored in memory 404 and does not get stuck in scratchpad array 604 and / or history buffer 606. For example, in some implementations, the recreated original data flows through or continues through scratchpad array 604 and history buffer 606 based on the years or lifetime of the recreated original data in scratchpad array 604 and / or history buffer 606. In these implementations, when the data reaches a given years or lifetime, scratchpad array 604 and / or history buffer 606 automatically migrate the data to history buffer 606 and memory 404, respectively. As another example, in some implementations, compressed data includes “end of data” (“end of file”, etc.) characters, commands, symbols, etc., at or near the end of the compressed data (e.g., as the last character, command, symbol, etc.). The presence of characters, commands, symbols, etc., at the end of the data causes the command processor to automatically migrate the data to the temporary register array 604 and / or the history buffer 606, respectively. In this way, the recreated original data will eventually flow to or advance to the memory 404, even if it is at the end of the compressed data.

[0067] In some implementations, the register array 604 and the history buffer 606 include mechanisms that enable the determination of information about previously recreated original data. These mechanisms keep track of and associate information about the recreated original data generated during the processing of previous text write commands and string copy commands. In some implementations, the mechanisms include a line counter 630 and a byte validity (BV) tracker 634. The line counter 630 is a function block that performs operations to maintain a line count 632, which indicates the number of N-byte lines that have migrated from the register array 604 to the history buffer 606 (up to the current time) during the processing of text write commands and string copy commands. The line counter 630 increments the line count 632 each time an N-byte line moves / migrates from the register array 604 to the history buffer 606. 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 processing subsystem 406, network interface, sensor, etc.). In some implementations, the row count 632 is stored in a memory element coupled to the string copy engine 602 via a relatively direct signal line, and is therefore quickly accessible by the string copy engine 602.

[0068] The byte validity tracker 634 is a function block that performs operations to maintain a set of byte validity indicators (INDs) 638 in the byte validity array 636. Each individual byte validity indicator 638 in the byte validity array 636 is associated with each byte in an N-byte row of the register array 604. When recreated original data is written to each byte in the register array 604, the byte validity tracker 634 sets the corresponding byte validity indicator 638 to indicate that valid recreated original data exists in that byte. When a byte of recreated data is moved / migrated from the register array 604 to the history buffer 606 (or when bytes in the register array 604 are initialized, cleared, invalidated, etc.), the byte validity tracker 634 clears the corresponding byte validity indicator 638 to indicate that valid recreated original data does not exist in that byte. An example of a byte validity indicator 638 is provided in... Figure 7 Presented in. For example, in Figure 7As can be seen, register array row 700, as an example of an N-byte row from register array 604, has valid data in the first and third bytes. The corresponding (i.e., first and third) byte validity indicators 638 in byte validity indicator 702, as an example of byte validity indicators 638 from byte validity array 636, are set to 1 to indicate that data is valid in these bytes, and otherwise set to 0. In some embodiments, byte validity array 634 is located close to string copy engine 602, and the individual byte validity indicators 638 are coupled to string copy engine 602 via relatively direct signal lines. Therefore, string copy engine 602 can quickly access byte validity indicators 638 to determine whether the associated bytes contain valid, recreated original data.

[0069] As mentioned above, dependencies (or conversely, unresolved dependencies) can exist between string copy commands. A direct dependency exists when a string copy command copies a string from the recreated original data that was appended to the recreated original data by a previous string copy command. An indirect dependency exists when a string copy command copies a string from the recreated original data that was appended to the recreated original data by a text write command that stopped processing when the earlier string copy command completed (and thus the string copy command indirectly depends on the earlier string copy command).

[0070] The string copy engine 602 uses a row count 632 and a valid byte array 636 to ensure that dependencies between string copy commands are handled appropriately. The string copy engine 602 uses the row count 632 to determine whether the string to be copied by the string copy command from a specified distance back from the recreated original data exists in the register array 604 and / or the history buffer 606 (recall that portions of the same multibyte string may be stored in N-byte rows in the register array 604 and the history buffer 606). For example, the string copy engine 602 may compare the relative value of the distance from the string copy command with the row count 632, and determine that an unresolved dependency exists when the difference is greater than a threshold. For example, suppose register array 604 holds four N-byte lines. If line count 632 indicates that four N-byte lines exist in history buffer 606, the maximum number of all N-byte lines present in register array 604 and history buffer 606 is eight (however, recall that some of the N-byte lines in register array 604 may not yet have valid data due to an ongoing string copy command and / or its subsequent text write command). In this case, when a string copy command copies data from the tenth N-byte line and therefore the difference between the distance and line count 632 is two and greater than the threshold zero, string copy engine 602 determines that there is an unresolved dependency. In other words, because the previous string copy command and / or text write command has not yet been processed, fewer N-byte lines than are required to make it possible to copy some or all of the strings used for the string copy command from the recreated original data have been added to the recreated original data in register array 604 and / or history buffer 606. In this case, the processing of the previous string copy command and / or one or more text write commands should be completed before string copy engine 602 continues processing the string copy command. Therefore, the string copy engine 602 temporarily suspends the processing of string copy commands to allow the processing of previous string copy commands and / or one or more text write commands to be completed before the string copy engine 602 continues to process string copy commands.

[0071] The string copy engine 602 uses a byte validity indicator 638 to determine whether the string to be copied from the register array 604 by the string copy command exists and is ready to be copied from the register array 604. In other words, a previous string copy command and / or text write command may not have written the necessary recreated original data to the register array 604, and therefore a specific byte in the register array 604 is still invalid. Therefore, the string copy engine 602 checks whether the byte validity indicator indicates that the necessary data exists in the bytes of the N-byte row in the register array 604. If the data does not exist, the string copy engine 602 temporarily suspends the processing of the string copy command to allow the processing of the previous string copy command and / or one or more text write commands to complete before the string copy engine 602 continues processing the string copy command.

[0072] In some implementations, the checks described above for line count 632 and byte validity indicator 638 are performed in pairs, one after the other as needed. In these implementations, when processing a string copy command, the string copy engine 602 checks the line count 632 as described above to ensure that a given N-byte line is in the register array 604 (again, the N-byte line may not have been fully written due to an ongoing string copy command and / or its subsequent literal write command). Then, if the line count 632 indicates that the given N-byte line exists in the register array 604, the string copy engine 602 checks the byte validity indicator 638 to ensure that a specific byte of the N-byte line exists in the register array 604. If either of these checks fails (i.e., indicating that the N-byte line does not exist in the register array 604 or that a specific byte has not yet existed in the register array 604), the string copy engine 602 temporarily suspends the processing of the string copy command to allow the processing of previous string copy commands and / or one or more literal write commands to be completed before the string copy engine 602 continues processing the string copy command.

[0073] After the string copy engine 602 has ensured that no unresolved dependencies are preventing the processing of the string copy command, it processes the string copy command. Generally, processing the string copy command involves retrieving a string (i.e., one or more bytes) of the previously recreated original data from the register array 604 and / or the history buffer 606 and appending that string to the recreated original data. To retrieve the string, the string copy engine 602 uses distance 614 to determine the position in the register array 604 or the history buffer 606 where to begin string copying (e.g., the first byte to read). The string copy engine 602 also uses length 616 to determine the number of bytes of the recreated original data to read from the register array 604 and / or the history buffer 606. Starting from the position in the register array 604 or the history buffer 606, the string copy engine 602 then sequentially reads that number of bytes of the recreated original data from the register array and / or the history buffer, for example, via register data 640 and read data 642. For read operations, the string copy engine 602 can directly read sequential logic storage elements in the register array 604, but performs typical memory read operations for reading memory elements in the history buffer 606 (e.g., SRAM memory read operations when the history buffer 606 is implemented using SRAM, etc.). To append a string to the recreated original data, the string copy engine 602 writes the string (i.e., bytes of the recreated original data read from the register array 604 and the history buffer 606) to a location in the register array 604 and / or the history buffer 606, as identified by address 618. It should be noted that individual portions of sufficiently long multi-byte strings can be stored in the register array 604 and the history buffer 606, and therefore portions of the string can be read from and written to the register array and the history buffer 606, as described above (i.e., data can be migrated from the register array 604 to the history buffer 606 to make room in the register array 604 for longer strings).

[0074] Despite Figures 5 to 7 The decompression subsystem 408 and command processor 502 in the original document present a specific number and arrangement of functional blocks, but in some embodiments, the decompression subsystem 408 and command processor 502 contain different numbers and / or arrangements of functional blocks. For example, in some embodiments, command processor 502 includes two or more command buffers and / or three or more string copy engines, as used in... Figure 5The multiple boxes in the diagram are shown. As another example, in some embodiments, the history buffer 606 is "virtualized," and at least some of the recreated original data described above as being stored in the history buffer 606 is instead stored in memory 404. In these embodiments, writing the recreated original data to at least some portions of the history buffer 606 and reading the previously recreated original data from it involves 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 the history buffer 606 can be smaller in layout size, use less power, etc., but the access time for the recreated original data stored in memory 404 increases.

[0075] The process of decompressing compressed input data.

[0076] In the described implementation, a decompression subsystem (e.g., decompression subsystem 408) including a command generator and a 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). Figure 8 A flowchart illustrating a process for decompressing compressed input data according to some implementation schemes is presented. It should be noted that... Figure 8 The operations shown are presented as general examples of operations performed by some implementations. Operations performed by other implementations include different operations, operations performed in different orders, and / or operations performed by different entities or functional blocks.

[0077] for Figure 8The illustrated process assumes that the decompression subsystem receives compressed input data from a source (such as a file, data stream, etc.). In other words, individual bits of the compressed input data are being received by the decompression subsystem and are therefore available for operation by the command generator and command processor within the decompression subsystem. In some embodiments, the decompression subsystem simply (and may only) decompresses the compressed input data provided to it by another entity (e.g., a processing subsystem, memory) to generate a string that recreates the original data from which the compressed input data was created. In other words, in these embodiments, the decompression subsystem does not perform any operations other than outputting the recreated original data generated from the compressed input data provided to it. 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, network interface, I / O device, etc.), storing the string of the recreated original data in memory, and / or providing the string of the recreated original data to other entities.

[0078] for Figure 8 In the example, the first and second string copying engines perform certain operations "essentially in parallel" because these operations are performed at roughly the same time. This is in... Figure 8 This can be viewed as parallel branches of the flowchart (i.e., branches including steps 802 to 804 and branches including steps 806 to 812). These operations are performed approximately at the same time because they begin at the same or nearly the same time, for example, in consecutive cycles of the control clock in an embodiment with only one command buffer (e.g., command buffer 600), or in the same clock cycle in an embodiment with two or more command buffers. Additionally, although... Figure 8 Not shown in the diagram, but the first string copy engine initially checks for any unresolved dependencies between the first string copy command and previous string copy commands (regarding...). Figure 10 (A more detailed description of dependency checking). For Figure 8 For example, assuming no unresolved dependencies are found, the first string copy engine continues to process the first string copy command.

[0079] As in Figure 8As can be seen, the process begins when the command processor forwards the first string copy command to the first string copy engine and the second string copy command to the 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) from the command generator (e.g., command generator 500) for processing each of the first and second string copy commands. The one or more command buffers then forward the appropriate information to the first string copy engine to process the first string copy command and to the second string copy engine to process the second string copy command.

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

[0081] The first string copying engine then appends the first string to the recreated original data (step 804). For this operation, the first string copying engine writes the individual bytes of the first string (which is the recreated original data) to the register array starting from the address-indicated position in the register array. It should be noted that one or more previous string copy commands and / or text write commands may not have completed their corresponding writes to the register array, and therefore the first string command may write data to the register array beyond the current end of the recreated original data in the register array. However, for the append operation, the first string copying engine may simply add the recreated original data to the end of the existing recreated original data. Additionally, when the first string is long enough and / or the register array has sufficiently filled the previously recreated original data, the register 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 copying engine to continue writing the recreated original data to the register array.

[0082] Upon receiving a 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 mentioned above, unresolved direct or indirect dependencies may exist because the first and second string copy commands are executed substantially in parallel and the first string copy command has not yet written the recreated original data to the register array and / or the data has not yet been migrated from the register array to the history buffer to be copied for the second string. For this operation, the second string copy engine checks for these unresolved dependencies (regarding...). Figure 10 (A more detailed description of dependency checking follows). When a direct or indirect dependency is found (i.e., an unresolved dependency), the second string copy engine stops further processing of the second string copy command until the dependency is resolved (step 808). For this operation, the second string copy engine stops or otherwise delays processing the second string copy command until the first string copy command has written the portion of the first string required by the second string into the register array and / or history buffer.

[0083] The second string copying engine then retrieves the second string from the recreated original data (step 810). For this operation (or for the earlier determination of dependencies), the second string copying engine determines the position in the register array or history buffer from which to read the second string based on distance, and thus determines the specific recreated original data to retrieve for the second string. For example, the second string copying engine can use this distance to calculate a specific byte in the N-byte row in the register array or history buffer from which to begin reading the second string. The second string copying engine then reads one or more bytes of the second string sequentially from the register array and / or history buffer, starting from that position in the register array or history buffer, based on the length of the second string. At the end of this operation, the second string copying engine has a copy of one or more bytes of the second string.

[0084] The second string copying engine then appends the second string to the recreated original data (step 812). For this operation, the second string copying engine writes the individual bytes of the second string (which is the recreated original data) to the positions in the register array. It should be noted that one or more previous string copy commands and / or text write commands may not have completed their corresponding writes to the string copying engine, and therefore the second string command may write data to the register array beyond the current end of the recreated original data in the register array. However, for append operations, the second string copying engine may simply add the recreated original data to the end of the existing recreated original data. Additionally, when the second string is long enough and / or the register array has sufficiently filled the previously recreated original data, the register 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 rows for the second string copying engine to continue writing the recreated original data to the register array.

[0085] The process for handling the recreated raw data in the scratchpad array and history buffer.

[0086] In the described implementation, the command buffer and string copying engine in the decoding subsystem write the recreated original data (i.e., literals and strings) to the register array and the history buffer, respectively. Since the recreated original data is written to the register array and the history buffer, data progresses to or flows to memory via these buffers. Figure 9 A flowchart illustrating a process for storing recreated original data in a scratchpad array and a history buffer, according to some implementation schemes, is presented. It should be noted that... Figure 9 The operations shown are presented as general examples of operations performed by some implementations. Operations performed by other implementations include different operations, operations performed in different orders, and / or operations performed by different entities or functional blocks.

[0087] for Figure 9 For example, when the command buffer or string copy engine is preparing to output the bytes of the recreated original data, operations are performed to move or migrate data in the scratchpad array and / or history buffer. However, in some implementations, Figure 9 The operation can be performed at any time. For example, in some implementations, Figure 9The operation is performed dynamically. As the recreated original data is written to a specific location in the register array and / or history buffer, the recreated original data is moved from other locations to prepare for receiving the recreated original data at other locations. In this way, the register array and / or history buffer are prepared to receive the recreated original data "on the fly." Generally, in the described implementation, locations are made available as needed to store bytes of the recreated original data in the register array and / or history buffer. Additionally, for Figure 9 In the example provided, the recreated raw data is described as being forwarded to or flowed into memory, but this is merely an example. In some implementations, the recreated raw data is forwarded to or flowed into another destination, such as a processing subsystem, network interface, I / O device, etc. It should be noted that when the compressed input data is decompressed, all the recreated raw data eventually flows to or through a scratchpad array and a history buffer into memory (or another entity), where it is stored for further operations, and the scratchpad array and history buffer will eventually be empty.

[0088] As in Figure 9 As can be seen, the process begins when the command buffer or string copy engine is ready to output the bytes of the recreated original data (step 900). For example, the command buffer can append text to the recreated original data, or the string copy command can append a string to the recreated original data.

[0089] Before the recreated original data can be written to the register array and / or history buffer, the decompression subsystem (e.g., in the register array and / or history buffer or its associated controller, etc.) ensures that there is sufficient space in the register array and / or history buffer to store the data. For this operation, the decompression subsystem determines whether all N-byte rows in the register array are full (filled with the previously recreated original data) (step 902). This can occur when a previous text write command and / or string copy command has caused the command buffer and / or string copy engine to write enough input to the register array to fill the relatively small number of N-byte rows in the register array. When all rows in the register array are full, the decompression subsystem determines whether all rows in the history buffer are full (step 904). When all rows in the history buffer are full (step 904), the decompression subsystem moves or migrates bytes of data from one or more N-byte rows in the history buffer to memory (e.g., memory 404) to free one or more N-byte rows in the history buffer (step 906). The decompression subsystem moves or migrates bytes of data from one or more N-byte rows in the scratchpad array to one or more N-byte rows in the history buffer (step 908). At the end of this operation, there is sufficient space in the scratchpad array and / or the history buffer to store the bytes of the recreated original data.

[0090] The command buffer or string copy engine then stores the bytes of the recreated original data into the next byte of the given N-byte row in the register array (step 910). For this operation, the command buffer or string copy engine stores the bytes of the recreated original data sequentially into the given N-byte row in the register array (recall that all the recreated original data from the previous string copy command and / or its subsequent literal write command may not have been written into the previous bytes of the N-byte row, and therefore the recreated original data is written "sequentially" into the N-byte row from a specific position after one or more bytes that have not yet been valid). If the given N-byte row in the register array is filled with bytes written (step 912), that is, if all bytes in the given N-byte row are full, then the next N-byte row in the register array is used as the given N-byte row (step 914). In other words, when a particular N-byte row in the register array is full, subsequent bytes of the recreated original data will be written into the next N-byte row in the register array. If no more bytes are available to be appended to the recreated original data in the register array or history buffer (i.e., if all bytes of the recreated original data have already been output by the command buffer or string copy engine) (step 916), the process ends. Otherwise, if more bytes of the recreated original data are available (step 916), the process returns to step 902, where the register array and / or history buffer are checked for fullness (steps 902 to 908) before the next byte is appended to the recreated original data (step 910).

[0091] The process for checking dependencies

[0092] In the described implementation, the dependencies of string copy commands are checked on strings written to the register array and / or history buffer by previous text write commands and string copy commands. Figure 10 A flowchart illustrating a process for checking the dependencies of a string copy command, according to some implementation schemes, is presented. It should be noted that... Figure 10 The operations shown are presented as general examples of operations performed by some implementations. Operations performed by other implementations include different operations, operations performed in different orders, and / or operations performed by different entities or functional blocks.

[0093] Figure 10The process begins when the functional blocks in the decompression maintain records used to determine dependencies. More specifically, when one or more bytes of the recreated original data are stored into bytes in one or more N-byte rows in a register array, a byte validity tracker (e.g., byte validity tracker 634) sets a byte validity indicator (e.g., byte validity indicator 638) associated with each of the one or more bytes to indicate that the associated byte is storing the recreated original data (step 1000). For this operation, the byte validity tracker sets the byte validity indicator to a value such as 1 in the byte validity array (e.g., byte validity array 636) to indicate that the corresponding byte in the register array stores valid recreated original data. Additionally, when N bytes of the recreated original data are moved from byte rows in the register array to N-byte rows in the history buffer, a row counter (e.g., row counter 630) increments the row count, which indicates the number of N-byte rows previously appended to the recreated original data (step 1002). For this operation, as each N-byte row of original data worth recreating is migrated from the scratchpad array to the history buffer, the row counter increments the row count, thereby updating the row count to preserve the number of N-byte rows present in the history buffer and memory (for rows migrated from the history buffer to memory).

[0094] The decompression subsystem then uses records (i.e., row counts and byte validity indicators) to determine if there are any unresolved dependencies in the string copy command. In other words, the string copy engine (or another entity) uses the byte validity indicator and / or row count to check for direct or indirect dependencies of the string copy command on previous strings of the recreated original data (step 1004). For this operation, for a given string copy command, the string copy engine compares the distance and length of the string of the previously recreated original data to be acquired with the value of the row count to determine whether the N-byte row including the required data is present (or not present) in the register array and / or history buffer. When the row count indicates that less recreated original data than required has been written to the register array and / or history buffer (and therefore the N-byte row is not present in the register array and / or history buffer), the string copy engine detects an unresolved dependency. Additionally, when the byte indicator indicates that bytes of the recreated original data required by the string copy command are not present in the register array, the string copy engine detects an unresolved dependency. As described above, when an unresolved dependency is detected, the string copy engine stops processing string copy commands to allow the original data to be recreated to be written to the register array and / or history buffer. In some implementations, this stops for a specified period of time, until a specific byte is detected as present (e.g., by periodically rechecking the byte validity indicator and / or line count, etc.), until the previous text write command and / or string copy command exits, etc.

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

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

[0097] In some embodiments, data structures representing some or all of the structures and mechanisms described herein (e.g., electronic device 400 or a portion thereof) are stored on a non-transitory computer-readable storage medium, including databases or other data structures 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 structures may be behavioral-level descriptions or register-transfer-level (RTL) descriptions of hardware functionality in a high-level design language (HDL) (such as Verilog or VHDL). This description can be read by a synthesis tool that synthesizes the description to generate a netlist comprising a list of gate / circuit elements from a synthesis library representing the functionality of the hardware including the structures and mechanisms described above. The netlist can then be placed and routed to generate a dataset describing the geometry to be applied to a mask. The mask can then be used in various semiconductor manufacturing steps to produce one or more semiconductor circuits (e.g., integrated circuits) corresponding to the structures and mechanisms described above. Optionally, the database on the computer-accessible storage medium may, as needed, be a netlist (with or without a synthesis library), a dataset, or Graphical Data System (GDS) II data.

[0098] In this specification, variables or unspecified values ​​(i.e., general descriptions of values ​​in the absence of specific instances of values) are represented by letters such as N, M, and X. As used herein, 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; that is, some or all of the general variables and unspecified values ​​may be expected to have different variables and values. In other words, the N and any other letters used to represent variables and unspecified values ​​in this specification are not necessarily related to each other.

[0099] As used herein, the expression “etc.” is intended to represent one and / or case, that is, an equivalent of “at least one” of the elements associated with “etc.” in the list. For example, in the statement “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 associated with “etc.” in the list are merely examples from a set of examples, and in some embodiments, at least some of these examples may not appear.

[0100] The foregoing description of embodiments is presented for illustrative and descriptive purposes only. This foregoing description is not intended to be exhaustive or to limit the embodiments to the disclosed form. Accordingly, many modifications and variations will be apparent to those skilled in the art. Furthermore, the foregoing disclosure is not intended to limit the embodiments. The scope of the embodiments is defined by the appended claims.

Claims

1. An electronic device for decompressing compressed data to recreate the original data from which the compressed data was generated, the electronic device comprising: A temporary register array, which is used to store the recreated original data; The first string copying engine processes the first string copying command through the following operations: Obtain the first string from the recreated original data; as well as Append the first string to the recreated original data; as well as The second string copying engine processes the second string copying command through the following operations: Based on the amount of the recreated original data that has been moved from the scratchpad array to another memory resource, check the direct dependency of the second string copy command on the first string. When the second string copy command obtains bytes from the first string, a direct dependency occurs. When the direct dependency is found, further processing of the second string copy command is stopped until the first string copy engine appends the corresponding part of the first string to the recreated original data. Obtain the second string from the recreated original data; and The two strings are appended to the recreated original data.

2. The electronic device of claim 1, wherein when processing the second string copy command, the second string copy engine further: Check the indirect dependency of the second string copy command on the first string. An indirect dependency occurs when the second string copy command retrieves one or more bytes from the text appended to the recreated original data based on a text write command between the first string copy command and the second string copy command. When the indirect dependency is found, stop further processing of the second string copy command until the text is appended to the recreated original data.

3. The electronic device as claimed in claim 1, The temporary register array includes sequential logical storage elements for storing X separate N-byte rows of the recreated original data; and The electronic device also includes a history buffer comprising memory elements for storing Y separate N-byte rows of the recreated original data, where Y and X are numbers, and Y is greater than X.

4. The electronic device of claim 3, wherein appending the given string to the recreated original data comprises: When the X N-byte rows in the register array are full, the previously recreated original data is moved from one or more N-byte rows in the register array to one or more N-byte rows in the history buffer in a first-in-first-out order to free up the one or more N-byte rows in the register array to store bytes of the recreated original data from the given string. as well as Bytes from the given string are stored sequentially into bytes in one or more N-byte rows of the register array.

5. The electronic device of claim 4, further comprising: Memory; Appending the given string to the recreated original data includes: When the Y N-byte rows in the history buffer are full, the previously recreated original data is moved from one or more N-byte rows in the history buffer to the memory in a first-in-first-out order to free up the one or more N-byte rows in the history buffer to store bytes of the recreated original data moved from the register array to the history buffer.

6. The electronic device of claim 4, wherein the second string copying engine checks the direct dependency based on: a line count, the line count indicating the number of N-byte lines previously appended to the recreated original data, wherein the line count is incremented when an N-byte line is moved from the register array to the history buffer, the line count corresponding to the amount; and A byte validity indicator, wherein the byte validity indicator includes a byte validity indicator for each byte in the X rows of N bytes in the register array, each byte validity indicator indicating whether the corresponding byte in the register array currently stores valid recreated original data, wherein the byte validity indicator is set when a byte of recreated original data is stored in the corresponding byte in the register array and is cleared when a byte of recreated original data is moved from the corresponding byte in the register array to the history buffer.

7. The electronic device of claim 6, wherein when examining the direct dependency of the second string copy command on the first string, the second string copy engine: Obtain the distance and string length from the second string copy command; and The distance, the string length, and one or both of the line count and the byte validity indicator are used to determine whether the second string copy command has the direct dependency on the first string.

8. The electronic device of claim 3, wherein retrieving a given string from the recreated original data when processing a string copy command comprises: The distance from the string copy command is used to determine the position in the register array or the history buffer; The string length from the string copy command is used to determine the number of bytes of recreated original data to be read from the register array and / or the history buffer; as well as Starting from the position in the register array or the history buffer, read the number of bytes of the recreated original data sequentially from the register array and / or the history buffer.

9. The electronic device as claimed in claim 3, wherein: The sequential logic storage elements in the temporary register array include flip-flops and / or latches; and The memory elements in the history buffer include static random access (SRAM) memory elements.

10. The electronic device of claim 3, further comprising: Command processor, the command processor: Receive text write commands; Obtain the text value identified in the text writing command; as well as Appending the text value to the recreated original data, the appending including: The text value is stored into one or more specified bytes in one or more N-byte rows in the register array, the storage including moving bytes of the recreated original data from the register array to the history buffer to release the one or more N-byte rows in the register array when all of the X N-byte rows in the register array are full.

11. The electronic device of claim 1, further comprising: 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, thereby processing it in a cyclic manner.

12. The electronic device of claim 1, further comprising: At least one command generator receives a string copy command and forwards the string copy command to a first string copy engine and a second string copy engine, whereby processing is performed when each of the first string copy engine and the second string copy engine becomes available to process the string copy command.

13. A method for decompressing compressed data in an electronic device to recreate the original data from which the compressed data was generated, the electronic device comprising a register array for storing the recreated original data, a first string copying engine, and a second string copying engine, the method comprising: The first string copying engine processes the first string copying command through the following operations: Obtain the first string from the recreated original data; as well as Append the first string to the recreated original data; as well as The second string copying engine processes the second string copying command through the following operations: Based on the amount of the recreated original data that has been moved from the scratchpad array to another memory resource, check the direct dependency of the second string copy command on the first string. When the second string copy command obtains bytes from the first string, a direct dependency occurs. When the direct dependency is found, further processing of the second string copy command is stopped until the first string copy engine appends the corresponding part of the first string to the recreated original data. Obtain the second string from the recreated original data; and The two strings are appended to the recreated original data.

14. The method of claim 13, wherein processing the second string copy command by the second string copy engine comprises: Check the indirect dependency of the second string copy command on the first string. An indirect dependency occurs when the second string copy command retrieves one or more bytes from the text appended to the recreated original data based on a text write command between the first string copy command and the second string copy command. When the indirect dependency is found, stop further processing of the second string copy command until the text is appended to the recreated original data.

15. The method of claim 13, wherein: The register array includes sequential logic storage elements for storing X separate N-byte rows of the recreated original data; and the electronic device further includes a history buffer, which includes memory elements for storing Y separate N-byte rows of the recreated original data, where Y and X are numbers, and Y is greater than X; and Appending the given string to the recreated original data includes: When the X N-byte rows in the register array are full, the previously recreated original data is moved from one or more N-byte rows in the register array to one or more N-byte rows in the history buffer in a first-in-first-out order to free up the one or more N-byte rows in the register array to store bytes of the recreated original data from the given string. as well as Bytes from the given string are stored sequentially into bytes in one or more N-byte rows of the register array.

16. The method of claim 15, wherein: The electronic device includes a memory; and Appending the given string to the recreated original data includes: When the Y N-byte rows in the history buffer are full, the previously recreated original data is moved from one or more N-byte rows in the history buffer to the memory in a first-in-first-out order to free up the one or more N-byte rows in the history buffer to store bytes of the recreated original data moved from the register array to the history buffer.

17. The method of claim 15, wherein the method further comprises: When an N-byte row moves from the temporary register array to the history buffer, the row count is incremented; When storing the bytes of the recreated original data into the corresponding bytes in the register array, a byte validity indicator is set, which indicates whether the corresponding bytes in the register array are currently storing valid recreated original data; as well as The byte validity indicator is cleared when the bytes of the recreated original data are moved from the corresponding bytes in the register array to the history buffer.

18. The method of claim 17, wherein checking the direct dependency of the second string copy command on the first string comprises: The distance and string length are obtained from the second string copy command by the second string copy engine; as well as The second string copying engine uses one or both of the distance, the string length, the line count, and the byte validity indicator to determine whether the second string copying command has the direct dependency on the first string.

19. The method of claim 13, wherein: The register array includes sequential logic storage elements for storing X separate N-byte rows of the recreated original data; and the electronic device further includes a history buffer, which includes memory elements for storing Y separate N-byte rows of the recreated original data, where Y and X are numbers, and Y is greater than X; and Retrieving a given string from the recreated original data when processing a string copy command includes: The distance from the string copy command is used to determine the position in the register array or the history buffer; The string length from the string copy command is used to determine the number of bytes of the recreated original data to be read from the register array and / or the history buffer; and Starting from the position in the register array or the history buffer, read the number of bytes of the recreated original data sequentially from the register array and / or the history buffer.

20. The method of claim 13, wherein: The register array includes sequential logic storage elements for storing X separate N-byte rows of the recreated original data; and the electronic device further includes a history buffer, which includes memory elements for storing Y separate N-byte rows of the recreated original data, where Y and X are numbers, and Y is greater than X; The sequential logic storage elements in the temporary register array include flip-flops and / or latches; and The memory elements in the history buffer include static random access (SRAM) memory elements.

21. The method of claim 13, wherein: The electronic device includes: a command processor; a register array including sequential logic storage elements for storing X separate N-byte rows of the recreated original data; and a history buffer including memory elements for storing Y separate N-byte rows of the recreated original data, where Y and X are numbers, and Y is greater than X; The method further includes: The command processor receives the text write command; The command processor obtains the text value identified in the text writing command; and The command processor appends the text value to the recreated original data, the appending including: The text value is stored into one or more specified bytes in one or more N-byte rows in the register array, the storage including moving bytes of the recreated original data from the register array to the history buffer to release the one or more N-byte rows in the register array when all of the X N-byte rows in the register array are full.

Images