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 _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
