On Dec 20, 2007, at 10:49 AM, John Griessen wrote: > John Doty wrote: >> On Dec 20, 2007, at 7:07 AM, Steve Meier wrote: > >>> I have expressed concerns that the data isn't flat and thus isn't >>> suitable for flat files. >> >> The maps within a relational database *are* flat, and may be >> expressed as flat files. I have seen such an implementation. So, I >> think this is a false dichotomy. > > Flat files might be bad to try and use on a chip design, > or large board, but then you could choose not to write them. > I think the flat files can be a path to results, then be made > optional when a good working database is hooked in, and giving > results. > > Trying to make the database optional even after developing its use > sounds hard. Is there opposition to a database? No database ever > would > be limiting...
Show me how it's used. Here's the flow I envision: 1. In gschem, I choose a component graphic from the library. It gets automagically copied into my project symbol pool, with a name of my choosing. So let's suppose I grab a resistor-1 and name it LVDS- term.sym. Why is this better than embedding? Because I get exactly one private copy. Not one per instance or one per page, but one per project. This means that Hs and edits actually do the right thing: they make project-wide changes. 2. Now I place one, do Hs, put in part=LVDS-term (or maybe the copy already gave me that default), add in footprint=0603 and value=100. Those will do for now. 3. The symbol browser should give me a shortcut to my project symbol pool, so I can add more terminators as needed. 4. Maybe I have separate project symbols for other kinds of resistors, or maybe I just override the attributes at schematic level. In one design I did with Viewlogic this way, every nonpolar cap used the bypass_cap symbol, but the minority that weren't bypass caps had their attributes overridden at schematic level. Okay, now I've entered the schematic: the project moves to BOM management. What I want here is a "parts" file with the following characteristics: Easily editable as text, including things like global search and replace. Readable by a human being. No graphical parameters. Keyed by the "part" attribute. Definitive: anything here overrides the schematic. So suppose we've decided to use 0402 parts for LVDS termination. The LVDS-term entry in the parts file gets footprint=0402, overriding the symbol and schematics. Note that I might switch parts files during the project: the prototype might use one, the flight model another, completely different. I suppose this likely to happen in mass production also (quick parts versus cheap parts). A schematic page copied from one project to another might use a different parts file, but be electrically the same. gschem and gnetlist would look in here for attributes. Think of this as a "source file" for the BOM. Now, I have absolutely no problem with a database tool for filling in the blanks and updating this file. I don't, however, see how that should work, or where the data will come from, and I doubt we'll have such a thing soon. So, the ability to manage attributes as text separate from graphics should not be hostage to the database idea. > > John Griessen > > > -- > Ecosensory Austin TX > > > _______________________________________________ > geda-user mailing list > geda-user@moria.seul.org > http://www.seul.org/cgi-bin/mailman/listinfo/geda-user John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ [EMAIL PROTECTED] _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user