SpecElectronicsCAD - Revision history

Romain2Boss at 11:03, 25 May 2013

2013-05-25T11:03:49Z

← Older revision		Revision as of 11:03, 25 May 2013
Line 130:		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]]

SebastianGoette at 20:04, 21 May 2013

2013-05-21T20:04:14Z

← Older revision		Revision as of 20:04, 21 May 2013
Line 113:		Line 113:

	==Component abstraction==		==Component abstraction==
			Inkscape's symbol functionality already supports most of this.

	===Component features===		===Component features===
	# Like groups, components group objects together		# Like groups, components group objects together
Line 120:		Line 122:

	===Required code===		===Required code===
	* Python interface for parametric ~~component~~ generation		* Python interface for parametric symbol generation

	==See also==		==See also==

SebastianGoette at 20:01, 21 May 2013

2013-05-21T20:01:43Z

← Older revision		Revision as of 20:01, 21 May 2013
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 110:		Line 117:
	# Components have some metadata/parameters associated with them		# Components have some metadata/parameters associated with them
	# The parts of a component may be on different PCB layers (i.e. be assigned different PCB layer classes)		# 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). ~~Pins may have some metadata like direction and default net name~~		# 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===
	* Python interface for parametric component generation		* Python interface for parametric component 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==

SebastianGoette: /* Component abstraction */

2013-05-21T19:51:41Z

Component abstraction

← Older revision		Revision as of 19:51, 21 May 2013
Line 107:		Line 107:
	==Component abstraction==		==Component abstraction==
	===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). Pins may have some metadata like direction and default net name

	===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 component 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)		* 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		* An actual “component” object that can span multiple layers

SebastianGoette: /* Hard */

2013-05-21T19:44:34Z

Hard

← Older revision		Revision as of 19:44, 21 May 2013
Line 55:		Line 55:
	==Missing features==		==Missing features==
	===Hard===		===Hard===
	* ~~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

SebastianGoette at 15:09, 9 May 2013

2013-05-09T15:09:07Z

← Older revision		Revision as of 15:09, 9 May 2013
Line 121:		Line 121:

	The [https://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2013/jaseg/1 GSoC Proposal]		The [https://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2013/jaseg/1 GSoC Proposal]

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

SebastianGoette at 15:08, 9 May 2013

2013-05-09T15:08:31Z

← Older revision		Revision as of 15:08, 9 May 2013
Line 116:		Line 116:
	* 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)		* 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		* An actual “component” object that can span multiple layers

			==See also==
			[https://bitbucket.org/boldport/pcbmode PCBmodE]

			The [https://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2013/jaseg/1 GSoC Proposal]

SebastianGoette: Created page with "=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..."

2013-04-30T14:38:51Z

Created page with "=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..."

New page

=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===
* Component abstraction
** 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===
# Components may be references to a ''library'' or be physically embedded into the document
# Like groups, components group objects together‒but they may do this cross-layer
# 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

===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