Difference between revisions of "SpecElectronicsCAD"

From Inkscape Wiki
Jump to navigation Jump to search
Line 55: Line 55:
==Missing features==
==Missing features==
* Component abstraction
* Extension of the Symbols code to an abstraction usable for components
** Auto reference generation (“C1”, “R17” etc.)
** Auto reference generation (“C1”, “R17” etc.)
* Connectivity test/netlist generation/net names
* Connectivity test/netlist generation/net names

Revision as of 19:44, 21 May 2013

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)

Not so hard

  • Gnd/other plane fills → I think there already is a live path effect for that
  • Clearance calculation/DRC
  • PCB layers → Will map nicely to regular inkscape layers
  • 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
    • Is there some existing functionality that can be (ab)used for that?
  • Propagate net (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

Component features

  1. Components may be references to a library or be physically embedded into the document
  2. Like groups, components group objects together‒but they may do this cross-layer
  3. Components have some metadata/parameters associated with them
  4. Components can have terminals or pins (these are important for trace routing and netlist generation). Pins may have some metadata like direction and default net name

Required code

  • Component library‒(easiest version: folder of SVGs, or a folder of folders of SVGs for easier organization)
  • Component templates to be placed in a library‒I plan on two options: an SVG file (which is just pasted into the document) or python scripts outputting SVG (for parametrizeable generators) → There already is a blueprint of that exact technology (but applied on a whole-document basis as document templates)
  • An actual “component” object that can span multiple layers

See also


The GSoC Proposal

The SVG Connector draft