pcb-rnd knowledge pool

 

Netlist based workflow vs. "just draw"

netlist_based by Tibor 'Igor2' Palinkas on 2018-08-16	Tags: roadmap, netlist, rat, forward, back, annotation, drc, short, network
node source

 

Abstract: Decision: pcb-rnd should favor the netlist based workflow over the "just draw things" workflow, while still supporting both. Background of the decision, including history of netlist support in pcb. Detailed roadmap how the new policy is achieved.

 

pcb history: details

Early versions of pcb did not have netlist or even elements. The user edited copper, geometry. Life^WBoards were simple back then, the user kept the schematics in head or on paper and drew the pins of DIPs manually on the 100 mil grid for each IC.

Later on elements got introduced; first version treated all elements as one big element, so there was one element per board, but later on it got split up and it became possible to place multiple elements. Since this is still mid 90s, elements were generated using m4 macros, it was not possible to load "file elements". There's still no netlist.

In a later release pcb started to have netlists and rat lines. Netlist could be loaded from a file, but a netlist was just a netlist, nothing more - no footprints or component values.

Around this time gschem development started to boot up. After a while it became sort of a de facto standard that pcb is used together with gschem, transport being the netlist exported from gschem.

This later on got more automatized with gsch2pcb, which introduced a new feature: beside the netlist, it also imported (and placed) the footprints. Major drawbacks included:

• yet another set of rc file and configuration, so the user had to tell pcb where the lib is, but then explain the same thing to gsch2pcb as well
• gsch2pcb tries to parse the pcb file to figure what footprints are already there
• at the end the user still needs to execute 3 or more steps from pcb-rnd to load all outpit of gsch2pcb

These drawbacks are all fixed with gsch2pcb-rnd. However, gsch2pcb is "nobody's project": while the original version is parsing pcb files, it still needs a deep understanding of the schematics side as well and run gnetlist, so it could be as well part of the gaf project. Maybe this why gsch2pcb has so many copies: one in pcb-rnd, another in lepton-eda and a third in geda/gaf.

Anoter major drawback is that gsch2pcb does not fit well in the GUI. Many users wanted a single-click forward annotation from gschem to pcb. This induced the import schematics feature in pcb, which is a different version of gsch2pcb living inside the pcb executable. It runs gnetlist (or a makefile) too and executes the resulting commands loading the footprints and the netlist.

pcb history: summary

In short, pcb went a long way between 1990 and 2009:

• from no elements at all
• to one elmenent
• to multiple elements and library
• to netlist
• to depend (a bit too much) on gschem
• to gsch2pcb and import schematics

pcb-rnd went even further introducing local netlist changes and back annotation.

pcb-rnd: netlist vs. no netlist problem

However, much of the code is still built as if we did not have netlists. Some oldish features are still living in the 90s, assuming the user is drawing copper from head, not using a netlist.

This is because nobody ever though this over: a lot of things are easy in one way if you have a netlist and another way if you don't. For these features it is impossible to design the feature to be equally simple and easy for both use cases. Nobody made a decision whether pcb-rnd (or pcb) should more in favor of netlist driven design or more in favor of "just draw!".

"More in favor" does not mean "supports exclusively". It only means that whenever there's a contradiction and a feature needs to be tuned, we tune it consistently for one of these use cases, knowning that users of the other use case will have to do more clicks.

solution

The decision is that we favor the netlist driven approach. There are 3 use cases:

• netlist driven, with netlist imported
• netlist driven, with the board and the netlist built from scratch, within pcb-rnd
• no-netlist boards

By far the most common is the first by now. Typical examples of the second is adapter boards: a connector and a led, a connector and some smd part, mechanical parts (e.g. standoff for an opto sensor). These are so simple that we often draw them without drawing a schematics. However, if pcb-rnd would have better support for building a netlist while drawing the board, that would make editing (and verifying) such boards much simpler.

Finally, some boards are so simple that they don't need any netlist at all. That remains possible too, but the UI will not be optimized for that use case.

We already have good support for the first and the last use cases but no good support for the second.

roadmap

1. tree/table/list widget for lesstif
2. tree/table/list widget in gtk and DAD
3. rewrite the netlist dialog using DAD
4. extend the new netlist dialog to allow netlist editing (including netlist creation)
5. extend the draw rat line UI to be more netlist-integrated: drawing a rat shall mean creating a persistent net (in the patch netlist, so it can be back annotated to create a schemaics later, if needed)
6. (by this point we fully support the second use case: creating the netlist within pcb-rnd)
7. fine tune existing actions for netlist based design

   Actions affected

   The following actions and operations will be fine tuned to be more in favor of the netlist based design:

   • loading a subcircuit into buffer should set the footprint attribute just like import_sch does
   • manually drawn rat lines should be more coupled to the netlist
   • netlist export should be able to export the netlist patch or the full patched netlist or the input netlist