OPC Parameter Optimization Based on Design Hierarchy
Ding Hua, Li Xin, Sun Changjiang
HuaHong NEC,Shanghai
Abstract:
There are many kinds of design hierarchy. Different hierarchy needs different OPC parameter settings. In this paper, one real typical case (open-slit case) is given to discuss how to setup parameters based on design hierarchy. It shows that proper parameter settings can make the recipe more easily used and reduce turning around time.
Open-Slit Issue Case:
This is an illustrative case simplified from a real metal layer case.
Design hierarchy description:
Plot 1. One part of GDS. This part will be analyzed in the following sections.
Plot 2. The enlargement of the green circle part in Plot 1.
In Plot 2, the blue, yellow and green lines indicate the mapping relations between the rectangle polygon and its hierarchy. The small polygon in the red circle will be the focus in the paper. It shows that this small polygon directly belongs to RST_X_PRX210_1C_CELL and that its neighboring polygons directly belong to other cells.
Hierarchy analysis by Proteus:
When doing OPC, firstly the Synopsys tool Proteus will analyze the design hierarchy. Based on the hierarchy, Proteus will determine which part will be the target (.main) and which part will be the environment (.context). [1, 2]
Plot 3. The target (.main) and environment (.context) analysis by Synopsys tool Proteus. The three green circles in Plot 3 and the red circle in Plot 2 indicate the same position.
The left picture is the target (.main), the creation of which is based on polygons indicated by blue lines in Plot 2. On the right bottom of this picture, there is one small polygon, only 10nm high. Here we call this small polygon as sliver polygon. The center picture is the environment (.context), the creation of which is based on the polygons indicated by yellow and green lines in Plot 2.
The right picture is the whole template including both the target and environment (.main+.context).
Recipe description and OPC result:
After hierarchy analysis, the Proteus will use recipe to correct the design. The recipe we use here is simplified from the real recipe and illustrated as follows.
SOURCE_GROUPS
drawn 1:0
END_SOURCE_GROUPS
PROGRAM_FLOW
drawn_snap = snap_angle_dd(12,12,drawn)
interest = bias(1678,bb(drawn.main))
relevant = bias(1678, drawn.main) * interest
merged = drawn_snap * relevant
healed = merged
healed_main = drawn.main
CORBASIC( 0, Dissector_Corrector, \
COR_IN:0, healed, \
corrected, COR_OUT:0)
expanded = bias(7,healed_main)*healed
blott = bias(50,expanded) – drawn.context
intrude = blott*healed
finished = under_over(7,(over_under(7, intrude))*corrected)
END_PROGRAM_FLOW
GDS_OUTPUT
finished 1:0
END_GDS_OUTPUT
Plot 4. The left picture is the target (.main) after OPC. The right picture is the after OPC. The red circles in the two pictures and the green circles in Plot 3 are the same position. There is an open-slit in the red circle.
Now we analyze the reason why there is an open-slit.
After the CORBASIC call, the recipe does some Boolean. After the following Boolean
expanded = bias(7,healed_main)*healed
blott = bias(50,expanded) – drawn.context
intrude = blott*healed
the intrude which represents the sliver polygon is still 10nm high. So after the following Boolean
finished = under_over(7,(over_under(7, intrude))*corrected)
the finished disappears, because the 7 (bias) * 2 > 10 (sliver polygon’s height). That means the sliver polygon disappears after OPC, please see the left picture in Plot 3.
To understand further, the under_over and over_under functions are illustrated in Plot 5.
Plot 5. under_over and over_under functions explaination.
The under_over and over_under functions can be used to eliminate small notches and fill small gaps. That is why we use it in the recipe. But now these functions meet the special case -Sliver polygon, sliver polygon, then the open-slit issue occurs.
One solution:
To solve this issue, an easy way which can be used is to revise the following Boolean line
from
finished = under_over(7,(over_under(7, intrude))*corrected)
to, for example,
finished = under_over(4,(over_under(4, intrude))*corrected)
We change the bias from 7 to 4 here, because 4 (bias) * 2 < 10 (sliver polygon’s height).
Plot 6. The OPC result after using new value in under_over and over_under statement. The right
Plot 7. OPC result after two keywords are added.
From the Plot 6, we can see that the Sliver polygon will not disappear after OPC and then the open-slit issue can be covered.
Another solution:
To solve this open-slit issue, we have another solution by adding two keywords into the recipe
NEW_COMPRESSION_FLAT
COMPRESSION FLAT.
These two keywords combine the sliver polygon to its neighboring polygon before OPC correction. So there is no sliver polygon before running the recipe and then there is no side effect created by the recipe line
finished = under_over(n,(over_under(n, intrude))*corrected
So the open-slit issue can be covered. Please see the OPC result after the two keywords are added in Plot 7.
Comparison of two solutions:
1. The second solution is easily used.
The first solution does work. But before an OPC production, we don’t know whether there is open-slit issue and how big the sliver polygon will be, because we have no time to go through all the hierarchy of the design. So before OPC we don’t know how to set recipe line
finished = under_over(n,(over_under(n, intrude))*corrected
Only when we finish the OPC and after post-OPC check, we can know whether there is open-slit issue and how big the sliver polygon is. But when we find that we need to rerun the recipe to cover the open-slit issue, we waste once OPC-running time.
The second solution works well even when we don’t know the size of the sliver polygon before OPC.
2. The second solution saves running time.
As we point in the first point, because we don’t need to rerun the recipe to cover the open-slit issue. The second solution saves running time.
Another reason is that the second solution creates fewer templates in this case. Compare the below two log files output after hierman running:
Log 1. Hierman log file output without two keywords setting.
Log 2. Hierman log file output after two keywords setting (same as the second solution).Log-2 shows that the second solution creates fewer templates than the first. So the second solution saves running time.
Suggestion:
From the above discussion, we can see that the hierarchy can affect the OPC heavily. It is better that the factor for ease of OPC can be considered in design phase. It is especially important when the minimum feature becomes smaller and smaller. That is to say, the design team and OPC team need to cooperate more closely in order to reduce turning around time.
In conclusion:
We illustrate one case to show how to set OPC parameters based on the design hierarchy. And it shows good setting can make the recipe more easily used and save turning around time. But the OPC parameter settings are case by case.
Reference:
[1] Proteus Reference Manual, Synopysys Company, Version W-2004.09-11, March 2006.
[2] Proteus Getting Started Guide, Synopysys Company, Version W-2004.09-11, March 2006.
Insight China
-
SNUG
-
White Paper
-
Good Chip Series
