# pcb-rnd devlog

## Pad stacks announcement

by Igor2

### Intro

#### 1. What is a padstack?

A padstack is an optional hole (plated or unplated) and a list of layertype-shape pairs for the pads. Layertype includes not only copper, but any layer type.

#### What can a padstack do?

It is the replacement object for vias, pins and smd pads. It is universal enough that it's easy to describe all three cases. It removes almost every limitation in those objects that ever got mentioned on the mailing list. It's so universal that it can make perfect fiducials and align markers.

#### How does it make a PCB designer's life easier?

It introduces the following features, which will be described in separate announcements to keep things shorter:

- almost arbitrary pad shapes for pins, vias and smd pads (e.g. oblong pads, asymmetric circles or octagons, hexagons, pentagons, arbitrary convex polygons)
- different pad shape on various layers (e.g. smaller pad on inner copper layer vs. larger pad on outer copper layer)
- possibility for explicit, user defined shapes even on mask and paste layers
- blind/buried via
- cache/library of matching padstacks - possibility to change one and affect all instances, but also possibility to take out a single padstack from the group to deviate
- thermal on anything - there's no difference between smd pad or pin

#### How does it make the coder's life easier?

- a single, unified object instead of 3 different objects (via, pin, pad)
- shape is not a flag anymore - no more square or octagon flag, but a clean API that returns the actual shape on the given layer
- pcb-rnd has extensive IO capability to other file formats (kicad, eagle, hyperlinks, etc.); with padstacks it's much easier to reproduce their pads

#### Next steps, what to expect

First, we are getting padstack related bugs and missing features fixed in trunk/ as our users are starting to test it. Then the next release, scheduled to the end of 2017, will feature a hopefully 100% stable, production quality padstack support.

We will then start rewriting the IO plugins to support padstacks instead of vias, pins and pads. This includes the .pcb plugin too - it will convert old data to padstacks on load and padstacks to old data on save, transparently.

Finally, when no code uses the old data model anymore, we will remove a lot more code than we had to add for padstacks and subcircuits. We will remove pads, pins, vias, elements, element lines and element arcs. This will probably happen some time in 2018.

### 2. Thermals

A padstack normally includes shapes, one per layer type. "Normally", because it's optional: for example the simplest mounting hole can be a padstack that has an unplated hole and no shapes at all. The hole is optional too: an smd pad typically contains shapes (e.g. for top copper, top mask and top past but no hole.

A shape is a filled circle, a line (round or square cap) or an arbitrary shaped convex polygon. The shape doesn't have to be centered at the hole.

Restrictions: only one shape per layer type, only one hole per padstack. (This is enough for vast majority of the use cases, for the rest, heavy terminals in subcircuits shall be used; a heavy terminal can contain anything that can be drawn on a PCB, without restriction.)

Since an arbitrary shaped pin or via needs to be able to make a thermal, the thermal code got upgraded to handle all the above shapes. A matrix of how they each look:

And yes, this does mean smd pads can have thermals, as long as they are done with the new padstacks, and not the old pad objects.

The ability to have different shape per layer type makes it easier to use the inner layers of dense boards: outer layers can have larger pads for better soldering of through-hole pins, while inner pads can be as small as the fab permits, to allow more traces to pass between them.

A padstack instance can be rotated and mirrored, still referring to the same central padstack prototype for the shapes. A padstack instance can have a different clearance, still using the same prototype. If a padstack instance needs to deviate, it's very cheap to copy the prototype and starts its own group with the deviations included.

There are two features I have not decided about yet, but will do in a few days:

- I have half-working code for a "thermal style" that removes the copper shape on a specific layer group; this again could be used for saving space on inner layers
- I have half-working code for a per-shape clearance; it may be that I will provide both a global, per pad stack instance clearance option and a padstack prototype defined per shape clearance. Rationale: some IPC suggests the clearance on inner layers can be tighter than on outer layers, for various reasons. This may matter on dense boards.

### 3. blind/buried vias

Because a padstack already has to be able to look up its pad shape on a per layer group (physical layer) basis, it was sort of trivail to add blind/buried vias too.

The hole starting layer group and ending layer group is specified in a way that is transferrable between different pad stacks. The simplest thing to describe is the all-way throuh hole (needs no extra parameter). The second simplest is a blind hole (needs one parameter). A buried hole needs 2.

Following the best pcb-rnd traditions, things are not entangled: whether a padstack has a hole or not does not depend on whether it has shapes on copper or other layers. Whether a hole is plated does not depend on if it's through, blind or buried.

This gives the user maximum flexibility of combining the features, even building things that we would normally regard broken constructs, like an unplated buried hole between two inner layers, with a pad on each layer.

Again following the best pcb-rnd traditions, we are not to outsmart the user. We let the user do what the user finds useful. Later on we will provide DRC to warn for strange looking constructs, but it's the user's responsibility to use or abuse a feature.

### 4. UI

pad stacks can be created similar to elements and subcircuits: draw objects on various layers, then select them and convert the selection to padstack using a menu. Or select them, copy to buffer, and convert the buffer.

There will be soon a padstack breakup function too, again similar to what elements and subcircuits have these days. And of course, some time later there might be a way to save and load padstacks, just like footprints, and then pcb-rnd will be able to open the padstack files directly for editing, just like when we edit elements or subcircuits. We may even end up having a library selection system for them, similar to the footprint lib's.

Another UI feature is a new dialog box (supported by all gtk and lesstif HIDs!) that presents two tabs: one for the specific padstack reference the user clicked on and one for the prototype. This dialog allows the user to change the basic parameters, like clearance and hole properties, including plating and bbvia aspects.

Later on this dialog will offer shortcuts for copying and transforming shapes, per layer type, e.g. it will be easy to do things like "copy top copper shape to top mask, bloat it up by 5%".

Another TODO for the near future is that the routing style should have a padstack prototype for each style, instead of via parameters. And there should be a very simple dialog that can create a "classic via" prototype using only the hole diameter, ring diameter and clearance.

### 5. Implementation details

A padstack put on a board is really just a reference to a padstack prototype, sort of "copy that prototype to this x;y location, with this rotation angle and mirror it". The prototypes are kept in a transparent cache.

Since prototypes have to be retrieved during drawing, the above process shall be fast. It would be suboptimal to perform the rotation and mirroring on each draw. Instead, each rotated/mirrored ("transformed") version ever referenced are kept in the cache and are referenced directly by the padstack reference. These tranformed variants are not saved in files but are always generated runtime, upon the first request. If the shape needs to be changed, e.g. bloat or shrink, all the cached tranformed variants need to go under the same operation.

The non-transformed version of each prototype is called the "canonical form" and is saved/loaded on file IO. (Padstacks are obviously accessible only in our native format at the moment; later on alien formats that also support some sort of pad stacks will catch up; we are not going to change the .pcb format, tho, so padstacks will not be available there)

A low level of the padstack code uses a hash algorithm for being able to rapidly detect if the canonical variant of a prototype to be added already presents in the cache - if so the, duplicate is not added, but the existing item is referenced.