Methods for accelerating hash-based compression and apparatuses using the same

The invention introduces a method for accelerating hash-based compression, performed in a compression accelerator, comprising: receiving, by a plurality of hash functions, a plurality of substrings from an FSM (Finite-State Machine) in parallel; mapping, by each hash function, the received substring to a hash index and directing a selector to connect to one of a plurality of match paths according to the hash index; transmitting, by a matcher of each connected match path, a no-match message to the FSM when determining that a hash table does not contain the received substring; and transmitting, by the matcher of each connected match path, a match message and a match offset of the hash table to the FSM when determining that the hash table contains the received substring, wherein the match offset corresponds to the received substring.

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of China Patent Application No. 201710347210.1, filed on May 17, 2017, the entirety of which is incorporated by reference herein.

BACKGROUND

Technical Field

The present invention relates to a microprocessor, and in particular, to methods for accelerating hash-based compression and apparatuses using the same.

Description of the Related Art

The most complicated technology of a compression accelerator is the LSM (longest-prefix string matching). LSM methods can be categorized into those that are CAM (Content addressable Memory)—based and those that are hash-based. Hash-based string matching is usually optimized by reducing hash chains and/or using a lower-conflict hash function, whose optimization is conventionally realized in the software domain. However, the performance of software is typically worse than that of dedicated hardware. Therefore, what is needed are methods for accelerating hash-based compression performed in dedicated hardware and apparatuses using the same to overcome the aforementioned drawbacks.

BRIEF SUMMARY

An embodiment of the invention introduces a method for accelerating hash-based compression, performed in a compression accelerator of a microprocessor, comprising: receiving, by a plurality of hash functions, a plurality of sub strings from an FSM (Finite-State Machine) in parallel; mapping, by each hash function, the received substring to a hash index and directing a selector to connect to one of a plurality of match paths according to the hash index; transmitting, by a matcher of each connected match path, a no-match message to the FSM when determining that a hash table does not contain the received substring; and transmitting, by the matcher of each connected match path, a match message and a match offset of the hash table to the FSM when determining that the hash table contains the received substring, wherein the match offset corresponds to the received substring.

An embodiment of the invention introduces an apparatus for accelerating hash-based compression, at least containing: an FSM; and a hash matcher coupled to the FSM. The hash matcher at least contains hash functions, a selector coupled to the hash functions, and match paths coupled to the selector. The hash functions receives the substrings from the FSM, each hash function maps the received substring to a hash index and directs the selector to connect to one of the match paths according to the hash index. A matcher of each connected match path transmits a no-match message to the FSM when determining that a hash table does not contain the received substring. The matcher of each connected match path transmits a match message and a match offset of the hash table to the FSM when determining that the hash table contains the received substring.

The aforementioned FSM of the invention can output multiple hash requests to multiple hash functions in parallel at one clock cycle to trigger multiple hash matches. In addition, with the recordings of states, match lengths and match offsets in the intermediary buffer that are introduced by the invention, the raw string can be compressed in the original order based on out-of-order calculation results of hash matches and LSMs corresponding to the recorded instances.

DETAILED DESCRIPTION

FIG. 1is a system diagram of a microprocessor according to an embodiment of the invention. A microprocessor10may contain processor cores170_1to170_j and accelerators150_1to150_i, where i and j are integers and may be set depending on different design requirements. The accelerators150_1to150_i, for example, may be AFUs (Accelerator Functional Units). Components of any of the processor cores170_1to170_j participate in the execution of computer instructions, such as an ALU (Arithmetic Logic Unit), a FPU (Floating Point Unit), a L1 cache and a L2 cache. An instruction cycle (sometimes called a fetch—decode—execute cycle) being the basic operational process is employed in each processor core. It is the process by which a processor core retrieves a program instruction from its memory, determines what operation the instruction indicates, and executes those operations. The accelerators150_1to150_i may perform different functions and connect to a last-level cache110via an accelerator interface130to exchange data with the processor cores170_1to170_j using virtual addresses. Any of the accelerators150_1to150_i assists the processor cores170_1and170_j to perform designated functions with heavy computation loading more efficiently, such as compression, ciphering/deciphering, regular matching or the like, thereby reducing the workload on the processor cores170_1to170_j. One of the accelerators150_1to150_i is a compression accelerator to complete a string compression.

FIG. 2is a block diagram of a compression accelerator according to an embodiment of the invention. A compression accelerator20contains a data buffer210and the length of the data buffer210may be 1024 M bytes for storing a raw string and a compressed string. It should be noted that, in alternative embodiments, the data buffer210may be located in the last-cache110as shown inFIG. 1; that is, the data buffer210may be located outside of the compression accelerator20. A fetch unit220issues a look-ahead request to the data buffer210to fetch a fixed length of the raw string to be compressed, such as 16 bytes, and stores the fetched string in a look-ahead buffer280as the subject to be compressed. Characters of the string to be compressed are stored in an intermediary buffer230in order. The intermediary buffer230stores information regarding hashed and longest-string-matched results associated with each character. Specifically, the intermediary buffer230is segmented into multiple segments of memory spaces and each segment is used to store information of an instance. Each instance contains several fields for recording an index, a character, a state, a match offset, a match length or others. Since the compression accelerator20contains many parallel computations, the computation time (or referred to as clock cycles) for each instance cannot be predicted; that is, the computation result of a later instance may be generated earlier than that of a former one. Therefore, embodiments of the invention introduce the intermediate buffer230to make sure that the output sequence of the computation results of all instances is consistent with the original order of the characters to be compressed, and accordingly complete the longest-string-matching. The intermediary buffer230further contains an issuance pointer and a retirement pointer to point to an instance that needs to issue a hash request and an instance to be retired, respectively. Initially, the fetch unit220fetches multiple characters to be compressed from the raw string of the data buffer210and stores the characters in the instances of the intermediary buffer230in order. An FSM (Finite-State Machine)240may issue a hash request to a hash matcher250for an instance to obtain information indicating whether a string with a length of n that is associated with the instance can match one hash key of a hash table. In some embodiments, n is 3 or greater. The FSM240may further issue a data request to an LSM (longest string matcher)260for an instance to obtain the length of the original string of a sliding window of the data buffer210that can be matched following of the string of the instance. It should be noted that the string of the sliding window is located before the original string to be compressed within the intermediary buffer230; that is, the string of the sliding window is the string that has been compressed. The FSM240may be implemented in fixed functions of PLD (Programmable Logic Device), PLC (Programmable Logic Controller), FPGA (Field Programmable Gate Array) or ASIC (Application-Specific Integrated Circuit) to complete the controls described in the embodiments of the invention.

FIG. 3is a state diagram according to an embodiment of the invention. Initially, the fetch unit220fetches multiple characters to be compressed from the raw string of the data buffer210and stores the characters in the instances of the intermediary buffer230in order. For example, the fetch unit220fetches a string “abcdxyzefgaf” and stores characters thereof in the intermediary buffer230in order. A state of each instance is initiated as an idle state S31and the idle state S31may be represented in null value. Table 1 shows initiated results for the instances:

TABLE 1MatchLengthMatchIndexCharacterState(len)Offset0a/1b/2c/3d/4x/5y/6z/7e/8f/9g/10a/11f/The symbol “/” represents a null value.

Methods for accelerating hash-based compression contain several procedures: a hash request procedure; a hash reply procedure; a data reply procedure; and a retirement procedure. The hash request and the retirement procedures are performed in parallel and have higher priorities than the others.FIG. 4is a flowchart of a hash request procedure according to an embodiment of the invention. At each clock cycle, the FSM240obtains an instance that is pointed by the issuance pointer (step S410), issues a hash request for the obtained instance to a hash matcher250(step S430), updates the state of the instance with “HASH_ISSUED” to indicate that the instance enters a hash request state S32(step S450) and updates the issuance pointer to point to the next instance (step S470). The hash request contains a string with a length n that has the character of the obtained instance followed by characters of subsequent instances. For example, the hash request corresponding to the instance 0 contains the string “abc”, the hash request corresponding to the instance 1 contains the string “bcd”, and so on. The string “abc” and “bcd” may be referred to as substrings of the raw string “abcdxyzefgaf”.

FIG. 5is a flowchart of a hash reply procedure according to an embodiment of the invention. After receiving a reply corresponding to an instance from the hash matcher250(step S510), the FSM240determines whether the reply contains a match message (step S530). When the reply contains a no-match message (the “No” path of step S530), the state of the instance is updated with “NM” to indicate that the instance enters a no-match state S34(step S550). The reply received from the hash matcher250contains the requested string to make the FSM240recognize which instance is associated with the reply. When an instance enters the no-match state S34, the FSM240may recycle memory space of the instance at a future clock cycle for another instance to be produced. When the reply contains a match message (the “Yes” path of step S530), the FSM240obtains a match offset from the reply (step S571), issues a data request corresponding to the instance to the LSM260(step S573). The data request contains the obtained match offset, making the LSM260search the string of the sliding window of the data buffer210and obtain a longest-match length between the string of the sliding window starting with the obtained match offset and the string of the intermediary buffer230that starts with the character of the instance. After that, the match length of the instance is updated with n (step S573) and the state of the instance is updated with “DATA ISSUED” to indicate that the instance enters a data request state S33(step S577). For example, after 7 clock cycles, the FSM240updates the instance states of the intermediary buffer230according to the replies from the hash matcher250and the LSM260as follows:

TABLE 2MatchLengthMatchIndexCharacterState(len)Offset0aNM1bHASH_ISSUED2cNM3dNM4xDATA_ISSUED310005yNM6zNM7e/8f/9g/10a/11f/
Table 2 shows hash requests corresponding to the instances 0 to 6 has been issued to the hash matcher250. The FSM240has received replies corresponding to the instances 0, 2-3 and 5-6 that contain no-match (NM) messages. That is, the hash matcher250finds no-match for the strings “abc”, “cdx”, “dxa”, “dxy”, “yze” and “zef” corresponding to the instances 0, 2-3 and 5-6. In other words, the strings are not present in the raw string of the sliding window of the data buffer210. In addition, the FSM240has received a reply corresponding to the instance 4 that contains a match message from the hash matcher250, has issued a data request to the LSM260and hasn't received any reply from the LSM260. The hash matcher250finds a match for the string “xyz” corresponding to the instance 4; that is, the string “xyz” is present in the string of the sliding window of the data buffer210. The FSM240obtains a match offset of the sliding window for the string “xyz” of the instance 4 and issues a data request comprising the match offset to the FSM260, making the LSM260search the string of the sliding window of the data buffer210and obtain a longest-match length between the string of the sliding window that starts with the match offset1000and the string of the intermediary buffer230that starts with “xyz”. In addition, the FSM240hasn't received any reply corresponding to the instance 1 from the hash matcher250. It should be noted that, in alternative embodiments, after obtaining the match offset corresponding to an instance from the reply (step S571), the FSM240issues a data request corresponding to the instance to the LSM260(step S573) but does not update the content of the instance of the intermediary buffer230(that is, does not execute steps S575and S577).

FIG. 6is a flowchart of a data reply procedure according to an embodiment of the invention. When receiving a reply corresponding to an instance from the LSM260(step S610), the FSM240obtains a length l from the reply that is calculated by the LSM260(step S630) and determines whether the length l is shorter than the maximum match length max_match (step S650). When the length l is shorter than the maximum match length max_match (the “Yes” path of step S650), the state of the instance is updated with “PM” to indicate that the instance enters a partial match state S37(step S671) and a match length of the instance is updated with len=len+l (step S673). When an instance enters the partial match state S37, the FSM240may recycle memory space of the instance at a future clock cycle for another instance to be produced. When the length l is not shorter than (usually equals) the maximum match length max_match (the “No” path of step S650), the state of the instance is updated with “FM” to indicate that the instance enters a full match state S36(step S691), a match length of the instance is updated with len=len+max_match (step S693), and a further data request corresponding to the instance is issued to the LSM260for continuing to match the following string (step S695). It should be understood that if the step for updating the content of the instance of the intermediary buffer230as shown inFIG. 5is omitted, the match length is updated with len=len+l+n as shown inFIG. 6instead, where n is the length of the substring corresponding to the instance.

In one clock cycle, the FSM240not only perform the hash request procedure but also the retirement procedure.FIG. 7is a flowchart of a retirement procedure according to an embodiment of the invention. In each clock cycle, the FSM240obtains a state of the instance pointed by the retirement pointer (step S710), determines whether the state of the instance of the intermediary buffer230is the no-match state (step S731). When the state is the no-match state (the “Yes” path of step S731), the character of the instance is output to a formatter270to enable the formatter270to compress the raw string of the look-ahead buffer280accordingly (step S733), the state of the instance is updated with the null value and the retirement pointer is updated to point to the next instance for retiring the instance, enabling memory space of the instance can be provided for a future pushed instance (step S770). When the state of the instance is not the no-match state (the “No” path of step S731), it is determined whether the state of the instance is the partial match state (step S751). When the state of the instance is the partial match state (the “Yes” path of step S751), the match offset and the match length of the instance is output to the formatter270to enable the formatter270to compress the raw string of the look-ahead buffer280accordingly (step S753), the state of the instance is updated with the null value and the retirement pointer is updated to point to the next instance for retiring the instance, enabling memory space of the instance can be provided for a future pushed instance (step S770). The formatter270may use LZ4, LZO (Lempel-Ziv-Oberhumer), DEFLATE, or other algorithms to compress the raw string. When the state is neither no-match state nor partial match state (the “No” path of step S751), it means a full match and the FSM240issues a further data request corresponding to the instance to the LSM260for continuing to compare the following string as illustrated in step S691ofFIG. 6and does not perform any retirement for the instance. The “No” path of step S751ofFIG. 7is connected to step S710and the FSM240waits for a future update of the state of the instance. In general, the FSM240performs the retirement procedure as shown inFIG. 7according to an original order of the sub strings stayed in the raw string, which correspond to the instances; that is, the movement of the retirement pointer follows the original order, and outputs results to the formatter270according to the states, match lengths and match offsets of the instances of the intermediary buffer230(will be illustrated with Tables 3 to 5 as follows), enabling the formatter270to compress the raw string accordingly. Details will be described in the following with references made to Tables 3 to 5.

What follows are the cases shown in Table 2. Assume that, at clock cycle c7, the issuance pointer points to the instance 7, the retirement pointer points to the instance 0, the maximum match length max_match is preset to 16, and the FSM240receives a reply corresponding to the instance 4 from the LSM260: Refer toFIG. 4. At this clock cycle, the FSM240obtains the instance 7 pointed by the issuance pointer (step S410), issues a hash request that contains the string “efg” to the hash matcher250for the instance 7 (step S430), updates the state of the instance 7 with “HASH_ISSUED” to indicate that the instance 7 enters the hash request state S32(step S450) and updates the issuance pointer to point to the instance 8 (step S470). Refer toFIG. 7. The FSM240obtains the state of the instance 0 pointed by the retirement pointer (step S710). Since the state of the instance 0 is NM, the FSM240outputs the character “a” of the instance 0 to the formatter270, enabling the formatter270to compress the raw string of the look-ahead buffer280accordingly (step S733). Specifically, since the state of the instance 0 is NM, the character “a” maintains the original state and not to be compressed, and the sliding window of the data buffer210slides forward by one character. That is, the character “a” of the data buffer210is entered into the sliding window to become a part of a new dictionary. After that, the state of the instance 0 is updated with a null value “I” and the retirement pointer is updated to point to the instance 1 (step S770). Refer toFIG. 6. At this clock cycle, the FSM240receives a length 1=2 calculated by the LSM260from a reply corresponding to the instance 4 (step S630). Since 1<max_match, the state of the instance 4 is updated with “PM” to indicate that the instance 4 enters the partial match state S37(step S671) and the match length of the instance 4 is updated with len=3+2=5 (step S673). The instance states of the intermediary buffer230is updated as the following Table 3:

What follows are the cases shown in Table 3. Assume that, at clock cycle c8, the FSM240receives a reply corresponding to the instance 1 from the hash matcher250: Refer toFIG. 4. At this clock cycle, the FSM240obtains the instance 8 that is pointed by the issuance pointer (step S410), issues a hash request that contains the string “fga” to the hash matcher250for the instance 8 (step S430), updates the state of the instance 8 with “HASH_ISSUED” to indicate that the instance 8 enters the hash request state S32(step S450) and updates the issuance pointer to point to the instance 9 (step S470). Refer toFIG. 7. The FSM240obtains the state of the instance 1 pointed by the retirement pointer (step S710). Since the state of the instance 1 is HASH_ISSUED, the FSM240does nothing. Refer toFIG. 5. At this clock cycle, the FSM240receives a reply from the hash matcher250corresponding to the instance 1 (step S510). Since that the reply contains a no-match message, the state of the instance 1 is updated with “NM” to indicate that the instance 1 enters the no-match state S34(step S550). The instance states of the intermediary buffer230is updated as the following Table 4:

What follows are the cases shown in Table 4. Assume that, at clock cycle c9, the FSM240receives a reply corresponding to the instance 7 from the hash matcher250: Refer toFIG. 4. At this clock cycle, the FSM240obtains the instance 9 pointed by the issuance pointer (step S410), issues a hash request that contains the string “gaf” to the hash matcher250for the instance 9 (step S430), updates the state of the instance 9 with “HASH_ISSUED” to indicate that the instance 9 enters the hash request state S32(step S450) and updates the issuance pointer to point to the instance 10 (step S470). Refer toFIG. 7. The FSM240obtains the state of the instance 1 pointed by the retirement pointer (step S710). Since the state of the instance 1 is NM, the FSM240outputs the character “b” of the instance 1 to the formatter270, enabling the formatter270to compress the raw string of the look-ahead buffer280accordingly (step S733). Specifically, since the state of the instance 1 is NM, the character “b” maintains the original state and not to be compressed, and the sliding window of the data buffer210slides forward by one character. That is, the character “b” of the data buffer210is entered into the sliding window to become a part of a new dictionary. After that, the state of the instance 1 is updated with a null value “/” and the retirement pointer is updated to point to the instance 2 (step S770). Refer toFIG. 5. At this clock cycle, the FSM240receives a reply corresponding to the instance 7 from the hash matcher250(step S510). Since the reply contains a no-match message, the state of the instance 7 is updated with “NM” to indicate that the instance 7 enters the no-match state S34(step S550). The instance states of the intermediary buffer230are updated as per the following Table 5:

Refer toFIG. 7. Suppose that, after a period of time has elapsed, the FSM240obtains the state of the instance 4 pointed by the retirement pointer (step S710). It should be noted that, before this moment, the characters “c” and “d” of the raw string of the look-ahead buffer280are no-match and are not compressed. In addition, the characters “c” and “d” have been entered into the sliding window to become a part of a new dictionary. At this clock cycle, since the state of the instance 4 is PM, the FSM240outputs the match offset offset=1000 and the match length len=5 to the formatter270, enabling the formatter270to compress the raw string of the look-ahead buffer280accordingly (step S753). Since the state of the instance 4 is PM and its match length len=5, the string “xyzef” is replaced with (offset, len), that is (1000, 5) and the sliding window of the data buffer210slides forward by 5 characters; that is, the string “xyzef” of the data buffer210are entered into the sliding window to become a part of a new dictionary.

As shown in the above examples, the FSM240issues corresponding hash requests according to the order of instances to activate compression procedures. It should be noted that when the hash matcher250and the LSM260compute for each instance is not predictable, which is caused by, for example, the parallel mapping of the hash matcher250as described inFIG. 8, resulting these instances not being able to enter the no match state S34or the partial match state S37following the original order. Although these instances cannot be able to enter the no match state S34or the partial match state S37following the original order, by the aforementioned embodiments of the compression procedures, the FSM240can output the computation results of the hash matcher250and the LSM260to the formatter270in the original order of the instances with the aid of the retirement pointer.

FIG. 8is a block diagram of a hash matcher according to an embodiment of the invention. To accelerate hash matches, a hash matcher may contain multiple match paths in parallel and each match may contain a FIFO (First-In-First-Out) queue, a matcher and a memory bank. For example, a first match path contains a FIFO queue850_1, a matcher870_1and a memory bank890_1, a second match path contains a FIFO queue850_2, a matcher870_2and a memory bank890_2, and so on. Any of the hash functions810_1to810_4maps a sub string sent by the FSM240to a hash index, directs a selector830to connect to one of the match paths according to the hash index and transmits the sub string to the connected match path. When determining that a hash table does not contain the substring, the connected match path transmits a no-match message to the FSM240. When determining that the hash table contains the substring (that is, the substring exists in the sliding window of the data buffer210), the connected match path transmits a match message and a match offset of the hash table corresponding to the substring to the FSM240. For example, when the hash table contains the substring “xyz” corresponding to the instance 4, that means the substring “xyz” exists in the sliding window of the data buffer210. Although four match paths are described as examples in the embodiments of the invention, those skilled in the art may dispose more or fewer match paths in the hash matcher250according to different design requirements and the invention should not be limited thereto. The hash table is distributed in the four memory banks870_1to870_4. The memory banks870_1to870_4may be implemented in a cache. The hash table contains N entries. The memory bank870_1stores the 0thto the (N/4−1)thentries, the memory bank870_2stores the (N/4)thto the (N/2−1)thentries, the memory bank870_3stores the (N/2)thto the (3N/4−1)thentries and the memory bank870_4stores the (3N/4)thto the (N−1)thentries. That is, the hash table is distributed according to significant two bits of addresses. In alternative embodiments, the hash table may be distributed according to the least two bits or other two bits of addresses. In some embodiments, each entry may contain related information regarding multiple (e.g. 3) hash keys and the hash keys have the same hash index to form a hash chain. For example, when n is 3 and each entry stores data using 16 bytes, the exemplary data structure is shown in Table 6:

To accelerate hash matches, the hash matcher250may contain four hash functions810_0to810_3performing the same hash algorithm in parallel for mapping any substring to a hash index of a fixed length. The length of the hash index is shorter than that of the substring. The FSM240outputs four hash requests to hash functions810_1to810_4simultaneously at the same clock cycle in a 4-issue way. Any of the hash functions810_1to810_4directs a selector830to connect to one of FIFO (First-In-First-Out) queues850_1to850_4for pushing a hash request into the connected FIFO queue. For example, when mapping the substring “abc” to a hash index “0”, the hash function810_1directs the selector830to connect to the FIFO queue850_1for pushing a hash request into the FIFO queue850_1. It should be noted that the hash request contains the substring generated by the FSM240and the hash index generated by the corresponding hash function.

The hash matcher250may contain four parallel matchers870_1to870_4. The matcher870_1is connected between the FIFO queues850_1and a memory bank890_1, the matcher870_2is connected between the FIFO queues850_2and a memory bank890_2, the matcher870_3is connected between the FIFO queues850_3and a memory bank890_3and the matcher870_4is connected between the FIFO queues850_4and a memory bank890_4. Any of the matchers870_1to870_4acquires the earliest entered hash request from the connected FIFO queue, searches an entry conform to the hash index of the hash request from the connected memory bank and determines whether the entry contains a valid hash key by inspecting a tag of the found entry. When the entry does not contain a valid hash key, the matcher determines that the entry conform to the hash index of the hash request is not found and replies to the FSM240with a message that the sub string of the hash request is no match. When the entry contains a valid hash key, the matcher further determines whether the valid hash key is the same as the substring of the hash request. When all valid hash keys of the entry are different from the substring of the hash request, the matcher replies to the FSM240with a message that the substring of the hash request is no match. When one valid hash key of the entry is the same as the substring of the hash request, the matcher replies to the FSM240with a message that the substring of the hash request is matched, and a hash offset is associated with the matched hash key.

FIG. 9is a block diagram of a matcher according to an embodiment of the invention. Although embodiments of the invention only describe the matcher870_1as examples, those skilled in the art may deduce details of the matchers870_2to870_4by analogy. The matcher870_1contains a comparator910_1to910_3and an arbiter930. The comparator910_1obtains a substring of a hash request from the FIFO queue850_1and a first hash key and a first hash offset from a corresponding entry of the memory bank890_1and determines whether the substring is the same as the first hash key. When the substring is the same as the first hash key, the comparator910_1outputs the first hash offset to the arbiter930. The comparator910_2obtains the substring of the hash request from the FIFO queue850_1and a second hash key and a second hash offset from the corresponding entry of the memory bank890_1and determines whether the substring is the same as the second hash key. When the substring is the same as the second hash key, the comparator910_2outputs the second hash offset to the arbiter930. The comparator910_3obtains the substring of the hash request from the FIFO queue850_1and a third hash key and a third hash offset from the corresponding entry of the memory bank890_1and determines whether the substring is the same as the third hash key. When the substring is the same as the third hash key, the comparator910_3outputs the third hash offset to the arbiter930. When receiving no hash offset from the comparators910_1to910_3, the arbiter930replies to the FSM240with a no-match message for the substring of the hash request. When receiving one hash offset from the comparators910_1to910_3, the arbiter930replies to the FSM240with a match message and the received hash offset for the substring of the hash request. When receiving two or more hash offsets from the comparators910_1to910_3, the arbiter930replies to the FSM240with a match message and the minimum of the received hash offsets for the substring of the hash request. For example, a substring “abc” of a hash request is mapped (or calculated) by the hash function810_1to a hash index “0” and an entry of the memory bank890_1that corresponds to the hash index “0” contains three hash keys and their hash offsets: the first hash key “abc” with the hash offset=50; the second hash key “xyz” with the hash offset=100; and the third hash key “abc” with the hash offset=200. It should be noted that, although the hash key “abc” is different from the hash key “xyz”, the mapped (or calculated) hash indexes by the hash function810_1are the same. With the calculation rules adopted by the hash function810_1, the hash indexes of the hash keys “abc” and “xyz” are both “0”. Two identical hash keys “abc” appeared in the corresponding entry mean that two substrings “abc” appear in the raw string of the sliding window at different offsets. Since the first and third hash keys “abc” are the same as the substring “abc” of the hash request, the comparators910_1and910_3output the first hash offset=50 and the third hash offset=200 to the arbiter930, respectively. The arbiter930replies to the FSM240with a match message and the minimum hash offset=50 for the substring “abc”. It should be noted that, in some other embodiments, when two or more of the aforementioned matches appear in any hash table of a memory bank, the arbiter930replies to the FSM240with a match message and all received hash offsets for a substring of a hash request.

The aforementioned FSM240of the invention can output multiple hash requests to multiple hash functions in parallel at one clock cycle to trigger multiple hash matches. In addition, with the recordings of states, match lengths and match offsets in the intermediary buffer230that are introduced by the invention, the raw string can be compressed in the original order based on out-of-order calculation results of hash matches and LSMs corresponding to the recorded instances.

FIG. 10is a flowchart of a method for performing hash matches according to an embodiment of the invention. The hash functions810_1to810_4receive multiple substrings from the FSM240in parallel (step S1010). Next, the hash function810_1maps the received substring to a hash index and directs the selector830to connect the hash function810_1to one of match paths according to the hash index (step S1031), the hash function810_2maps the received substring to a hash index and directs the selector830to connect the hash function810_2to one of match paths according to the hash index (step S1033), and so on. In should be noted that, in steps S1031, S1033, S1035and S1037, two or more of the hash functions810_1to810_4may connect to the same match path and push hash requests including the received substrings into the FIFO queues of this match path. Next, when determining that the hash table does not contain the substring received by the hash function810_1, a matcher (such as the matcher870_1,870_2,870_3or870_4) of the match path connected by the hash function810_1transmits a no-match message to the FSM240(step S1051). When determining that the hash table contains the substring received by the hash function810_1, a matcher (such as the matcher870_1,870_2,870_3or870_4) of the match path connected by the hash function810_1transmits a match message and a match offset of the hash table to the FSM240where the match offset corresponds to the received substring (step S1071). When determining that the hash table does not contain the substring received by the hash function810_2, a matcher (such as the matcher870_1,870_2,870_3or870_4) of the match path connected by the hash function810_2transmits a no-match message to the FSM240(step S1053). When determining that the hash table contains the substring received by the hash function810_2, a matcher (such as the matcher870_1,870_2,870_3or870_4) of the match path connected by the hash function810_2transmits a match message and a match offset of the hash table to the FSM240where the match offset corresponds to the received substring (step S1073). Details of steps S1055, S1075, S1057and S1077may be deduced by analogy and are omitted for brevity. It should be noted that, when the FIFO queue of one match path contains two or more hash requests, the matcher of this match path performs the aforementioned determinations for the hash requests according to the arrival orders of the hash requests. For example, when the FIFO queue of one match path contains hash requests received from the hash functions810_1and810_2and the hash request from the hash function810_1arrives earlier than the hash function810_2, steps S1031, S1051and S1071are performed earlier than steps S1033, S1053and S1073.

Although the embodiments have been described as having specific elements inFIGS. 1, 2, 8 and 9, it should be noted that additional elements may be included to achieve better performance without departing from the spirit of the invention. While the process flows described inFIGS. 4-7 and 10include a number of operations that appear to occur in a specific order, it should be apparent that those skilled in the art can modify the order to achieve the same objectives. Thus, the invention should not be limited to the specific order.