X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
Date: Thu, 9 Jul 2015 14:43:16 -0400
Message-Id: <201507091843.t69IhGF6028321@envy.delorie.com>
From: DJ Delorie <dj AT delorie DOT com>
To: geda-user AT delorie DOT com
In-reply-to: <DC183265-AD4B-4707-970F-1EE5D3578126@noqsi.com> (message from
	John Doty on Thu, 9 Jul 2015 10:48:25 -0600)
Subject: Re: [geda-user] Back annotation
References: <CAM2RGhTpfbqM7zNn72TBOjeL7B7LPT1PxSEU3+9aDdChFrPFTg AT mail DOT gmail DOT com> <alpine DOT DEB DOT 2 DOT 00 DOT 1507090507530 DOT 6924 AT igor2priv> <alpine DOT DEB DOT 2 DOT 11 DOT 1507091329350 DOT 3444 AT nimbus> <559E86A4 DOT 3040109 AT ecosensory DOT com> <DC183265-AD4B-4707-970F-1EE5D3578126 AT noqsi DOT com>
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


> but back-annotation into the schematic is very impractical.

[grabbing a sound-bite to reply to, but breaking the thread a bit]

To be fair, we've had this discussion many times in the past, and came
up with three different types of "back annotation":

1. some sort of two-way street between gschem and pcb, so that gschem
   gets updated wrt changes made in pcb.  This has been prototyped as
   an "in real time" dbus implementation for "live updates", but can be
   done with scripts too.  I think people who want this really want
   the live update part, which many integrated EDA tools provide.

2. A forward-annotate system from pcb to a *second* set of "as built"
   schematics.  The user could, of course, iterate these as-builts
   back to the design set as desired.  This lends itself to diffs and
   a more "big company" workflow.

3. Moving as-built data out of the schematic so that back-annotation
   isn't needed.  PCB would have to provide as-built info to the
   netlister, which would integrate that with the schematic info to
   build a new netlist.  We'd still need a #2-type tool though.

(personally, I like #3, and I think it would be a better way to enable
pin/gate swapping in heirarchical schematics, but of course it's the
hardest to implement)