pcb-rnd knowledge pool
data model rewrite: drawing primitives
| data1 by Tibor 'Igor2' Palinkas on 2017-08-13 | Tags: roadmap, data model, data, model, rewrite |
Abstract: Rodmap of the data model rewrite; introduction to the terminology of the old and the new data model.
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.