Difference between revisions of "SpecElectronicsCAD"

From Inkscape Wiki
Jump to navigation Jump to search
m
 
(3 intermediate revisions by one other user not shown)
Line 58: Line 58:
** Auto reference generation (“C1”, “R17” etc.)
** Auto reference generation (“C1”, “R17” etc.)
* Connectivity test/netlist generation/net names
* Connectivity test/netlist generation/net names
* Trace routing tool with 45° outing This absolutely is a task for the graph connector tool
* 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)
* 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===
===Not so hard===
* Gnd/other plane fills I think there already is a live path effect for that
* Gnd/other plane fills
** I think there already is a live path effect for that
* Clearance calculation/DRC
* Clearance calculation/DRC
* PCB layers → Will map nicely to regular inkscape layers
** 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
* File format support
** old Eagle format
** old Eagle format
Line 87: Line 94:
** Start with elements in descending net name priority: first human-set names, second everything derived from default pin names, third just make up names
** 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
* Find overlapping or touching elements
** Is there some existing functionality that can be (ab)used for that?
** Does not seem too complicated. Since the heavy lifting is done by 2geom this could be implemented in python.
* Propagate net (via labelling new parts)‒this is basically flood fill
** Propagate net names (via labelling new parts)‒this is basically flood fill


===Net names===
===Net names===
Line 106: Line 113:


==Component abstraction==
==Component abstraction==
Inkscape's symbol functionality already supports most of this.
===Component features===
===Component features===
# Components may be references to a ''library'' or be physically embedded into the document
# Like groups, components group objects together
# Like groups, components group objects together‒but they may do this cross-layer
# Components have some metadata/parameters associated with them
# Components have some metadata/parameters associated with them
# 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
# The parts of a component may be on different PCB layers (i.e. be assigned different PCB layer classes)
# 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===
===Required code===
* Component library‒(easiest version: folder of SVGs, or a folder of folders of SVGs for easier organization)
* Python interface for parametric symbol generation
* 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==
==See also==
Line 123: Line 130:


The [http://dev.w3.org/SVG/modules/connector/SVGConnector.html SVG Connector draft]
The [http://dev.w3.org/SVG/modules/connector/SVGConnector.html SVG Connector draft]
[[Category:Proposals]]
[[Category:Specification]]

Latest revision as of 11:03, 25 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.

Scenario

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

Hard

  • 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

PCBmodE

The GSoC Proposal

The SVG Connector draft