pcb-rnd knowledge pool


History: how the old element model was broken

old_elem by Tibor 'Igor2' Palinkas on 2017-05-30

Tags: insight, history, historic, element, footprint, subcircuit, rewrite, data, model

node source



Abstract: What problems we had with the old element model inherited from PCB and how we got rid of these problems with the subcircuit upgrade.

  Imported from the mailing list archives.

old model: pcb elements (pre-2017)

There are a lot of feature requests out there about extending the footprint model. A few random example:

It would be possible to add code just for these cases. However, each such example would introduce a new set of special cases in the code base, and these cases will always interact with almost all other such specil cases. Which means an exponential growth in special case vs. sepcial case interaction that would be rather hard to maintain long term. This is not the route we take in pcb-rnd.

Generally speaking, the problem is that our footprint model is a bag of special cases: footprints can have the special objects, for example:

There are some clever hacks to work around some of the limitations, usually by combining pads and pins. But this is not building from pure, orthogonal bricks, but building from fuzzy haystacks, mainly trying to combine and cancel side effects. I know this "works", I know we do this since forever, but this is far from the optimal solution.

new model: subcircuits (from mid 2017)

I am going to slowly replace this old mechanism in pcb-rnd with a new system called "subcircuits". From the user's point of view, a subcircuit takes the same role as a "footprint" (... in a lib, or "element", when placed on a board - as of gEDA/pcb terminology).

A subcircuit does not have special objects like "pins", "pads" or "element-lines". Instead, it has the same objects that the layout has: lines, arcs, polygons, text and vias. (In fact I am going to use the same C struct that the board uses, which is pcb_data_t in pcb-rnd).

Trick #1: flexible layer handling

Just like a board, a subcircuit also has a layer stack. When the subcircuit is a footprint, this layer stack is not a particular physical stack, rather a recipe. E.g. instead of fixed layer numbers, this stack would contain patterns like "this layer should be in the top copper physical layer on the board". It could indirectly reference any physical layer: copper, silk, mask, paste, outline; top, bottom or even inner layers. Once the subcircuit is placed on a board with an actual physicla layer stack, the layer binding is performed: with or without interactive user intervention, using the layer stack recipe, each layer the subcircuit uses is boud to one of the actual layers of the board.

Trick #2: flexible terminal handling

Just like in tEDAx, pins/pads are no special objects but plain drawing primitives tagged for a given terminal. Terminal is the "pin number, pin name" concept. A multiple vias, lines, arcs, polygons or even text objects can be tagged to be part of a terminal. The netlist sees terminals only.


In practice this means our new footprints will be capable of hosting:


This section is of historic interest only - we have implemented most of these already.

This will probably take a long time, spanning multiple development cyclces, just like the layer rewrite did.

Stage 1:

We will start implementing it in the current cycle and will make it gradually grow until it reaches its full featured, final form. We will make sure that at every intermediate release subcircuits are usable and alreayd provide extra features over footprints. We will keep the original footprints in place during this process.

Lihata board v3 will have support for subcircuits. The subcircuit subtree will also be avaialble as a subcircuit file format for sharing footprints.

While we are in this stage, we'll encourage users to use subcricuits instead of footprints, and always save in lihata board v3 instead of other formats. However, the code will still be able to use the old footprints in parallel.

Stage 2:

At some point in time subcircuits will be capable enough to replace footprints. At this point we will remove footprints, pins, pads, element-lines, element-arcs. We will also need to rewrite import code to convert old elements to subcricuits on load and rewrite export code to convert subcircuits back to elements for old formats.

Stage 3:

We'll convert pcblib from the old, element based .fp files to lihata subcircuit files. We'll rewrite the parametric footprint scripts to generate lihata subcircuits instead of pcb elements. This will include extending some of the parametrics with features that was not possible with pcb elements because of the limitaiton of the model/format.

(This also means our parametric footprints won't be available for pcb mainline without a conversion or without mainline upgraded to lihata formats and the subcircuit model)