# pcb-rnd devlog

## drawing primitives roadmap

by Igor2

### 1. current situation

A drawing primitive is an atomic object that the board (e.g. layers) is built of. gEDA/pcb has the following drawing primitives:

primitive | scope | limitation
--- | --- | ---
line | layer | none
arc | layer | none
text | layer | supported only one font
polygon | layer | none
via | global | same ring (pad) on all layers; limited number of shapes; no bbvia in pcb-rnd yet
element | global | can host only element-* objects, pins and pads
element-line | element | only on silk
element-arc | element | only on silk
element-text | element | only on silk, only one of value, refdes and device
pad | element | only line shape, only on top or bottom copper layer
pin | element | only via shape

What pcb-rnd has at the moment (summer of 2017, version 1.2.4) is basically the same, except full multi-font support and a basic support for subcircuits:

primitive | scope | limitation
--- | --- | ---
text | layer | none
subcircuit | global | can not interact with the netlist

A subcircuit can hold line, arc, text and polygon on any layer and vias.

### 2. goal

The following table shows where pcb-rnd will get in a few months:

primitive | scope | limitation
--- | --- | ---
line | layer | none
arc | layer | none
text | layer | none
polygon | layer | none
padstack | global | none
subcircuit | global | none

This means four major changes: "subcircuits as footprints", "subcircuit in subcircuit", "removal of elements" and "padstack instead of via". The result is a much cleaner model consisting of less primitives that are more universally usable.

### 3. subcircuits as footprints

For subcircuits to be available as footprints the new "terminal" concept is being introduced. A terminal is not a new drawing primitive, but a property of existing objects (made of other primitives). If an object is tagged to be part of a terminal, it starts acting as a terminal. Copper objects of a terminal can accept netlist connections just as pins and pads used to. A terminal has an ID that is similar to the old "pin number", "pad number" concepts.

The other important aspect is to be able to assign an ID ("refdes") to the subcircuit.

Most of these should be finished in the current development cycle and should be released this autumn.

### 4. subcircuits in subcircuits

Independently of that, to remove the last piece of limitation, a subcircuit will be able to host a subcircuit. This will enable users to build hierarchical boards, potentially supported by hierarchical netlists.

This may happen in this development cycle or in the next.

### 5. removal of elements

Once 3. is done, the old element model can be removed. For that, all IO plugins need to be upgraded first; they need to:

- convert elements to subcircuits on load
- convert subcircuits to elements on save

### 6. padstack instead of via

Finally, the good old via would be replaced by padstack. A padstack is an optional hole, and arbitrary (circle or polygon shaped) pads around the hole. Different pads can be created per layer - including not only copper layers but all layers, e.g. mask (cutout), paste, silk. It's likely that non-circular holes (e.g. line segments) will be allowed, for slots.

Since the hole is optional, a pad stack can represent a simple smd pad - with its paste and mask, without limitations on the shape.

Bonus: the hole doesn't need to be thru-hole, which means blind/buried vias.

This would probably happen next year.

### 7. Bonus: extended primitives

Once the number of the drawing primitives is cut back to 6, as a bonus feature it will be easy to implement extended primitives from plugins. An extended primitive:

- contains function pointers to the plugin implementing it
- is created and edited on the UI the same way as its base primitive
- saved and loaded as the base primitive + arbitrary metadata intended for the plugin
- acts as a subcircuit, can create other primitives within
- optionally can be rendered (drawn) differently than the base primitive; the render code is in the plugin

For example a via stitch can be a polygon or a line with extra parameters to specify via geometry and spacing. A polygon version can be used to plant a matrix of vias easily; e.g. under the hot center pad of a DC/DC chip. If the polygon is resized, the vias are recalculated. A line version would provide the center-line for placing a row of vias, e.g. for a waveguide. As the line is edited (e.g. endpoint moved, line length extended) the row of vias is recalculated.

This would probably happen next year.