kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 07/14/2014 10:37 AM, Wayne Stambaugh wrote:
> 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.


Where is the netlist in our minds?

     Is the netlist a file or is it a data structure?

In my mind it should be thought of as a data structure for the bit of time.


I'd hang it in the PROJECT class simply and simply learn to "use" it there first and
initially forget about load/save for a week or more.

This forces a unification of use, and ensures that form follows function.  That any needed
fields are identified before time is spent saving/loading.

Just teach both pcbnew and eeschema to use the data structure out of class PROJECT first.
 The *file* has been nothing other than a communication scheme between two or three
programs.  This was two or three programs which are now *one* program.


Please consider this new perspective.

You might find you don't even need a separate netlist *file*.  The netlist information is
held independently in both eeschema and pcbnew.  Either can reproduce it into a unified
data structure.  Having a common/shared data structure, concurrently accessible from
either pcbnew or eeschema allows unification of the netlist data structure because there
is only one netlist data structure.


  https://lists.launchpad.net/kicad-developers/msg13921.html


If the file is still thought to be necessary for awhile, then we should use the use the
"data on demand" technique and put the loading code into a shared library.  I have been
procrastinating putting a portion of libcommon into a shared library, but this would be a
good time to do it.