[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: gEDA-user: Solving the light/heavy symbol problem

On May 24, 2011, at 2:29 PM, DJ Delorie wrote:

>> I'd like to note that we have a serious power tool in gnetlist,
> Yup.  I had hoped to move some of the "heavyifying" data into a
> database or the layout (or whatever), and have gnetlist gather all the
> attribute data from the schematic, the database, and the layout.  It
> can then combine the data in order to update the layout.
> For example, to do pin swapping - you could set the pin numbers in the
> schematic, or leave them unspecified.  If unspecified, gnetlist would
> see unassigned pins and allocate them based on some pin map database,
> then give that to the layout.  On the next iteration, the pin numbers
> would be provided by the layout so gnetlist would know not to change
> them.  Either way, gnetlist gathers the pin information from wherever
> it is available, and doles it out to whoever needs it.

Pin numbers are a bit harder than most other attributes in the present state of gnetlist, because the front end employs pin numbers internally to track pin identity. The only package attribute that's like that is refdes, and the code I posted can't cope with changing those either. And while you're swapping pins, you'll probably want to swap slots, and those are even tougher to deal with in the back end, especially if the slots you want to swap are in separate packages. So, these things probably require refactoring of gnetlist, to put more of the data within reach of a plug-in.

> On a simpler scale, I expected gnetlist to read my "partdb" that maps
> light symbols and design rules to heavy symbols.  At least, for those
> attributes not already specified in the schematic.  No need to have
> hundreds of symbols, when you could have hundreds of rows in a
> database instead.

Yes. That's why I mentioned a "parser". And, of course, there's no reason that the rules need to come from a single place, using a uniform format. S-expressions are only the most convenient way to get started here.

> Thus, schematics need only concern themselves with schematics - the
> symbolic connections of the design.  Design-specific component
> attributes would be managed by gnetlist and gattrib.  Physical layout,
> simulation, or other "final" target information would be managed by
> their respective tools.
> But yes, this means gnetlist would have to take on much more
> responsibility for managing the project.
> With your workflow, for example, your "heavy" symbols might be "heavy"
> only by having a manufacturer's part number in them, or some keyword
> that says that it "is" ("purpose=bypass-cap" for example), with all
> the other information added by gnetlist.

I do believe we are in agreement.

John Doty              Noqsi Aerospace, Ltd.

geda-user mailing list