From Inkscape Wiki
Revision as of 11:03, 25 May 2013 by Romain2Boss (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Electronics CAD with Inkscape‒Missing functionality

Currently there is no nice open source electronics CAD tool. The largest competitors are gEDA which I find awkward to use and KiCad which I find even more awkward to use. Since a schematics editor is not much more than a special-purpose flow graph editor and a PCB layout editor is in fact nothing but a somewhat crippled vector graphics editor with some special-purpose features added I think it is very promising to modify a general purpose vector graphics editor to support the few special-purpose functions additionally required by an electronics CAD tool.


The electronics CAD process mainly consists of two parts: Drawing the schematic and PCB (Printed Circuit Board) layout. Normally, you will first draw a schematic and base your PCB layout off that. However, from then on you will frequently change the schematic and layout and want to have your chages in the one represented in the other.

A schematic is basically just a flow chart. The basic features are components (symbols) taken from a library that are put on a grid (because you do not want to mess around with a lot of manual aligning) and that are connected with wires (represented by lines). Wires are always either vertical or horizontal and have names for the signal the wire is carrying. Components have a list of attributes (an unique id, value/voltage, part number, supplier etc.), some of which are rendered on the schematic next to the component (normally these are id and value or part number). Finally, you want some function to place text anywhere for comments.

A PCB design in comparision is a little more complex. A printed circuit board is a stack of plastic and copper foil. The copper foil is etched into such shapes that when you solder components to it they are connected in just the right way. There may be multiple layers of copper foil (up to more than 10) in more complex designs. Two different layers of copper may be connected with a “via”, a small hole whose inside surface is plated with metal. These vias may go all the way from the top to the bottom of the board or just through a few layers in the middle (the latter is more expensive but common in complicated designs). Similar to vias, there are larger holes through which the leads of components may be stuck for soldering.

The outline of the PCB may be irregular, and the board may have slots, holes and even grooves.

Beyond the top- and bottommost copper layers, there are some special layers. On each side there is a “solder mask” which is a varnish that protects any surface that is not meant to be soldered on from dirt and oxidation (this makes the PCB green or blue or red), and a “silk screen” layer which is a usually white paint used to place human-readable markings with part numbers, ids, values, outlines as well as comments, copyright notices etc. on the surface on the board.

A very important feature of PCB layout programs is called “DRC” (design rule checking). The most important of several possible design rule checks is that on the PCB layout traces do no touch and there always is some clearance between them.

Missing features


  • Extension of the Symbols code to an abstraction usable for components
    • Auto reference generation (“C1”, “R17” etc.)
  • Connectivity test/netlist generation/net names
  • Trace routing tool with 45° outing
    • This absolutely is a task for the graph connector tool
  • Schematic ↔ PCB mapping (components added in the schematic are also added on the PCB, components (packages) on the PCB may be exchanged for other, compatible packages)
    • To ease this, schematic and PCB layout could be placed on different layers of a single SVG file

Not so hard

  • Gnd/other plane fills
    • I think there already is a live path effect for that
  • Clearance calculation/DRC
    • This naturally is part of the netlist generation
  • PCB layers
    • Can be implemented by SVG classes. When SVG 2.0 comes around, these can be assigned z-order attributes.
    • Most other parts of Inkscape do not need to be aware of these classes, they only need special treatment when exporting to PCB formats.
    • PCB layer classes are assigned when creating a component. Some kind of GUI would be nice for this.
  • File format support
    • old Eagle format
    • new (XML-based) Eagle format
    • Gerber
    • gEDA
    • KiCad
  • Page frame templates → The actual frame can be realized as a drawing on a locked layer
    • Auto-insertion of document properties into text fields → This looks like some pretty straight-forward placeholder replacement to me
      • ...and part numbers/values
  • non-rectangular page outlines? → Probably, Inkscape's page abstraction will not even be used for the board outline (but instead a layer containing a polygon will be)
  • distance measurement tool‒ This is very useful even outside of electronics
  • object highlighting → Some limited version of this already exists in form of these quickly disappearing red path visualizations
    • Should appear on mouse hovering (perhaps with mod key)
    • Should highlight the whole object, not just paths/fills/etc.
    • Perhaps render the object transparent with increased brightness on top of everything else?
  • transparent/desaturated “see-though” rendering of inactive layers

Connectivity testing/netlist generation

Algorithm overview

  • Select starting point
    • Start with elements in descending net name priority: first human-set names, second everything derived from default pin names, third just make up names
  • Find overlapping or touching elements
    • Does not seem too complicated. Since the heavy lifting is done by 2geom this could be implemented in python.
    • Propagate net names (via labelling new parts)‒this is basically flood fill

Net names

  • All pins/traces/planes ought to have net names
    • Net names have a “priority” (an integer): 0 for auto-generated names, 100 for names derived frmo default pin names and 200 for manually-set names
  • After propagating existing names, start assigning generated names to unnamed elements and propagate these

Starting points for the algorithm

  • Pins/pads, traces, planes
    • Generate names for pins by using the default net name of the pin (“CLK”). Check whether the name already exists in the document and if yes, append a number to the default net name (“CLK2”). Repeat until an unique name has been found.
  • Find those by just iterating through the object tree → even pins should be found there despite them being part of a component

Dynamic updating

  • Dynamic updating should be the normal case. When something is removed, the connectivity of its former net has to be re-checked.
    • If there is a netsplit, drop the old net name, then search the two net parts for two starting points for the aforementioned algorithm. If none are found, just use any element.
    • If there is an addition to an existing net (and thus a name collision), do the obvious: Use the name with the higher priority

Component abstraction

Inkscape's symbol functionality already supports most of this.

Component features

  1. Like groups, components group objects together
  2. Components have some metadata/parameters associated with them
  3. The parts of a component may be on different PCB layers (i.e. be assigned different PCB layer classes)
  4. Components can have terminals or pins (for trace routing and netlist generation). This nicely maps to the point elements described in the SVG Connector draft

Required code

  • Python interface for parametric symbol generation

See also


The GSoC Proposal

The SVG Connector draft