# DRC Tolerance

edited April 2016 in General
I tried searching for this topic but could not find the answer and so I thought I'd ask. Is there a inherent command or procedure to add in a tolerance to a dimension for DRC checks? What I mean is that I have a spacing rule of 10µm for example. However, I would like to have a spacing of 9.9µm passing the rule also. I do not want to enter 9.9µm as the spacing rule value to be checked. This is particularly useful when drawing concentric circles which are converted into polygons. Hence if two concentric circles are drawn with an intentional space of 10µm, due to the "conversion" into polygons, there are locations where the spacing is not 10µm but something slightly smaller.

Thanks,

Vikas

• edited November -1

Hi Vikas,

So you want circles to be checked with less spacing but "other" layout with the correct one? That means the algorithm needs to distinguish between "intentionally wrong" and "really wrong". I don't see how an algorithm could be able to decide this.

One solution would be to fix the generator (let it create slightly bigger circles so the spacing is conforming to the rule).

Or you implement two DRC rules: a check below 9.9 which is a "real" error and below 10 which is a "soft error". If you have a way to identify your circles by some cover polygon, you can even mask out theses errors in that region with a "NOT".

Matthias

• edited November -1
Thanks Matthias. Yes, I have been going down the path of having two DRC decks. But I will try the "NOT" option.

Thanks,

Vikas
• edited November -1
On further thought - let me try explaining this again. I have rule for example which states that separation should be 10µm. I would like to allow a space of 9.9µm to pass. Similarly, I have a min width rule of 10µm and I am OK with a 9.9µm shape.

Since the rule is 10µm - I do not want to code it as 9.9µm. I have several hundreds of rules and this means that I would have to code each one with an offset. In addition to a "technical" problem, this also creates a problem of "documentation" since the design manual and DRC code would be different.

See two examples of what I am referring to below:

Error tolerance
Sets the error tolerance for DRC checking as a fraction of the Layout Options Database unit size. ERROR_TOLERANCE 0.5 is a 0.5 layout dbu tolerance
ERROR_TOLERANCE <fraction_of_dbu>

http://semimd.com/favre/2015/09/30/design-rule-checking-for-silicon-photonics/

By taking advantage of the Calibre eqDRC capabilities, users can query various geometrical properties (including the properties of error layers), and perform further manipulations on them with user-defined mathematical expressions. Therefore, in addition to knowing whether the shape passes or fails the DRC rule, users can also determine any error amount, apply tolerance to compensate for the grid snapping effect, perform checks with property values, process the data with mathematical expressions, and so on.
• edited April 2016

Hi Vikas,

I wish people would stop comparing an open source tool with heavy commercial solutions.

There is one great advantage of open source and I wonder why only very few consider this: you can modify the tool! If you need a new feature, add it. If you find a bug, fix it.

But I personally don't see need for action here. You say, you have hundreds of rules and don't want to write "wrong" values. You don't have to! DRC is Ruby and Ruby is a language that supports computation and variables. So instead of writing:

``````...
errors = your_layer.width(9.9.um)
...
``````

ou can write

``````# The width according to the design manual:
width_limit = 10.um
# A "tolerance" applied to allow for polygon roughness:
delta = 100.nm
...
errors = your_layer.width(width_limit-delta)
...
``````

What a great way to document your code!

Matthias

• edited November -1
:-) Danke!