Adding HRES table for GF180MCU DRC #63
Conversation
|
@atorkmabrains can you review it first? |
| # limitations under the License. | ||
| ################################################################################################ | ||
|
|
||
| if FEOL |
|
|
||
| if FEOL | ||
| #================================================ | ||
| #----------------H POLY RESISTOR----------------- |
| logger.info('Executing rule HRES.1') | ||
| hres1_l1 = resistor.interacting(hres1_poly).space(0.4.um, euclidian) | ||
| hres1_l1.output('HRES.1', 'HRES.1 : Minimum space. Note : Merge if the spacing is less than 0.4 um. : 0.4µm') | ||
| hres1_l1.forget |
klayout/drc/rule_decks/hres.drc
Outdated
|
|
||
| # Rule HRES.7: Minimum Pplus overlap of contact on Poly2 resistor. is 0.2µm | ||
| logger.info('Executing rule HRES.7') | ||
| hres7_l1 = contact.and(hres_poly).enclosed(pplus, 0.2.um, euclidian).polygons(0.001.um) |
There was a problem hiding this comment.
@proppy DBU is sensitive to GDS scaling. I prefer real measurement value.
There was a problem hiding this comment.
but don't we want to smaller possible unit there?
There was a problem hiding this comment.
Yes, but In some cases were we are measuring corner to corner for example, we have seen that klayout has numerical errors. And it's better to have a slightly larger tolerance.
There was a problem hiding this comment.
then maybe it's best to define a top level ε variable for this delta so that arithmetic can be done on it (when you need to add or subtract it) and be easier to update if the "numerical errors" conditions happen to change.
There was a problem hiding this comment.
@proppy Each rule might have a different delta. It's not the same for all rules. I thought like you mentioned above, but while running through klayout and testing. We have seen that every type of rule might have a different delta.
There was a problem hiding this comment.
My comment to this: measurements usually are taken in terms of database units (usually nm). Rounding happens to the closer value and is not exactly specified when in between. So if you measure across a diagonal, you may have an exact value like 0.9995 and it will come out as 1000 DBU (assuming a DBU of 1 nm) or 999 DBU which will either give you an error or not.
It is pretty common in any-angle situations that you have to work with some delta. Technically you could implement the check with projection metrics exactly and with a slightly smaller value in Euclidian metrics.
But honestly I think this is nitpicking. Physics is usually in a way that corner-to-corner situations are much different from edge-to-edge ones due to resist or lithography effects and long lines usually behave differently than short edge-to-edge interaction cases. There is no simple mathematical model that describes these cases properly. Every rule you are using is an approximation and so are the check implementations. In practice, DRC checks are made to remind you to take care of potentially critical situations. It's not a good idea to exploit the layout space down to the very limits allowed by DRC (and good layout engineers know that), so whether the check is precise to nanometers or not does not make a difference between a functional and a non-functional chip.
There was a problem hiding this comment.
Each rule might have a different delta
Is that currently the case (I couldn't only find 0.001um delta in the current set of rules) or something that you're predicting?
But honestly I think this is nitpicking
How would you recommend that we maintain those delta?
- encode them directly it in the rule parameter:
with_length(80.00X.um, nil) - express them with discrete offset value:
with_length(80.001.um + X.dbu, nil)
There was a problem hiding this comment.
filed #67 to discuss this further
klayout/drc/rule_decks/hres.drc
Outdated
| # Rule HRES.8: Space from salicide block to contact on Poly2 resistor. | ||
| logger.info('Executing rule HRES.8') | ||
| hres8_l1 = contact.and(hres_poly).separation(sab, | ||
| 0.22.um).polygons(0.001.um).or(contact.and(hres_poly).interacting(sab)) |
There was a problem hiding this comment.
@proppy Same comment.
There was a problem hiding this comment.
Is that a workaround for a KLayout bug?
There was a problem hiding this comment.
according to #65 (comment) this is to convert edges to polygons, I suggested using simple_merge_e2p instead but @atorkmabrains is not sure if this is available in the DRC context.
There was a problem hiding this comment.
filed #66 to investigate this further
klayout/drc/rule_decks/hres.drc
Outdated
| logger.info('Executing rule HRES.9') | ||
| hres9_sab = sab.interacting(pplus).interacting(res_mk).interacting(resistor) | ||
| hres9_clear_sab = hres9_sab.not(hres_poly) | ||
| hres9_bad_inside_edge = hres9_sab.edges.inside_part(hres_poly).extended(0, 0, 0.001.um, 0.001.um).interacting( |
| logger.info('Executing rule HRES.10') | ||
| pplus1_hres10 = pplus.and(sab).drc(width != 0.1.um) | ||
| pplus2_hres10 = pplus.not_overlapping(sab).edges | ||
| hres10_l1 = pplus1_hres10.or(pplus2_hres10).extended(0, 0, 0.001.um, 0.001.um).interacting(hres_poly) |
klayout/drc/rule_decks/hres.drc
Outdated
| hres_poly = poly2.interacting(pplus).interacting(sab).interacting(res_mk).interacting(resistor) | ||
| hres1_poly = poly2.interacting(pplus).interacting(sab).interacting(res_mk) | ||
|
|
||
| # Rule HRES.1: Minimum space. Note : Merge if the spacing is less than 0.4 um. is 0.4µm |
There was a problem hiding this comment.
not sure why need to repeat the constraint twice?
There was a problem hiding this comment.
Same as above
| pplus2_hres10.forget | ||
|
|
||
| # Rule HRES.11 is not a DRC check | ||
| ## Please refer to https://gf180mcu-pdk.readthedocs.io/en/latest/physical_verification/design_manual/drm_10_03.html#hres-poly-resistor-phres-optional-with-one-additional-mask |
FaragElsayed2
force-pushed
the
hres_google
branch
from
50850ad to
f540526
Compare
klayout/drc/rule_decks/hres.drc
Outdated
|
|
||
| # Rule HRES.7: Minimum Pplus overlap of contact on Poly2 resistor is 0.2µm. | ||
| logger.info('Executing rule HRES.7') | ||
| hres7_l1 = contact.and(hres_poly).enclosed(pplus, 0.2.um, euclidian).polygons(0.001.um) |
There was a problem hiding this comment.
should we save contact.and(hres_poly) in an intermediate variable? it seems that it is duplicated below.
Adding HRES table for GF180MCU DRC
Fixes #43