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