kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 7/14/2014 11:19 AM, Tomasz Wlostowski wrote:
> On 14.07.2014 13:53, Lorenzo Marcantonio wrote:
>> On Mon, Jul 14, 2014 at 01:12:48PM +0200, Tomasz Wlostowski wrote:
>>> ^^ all of this could be likely done by the same piece of code, that
>>> simply
>>> compares the two netlists and generates the differences. This part is
>>> generic. The way the differences are resolved is specific to
>>> pcbnew/eeschema/cvpcb. An ECO report/visual diff would be just a
>>> useful side
>>> effect of this approach.
>>
>> Correct. See my comment as 'could be a lib or a separate process'. The
>> output format (in the sense of 'how this routine emits output' however
>> *will* matter (can be put out on a file or drive the 'difference
>> resolutor',
>> more or less like an expat parser).
>>
>>> I don't think we need a separate tool. Our aim is to be able to see what
>>> gets changed on the PCB/SCH and pick which changes to apply and
>>> reject. The
>>> ECO you're talking about needs not be a physical file, it can be
>>> implicitly
>>> generated whenever user requests updating the PCB/schematic. Most of the
>>> code is probably already in place, what we want is to make it more
>>> controllable (so that, for instance, you could undo a recent netlist
>>> update
>>> in pcbnew).
>>
>> The 'separate tool' could be simply a wrapper for a lib call, as I said.
>> Since you talked about documentation I tought it was needed some kind of
>> output file.
>>
>>>> cvpcb only needs to touch the footprints
>>> As agreed with Wayne, there's no place for cvpcb as a separate tool
>>> in the
>>> future of Kicad. Footprint selection should be done on the schematic
>>> level.
>>
>> OK, that doesn't change very much the interaction model anyway (and
>> cvpcb would be the easiest part).
>>
>>> So why not copy them, just like pcbnew does? IIRC the model code in
>>> eeschema
>>> is to be reworked anyway...
>>
>> I think that would be for *another* proposal. The problem with the
>> current model is that pin are fixed in position. So given the typical
>> 7400:
>>
>> U1A
>> --1--\
>>     |  O3--
>> --2--/
>>
>> you can gateswap easily, the info *could* be already there:
>>
>> U1B
>> --4--\
>>     |  O6--
>> --5--/
>>
>> But how do you pinswap?
>>
>> U1A
>> --2--\
>>     |  O3--
>> --1--/
>>
>>    ^ how?
>>
>> You could either a) duplicate and physically swap the pins on the part
>> (more or less the way we do it on pcbnew) or b) use an indirection table
>> to represent the mapping beten, say 'logical pins' 1, 2 and physical
>> pin 1 and 2. a) is IMHO more difficult to handle from a 'declarative'
>> backannotation (how do you represent it?), b) is just another data
>> structure to handle.
> 
> Lorenzo,
> 
> IMHO both a) and b) are too complex to handle.
> 
> Proprietary EDA packages (at least Cadence and Altium) simply swap the
> labels on the wires connected to the pins instead of swapping the pins
> in the component. It means no special mappings and data structures -
> just reconnecting the net label from one pin to another, and could be
> probably done without any changes to eeschema's internal logic.
> 
> Cheers,
> Tom
> 

Irregardless of how we implement this and what forward and backward
annotation features we choose support, it will require merging the
netlist (s-expr version) write code in Eeschema and the read code in
Pcbnew (used in CvPcb) into a cohesive object that can be used anywhere.
 I refactored the netlist read code in Pcbnew a while back and realized
that we effectively have two separate implementations for handling
netlists.  The read implementation in Pcbnew is not 100% complete so it
will have to be completed in order to preserve all of the information in
the netlist file for the trip back to Eeschema.  At some point, I intend
to revisit this.  Once this is completed, I would like to see the
separate cmp file go away since it is redundant when using the s-expr
netlist format.

Wayne