When Order Matters

Do you brush your teeth before dinner? Put on your shoes before going to bed? Iron your clothes before you wash them? Okay, forget that last one. No one irons clothes anymore…do they? Anyway, my point is, if you want to achieve the best results from a process, order can be really important. And so it is with double patterning (DP) error debugging.

As I’ve discussed, there are many types of errors that can occur when trying to design a layer using LELE double patterning in 20/16/14nm technology nodes. As a result, I’ve been asked quite a few times “Is there a preferred way a designer should address the various types of DP errors?” This is actually a very good question, and the short answer is yes, the order in which you address errors can make quite a difference in the efficiency of your debug efforts. Now for the long answer…

There are five types of errors you may encounter in a DP design layer (excluding errors associated with using stitches). Here is the order in which I recommend a designer work on debugging these errors:

1. Minimum opposite mask spacing errors
2. Self-conflict same mask spacing errors
3. Anchor self-conflict errors
4. Odd cycle errors
5. Anchor path errors

In my experience, adhering to this order minimizes the amount of work required to fix all of these errors, and limits the confusion of misleading results occurring in the other checks further down the list. Let me explain.

The first error type is the traditional minimum opposite mask spacing errors. This error type is first because it is the most fundamental error, in that it involves exactly two polygons, is isolated to exactly one space, and there is no possible coloring solution that resolves the error. When you break a fundamental minimum spacing constraint, you can also cause a lot of other noise in the other error types, as shown in Figure 1.

Figure 1: Minimum opposite mask spacing errors cause noise in odd cycle DP errors.

On the left, two polygons violate the minimum opposite mask spacing constraint. This fundamental spacing violation creates a diagonal tip to tip separator constraint in the layout, which leads to two odd cycle violations between the four polygons. As odd cycle violations suggest to the designer that they may adjust any of the spaces involved in the odd cycle to “fix” the issue, it is possible for a designer to fix the odd cycle, but not fix the original minimum spacing violation! Designers can end up making two fixes when only one is needed. As shown on the right, if the minimum spacing violation is fixed, the odd cycles don’t even occur, so you fix both issues at once.

The second error type on the list is the self-conflict same mask spacing error. These are single polygons that have notch spaces between themselves that violate the min same-mask spacing constraints. This error type is also a very fundamental error isolated to a single polygon. As the polygons associated with these errors interact with other polygons, they can also form other error types (Figure 2).

Figure 2: Self-conflict same mask spacing error causing noise in odd cycle DP errors.

On the left, the red polygon is in conflict with itself. This error is usually flagged by highlighting the polygon. The separator constraints that form in this layout example create an odd cycle error of one. Again, fixing the self-conflict error fixes the odd cycle error as well.

Number three on our list is the anchor self-conflict error type. Once again, this error type is a very fundamental error isolated to a single polygon. This error occurs when a single polygon has more than one conflicting anchor request. These errors can cause some rather interesting noise on the anchor path errors. Figure 3 shows this issue.

Figure 3: Anchor self-conflict errors causing noise in anchor path errors.

On the left, there is a single polygon with two discrepant color anchor markers overlapping it. The coloring tool does not know which color to assign to the polygon, so it will make a random selection on which color to follow. Given the separator interactions with other polygons, there is a path from this polygon down to the bottom polygon. If the tool randomly chooses to follow the blue anchor request, an anchor path error to the green anchored polygon at the bottom is created. If the tool randomly selects the green anchor, no anchor path error will be shown. By fixing the fundamental anchor self-conflict error, the results of the anchor path errors become deterministic, as opposed to random.
Now you’ve resolved all the fundamental, isolated error types, leaving only the more long-range odd cycle and anchor path error types. I suggest fixing odd cycle errors first, as they can interact with an anchor path error (Figure 4).

Figure 4: Odd cycle errors interacting with anchor path errors.

On the left is an odd cycle error. Due to the separator interactions with other polygons, this odd cycle interacts with two anchored polygons at the top and bottom, such that an anchor path error also exists. The odd cycle requires the designer to fix one of the three spaces involved in the cycle. Regardless of which one is fixed, the anchor path error will also be fixed, as shown on the right.

However, the reverse is not true. If designers attempt to fix the anchor path first, they may choose to fix the space between the top anchor and the middle polygon, or the space between the bottom anchor and the middle polygon. Either of these adjustments fixes the anchor path error, but does not fix the odd cycle error. For this reason, it makes more sense to fix any odd cycle errors first before fixing the anchor paths.

Now, don’t misunderstand me. I am not saying that if you don’t follow my advice, you will never get a clean design. You can be very successful reaching design closure fixing errors in any order you like. I am suggesting there is some significant probability that randomly fixing various DP error types may lead to extra design changes and unnecessary debug confusion, and I hope the guidance I’ve provided makes you more productive. I would love to hear about your experiences in DP debug, and whether or not changing the order of your error debugging helped you.

In my next blog, we will begin to look at another new type of multi-patterning potentially coming in advanced nodes, called SADP. Don’t you just love learning about yet another type of multi-patterning? See you next time!