kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 7/14/2014 12:26 PM, Dick Hollenbeck wrote:
> 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.

I see no issue with using a data structure instead of passing files back
and forth.  In fact, I prefer this method.  It certainly makes life a
whole lot easier.  The only caveat is will there be some odd corner case
where you have to parse an existing netlist file for legacy purposes.  I
can't think of one off the top of my head but that doesn't mean there
isn't one.

> 
> 
>   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.
>