pcb-rnd knowledge pool
Polygon-side clearance: enforce_clearance
| enforce_clearance by Tibor 'Igor2' Palinkas on 2020-05-06 | Tags: insight, enforce_clearance, polygon, side, clearance, globalunify, unified |
Abstract: There are three schools for maintaining clearance values: probably the most common is when the clearance is set at the polygon; some software have the clearance globally set for all objects; and pcb-rnd and gEDA, where clearance is traditionally set on a per-clearing-object basis. A recent data model upgrade in pcb-rnd however allows both per-poly and per-clearing-object clearances, even in the same time.
The two seemingly contradicting models
Our per-object-clearance model with decades of history in gEDA/PCB is that each object has its on clearance value. This way an object has a single clearance gap in whatever polygon it crosses.
Pro: objects of high voltage networks can have greater clearance than objects of low voltage networks, within the same polygon. Or different signal traces with different high frequency properties can have different clearances within the same polygon.
(source: hv.lht )
Con: it is somewhat harder to guarantee uniform clearance value across a board. However, with query() and propset() (or advanced search and propedit) pcb-rnd already had a both CLI and GUI ways to easily do that.
Another model, the per-polygon-clearance is used more commonly in EDA software, places the clearance value in the polygon. This way any object within a givven polygon will have the same clearance gap.
Pro: very easy to guarantee unified clearance value for hundreds of objects within a polygon; very easy to change that unified clearance value.
Con: if a different clearance value is needed for some objects (high voltage nets, high speed nets, that can be done only by splitting up the polygons, resulting a patchwork of overlapping polygons with different clearance settings just to make local deviance of clearance around an object possible. Such setup is hard to follow and maintain.
Two in one: supporting both
Recent upgrade of pcb-rnd data model allows both models in the same time: polygons have a new, optional enforce_clearance field. When clearance happens between an object and a polygon, the actual clearance value is the greater value of the object's clearance field and the polygon's enforce_clearance field.
For compatibility, the default value of enforce_clearance is 0, which will never be greater than the object's clearance, thus by default pcb-rnd uses the per-object-clearance model, being backward compatibl.
If the user wants to use the per-polygon-clearance instead, the clearance of all objects should be set to a low, but non-zero value (e.g. 0.01 mm or 0.1 mil) and the enforce_clearance of every polygon shall be set to the desired clearance value.
Finally, the combined-clearance model works too, from two directions.
- the user may choose to go by the traditional per-object-clearance by default and increase the clearance within a specific polygon using the enforce_clearance value; this results in mostly unified clearances in that poly, except for a few objects that had greater clearance value for whatever local reason
- or the user may choose to generally use the per-polygon-clearance , having 0.01 mm object clearance on most all objects by default (e.g. setting it from the route style), using the enforce_clearance to determine the clearance from the polygon side for almost all objects. Then a few special objects can be manually set to have higher clearance than the usual.
What the new system can NOT do
There is only one thing the new system can not do: it can not make clearance value smaller. For example enforce_clearance can not be used to make clearance smaller than what specified in the clearing object's clearance field. Or the object's clearance field can not be used to make the gap smaller than what specified in the polygon's enforce_clearance field.
It's always the greater clearance value that is applied. If the user needs to decrease the clearance between objects and the polygon, that always needs to be done manually or using query() and propset() (or advanced search and propedit).
Why do we have this?
The main reason for adding this feature is file format (and data model) compatibility with other EDA tools, those that use the per-polygon-clearance approach. Most of the time setting the same clearance value for each clearing object could yield the same result on an import, but in some cases, when a single object crosses two polygons with different enforce_clearance settings, it can not be reproduced with a pure per-object-clearance system.
(source: split.lht )
Fixing this the question was whether it is simply impossible, or there would be an ugly global switch in the configuratin between the two models or if it is possible to do a combined model while keeping backward compatibility. The current solution is the third and did not require too much code.