X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Date: Mon, 31 Aug 2015 14:36:41 +0200 (CEST)
X-X-Sender: igor2 AT igor2priv
To: "Markus Hitter (mah AT jump-ing DOT de) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
X-Debug: to=geda-user AT delorie DOT com from="gedau AT igor2 DOT repo DOT hu"
From: gedau AT igor2 DOT repo DOT hu
Subject: Re: [geda-user] back annotation proposal (RFC)
In-Reply-To: <55E44609.3060606@jump-ing.de>
Message-ID: <alpine.DEB.2.00.1508311430040.6924@igor2priv>
References: <alpine DOT DEB DOT 2 DOT 00 DOT 1508301838470 DOT 6924 AT igor2priv> <201508301802 DOT t7UI2twS031311 AT envy DOT delorie DOT com> <CAM2RGhRgPQG2WDFVb0SFvMbypyYKS2oYtD=851WHR6fOB4iWdA AT mail DOT gmail DOT com> <201508310341 DOT t7V3fcfh022966 AT envy DOT delorie DOT com> <20150831111604 DOT 5b1bb421bc015de9a848e8a9 AT gmail DOT com>
 <alpine DOT DEB DOT 2 DOT 00 DOT 1508311141070 DOT 6924 AT igor2priv> <55E44609 DOT 3060606 AT jump-ing DOT de>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
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



On Mon, 31 Aug 2015, Markus Hitter (mah AT jump-ing DOT de) [via geda-user AT delorie DOT com] wrote:

> Am 31.08.2015 um 11:51 schrieb gedau AT igor2 DOT repo DOT hu:
>> My proposal assumes there is a way a "netlist patch" can be loaded in
>> gschem. Probably the same way as pcb can load a new netlist into an
>> existing/open pcb.
>
> How does a user find out which kind of "patches" are allowed? To know this, the initial netlist has to have all the neccessary informations already, like which pin can be replaced with which other pin and under which conditions. Having all the logic in place one can go just as well without back-annotation.

In my model, the user understands the schematics and can decide. This 
is how I do in practice. I'd only provide the technical tools so that the 
netlist change infromation I figure during routing is carried back to 
gschem by software instead of me remembering them.

So in this model, the initial netlist is not different from our current 
netlist in any bit. There's no extra "this could be swapped or remapped" 
info encoded in the schematics or in the netlist.

This is a very different approach from DJ's and imposes different 
assumptions on the person(s) working on the schematics/layout.

>
> Back-annotation is still possible, of course, but it's then more a user convenience to allow the user to see in gschem which pins were actually used. For those users which actually care about pin usage.

I don't fully understand these two sentences. If you mean that my proposal 
is a convenience feature that doesn't fully and generally solve the 
mapping problem: yes, that was my original intention.

Regards,

Igor2