Patent Grant
8250514
The present invention is directed towards method and apparatus for routing.
A circuit design layout, such as an integrated circuit (“IC”), a printed circuit board (PCB), an IC package, etc. is a device (e.g., a semiconductor device) that includes many electronic components, such as transistors, resistors, diodes, and so on. These components are often interconnected to form multiple circuit components, such as gates, cells, memory units, arithmetic units, controllers, decoders, etc. A circuit design layout includes multiple layers of wiring that interconnect its electronic and circuit components. Traditionally, circuit design layouts use preferred direction (“PD”) wiring models, which specify a preferred wiring direction for each of their wiring layers. In preferred direction wiring models, the preferred direction typically alternates between successive wiring layers. One example of a PD wiring model is the PD Manhattan wiring model, which specifies alternating layers of preferred-direction horizontal and vertical wiring.
Design engineers design the IC's and PCB's by transforming logical or circuit descriptions of the IC's or PCB's into geometric descriptions, called layouts. These layouts typically include (1) circuit modules (i.e., geometric representations of electronic or circuit IC components) with pins, and (2) interconnect lines (i.e., geometric representations of wiring) that connect the pins of the circuit modules. A net is typically defined as a collection of pins that need to be connected. A list of all or some of the nets in a layout is referred to as a net list.
To create layouts, design engineers typically use electronic design automation (“EDA”) applications. These applications provide sets of computer-based tools for creating, editing, and analyzing layouts for IC design, Printed Circuit Board (PCB) designs, or Packages. One EDA tool is a router that defines routes for interconnect lines that typically connect the pins of the nets.
The underlying engine for essentially all modern routers is a path finding algorithm, herein called the Single Connection Router (SCR). The SCR selects a particular path (or route) from one or more source locations (called pads) on one or more layers to one or more target locations (also pads) on one or more layers.
Potential paths are considered by “expanding” from one location to the next, starting with the location of the source (or one of the potential source locations) and ending with the target location (or one of several potential target locations). In a gridded-router, the expansion proceeds from one cell to an adjacent cell on the same layer or to the corresponding cell on another layer.
In a topological router, the expansion proceeds along the topological map from one channel to the next or to another layer. A topological route is a route that is defined in terms of its relation to other layout items, such as pins, obstacles, boundaries, and/or other topological routes of other nets. As such, a topological route provides a general plan for how to route a net, without necessarily providing a specific geometric path to do so. One topological route represents a set of diffeomorphic geometric routes (i.e., a set of geometric routes that can be morphed into one another through a continuous sequence of perturbations without changing the route's path relative to any other pin, path, or obstacle).
The path selection process described above is controlled by means of cost functions. Costs are typically computed for each expansion and then added together to get a partial subtotal to reach from its source up to the current location. Costs have numeric value (for example, higher is worse). The SCR finds the path from a source location to a target location with the lowest total cost that satisfies all the predetermined rules. This cost is typically computed as the sum of several different individual costs, such as direction, length, accumulated crosstalk, etc. The direction cost is usually charged whenever the direction of the expansion differs from the “preferred direction” for that layer. For example, routing vertically on a horizontal layer is considered a “wrong-way” and incurs an extra “wrong-way cost”.
The overall quality of the routing is directly determined by the cost computation. Better algorithms for computing costs result in better routing, where better might mean faster (fewer potential paths considered) or higher quality (higher likelihood of 100% completion) or some combination. Improvements to the underlying cost computation directly account for significant differences between competing routing products. Therefore, it is critical to the success of any router to use the best possible cost algorithms.
Historically, almost all routers (for IC, PCB and Packages) have been Manhattan routers. In a Manhattan (or horizontal/vertical) router, most routing etch on some layers is horizontal and most routing etch on the other layers is vertical. When selecting paths, the SCR would insert a via (a connection between layers) to connect the horizontal etch segments on one layer with the vertical segments on the other layer. This technique is still used in some IC routers where the size of a via is relatively small compared to the size of etch segments.
Some fabrication technologies used in manufacturing IC's do not allow any vertical routing on a horizontal layer or any horizontal routing on a vertical layer due to lithography limitations. For instance,
Some IC routers and PCB routers have implemented a wrong-way cost. This allows some horizontal routing on vertical layers and some vertical routing on horizontal layers but makes the cost higher than staying with the layer's preferred routing direction.
A few routers have allowed more than just vertical and horizontal routing directions. They might, for example, support layers with a +45° or −45° bias or other angles. Some gridded routers have automatically flipped the preferred routing direction along the edge of the design. For example, on a gridded-design, there is no point in preferring horizontal routing in cells along the east or west edge of the design, since there is no adjacent cell in that direction.
Some routers allow users to manually override the preferred routing direction for a particular region of the design. For example, this would allow the user to change the preferred routing direction on the north side of a ball grid array (BGA) to be vertical on all layers, even on layers with horizontal preferred directions. However, forcing the user to manually override the preferred routing direction for each section of the design is slow, tedious and error prone. It limits the “what if” planning that the user can explore.
Adjusting routing directions only around the outer perimeter of the design had some advantage many years ago because it allowed some routing to go all the way around the outside, thus completing the last few connections. However, most of the congestion is near high-pin count devices. Also, most nets have length limitations which disallow very long connections. Thus, flipping the preferred routing direction only around the outside edge of the design has limited value in modern routers. Therefore, there is a need in the art for a general mechanism to allow the router to automatically adjust the preferred routing direction for a region of the design.
Some embodiments present a method of routing for a multilayer circuit design layout, such as an integrated circuit (IC), a printed circuit board (PCB), an IC package, etc. The design layout has a set of possible preferred local routing directions and each layer has a default preferred routing direction. The method receives a set of user specified constraints on routing directions for particular regions of the multilayer design layout. The method tessellates the available space for routing into separate tiles.
The set of user specified constraints includes one or more of the following: user designated flows, locked etches, “etch keep-out” areas, user “planned” or user “viewable” data, etc. The method automatically defines a preferred local routing direction for each tile based on a set of user specified constraints by performing the following steps. The method initializes an interim preferred routing direction of each tile to a predetermined direction. The method uses a set of objects created by the user defined constraints to compute new routing directions for each tile. The method uses the new routing directions to modify the interim preferred routing direction of each tile. The method uses the interim preferred routing direction of each particular tile to determine a final preferred routing direction for the particular tile.
Some embodiments present a method of routing for a multilayer circuit design layout. The design layout has a set of possible preferred local routing directions and each layer has a default preferred routing direction. The method receives a first set of user specified preferred routing directions for particular regions of the multilayer design layout. The method tessellates the available space for routing into separate tiles. The tiles are determined independent of the regions. The method automatically defines a second preferred local routing direction for each tile based on the user specified preferred routing directions.
Some embodiments present a method of determining preferred routing directions for a multilayer circuit design layout. The multilayer circuit design layout has a set of possible preferred routing directions. Each layer has a general preferred routing direction. The method tessellates available space for routing into separate tiles. The method initializes each tile with all possible preferred routing directions marked as available. The method uses a set of user defined constraints to determine which preferred directions are blocked for each tile. The method determines preferred local routing directions for each tile based on preferred directions that are not blocked on each tile.
The novel features of the invention are set forth in the appended claims. However, for purpose of explanation, several embodiments of the invention are set forth in the following figures.
In the following description, numerous details are set forth for purpose of explanation. However, one of ordinary skill in the art will realize that the invention may be practiced without the use of these specific details. In other instances, well-known structures and devices are shown in block diagram form in order not to obscure the description of the invention with unnecessary detail.
Some embodiments present a method of routing for a multilayer circuit design layout, such as an integrated circuit (IC), a printed circuit board (PCB), an IC package, etc. The design layout has a set of possible preferred local routing directions and each layer has a default preferred routing direction. The method receives a set of user specified constraints on routing directions for particular regions of the multilayer design layout. The method tessellates the available space for routing into separate tiles.
The set of user specified constraints includes one or more of the following: user designated flows, locked etches, “etch keep-out” areas, user “planned” or user “viewable” data, etc. The method automatically defines a preferred local routing direction for each tile based on a set of user specified constraints by performing the following steps. The method initializes an interim preferred routing direction of each tile to a predetermined direction. The method uses a set of objects created by the user defined constraints to compute new routing directions for each tile. The method uses the new routing directions to modify the interim preferred routing direction of each tile. The method uses the interim preferred routing direction of each particular tile to determine a final preferred routing direction for the particular tile.
Some embodiments present a method of routing for a multilayer circuit design layout. The design layout has a set of possible preferred local routing directions and each layer has a default preferred routing direction. The method receives a first set of user specified preferred routing directions for particular regions of the multilayer design layout. The method tessellates the available space for routing into separate tiles. The tiles are determined independent of the regions. The method automatically defines a second preferred local routing direction for each tile based on the user specified preferred routing directions.
Some embodiments present a method of determining preferred routing directions for a multilayer circuit design layout. The multilayer circuit design layout has a set of possible preferred routing directions. Each layer has a general preferred routing direction. The method tessellates available space for routing into separate tiles. The method initializes each tile with all possible preferred routing directions marked as available. The method uses a set of user defined constraints to determine which preferred directions are blocked for each tile. The method determines preferred local routing directions for each tile based on preferred directions that are not blocked on each tile.
Several more detailed embodiments of the invention are described in sections below. Before describing these embodiments further, the overall flow of a router of some embodiments is given in Section I below. This discussion is followed by the discussion in Section II of a method that some embodiments use to determine preferred routing directions on regions of a circuit design layout. Next, Section III describes an alternative method that some embodiments use to determine preferred routing directions. Last, Section IV describes a computer system with which one embodiment of the invention is implemented.
I. Overall Flow
Next, the user specifies (at 410) locked etches. Locked etches are any connections between pads or pins of the design layout that the user has designated not to be modified.
Next, the user specifies (at 415) etch “keep-out” areas. An etch keep-out area is a region of the design that the user has indicated cannot be used for any etch.
Next, the user views and modifies (at 420) “planned” or “user viewable” data. Some embodiments provide a mechanism for the users to define their design intent or strategy in the form of data that is stored with the design database. The mechanism allows a user to either use a set of heuristics to define the design intent or strategy or to view and modify a set of design strategies suggested by the system. The router then uses this guidance from the user to create a plan for routing the design. The user can then modify the guidance to the router until the results for the plan are acceptable. Then, using the planned flow, the router can complete the design by creating detailed paths consisting of etch segments and vias. If a significant portion of the planned data blocks any routing directions, they could be marked as blocked. Some embodiments implement only a subset of the user defined constraints described in 405-420 above. Also, the user specified constraints may be specified in any order other than the sequence shown in
Process 400 also tessellates (at 425) the available space for routing into regions. The process divides the entire region available for routing on all layers of the design layout into separate regions, herein called tiles. Any one tile is on a particular layer but the set of all tiles completely covers the entire routable design area on all layers.
The tiles identified after tessellating can overlap or encompass one or more of the regions for which the user specified constraints are identified. Some tiles can fall within one of those regions. Also, some embodiments determine tiles independently of the user specified constraints. Some embodiments, on the other hand, utilize the user specified constraints (for instant, the vertices of etch keep-out areas) as a criteria for determining tile locations.
The process then automatically determines (at 430) the preferred local routing direction of each tile based on the user specified constraints. Detailed description of how several embodiments determine the preferred local routing direction of each tile based on the available data is given in Sections II and III below.
II. Determining Preferred Routing Directions on Regions
Some embodiments use a predetermined set of preferred local routing directions. These embodiments initialize the preferred local routing direction of each tile to mark all directions as available. The user specified constraints are then examined to determine which directions are blocked for each individual tile. A final preferred local routing direction is then determined for each tile.
For simplicity, the steps of defining the user specified constraints (which were described in 405-420 above) and tessellation (which was described in 425 above) are not shown in
One of ordinary skill in the art would realize that other preferred routing directions can be readily defined. For instance, some embodiments define diagonal preferred routing directions. Also, the preferred routing directions only affect the penalty costs associated with the direction of a route. Each router allocates costs based on other factors, such as the length of a route. Therefore, a horizontal route in a tile that has a local preferred horizontal routing direction will incur no cost based on the direction of the route. The route, however, may still incur costs based on the length of the route. Also, the directions indicated above do not place any restrictions on the route to go, for instance, strictly horizontal or strictly vertical. The directions indicated above are just “preferred” directions. For example, in some embodiments, a router may also allow ±45° diagonal routing. In these embodiments, a preferred horizontal routing direction incurs no directional costs for horizontal routes and high directional costs for vertical and ±45° directions.
Next, process 900 examines (at 910-945) all objects defined by the user specified constraints and removes all directions that are inconsistent with these objects from the set of “available” preferred routing direction of each tile. As described above, examples of the user specified constraints and the objects created by them are user designated flows, locked etches, etch keep-out areas, and user planned (or user viewable) data. Specifically, the process selects (at 910) the first object to process. Next, the process selects (at 915) the first tile that is affected by the currently selected object. As described above (for instance in relation with
The process then removes (at 920) all directions that are inconsistent with the selected object from the list of “available” preferred routing directions of the tile. The pseudo code below illustrates how some embodiments remove directions based on an object (such as user designated flows, locked etches, etch keep-out areas, etc.) that goes through a tile.
if object intersects two corners of the tile
else if object traverses through opposite tile edges
else if object traverses adjacent tile edges
end if
As shown in the pseudo code above, if an object (such as the locked etch 605 shown in
Also, as shown in the pseudo code above, if the object traverses through the opposite tile edges, either horizontal or vertical direction is removed based on which edges the object traverse. Specifically,
Also, if the object traverses through adjacent tile edges, the blocked directions are determined based on where the object intersects the edges.
Next, the process determines (at 925) whether all tiles that are affected by the selected object are examined. If not, the process selects (at 930) the next tile affected by the currently selected object and proceeds to 920 that was described above. Otherwise, the process determines (at 940) whether all objects are examined. If not, the process selects (at 945) the next object to examine and proceeds to 915 that was described above.
Otherwise, the process examines (at 950-990) all tiles to determine their final preferred routing direction. Specifically, the process selects (at 950) the first tile to examine. Next, the process determines (at 960) whether any preferred routing directions remain available for the tile. If not, the process sets (at 965) the preferred routing direction of the tile to the default preferred routing direction of the current layer of the design layout (i.e., the layer that the current tile is located at). The process then proceeds to 985 which is described below.
If on the other hand, there are still some preferred routing directions available for the tile, the process determines (at 970) whether only one preferred direction is still available for the tile. If yes, the process sets (at 975) the preferred routing direction of the tile to the only remaining available preferred routing direction of the tile. The process then proceeds to 985 which is described below. If, on the other hand, more than one preferred routing direction remains available for the tile, the process uses (at 980) a predetermined set of rules to select a final preferred routing direction for the tile. The following pseudo code shows an algorithm that some embodiments use to set the final preferred routing direction of a tile when several preferred routing directions are still available for the tile.
if the available preferred direction set includes both vertical and horizontal
else if the available preferred direction is vertical
else if the available preferred direction is horizontal
else if the available preferred direction set includes both tildeVertical and tildeHorizontal
else if the available preferred direction is tildeVertical
else if the available preferred direction is tildeHorizontal
else
end if
As shown in the above pseudo code, each different combination of available preferred routing directions result in a specific final preferred routing direction for each tile. For instance, if the available preferred direction set includes both vertical and horizontal directions, the final preferred routing direction of the tile is set to AnyDirection. Otherwise, if the available preferred direction is vertical, the final preferred routing direction of the tile to vertical. Otherwise, if the available preferred direction is horizontal, set the final preferred routing direction of the tile to horizontal, and so on.
Next, the process determines (at 985) whether all tiles are examined. If not, the process selects (at 990) the next tile to examine and proceeds to 960 which was described above. Otherwise, the process exits.
Some embodiments implement a variation of process 900 which starts with an empty list of blocked preferred routing directions for each tile. As more objects are examined, these embodiments add more blocked directions to each list, rather than removing available directions.
III. Determining Preferred Routing Directions on Regions
Some embodiments use a predetermined set of preferred local routing directions. These embodiments initialize the preferred local routing direction of each tile to a predetermined interim direction. Each tile is then individually examined to compute new directions based on each user specified constraint that affects the selected tile. These newly computed directions are merged (or blended) with the current interim preferred direction of the tile. The final preferred local routing direction of a tile is, therefore, determined based on which interim directions, if any, are merged with the initial interim preferred direction.
Different embodiments use different values for the above mentioned initial predetermined interim direction. Some embodiments initialize all tiles directions to the interim preferred direction of “UnknownDirection”. Some embodiments first perform process 900 to determine a preferred routing direction of each tile using the “blocking” method described in Section II above. This direction is then used to initialize the interim preferred routing direction of each tile for the “merging” approach described in this section.
For simplicity, the steps of defining the user specified constraints (which were described in 405-420 above) and tessellation (which was described in 425 above) are not shown in
Next process 1300 selects (at 1310) the first tile to examine. The process then selects (at 1315) the first object that affects the selected tile. The process uses (at 1320) information from the selected object to compute new direction (or directions) to merge with the current interim preferred routing direction of the tile. Some embodiments do not consider the effect (if any) of a flow that does not completely pass through a tile. For instance, flow 515, shown in
The pseudo code below illustrates how some embodiments determine an interim preferred direction based on an object that goes through a tile.
if object intersects two corners of the tile
else if object traverses through opposite tile edges
else if object traverses adjacent tile edges or one corner and one edge
end if
As shown in the pseudo code above, if an object (such as the locked etch 605 shown in
Similarly, if the object traverses through the opposite tile edges, the interim direction is horizontal or vertical based on which edges the object traverse. For instance, object 1105 (shown in
Also, if the object traverses through adjacent tile edges, the interim direction is determined based on where the object intersects the edges. Object 1205 shown in
After 1320, process 1300 determines (at 1325) whether one or more new preferred directions are computed for the tile. If not, the process proceeds to 1335 which is described below. Otherwise, the process blends (at 1330) the newly computed preferred routing directions with the current interim preferred routing direction of the tile. The process then proceeds to 1335 which is described below. The following pseudo code shows an algorithm that some embodiments use to blend a newly computed direction with the current interim preferred direction of a tile.
As shown in the pseudo code above, the newly preferred routing direction is blended with the current interim preferred routing direction to update the interim preferred routing direction. For instance, if the newly computed direction is horizontal or vertical interim preferred direction of the tile is set to the newly computed direction. Otherwise, if the current interim preferred direction is horizontal or vertical, the preferred direction of the tile is not change. Otherwise, if the newly computed directions are tildeVertical and tildeHorizontal, the interim preferred direction of the tile is set to AnyDirection, and so on. A person of ordinary skill in the art would realize that similar rules can be defined if other preferred routing directions are defined.
Next, the process determines (at 1335) whether more objects affect the currently selected tile. If yes, the process selects (at 1340) the next object that affects the tile and proceeds to 1320 which was described above. If the process determines (at 1335) that no more objects affect the current tile, the process determines (at 1345) whether the interim preferred routing direction of the tile is still marked as “UnknownDirection”. This is the case, for instance, when the interim preferred routing direction was initialized to “UnknownDirection” and no user specified constraints go through the tile. If the interim preferred direction is still “UnknownDirection”, the process sets (at 1350) the final preferred routing direction of the tile to the default routing direction of the current layer of the design layout (i.e., the layer that the current tile is located in it). The process then proceeds to 1360 which is described below. In embodiments that initialize the interim preferred routing directions of the tile to the direction that is determined by the “blocking” method of process 900, operations 1345 and 1350 are not performed.
If (after 1345), the process determines that the interim preferred direction is not marked as “UnknownDirection”, the process sets (at 1355) the final preferred routing direction of the tile to the current interim preferred routing direction of the tile. Next, the process determines (at 1360) whether all tiles in the design layout are examined. If not, the process identifies (at 1365) the next tile to examine and proceeds to 1315 (which was described above) to process the next tile. Otherwise, the process exits.
Once the preferred local routing direction has been assigned for all tiles, standard costing rules are used to establish what is considered “wrong-way” routing and what cost, if any, should be assigned to that wrong-way routing. The routing processes 900 and 1300, therefore, automatically define the preferred direction of each tile by taking into account the available information (locked etch, flows, etch keep-out, planned data, etc.) about the tile. As described for the embodiments above, the preferred routing directions for all areas of the design are no longer dictated by the preferred routing direction for the entire layer. The routing process also takes into account any of the existing geometries on the design and is not restricted to choose paths early on that would not be allowed later. This allows the router to generate fewer expansion probes to find solutions. Fewer expansion probes improve the speed of the routing engine (SCR).
By incorporating knowledge of the local routing conditions, the path selection algorithms can select the best paths. This results in efficient use of the available routing real estate. Use of this invention allows the routing engine (SCR) to run faster, pushing and popping fewer probes during expansion for designs with flows and/or locked etch. By adapting the wrong-way costs to the local routing conditions, better path selection is obtained. With better path selection, the entire router is more powerful (gets better completion and works faster).
IV. The Computer System
The bus 1405 collectively represents all system, peripheral, and chipset buses that support communication among internal devices of the computer system 1400. For instance, the bus 1405 communicatively connects the processor 1410 with the read-only memory 1420, the system memory 1415, and the permanent storage device 1425.
From these various memory units, the processor 1410 retrieves instructions to execute and data to process in order to execute the processes of the invention. The read-only-memory (ROM) 1420 stores static data and instructions that are needed by the processor 1410 and other modules of the computer system. The permanent storage device 1425, on the other hand, is a read-and-write memory device. This device is a non-volatile memory unit that stores instruction and data even when the computer system 1400 is off. Some embodiments of the invention use a mass-storage device (such as a magnetic or optical disk and its corresponding disk drive) as the permanent storage device 1425. Other embodiments use a removable storage device (such as a floppy disk or Zip® disk, and its corresponding disk drive) as the permanent storage device.
Like the permanent storage device 1425, the system memory 1415 is a read-and-write memory device. However, unlike storage device 1425, the system memory is a volatile read-and-write memory, such as a random access memory. The system memory stores some of the instructions and data that the processor needs at runtime. In some embodiments, the invention's processes are stored in the system memory 1415, the permanent storage device 1425, and/or the read-only memory 1420.
The bus 1405 also connects to the input and output devices 1430 and 1435. The input devices enable the user to communicate information and select commands to the computer system. The input devices 1430 include alphanumeric keyboards and cursor-controllers. The output devices 1435 display images generated by the computer system. For instance, these devices display IC design layouts. The output devices include printers and display devices, such as cathode ray tubes (CRT) or liquid crystal displays (LCD).
Finally, as shown in
While the invention has been described with reference to numerous specific details, one of ordinary skill in the art will recognize that the invention can be embodied in other specific forms without departing from the spirit of the invention. For instance, the user specified constraints shown in 405-420 can be entered in any order and some embodiments may not utilize all these user specified constraints. Also, different preferred local routing directions (including diagonal preferred local routing directions) are defined in some embodiments.
The tiles identified after tessellating can overlap or encompass one or more of the regions for which the user specified constraints are identified. Some tiles can fall within one of those regions. Also, some embodiments determine tiles independently of the user specified constraints. Some embodiments, on the other hand, utilize the user specified constraints (for instance, the vertices of etch keep-out areas) as a criteria for determining tile locations. The available routable space of the circuit design layout can be tessellated into shapes other than rectangular. Also, the invention can be implemented for detailed routers as well as for global routers. Thus, one of ordinary skill in the art would understand that the invention is not to be limited by the foregoing illustrative details, but rather is to be defined by the appended claims.
| Number | Name | Date | Kind |
|---|---|---|---|
| 4571451 | Linsker et al. | Feb 1986 | A |
| 4615011 | Linsker | Sep 1986 | A |
| 4777606 | Fournier | Oct 1988 | A |
| 4782193 | Linsker | Nov 1988 | A |
| 4855253 | Weber | Aug 1989 | A |
| 4855929 | Nakajima | Aug 1989 | A |
| 4910680 | Hiwatshi | Mar 1990 | A |
| 5375069 | Satoh et al. | Dec 1994 | A |
| 5541005 | Bezama et al. | Jul 1996 | A |
| 5635736 | Funaki et al. | Jun 1997 | A |
| 5637920 | Loo | Jun 1997 | A |
| 5640327 | Ting | Jun 1997 | A |
| 5646830 | Nagano | Jul 1997 | A |
| 5650653 | Rostoker et al. | Jul 1997 | A |
| 5673201 | Malm et al. | Sep 1997 | A |
| 5689433 | Edwards | Nov 1997 | A |
| 5723908 | Fuchida et al. | Mar 1998 | A |
| 5737237 | Tanaka et al. | Apr 1998 | A |
| 5784289 | Wang | Jul 1998 | A |
| 5798936 | Cheng | Aug 1998 | A |
| 5801385 | Endo et al. | Sep 1998 | A |
| 5801960 | Takano et al. | Sep 1998 | A |
| 5811863 | Rostoker et al. | Sep 1998 | A |
| 5814847 | Shihadeh et al. | Sep 1998 | A |
| 5822214 | Rostoker et al. | Oct 1998 | A |
| 5880969 | Hama et al. | Mar 1999 | A |
| 5889329 | Rostoker et al. | Mar 1999 | A |
| 5980093 | Jones et al. | Nov 1999 | A |
| 6006024 | Guruswamy et al. | Dec 1999 | A |
| 6014507 | Fujii | Jan 2000 | A |
| 6077309 | Lin | Jun 2000 | A |
| 6111756 | Moresco | Aug 2000 | A |
| 6150193 | Glenn | Nov 2000 | A |
| 6209123 | Maziasz et al. | Mar 2001 | B1 |
| 6256769 | Tamarkin et al. | Jul 2001 | B1 |
| 6260183 | Raspopovic et al. | Jul 2001 | B1 |
| 6262487 | Igarashi et al. | Jul 2001 | B1 |
| 6263475 | Toyonaga et al. | Jul 2001 | B1 |
| 6301686 | Kikuchi et al. | Oct 2001 | B1 |
| 6307256 | Chiang et al. | Oct 2001 | B1 |
| 6316838 | Ozawa et al. | Nov 2001 | B1 |
| 6324674 | Andreev et al. | Nov 2001 | B2 |
| 6330707 | Shinomiya et al. | Dec 2001 | B1 |
| 6338985 | Greenwood | Jan 2002 | B1 |
| 6407434 | Rostoker et al. | Jun 2002 | B1 |
| 6412097 | Kikuchi et al. | Jun 2002 | B1 |
| 6441470 | Shenoy | Aug 2002 | B1 |
| 6448591 | Juengling | Sep 2002 | B1 |
| 6516447 | Wadland et al. | Feb 2003 | B2 |
| 6516455 | Teig et al. | Feb 2003 | B1 |
| 6526555 | Teig et al. | Feb 2003 | B1 |
| 6601222 | Mehrotra et al. | Jul 2003 | B1 |
| 6645842 | Igarashi et al. | Nov 2003 | B2 |
| 6651233 | Teig et al. | Nov 2003 | B2 |
| 6671864 | Teig et al. | Dec 2003 | B2 |
| 6711727 | Teig et al. | Mar 2004 | B1 |
| 6769105 | Teig et al. | Jul 2004 | B1 |
| 6772406 | Trimberger | Aug 2004 | B1 |
| 6792587 | Xing et al. | Sep 2004 | B2 |
| 6858928 | Teig et al. | Feb 2005 | B1 |
| 6858935 | Teig et al. | Feb 2005 | B1 |
| 6858939 | Teig et al. | Feb 2005 | B1 |
| 6870255 | Teig et al. | Mar 2005 | B1 |
| 6889371 | Teig et al. | May 2005 | B1 |
| 6889372 | Teig et al. | May 2005 | B1 |
| 6898773 | Teig et al. | May 2005 | B1 |
| 6900540 | Teig et al. | May 2005 | B1 |
| 6915500 | Teig et al. | Jul 2005 | B1 |
| 6973634 | Teig et al. | Dec 2005 | B1 |
| 6988258 | Tan et al. | Jan 2006 | B2 |
| 6996789 | Teig et al. | Feb 2006 | B2 |
| 7003748 | Hsu | Feb 2006 | B1 |
| 7003752 | Teig et al. | Feb 2006 | B2 |
| 7010771 | Teig et al. | Mar 2006 | B2 |
| 7013445 | Teig et al. | Mar 2006 | B1 |
| 7017137 | Wadland et al. | Mar 2006 | B2 |
| 7024650 | Teig et al. | Apr 2006 | B2 |
| 7036101 | He et al. | Apr 2006 | B2 |
| 7036105 | Teig et al. | Apr 2006 | B1 |
| 7047513 | Teig et al. | May 2006 | B2 |
| 7055120 | Teig et al. | May 2006 | B2 |
| 7058919 | Young et al. | Jun 2006 | B1 |
| 7062743 | Kahng et al. | Jun 2006 | B2 |
| 7080342 | Teig et al. | Jul 2006 | B2 |
| 7086024 | Hsu et al. | Aug 2006 | B2 |
| 7096449 | Teig et al. | Aug 2006 | B1 |
| 7117468 | Teig et al. | Oct 2006 | B1 |
| 7171635 | Teig et al. | Jan 2007 | B2 |
| 7174529 | Hetzel | Feb 2007 | B1 |
| 7185304 | Suto et al. | Feb 2007 | B2 |
| 7197738 | Hetzel et al. | Mar 2007 | B1 |
| 7340711 | Hetzel et al. | Mar 2008 | B2 |
| 7412682 | Malholtra et al. | Aug 2008 | B2 |
| 7441220 | Hetzel et al. | Oct 2008 | B2 |
| 7480885 | Frankle et al. | Jan 2009 | B2 |
| 20010009031 | Nitta et al. | Jul 2001 | A1 |
| 20010039643 | Kuroda et al. | Nov 2001 | A1 |
| 20020069397 | Teig et al. | Jun 2002 | A1 |
| 20020100009 | Xing et al. | Jul 2002 | A1 |
| 20020124231 | Teig et al. | Sep 2002 | A1 |
| 20020147958 | Teig et al. | Oct 2002 | A1 |
| 20030009737 | Jan 2003 | A1 | |
| 20030025205 | Shively et al. | Feb 2003 | A1 |
| 20030084416 | Dai et al. | May 2003 | A1 |
| 20030088844 | Teig et al. | May 2003 | A1 |
| 20030126578 | Wadland et al. | Jul 2003 | A1 |
| 20040098696 | Teig et al. | May 2004 | A1 |
| 20040098697 | Frankle et al. | May 2004 | A1 |
| 20040243960 | Hsu et al. | Dec 2004 | A1 |
| 20050071797 | Fujii | Mar 2005 | A1 |
| 20050138578 | Alpert et al. | Jun 2005 | A1 |
| 20050138593 | Okumura | Jun 2005 | A1 |
| 20050229134 | Hetzel et al. | Oct 2005 | A1 |
| 20050240894 | Teig | Oct 2005 | A1 |
| 20050273746 | Malhotra et al. | Dec 2005 | A1 |
| 20050273747 | Malhotra et al. | Dec 2005 | A1 |
| 20050273748 | Hetzel et al. | Dec 2005 | A1 |
| 20060112366 | Wadland et al. | May 2006 | A1 |
| 20060156266 | Alpert et al. | Jul 2006 | A1 |
| 20060236291 | Siegel et al. | Oct 2006 | A1 |
| 20060242614 | Wadland et al. | Oct 2006 | A1 |
| 20090024977 | Hetzel et al. | Jan 2009 | A1 |
| 20100180250 | Malhotra et al. | Jul 2010 | A1 |
| Number | Date | Country |
|---|---|---|
| 04000677 | Jan 1992 | JP |
| 2000-082743 | Mar 2000 | JP |
| WO 2005122027 | Dec 2005 | WO |
| WO 2005122028 | Dec 2005 | WO |
