Index: doc/devlog/20170205_schimp.html
===================================================================
--- doc/devlog/20170205_schimp.html (nonexistent)
+++ doc/devlog/20170205_schimp.html (revision 6712)
@@ -0,0 +1,35 @@
+
+
+
+
+ what's needed for schematics -> pcb-rnd
+If a path between a schematics capture program and pcb-rnd is to be implemented,
+the following information needs to be passed:
+
+ - schematics -> pcb (forward annotation)
+ Any file format the schematics tool prefers and delivers at least this
+ set of information:
+
+ - Each component/part needs an unique identifier, a "refdes", e.g. R1, U4.
+
- Each pin/pad needs an unique identifier within it's component/part, so at the end "U4-3" uniquely identifies pin 3 of component U4.
+
- Each component/part needs a footprint (a free form text). Optionally arbitrary user specified key=value pairs per part can solve this and a lot more.
+
- A list of named networks. Optionally with user specified key=value pairs per network (less important here).
+
- A list of component-pin pairs per network.
+
- The netlist can be flat or hierarhic.
+
+
+ - pcb -> schematics (back annotation)
+ pcb-rnd emits a netlist patch described
+ here , but it
+ could emit any other format the schematics tool needs. The schematics tool
+ would need to understand the following concepts while reading a back
+ annotation file:
+
+ - Unique part refdes and pin number, as above
+
- Named networks, as above
+
- "this is how the network looked like when we started" (net name, list of pins)
+
- "the user removed this pin from that network" operation
+
- "the user added this pin from that network" operation
+
- optional: "the user changed this key=value pair of this part"
+
+