Source: http://www.google.com/patents/US7697518?dq=amazon.com
Timestamp: 2016-07-28 05:06:26
Document Index: 166694530

Matched Legal Cases: ['art, 6', 'art, 1', 'art, 1', 'Art, 1', 'art, 2', 'art, 1', 'art, 2']

Patent US7697518 - Integrated search engine devices and methods of updating same using node ... - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inPatentsMethods of updating b-tree data structures (e.g., b*tree data structure) using search key insertion and deletion operations proceed from respective known states (e.g., respective canonical forms). These insertion operations include inserting a first search key into the b-tree by reconfiguring (e.g.,...http://www.google.com/patents/US7697518?utm_source=gb-gplus-sharePatent US7697518 - Integrated search engine devices and methods of updating same using node splitting and merging operationsAdvanced Patent SearchPublication numberUS7697518 B1Publication typeGrantApplication numberUS 11/532,225Publication dateApr 13, 2010Filing dateSep 15, 2006Priority dateSep 15, 2006Fee statusPaidPublication number11532225, 532225, US 7697518 B1, US 7697518B1, US-B1-7697518, US7697518 B1, US7697518B1InventorsPascal de WitOriginal AssigneeNetlogic Microsystems, Inc.Export CitationBiBTeX, EndNote, RefManPatent Citations (99), Non-Patent Citations (26), Referenced by (13), Classifications (6), Legal Events (7) External Links: USPTO, USPTO Assignment, EspacenetIntegrated search engine devices and methods of updating same using node splitting and merging operations
US 7697518 B1Abstract
Methods of updating b-tree data structures (e.g., b*tree data structure) using search key insertion and deletion operations proceed from respective known states (e.g., respective canonical forms). These insertion operations include inserting a first search key into the b-tree by reconfiguring (e.g., pre-processing) a plurality of sibling nodes of the b-tree into a predetermined overloaded form having a shape that is independent of a value of the first search key to be inserted therein. An operation is then performed to split the sibling nodes by redistributing the first and other search keys among an expanded plurality of the sibling nodes. These insertion operations use a process that trades off possibly performing additional memory accesses (e.g., to shift search keys (and/or handles or pointers) to the predetermined overloaded form) for the certainty that the same key movements are ultimately performed during operations to split sibling nodes.
1. A method of updating a b-tree of search keys within a search engine, comprising the steps of:
inserting a first search key into the b-tree by reconfiguring a plurality of sibling nodes of the b-tree into an overloaded form having a shape that is independent of a value of the first search key inserted therein and then performing a split operation on the plurality of sibling nodes by redistributing the first and other search keys among an expanded plurality of the sibling nodes; and
deleting a second search key from the b-tree by reconfiguring the plurality of sibling nodes into a predetermined underloaded form having a shape that is independent of a value of the second search key omitted therefrom and then performing a merge operation on the plurality of sibling nodes by redistributing remaining search keys among a reduced plurality of the sibling nodes.
2. The method of claim 1, wherein the b-tree is a b*tree of type N−(N+1), where N is a positive integer greater than one; and wherein the predetermined underloaded form includes a sibling node at a minimum fill level less one.
3. The method of claim 1, wherein the overloaded form is a canonical form.
4. An integrated circuit search engine, comprising:
a hardware implemented b-tree of search keys; and
a maintenance engine electrically coupled to said hardware implemented b-tree of search keys, said maintenance engine configured to insert a first search key into the b-tree by reconfiguring a plurality of sibling nodes of the b-tree into an overloaded form having a shape that is independent of a value of the first search key inserted therein and then performing a split operation on the plurality of sibling nodes by redistributing the first and other search keys among an expanded plurality of the sibling nodes, wherein said maintenance engine is further configured to delete a second search key from the b-tree by reconfiguring the plurality of sibling nodes into a predetermined underloaded form having a shape that is independent of a value of the second search key omitted therefrom and then performing a merge operation on the plurality of sibling nodes by redistributing remaining search keys among a reduced plurality of the sibling nodes.
5. The integrated circuit search engine of claim 4, wherein the overloaded form is a canonical form.
This application is related to U.S. application Ser. No. 11/184,243, filed Jul. 19, 2005, and U.S. application Ser. No. 11/374,622, filed Mar. 13, 2006, the disclosures of which are hereby incorporated herein by reference.
Linear sorting techniques may be utilized to arrange a plurality of search prefixes (a/k/a search “keys”) within an integrated circuit search engine device. One such linear sorting technique is based on the starting address of a prefix range associated with each search prefix. In the event a plurality of the search prefixes have the same starting address but different prefix lengths, then a search prefix with a shorter prefix length may be treated as “less than” a search prefix with a longer prefix length. One example of a plurality of 8-bit search prefixes is illustrated by TABLE 1.
The search prefixes in TABLE 1 may be sorted linearly as shown in FIG. 1, with the smallest search prefix having the shortest prefix length (e.g., A:0/0) located on the left side of the array 10 and the largest search prefix with the longest search prefix (e.g., M:240/5) located on the right side on the array 10. To perform a linear search (i.e., lookup) operation, an applied search key is compared with every search prefix in the array 10, starting with the search prefix on the left side of the array 10, until a search prefix is found with a start address that is greater than the applied search key. Each search prefix in the array 10 that matches the applied search key is a potential longest prefix match. Once the search operation terminates at the right side of the array 10 (or at a search prefix with a start address than is greater than the applied search key), the rightmost search prefix that matches the search key is treated as the longest prefix match (LPM).
This search operation is an iterative process, with each search prefix being compared in sequence with the applied search key. As illustrated by FIG. 2, this process can also be implemented in a hardware-based array 20, by simultaneously comparing the applied search key (e.g., 171) to all of the search prefixes within the array 20, using a plurality of comparators 22 that generate match and non-match signals. In particular, each match between the applied search key and a search prefix results in the generation of a match signal (M) and each non-match results in the generation of a “less than” signal (LT) or a “greater than” signal (GT). The comparators 22 may generate these signals as two-bit binary signals (e.g., M=11b, LT=01b, and GT=10b). The longest prefix match is represented by the search prefix associated with the rightmost match signal M, which in FIG. 2 is represented by the search prefix Q:16812. This longest prefix match may be identified using a priority encoder (not shown) that is configured to receive the signals generated by the comparators 22.
Conventional network routing applications may also utilize tree data structures to support search operations within an integrated circuit device. These tree data structures may include b-tree structures that are kept balanced to prevent one or more branches of the tree from becoming longer than other branches of the tree and thereby increasing search latency. FIG. 3 illustrates a three-level b-tree data structure 30 containing the search prefixes of TABLE 1 and the array 20 of FIG. 2. This b-tree 30 is illustrated as including six leaf nodes at Level 2 (i.e., Nodes 2-0, 2-1, 2-2, 2-4, 2-5 and 2-6), two intermediate nodes at Level 1 (Node 1-0 and 1-1) and a root node at Level 0 (Node 0-0).
As illustrated by the highlighted search path, a search of the b-tree using 171 as a search key begins at Node 0-0. The search prefix J at Node 0-0 represents a match with the search key 171 because 171 (i.e., 10101011b) is a match with 128/2 (i.e., 10XXXXXX), where X represents a “don't-care” value. The search then proceeds to Node 1-1 (i.e., along a right-side branch from Node 0-0 to Node 1-1) because 171 is greater than 128. No matches are present at Node 1-1 because the search key 171 (i.e., 10101011b) does not match either the search prefix R:170/8 (10101010b) or the search prefix H:224/3 (i.e., 111XXXXX). Because the search key 171 is greater than 170 and less than 224, the search then proceeds to and terminates at Node 2-5, which is a leaf node of the b-tree 30. None of the search prefixes U:192/2, G:192/3 or K:208/5 at Node 2-5 represent a match with the search key 171. Thus, based on the illustrated search path, which traverses Nodes 0-0, 1-1 and 2-5 of the b-tree 30, only search prefix J:128/2 represents a matching entry with the search key 171. However, as illustrated best by FIG. 2, the search prefix Q:168/6, which resides at Node 2-4 of FIG. 3, actually represents the longest prefix match with the search key 171, yet this search prefix was not within the search path and was not detected during the search operation. Moreover, the search prefixes A:0/0, L:128/1 and N:160/4 also represent matches that were not within the search path. This means that the conventional sorting of prefixes within the b-tree 30 of FIG. 3 will not yield correct results for all search keys. To address this limitation associated with the b-tree 30 of FIG. 3, span prefix masks have been used to support accurate longest prefix match search operations. These masks are described more fully in commonly assigned U.S. application Ser. No. 11/184,243, filed Jul. 19, 2005, the disclosure of which is hereby incorporated herein by reference.
Another example of a b-tree data structure is described in U.S. Pat. No. 6,490,592, which is assigned to Nortel Networks Limited. As described at Col. 1 of the '592 patent, conventional b-tree data structures may not be well suited for search operations that require identification of longest prefix matches (LPMs) within the b-tree data structure. To address this limitation, the '592 patent describes a modified b-tree data structure that is arranged so that data elements stored therein, which have no overlapping prefixes, are arranged in a standard b-tree structure. However, other data elements that have overlapping prefixes are arranged in a modified structure so that the prefix of such a data element contains the prefixes of all such data elements that succeed it in the b-tree. This modified structure is referred to as an L-structure. FIG. 3 of the '592 patent shows portions 300 and 340 that comprise a b-tree into which an L-structure 320 is inserted. Unfortunately, the use of L-structures within a b-tree may represent a form of prefix nesting that reduces a likelihood of achieving preferred b-tree properties that can reduce search latency and result in efficient utilization of memory space. In particular, for a fixed memory capacity and latency, which is related to tree height, the number of search prefixes that can be supported within the b-tree of the '592 patent is statistically dependent on the degree of nesting within the prefix data set supported by the b-tree. Accordingly, prefix data sets that require a high degree of nesting may result in an inefficient utilization of the memory space that is required to maintain the b-tree.
An additional type of b-tree data structure includes a b*tree data structure, which can require non-root nodes to be at least ⅔ full at all times. To maintain this fill requirement, a sibling node is not immediately split whenever it is full. Instead, keys are first shared between sibling nodes before node splitting is performed. Only when all sibling nodes within a group are full does a node splitting operation occur upon insertion of a new search key. FIG. 4 illustrates a conventional three-level b*tree data structure of � efficiency (i.e., N/(N+1)=3/4), having four key locations per node (i.e., M=4). These three levels are illustrated as L0, L1 and L2, where L0 is treated as the root level and L2 is treated as a leaf level. Level L1 is an intermediate level, which is a child relative to the root level and a parent relative to the leaf level. As will be understood by those skilled in the art, a b*tree of type N−(N+1) (i.e., 2-3, 3-4, 4-5, . . . ) requires all non-root nodes to be between N/(N+1) to 100% capacity (i.e, 67%, 75%, 80%, . . . up to 100%) before and after an insert or delete operation has been fully performed.
FIG. 5A illustrates a portion of a b*tree with excess capacity having three sibling nodes at a leaf level and a parent node at the root level containing the search keys A-K, which represent numeric search key values. The leftmost sibling node contains the search keys A, B and C, the middle sibling node contains the search keys E, F and G and the rightmost sibling node contains the search keys I, J and K. The parent node contains the search keys D and H. These sibling nodes are at 75% capacity, which meets the requirement that all non-root nodes be between N/(N+1) to 100% capacity for a 3-4 type b*tree, where N=3. As illustrated by FIG. 5B, an insertion of the key L into the b*tree of FIG. 5A increases the rightmost sibling node to full capacity without affecting the other two sibling nodes. The additional insertion of key M into the rightmost sibling node in the b*tree of FIG. 5B causes the transfer of key Ito the parent node and the transfer of key H from the parent node to the middle sibling node, as illustrated by FIG. 5C.
FIG. 5D illustrates the further insertion of node N into the rightmost sibling node, which causes an overflow that ripples through the parent and middle sibling nodes into the leftmost sibling node, which is now at full capacity. In FIG. 5E, a split between the sibling nodes and an increase in population of the parent node occurs in response to the further insertion of key O into the rightmost sibling node. This split from three to four sibling nodes is necessary to maintain a capacity of all non-root nodes in a range from 75% to 100% capacity, for N=3.
FIGS. 6A-6D illustrate three insertion examples that result in the splitting of sibling nodes having no excess capacity. As illustrated by FIG. 6A, the insertion of any additional key (#) into a b*tree with sibling nodes at full capacity results in a split among the sibling nodes and a repopulation of these nodes at equivalent levels (shown at 75%). In FIG. 6B, the insertion of key D+ into the leftmost sibling node results in a split that causes keys D, G and K to move to the parent node (displacing keys E and J) and a grouping of keys D+, E and F together in a sibling node. In FIG. 6C, the insertion of key I+ into the middle sibling node results in a split that causes keys D, H and K to move to the parent node (displacing keys E and J) and a grouping of keys I, I+ and J together in a sibling node. Finally, in FIG. 6D, the insertion of key N+ into the rightmost sibling node results in a split that causes keys D, H and L to move to the parent node (displacing keys E and J) and a grouping of keys M, N and N+ together in a rightmost sibling node. Thus, as illustrated by FIGS. 6B-6D, the value of the search key to be inserted into sibling nodes having no excess capacity influences the nature of the overflow and regrouping of keys during an operation to split the sibling nodes. This means that conventional hardware to perform insert operations may need to account for every possible insert location that may occur amongst the plurality of sibling nodes.
Some embodiments of the invention include methods of updating a b-tree data structure (e.g., b*tree data structure) using search key insertion and deletion operations that proceed from respective known states (e.g., respective canonical forms). These insertion operations include inserting a first search key into the b-tree by reconfiguring (e.g., pre-processing) a plurality of sibling nodes of the b-tree into a predetermined overloaded form having a shape that is independent of a value of the first search key to be inserted therein. An operation is then performed to split the sibling nodes by redistributing the first and other search keys among an expanded plurality of the sibling nodes. These insertion operations use a process that trades off possibly performing additional memory accesses (e.g., to shift search keys (and/or handles or pointers) to the predetermined overloaded form) for the certainty that the same key movements are ultimately performed during operations to split sibling nodes. The logical state reduction realized by having to deal with only a single split format results in design simplification and consequently reduces design time and verification effort because of the less varied logic required to implement the design and the reduced number of test cases needed to fully verify the design.
In addition, the deletion operations include deleting a second search key from the b-tree by reconfiguring the plurality of sibling nodes into a predetermined underloaded form having a shape that is independent of a value of the second search key to be omitted therefrom. This underloaded form includes a sibling node at a minimum fill level less one. An operation is then performed to merge the plurality of sibling nodes by redistributing remaining search keys among a reduced plurality of the sibling nodes. Like the case with the insertion operations, the deletion operations use a process that trades off possibly performing additional memory accesses (e.g., to shift search keys (and/or handles or pointers) to the predetermined underloaded form) for the certainty that the same key movements are ultimately performed during operations to merge sibling nodes.
Still further embodiments of the invention include an integrated circuit search engine having a hardware implemented b-tree of search keys therein and at least one maintenance engine for controlling, among other things, insert and delete operations within the b-tree. The maintenance engine, which is electrically coupled to the hardware implemented b-tree of search keys, is configured to insert a first search key into the b-tree by reconfiguring a plurality of sibling nodes of the b-tree into an overloaded form having a shape that is independent of a value of the first search key inserted therein and then performing a split operation on the plurality of sibling nodes by redistributing the first and other search keys among an expanded plurality of the sibling nodes. The maintenance engine is also configured to delete a second search key from the b-tree by reconfiguring the plurality of sibling nodes into an underloaded form having a shape that is independent of a value of the second search key omitted therefrom. The maintenance engine then performs a merge operation on the plurality of sibling nodes by redistributing remaining search keys among a reduced plurality of the sibling nodes.
FIG. 4 illustrates a conventional three-level b*tree data structure of � efficiency (i.e., N/(N+1)=�), having four key locations per node.
FIG. 5A illustrates a portion of a b*tree having a parent node and three sibling nodes with excess capacity.
FIG. 5B illustrates an example of a search key insertion into the b*tree of FIG. 5A.
FIG. 5C illustrates an example of a search key insertion into the b*tree of FIG. 5B, which requires an overflow into an adjacent sibling node.
FIG. 5D illustrates an example of a search key insertion into the b*tree of FIG. 5C, which requires an overflow into non-adjacent sibling node.
FIG. 5E illustrates an example of a search key insertion into the b*tree of FIG. 5D, which requires a 3-4 split for the b*tree to remain structurally correct.
FIG. 6A illustrates an example of a search key insertion into a b*tree that requires a split to remain structurally correct.
FIG. 6B illustrates an example of a search key insertion (search key D+) into a b*tree that requires a split to remain structurally correct.
FIG. 6C illustrates an example of a search key insertion (search key I+) into a b*tree that requires a split to remain structurally correct.
FIG. 6D illustrates an example of a search key insertion (search key N+) into a b*tree that requires a split to remain structurally correct.
FIG. 7A illustrates how an insertion of a search key into a b*tree includes preprocessing of nodes into an overloaded form, according to embodiments of the invention.
FIG. 7B illustrates an example of an insertion of a search key into a b*tree, according to the embodiments of FIG. 7A.
FIG. 7C illustrates an example of an insertion of a search key into a b*tree, according to the embodiments of FIG. 7A.
FIG. 8A illustrates how a deletion of a search key from a b*tree includes preprocessing of nodes into an underloaded form, according to embodiments of the invention.
FIG. 8B illustrates an example of a deletion of a search key from a b*tree, according to the embodiments of FIG. 8A.
FIG. 9 is a block diagram of a pipelined search engine device that supports operations illustrated by FIGS. 7A-7C and 8A-8B.
The present invention now will be described more fully with reference to the accompanying drawings, in which preferred embodiments of the invention are shown. This invention may, however, be embodied in many different forms and should not be construed as being limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. For example, although a pipelined b-tree implementation is disclosed herein (see, e.g., FIG. 9), additional embodiments of the invention can include heap (fully shared memory levels) or hybrid (some sharing of memory levels) memory models that support a b-tree data structure. Like reference numerals refer to like elements throughout.
FIG. 7A illustrates operations to insert a search key into a b*tree having sibling nodes with no excess capacity, according to embodiments of the present invention. The three sibling nodes illustrated at the top of FIG. 7A are each filled with four search keys, which are shown generically by the reference character “#”. This means the insertion of a new search key in the b*tree will ultimately result in a splitting of the three adjacent sibling nodes into an expanded plurality of adjacent sibling nodes (i.e., four sibling nodes). The population of the parent node, shown as a root node, also increases by one (i.e., from 2 to 3 search keys).
According to embodiments of the invention, the operations to split the sibling nodes within the b*tree are preceded by operations to pre-process the shape of the b*tree into a canonical form, which is shown as an overloaded form. This overloaded form is shown as overloading the leftmost sibling node to a level of M+1, where M is the maximum number of keys per node in the b*tree. The sibling node immediately adjacent the leftmost sibling node is loaded to a level of M and the remaining N−2 sibling nodes on the right side are also loaded to levels of M. In alternative embodiments of the invention, a sibling node other than the leftmost sibling node may be processed into an overloaded form for insert cases, with the remaining sibling nodes being allocated with M search keys. Thus, the location of the sibling node that is pre-processed into an overloaded form is arbitrary from a logic design standpoint. Nonetheless, the location must remain consistent to achieve the desired reductions in state machine complexity that are associated with processing insert instructions, which are received by a search engine device containing a hardware implemented b-tree of search keys.
One example of the operations illustrated by FIG. 7A is illustrated by FIG. 7B. In particular, FIG. 7B illustrates operations to insert search key I+into a b*tree having no excess capacity. As illustrated at the top of FIG. 7B, this b*tree includes search keys A-D, F-I and K-N in the sibling nodes and search keys E and J in the parent node. The pre-processing of the b*tree into the canonical form illustrated by FIG. 7A results in the formation of an overloaded leftmost sibling node containing search keys A-E, a middle sibling node containing search keys G-I and I+ and a rightmost sibling node containing search keys K-N. This canonical form of the b*tree structure is illustrated in the middle of FIG. 7B. A node splitting operation is then performed to convert the overloaded b*tree structure into the valid b*tree structure at the bottom of FIG. 7B, which contains four sibling nodes at 75% capacity.
Another example of the operations illustrated by FIG. 7A is illustrated by FIG. 7C. In particular, FIG. 7C illustrates operations to insert search key N+ into a b*tree having no excess capacity. As illustrated at the top of FIG. 7C, this b*tree includes search keys A-D, F-I and K-N in the sibling nodes and search keys E and J in the parent node. The pre-processing of the b*tree into the overloaded canonical form illustrated by FIG. 7A results in the formation of an overloaded leftmost sibling node containing search keys A-E, a middle sibling node containing search keys G-J and a rightmost sibling node containing search keys L-N and N+. This canonical form of the b*tree structure is illustrated in the middle of FIG. 7C. A node splitting operation is then performed to convert the overloaded b*tree structure into the valid b*tree structure at the bottom of FIG. 70, which contains four sibling nodes at 75% capacity. Accordingly, the b*tree structures in FIGS. 7B and 7C are processed into an overloaded format having a shape that remains unchanged regardless of the value of the search key to be inserted (e.g., I+ or N+). In this manner, the insertion process trades off possibly performing additional memory accesses (e.g., to shift search keys (and/or handles or pointers) to the predetermined overloaded format) for the certainty that the same key movements are ultimately performed for each and every split operation among sibling nodes. The logical state reduction realized by having to deal with only a single split format results in design simplification and consequently reduces design time and verification effort because of the less varied logic required to implement the design and the reduced number of test cases needed to fully verify the design.
Moreover, as illustrated by FIGS. 8A-8B, operations to pre-process sibling nodes of a b*tree into a canonical form that is suitable for processing delete instructions includes establishing one sibling node at a minimum fill capacity less one (i.e., ((N/(N+1))M)−1). In particular, FIG. 8A illustrates operations to delete a search key from a b*tree having sibling nodes at minimum fill levels, according to embodiments of the present invention. The four sibling nodes illustrated at the top of FIG. 8A are each filled with three search keys, which are shown generically by the reference character “#”. This means the deletion of a search key from the b*tree will ultimately result in a merging of the four adjacent sibling nodes into a reduced number of adjacent sibling nodes (i.e., three sibling nodes). The population of the parent node, shown as a root node, also decreases by one (i.e., from 3 to 2 search keys).
According to these embodiments, the operations to merge the sibling nodes within the b*tree are preceded by operations to pre-process the shape of the b*tree into a canonical form, which is shown as an underloaded form. This underloaded form is shown as including a rightmost sibling node that is filled to a minimum level less one (i.e., ((M(N/(N+1))−1). Thus, as illustrated by the b*tree of FIG. 8B, which illustrates four sibling nodes containing search keys A-C, E-G, I-K and M-O and a parent node containing keys D, H and L, an operation to delete key “G” from the b*tree initially causes the parent node to be rearranged to contain keys D, I and M and causes the three leftmost sibling nodes to contain keys: A-C; E, F and H; and J, K and L. The rightmost sibling node is also pre-processed to contain only keys N and O, which is below the minimum fill capacity of three keys per node for a b*tree of type 3-4. Thereafter, a merge operation is performed to rearrange the keys within a reduced number of sibling nodes, which are now at full capacity.
FIG. 9 illustrates a block diagram of a pipelined search engine device 60 that supports the above-described b-tree data structures and handle memory and is responsive to applied search keys and commands. This search engine device 60, which supports multiple four-level b-trees as separate tables (i.e., databases) that share the same node storage and search logic, includes a plurality of pipeline stages 70 a-70 d dedicated to each b-tree level and a separate pipeline stage 80 for the final result handle lookup and generation of result handles. The first pipeline stage 70 a represents a Level 0 block (L0) of the b-tree containing Level 0 storage elements, row buffers (optional in some designs) and comparator logic. The first pipeline stage 70 a is responsive to a head pointer and a key. The second pipeline stage 70 b represents a Level 1 block (L1) containing Level 1 storage elements, row buffers (optional in some designs) and comparator logic. The second pipeline stage 70 b is responsive to a sub-tree pointer, a best match result generated by the first pipeline stage 70 a and the key. Similarly, the third pipeline stage 70 c represents a Level 2 block (L2) containing Level 2 storage elements, row buffers (optional in some designs) and comparator logic. The third pipeline stage 70 c is responsive to a sub-tree pointer, a best match result generated by the second pipeline stage 70 b and the key. The fourth pipeline stage 70 d represents a Level 3 block (L3) containing Level 3 storage elements, row buffers (optional in some designs) and comparator logic. The fourth pipeline stage 70 d is responsive to a sub-tree pointer, a best match result generated by the third pipeline stage 70 c and the key. The final pipeline stage is a handle lookup stage 80, which performs handle lookup operations within a handle memory 82 to thereby generate a result handle in response to a handle block pointer.
A table maintenance engine 62 is also provided, which contains a plurality of sub-engines that integrate with corresponding ones of the four pipeline stages 70 a-70 d and the handle lookup stage 80. This table maintenance engine 62 performs operations including the search key insertion and deletion operations described with respect to FIGS. 7A-7C and 8A-8B during idle search clock cycles. A table configuration circuit 64 is provided, which can support multiple search trees and map a table ID associated with a received search request to a tree head pointer (HEAD POINTER) for the corresponding table. Because of the pipelined structure of the search engine device 60, the maximum search rate can equal the maximum clock speed supported by the four pipeline stages 70 a-70 d and the handle lookup stage 80.
The table maintenance engine 62 receives search keys and commands on behalf of the search engine device 60 and forwards search commands to the table configuration circuit 64. The table maintenance engine 62 also queues up any key insert and delete (update) commands it receives for processing because key insertion and deletion typically cannot be completed in a simple single pass through the search engine pipeline. When idle command cycles indicate there are memory access opportunities available to perform table maintenance accesses on the memories (L0, L1, L2, L3) within each pipeline stage 70 a-70 d and the handle memory 82 within the handle lookup stage 80, the maintenance engine 62 performs maintenance accesses corresponding to portions of a key insert or delete request. The maintenance engine 62 processes one insert or delete request at a time and manages search memory node allocation to thereby allocate free nodes when needed to process key inserts and returning freed nodes to a pool when freed during deletes. To ensure search coherency and permit searching while the maintenance engine 62 processes a key update, the maintenance engine 62 makes a copy of nodes that must be modified while processing updates and only modifies these “temporary” copies. Once all node copies have been modified at all necessary levels for a key update, the maintenance engine 62 updates pointers in all necessary search levels to point to the modified node copies it was working on and reclaims the original nodes, which were copied, for future use. These pointers are updated in a manner that preserves search coherency on every lookup.
Once all temporary node copies at all levels have been properly updated, a special command is executed within the pipeline of stages to thereby cause each level of the b-tree to point to the node copies and reclaim the nodes that are being replaced. This update process propagates through the pipeline across all level at the same speed as a search command. Accordingly, all searches that enter the pipeline before the special command will search against a database before any changes pertaining to the update are applied, but any searches that enter the pipeline after the special command will search against a database that appears to have been instantly and completely modified to reflect the update.
The table configuration circuit 64 receives search commands from the maintenance engine 62, which include a table ID for the table to be searched. The table configuration circuit 64 then maps the table ID, corresponding to a unique b-tree within the search engine device 60, to a root tree node pointer in the Level 0 block 70 a. The table configuration circuit 64 then forwards this pointer to the Level 0 block 70 a instructing it to perform a search starting at the root node pointed to by the root tree node pointer.
Each of the Level 0, Level 1 and Level 2 blocks 70 a-70 c corresponds to one of the upper three levels of an SPM b-tree, which is described more fully in U.S. application Ser. No. 11/184,243, filed Jul. 19, 2005. Each level receives a search key, a sub-tree pointer and an indication of the best match found by the previous levels in the search. In the case of the Level 0 block 70 a, which can only represent the root level in the b-tree, this best match indication is always null. A Level 0, Level 1 or Level 2 block reads a search node from its node storage based on the sub-tree pointer it receives and buffers it in a set of flip-flops within its respective row buffer sub-block. Each node stores a set of keys, SPM bit-masks and sub-tree pointers. The comparator sub-block compares the search key to all of the keys and the SPM bit-masks read from the node storage sub-block and determines the best match for the search key, if any, and also determines which of the node's sub-tree pointers the search should follow for the next level of the search. The Level 0, Level 1 or Level 2 block forwards the sub-tree pointer it finds to the next lower level block along with the search key. If the next lower level block finds a new best match, then this best match for the search key is forwarded to the next lower level search stage. However, if no new best match is found, then the best match from the previous higher stage is forwarded to the next stage.
The Level 4 block corresponds to the leaf level of the SPM b-tree. It receives a search key, sub-tree pointer and any indication of a best match from the previous levels in the search. The Level 4 block reads a search node from its node storage based on the sub-tree pointer that it receives and buffers it in a set of flip-flops within its row buffer sub-block. The comparator sub-block compares the search key to all of the keys read from the node storage sub-block and determines a best match, if any. If the Level 4 block finds a new best match for the search key, then it forwards its own best match as the handle pointer to the handle lookup block 80. Otherwise, if no new best match is found, then the best match received from the prior stage is passed as the handle pointer.
The handle lookup block 80 receives an indication of the best match found by the Level 0-Level 3 search stages 70 a-70 d and uses the best match as an index to lookup a search result handle in the handle memory 82. In response to the index, the handle memory 82 outputs a retrieved handle as the result handle (i.e., the search result).
Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS4606002Aug 17, 1983Aug 12, 1986Wang Laboratories, Inc.B-tree structured data base using sparse array bit maps to store inverted listsUS5228115Feb 12, 1992Jul 13, 1993International Business Machines CorporationHybrid backtrack/lookahead search technique for constraint-satisfaction problemsUS5261088 *Apr 26, 1990Nov 9, 1993International Business Machines CorporationManaging locality in space reuse in a shadow written B-tree via interior node free space listUS5430869May 29, 1991Jul 4, 1995Hewlett-Packard CompanySystem and method for restructuring a B-TreeUS5446887Sep 17, 1993Aug 29, 1995Microsoft CorporationOptimal reorganization of a B-treeUS5475837Jan 17, 1995Dec 12, 1995Hewlett-Packard CompanyMethod and system for restructuring a B-Tree for managing data during a node splitting operationUS5560007Oct 18, 1995Sep 24, 1996Borland International, Inc.B-tree key-range bit map index optimization of database queriesUS5644763 *Jun 28, 1995Jul 1, 1997Sybase, Inc.Database system with improved methods for B-tree maintenanceUS5666494Mar 31, 1995Sep 9, 1997Samsung Electronics Co., Ltd.Queue management mechanism which allows entries to be processed in any orderUS5758356Sep 12, 1995May 26, 1998Hitachi, Ltd.High concurrency and recoverable B-tree index management method and systemUS5787430Jun 30, 1994Jul 28, 1998International Business Machines CorporationVariable length data sequence backtracking a trie structureUS5812996Nov 6, 1995Sep 22, 1998Sybase, Inc.Database system with methods for optimizing query performance with a buffer managerUS5813000Mar 14, 1996Sep 22, 1998Sun Micro SystemsB tree structure and methodUS5822749Feb 28, 1997Oct 13, 1998Sybase, Inc.Database system with methods for improving query performance with cache optimization strategiesUS5897655Dec 10, 1996Apr 27, 1999International Business Machines CorporationSystem and method for cache replacement within a cache set based on valid, modified or least recently used status in order of preferenceUS5918245Mar 13, 1996Jun 29, 1999Sun Microsystems, Inc.Microprocessor having a cache memory system using multi-level cache set predictionUS5924115Mar 29, 1996Jul 13, 1999Interval Research CorporationHierarchical memory architecture for a programmable integrated circuit having an interconnect structure connected in a tree configurationUS6098150Nov 17, 1995Aug 1, 2000Sun Microsystems, Inc.Method and apparatus for fetching information from a cache memoryUS6115792Nov 9, 1999Sep 5, 2000Advanced Micro Devices, Inc.Way prediction logic for cache arrayUS6138123 *Jul 15, 1997Oct 24, 2000Rathbun; Kyle R.Method for creating and using parallel data structuresUS6219662Jul 9, 1998Apr 17, 2001International Business Machines CorporationSupporting database indexes based on a generalized B-tree indexUS6389507Jan 14, 2000May 14, 2002Gigabus, Inc.Memory device search system and methodUS6401117Mar 31, 1999Jun 4, 2002Intel CorporationPlatform permitting execution of multiple network infrastructure applicationsUS6404752Aug 27, 1999Jun 11, 2002International Business Machines CorporationNetwork switch using network processor and methodsUS6421730Apr 1, 1999Jul 16, 2002Intel CorporationProgrammable system for processing a partitioned network infrastructureUS6430527Aug 26, 1998Aug 6, 2002Avici SystemsPrefix search circuitry and methodUS6441053Jun 8, 1999Aug 27, 2002The Trustees Of The University Of PennsylvaniaInhibitors of glycogen synthase kinase-3 and methods for identifying and using the sameUS6460112Jun 22, 1999Oct 1, 2002Netlogic Microsystems, LlcMethod and apparatus for determining a longest prefix match in a content addressable memory deviceUS6460120Aug 27, 1999Oct 1, 2002International Business Machines CorporationNetwork processor, memory organization and methodsUS6480839 *Jul 18, 2000Nov 12, 2002Go2Market.ComSystem and method for improving database data manipulation using direct indexing within a B*tree index having a tunable index organizationUS6490592Dec 30, 1999Dec 3, 2002Nortel Networks LimitedMethod of and apparatus for generating a tree data structure supporting longest match lookupUS6522632Jun 25, 1998Feb 18, 2003Avici SystemsApparatus and method for efficient prefix searchUS6526055Oct 20, 1998Feb 25, 2003Sun Microsystems, Inc.Method and apparatus for longest prefix address lookupUS6532457Jul 14, 2000Mar 11, 2003Ezchip Technologies Ltd.Look-ahead tree structureUS6535491Nov 29, 1999Mar 18, 2003Cisco Technology, Inc.Method and apparatus for rapidly reconfiguring computer networks using a spanning tree algorithmUS6539369Dec 8, 2000Mar 25, 2003Mosaid Technologies, Inc.Method and apparatus for storing sparse and dense subtrees in a longest prefix match lookup tableUS6553370Oct 4, 2000Apr 22, 2003Lsi Logic CorporationFlexible search engine having sorted binary search tree for perfect matchUS6564211Oct 4, 2000May 13, 2003Lsi Logic CorporationFast flexible search engine for longest prefix matchUS6611832Oct 9, 2001Aug 26, 2003International Business Machines Corp.Data structure for longest-matching prefix searching and updating method for search table data structuresUS6633865Dec 23, 1999Oct 14, 2003Pmc-Sierra LimitedMultithreaded address resolution systemUS6636849Nov 22, 2000Oct 21, 2003Genmetrics, Inc.Data search employing metric spaces, multigrid indexes, and B-grid treesUS6636956Jul 6, 2001Oct 21, 2003Cypress Semiconductor Corp.Memory management of striped pipelined data structuresUS6662287Oct 18, 2001Dec 9, 2003Lsi Logic CorporationFast free memory address controllerUS6691124Apr 4, 2001Feb 10, 2004Cypress Semiconductor Corp.Compact data structures for pipelined message forwarding lookupsUS6694323Jan 27, 2003Feb 17, 2004Sybase, Inc.System and methodology for providing compact B-TreeUS6697276Feb 1, 2002Feb 24, 2004Netlogic Microsystems, Inc.Content addressable memory deviceUS6707693Jun 5, 2002Mar 16, 2004Netlogic Microsystems, Inc.Content addressable memory with simultaneous write and compare functionUS6757779Oct 31, 2001Jun 29, 2004Netlogic Microsystems, Inc.Content addressable memory with selectable mask write modeUS6768739Feb 9, 2000Jul 27, 2004Nec CorporationRouter with a cache having a high hit probabilityUS6778530Nov 8, 1999Aug 17, 2004Juniper Networks, Inc.Method and apparatus for multiple field matching in network deviceUS6831850Nov 18, 2003Dec 14, 2004Netlogic Microsystems, Inc.Content addressable memory with configurable class-based storage partitionUS6839800Aug 28, 2002Jan 4, 2005Hywire Ltd.RAM-based range content addressable memoryUS6859455 *Nov 10, 2000Feb 22, 2005Nasser YazdaniMethod and apparatus for building and using multi-dimensional index trees for multi-dimensional data objectsUS6934795Oct 31, 2001Aug 23, 2005Netlogic Microsystems, Inc.Content addressable memory with programmable word width and programmable priorityUS6941314Apr 15, 2002Sep 6, 2005Lsi Logic CorporationUser selectable editing protocol for fast flexible search engineUS6944709Oct 31, 2001Sep 13, 2005Netlogic Microsystems, Inc.Content addressable memory with block-programmable mask write mode, word width and priorityUS7007027 *Dec 2, 2002Feb 28, 2006Microsoft CorporationAlgorithm for tree traversals using left linksUS7016904Apr 25, 2001Mar 21, 2006Altera CorporationMethod and system for rapid insertion of various data streams into sorted tree structuresUS7017021Apr 4, 2001Mar 21, 2006Cypress Semiconductor Corp.High-speed message forwarding lookups for arbitrary length strings using pipelined memoriesUS7023807Nov 12, 2002Apr 4, 2006Timothy Scott MichelsNetwork switching device with pipelined search enginesUS7035844Feb 25, 2002Apr 25, 2006Lsi Logic CorporationFFS search and edit pipeline separationUS7047317Jun 14, 2000May 16, 2006Altera CorporationHigh performance network address processor systemUS7076602Oct 21, 2003Jul 11, 2006Hywire Ltd.Multi-dimensional associative search engine having an external memoryUS7107263Dec 8, 2000Sep 12, 2006Netrics.Com, Inc.Multistage intelligent database search methodUS7231373Dec 1, 2005Jun 12, 2007Zingtech LimitedTransaction processingUS7231383May 1, 2002Jun 12, 2007Lsi CorporationSearch engine for large-width dataUS7257530Feb 12, 2003Aug 14, 2007Hongfeng YinMethod and system of knowledge based search engine using text miningUS7289979Dec 10, 2003Oct 30, 2007Alcatel LucentParallel asymmetric binary search on lengthsUS7292162Jul 12, 2006Nov 6, 2007Madian SomasundaramData coding system and methodUS7383276Jan 30, 2004Jun 3, 2008Microsoft CorporationConcurrency control for B-trees with node deletionUS7426518Mar 28, 2003Sep 16, 2008Netlogic Microsystems, Inc.System and method for efficiently searching a forwarding database that is split into a bounded number of sub-databases having a bounded sizeUS7437354May 7, 2004Oct 14, 2008Netlogic Microsystems, Inc.Architecture for network search engines with fixed latency, high capacity, and high throughputUS7571156Mar 25, 2004Aug 4, 2009Netlogic Microsystems, Inc.Network device, storage medium and methods for incrementally updating a forwarding databaseUS20020089937Nov 14, 2001Jul 11, 2002Srinivasan VenkatacharyPacket matching method and systemUS20020146009Apr 4, 2001Oct 10, 2002Pankaj GuptaHigh-speed message forwarding lookups for arbitrary length strings using pipelined memoriesUS20020152413Jun 11, 2002Oct 17, 2002Waters Gregory M.Prefix search circuitry and methodUS20020161969Oct 31, 2001Oct 31, 2002Nataraj Bindiganavale S.Content addressable memory with programmable word width and programmable priorityUS20030009453Jul 3, 2001Jan 9, 2003International Business Machines CorporationMethod and system for performing a pattern match search for text stringsUS20030009466Jun 21, 2001Jan 9, 2003Ta John D. C.Search engine with pipeline structureUS20030093613Aug 9, 2002May 15, 2003David ShermanCompressed ternary mask system and methodUS20030093646Aug 28, 2002May 15, 2003Hywire Ltd.RAM-based range content addressable memoryUS20030123397Dec 31, 2001Jul 3, 2003Kang-Bok LeeMethod for generating nodes in multiway search tree and search method using the sameUS20030123459Sep 17, 2001Jul 3, 2003Heng LiaoEfficiency masked matchingUS20030163302Feb 12, 2003Aug 28, 2003Hongfeng YinMethod and system of knowledge based search engine using text miningUS20040030686Jun 6, 2003Feb 12, 2004Cardno Andrew JohnMethod and system of searching a database of recordsUS20040059731Dec 8, 2000Mar 25, 2004Yianilos Peter N.Multistage intelligent database search methodUS20040083336Oct 21, 2003Apr 29, 2004Hywire Ltd.Multi-dimensional associative search engine having an external memoryUS20040109451Dec 6, 2002Jun 10, 2004Stmicroelectronics, Inc.Apparatus and method of using fully configurable memory, multi-stage pipeline logic and an embedded processor to implement multi-bit trie algorithmic network search engineUS20040139274Oct 20, 2003Jul 15, 2004Hui Ronald Chi-ChunVirtual content addressable memory with high speed key insertion and deletion and pipelined key searchUS20040170379Feb 18, 2004Sep 2, 2004Kabushiki Kaisha TohsibaHierarchical storage scheme and data playback scheme for enabling random access to realtime stream dataUS20040193619Mar 28, 2003Sep 30, 2004Srinivasan VenkatacharySystem and method for efficiently searching a forwarding database that is split into a bounded number of sub-databases having a bounded sizeUS20040205229Oct 23, 2003Oct 14, 2004Isic CorporationMethod and apparatus for longest prefix matching in processing a forwarding information databaseUS20040249803May 7, 2004Dec 9, 2004Srinivasan VankatacharyArchitecture for network search engines with fixed latency, high capacity, and high throughputUS20050091443Oct 23, 2003Apr 28, 2005Hywire Ltd.Search method using coded keysUS20050131867Dec 10, 2003Jun 16, 2005AlcatelParallel asymmetric binary search on lengthsUS20050163122Dec 30, 2004Jul 28, 2005University Of Florida Research Foundation, Inc.System and methods for packet filteringUS20060259682Jul 12, 2006Nov 16, 2006Madian SomasundaramData coding system and methodUS20070276648Feb 13, 2007Nov 29, 2007Lsi Logic CorporationSequential tester for longest prefix search enginesWO2004088548A1Mar 26, 2004Oct 14, 2004Cypress SemiconductorSystem and method for efficiently searching a forwarding database that is split into a bounded number of sub-databases having a bounded size* Cited by examinerNon-Patent CitationsReference1"A B-Tree Dynamic Router-Table Design," IEEE Transactions on Computers, vol. 54, Issue 7, Jul. 2005, 27 pages.2"Answers.com," http://www.answers.com/topic/b-tree, B-tree: Information From Answers.com, Admitted prior art, 6 pages.3"B*-tree," http://en.wikipedia.org/wiki/B%2A-tree, Admitted prior art, 1 page.4"B-Trees: Balanced Tree Data Structures" pp. 1-8 (believed prior to Sep. 15, 2006) .5"Canonical form," http://en.wikipedia.org/wiki/Canonical-form, Admitted prior art, 1 page.6"Network address processor makes embedded DRAM a virtue," http://www.electronicproducts.com/print.asp?ArticleURL=octo12.oct2000, Printed Aug. 14, 2006, Admitted Prior Art, 1 page.7"Tree (data structure)," http://en.wikipedia.org/wiki/Tree-data-structure, (Redirected from Tree data structure, Admitted prior art, 2 pages.8"B-Trees: Balanced Tree Data Structures" pp. 1-8 (believed prior to Sep. 15, 2006) <http://www.bluerwhite.org/btree/>.9"Canonical form," http://en.wikipedia.org/wiki/Canonical—form, Admitted prior art, 1 page.10"Tree (data structure)," http://en.wikipedia.org/wiki/Tree—data—structure, (Redirected from Tree data structure, Admitted prior art, 2 pages.11Aggarwal et al. "A Model for Hierarchical Memory" Proceedings of the Nineteenth Annual ACM Conference on Theory of Computing STOC pp. 305-314 (1987).12 *Applicant Admitted Prior Art (AAPA) (Answers.com B-tree Web pp. 1-6) printed Aug. 1, 2006.13Bayer, R. et al., "Prefix B-Trees," ACM Trans. On Database Systems, vol. 2, No. 1, Mar. 1977, pp. 11-26.14Bender et al. "Cache-oblivious B-trees", SIAM J. Comput, 2000, pp. 1-18.15Chang et al., "Dynamic Routing Tables using Augmented Balanced Search Tree," National Cheng Kung University/l-Shou University, No Date, 35 pages.16Choudhury et al. "A New Buffer Management Scheme for Hierarchical Shared Memory Switches" IEEE/ACM Transactions on Networking (TON) 5(5):728-738 (1997).17Djordjevic et al. "A Hierarchical Memory System Environment" Proceedings of the 1988 Workshop on Computer Architecture Education WCAE (6 pages)(1998).18Henry Hong-yi Tzeng, "Longest Prefix Search Using Compressed Trees", In Proceedings of IEEE Globe.com, 1998.19Kobayashi et al. "A Longest Prefix Match Search Engine for Multi-Gigabit IP Processing", C&C Media Research Laboratories, NEC Corporation 2000 IEEE.20Lu et al. "A B-Tree Dynamic Router-Table Design" pp. 1-27 (believed prior to Sep. 15, 2006).21Nasser Yazdani et al., "Prefix Trees: New Efficient Data Structures for Matching Strings of Different Lengths", IEEE, 2001, p. 76-85.22O'Connor et al., "The Iflow Address Processor," 2001 IEEE, pp. 16-23.23Srinivasan et al. "Fast Address Lookups Using Controlled Prefix Expansion" Washington University in St. Louis, ACM Sigmetrics '98/ Performance '98 Joint International Conference on Measurement and Modeling of Computer Systems.24Suri et al. "Multiway Range Trees: Scalable IP Lookup with Fast Updates" (5 pages)(believed prior to Sep. 15, 2006) http://www.cs.edu/~Varghese/PAPERS/globecome2001.pdf.25Suri et al. "Multiway Range Trees: Scalable IP Lookup with Fast Updates" (5 pages)(believed prior to Sep. 15, 2006) http://www.cs.edu/˜Varghese/PAPERS/globecome2001.pdf.26Uga et al. "A fast and compact longest match prefix look-up method using pointer cache for very long network address", IT Network Service Systems Laboratories Midori 3-9-1 1, Musashino, Tokyo 180-8585, Japan, 1999 IEEE.* Cited by examinerReferenced byCiting PatentFiling datePublication dateApplicantTitleUS7801877 *Sep 21, 2010Netlogic Microsystems, Inc.Handle memory access managers and methods for integrated circuit search engine devicesUS7831626Sep 20, 2007Nov 9, 2010Netlogic Microsystems, Inc.Integrated search engine devices having a plurality of multi-way trees of search keys therein that share a common root nodeUS7953082 *Jun 27, 2008May 31, 2011National Taiwan UniversityMethod and system for packet classification with reduced memory space and enhanced access speedUS7953721 *May 31, 2011Netlogic Microsystems, Inc.Integrated search engine devices that support database key dumping and methods of operating sameUS7987205Dec 21, 2007Jul 26, 2011Netlogic Microsystems, Inc.Integrated search engine devices having pipelined node maintenance sub-engines therein that support database flush operationsUS8086641Dec 17, 2008Dec 27, 2011Netlogic Microsystems, Inc.Integrated search engine devices that utilize SPM-linked bit maps to reduce handle memory duplication and methods of operating sameUS8438330May 7, 2013Netlogic Microsystems, Inc.Updating cam arrays using prefix length distribution predictionUS8886677Jun 26, 2007Nov 11, 2014Netlogic Microsystems, Inc.Integrated search engine devices that support LPM search operations using span prefix masks that encode key prefix lengthUS8984013 *Sep 30, 2009Mar 17, 2015Red Hat, Inc.Conditioning the distribution of data in a hierarchical databaseUS8996453Dec 31, 2009Mar 31, 2015Red Hat, Inc.Distribution of data in a lattice-based database via placeholder nodesUS9031987Dec 31, 2009May 12, 2015Red Hat, Inc.Propagation of data changes in distribution operations in hierarchical databaseUS20090185568 *Jul 23, 2009National Taiwan UniversityMethod and system for packet classification with reduced memory space and enhanced access speedUS20110078200 *Mar 31, 2011Eric WilliamsonSystems and methods for conditioning the distribution of data in a hierarchical database* Cited by examinerClassifications U.S. Classification370/389International ClassificationH04L12/28, H04L12/56Cooperative ClassificationG06F17/30985, G06F17/30961European ClassificationG06F17/30Z1TLegal EventsDateCodeEventDescriptionSep 15, 2006ASAssignmentOwner name: INTEGRATED DEVICE TECHNOLOGY, INC.,CALIFORNIAFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:DE WIT, PASCAL;REEL/FRAME:018261/0699Effective date: 20060914Jul 17, 2009ASAssignmentOwner name: SILICON VALLEY BANK,CALIFORNIAFree format text: SECURITY AGREEMENT;ASSIGNORS:NETLOGIC MICROSYSTEMS, INC.;NETLOGIC MICROSYSTEMS INTERNATIONAL LIMITED;NETLOGIC MICROSYSTEMS CAYMANS LIMITED;REEL/FRAME:022973/0710Effective date: 20090717Owner name: SILICON VALLEY BANK, CALIFORNIAFree format text: SECURITY AGREEMENT;ASSIGNORS:NETLOGIC MICROSYSTEMS, INC.;NETLOGIC MICROSYSTEMS INTERNATIONAL LIMITED;NETLOGIC MICROSYSTEMS CAYMANS LIMITED;REEL/FRAME:022973/0710Effective date: 20090717Jul 23, 2009ASAssignmentOwner name: NETLOGIC MICROSYSTEMS, INC.,CALIFORNIAFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:INTEGRATED DEVICE TECHNOLOGY, INC.;REEL/FRAME:022996/0786Effective date: 20090717Aug 30, 2011ASAssignmentOwner name: NETLOGIC MICROSYSTEMS CAYMANS LIMITED, CALIFORNIAFree format text: RELEASE BY SECURED PARTY;ASSIGNOR:SILICON VALLEY BANK;REEL/FRAME:026830/0141Effective date: 20110826Owner name: NETLOGIC MICROSYSTEMS, INC., CALIFORNIAFree format text: RELEASE BY SECURED PARTY;ASSIGNOR:SILICON VALLEY BANK;REEL/FRAME:026830/0141Effective date: 20110826Owner name: NETLOGIC MICROSYSTEMS INTERNATIONAL LIMITED, CALIFFree format text: RELEASE BY SECURED PARTY;ASSIGNOR:SILICON VALLEY BANK;REEL/FRAME:026830/0141Effective date: 20110826Oct 15, 2013FPAYFee paymentYear of fee payment: 4Apr 16, 2015ASAssignmentOwner name: BROADCOM CORPORATION, CALIFORNIAFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:NETLOGIC I LLC;REEL/FRAME:035443/0763Effective date: 20150327Owner name: NETLOGIC I LLC, DELAWAREFree format text: CHANGE OF NAME;ASSIGNOR:NETLOGIC MICROSYSTEMS, INC.;REEL/FRAME:035443/0824Effective date: 20130123Feb 11, 2016ASAssignmentOwner name: BANK OF AMERICA, N.A., AS COLLATERAL AGENT, NORTHFree format text: PATENT SECURITY AGREEMENT;ASSIGNOR:BROADCOM CORPORATION;REEL/FRAME:037806/0001Effective date: 20160201RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services