kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 7/14/2014 12:46 PM, Dick Hollenbeck wrote:
> On 07/14/2014 11:26 AM, 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.
>>
>>
>>   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.
> 
> 
> You don't have to scrap any existing data structures.   Just think of this as a new
> twitter account.  You grab information that is pertinent when it comes in, you send out
> when you've done something of interest to others.
> 
> It does not replace your existing primary document data structures.
> 

True.  As of right now, only Eeschema has any knowledge of the complete
netlist data structures.  The Pcbnew version is a completely different
implementation for reading only the information that is needed to create
a board.  If the current netlist object (NETLIST_OBJECT_LIST) in
Eeschema is not too intertwined with the data structures in any of the
schematic objects, it shouldn't be too difficult to move it into
libcommon where it can be referenced anywhere.  If memory serves (and it
often doesn't at my age :)), I don't believe that is that the case.  My
guess is that some significant work is in order to make that transition.