pcb-rnd knowledge pool
Globalism vs. localism
| glob_loc by Tibor 'Igor2' Palinkas on 2018-08-11 | Tags: insight, global, local, parameters |
Abstract: Design decision: global vs. local parameters in the data model and on the UI. How to achieve global goals while keeping local object properties.
There are two opposing models in handling many EDA parameters, for example the clearance.
The local model says: each object has its own properties, including width and clearance. This is what we inherited from pcb. In this model it is very easy to generate local exceptions but is harder to guarantee uniform parameters over a board.
The global model says: clearance is something determined by the PCB fabbing process, why would you want to deviate at any part of your board? So it sets the clearance once, globally. It is very hard (or even impossible with some tools) to make a local exception but it is very easy to change the _board's_ clearance value when fabbing requirements change. Some EDA tools bring this globalism to an extent that there are even 1 or 2 via drill sizes - why would you want a different via geometry?
Our local model is rare among EDA tools. It is very powerful in the sense that it gives us a lot of control on little details. However, it gets somewhat less practical in common cases. The most common one is an old footprint problem: since each object has its own clearance, footprint pins/pads do too. The board has a preferred clearance determined by the circuit and the fab, each board may have different preferences, but the lib delivers always the same, hardwired clearances, which are most probably not matching any given board's.
One of the old workarounds for a similar problem is the "vendor drill" plugin that tries to overcome the very similar drill bit size problem using hardwired C code trying to adjust random hole sizes to predefined ones.
I've been thinking a lot about how to resolve this contradiction without sacrificing our flexiblity but also without adding a lot of custom C code crafted for special cases. I had this in mind while I was designing the query and the propedit plugins. With these, we have a nice, generic solution that takes 3 lines of action script (assuming nothing was selected before):
query(select, @.clearance < 15mil) propset(p/trace/clearance, 15mil) propset(p/padstack/clearance, 15mil)
The first action selects any object that has a clearance and the clearance value is below 15 mil. The next two lines change the property of trace clearances (lines and arcs) and padstack clearances^1. It is possible to achieve the same using the GUI^2.
This system provides extra flexibility because the query language supports full featured logical expression. For example it is possible to select objects only on specific layers. Or objects that match other criteries, e.g. only thick or thin traces (trying to make different clearance for them in two steps).
The other side of the flexibility is that it is not tied to any specific object field but works on any of them. For example the user may need to ensure that traces are of a specific width on a specific layer (e.g. for impedance matching). This method can adjust those traces, without the code having to introduce a new global setting, trying to understand this special case.
Footnote:
^1 The syntax differs because query lets the user filter for object type, while propset works on anything selected. With this setup, it's easier to use propset somewhat selectively.
^2 {s s} for advanced search, then build the same expression using the dialog box, then apply, then {e p} for edit properties where the clearance values can be edited.