kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 07/14/2014 12:21 PM, Wayne Stambaugh wrote:
> 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.

Sheesh, that would be too bad.  It seems like we might need a couple of keys for fast
searching, but the rest of it is nothing but a bunch of text fields.  I fail to see how we
got to spaghetti from there.

<whimper>
I would love to see more "information hiding", and more "only on a need to know" thinking
going into the design of KiCad's new code and data structures.  What's a declaration,
what's a definition, etc.  Headers only when and where needed...
</whimper>


==================

If need be, there could be two data structures, one outbound and one inbound, each from
the perspective of eeschema and pcbnew.  These could represent "my understanding, what I
am playing with, my deck of cards."  When they change, or when a new program module gets
loaded, such as a late term arrival eeschema.kiface, then it sends out a "hey, this is my
deck of cards" kiway-express message.

Otherwise the kiway-express message might be similar, but point to a smaller portion of
the outbound data structure.  Of course the outbound data structure is not actually
outbound, it is write only for one kiway player, and read-only for the other.  The
kiway-express message merely brings attention to the change in the outbound one.


Dick