Bill Gatliff wrote: > * a schematic "symbol" represents some or all of a "component" > * a "component" might satisfy the functionality indicated by more than > one symbol > * a "component" comes in one or more "footprints" > * "footprints" are used by more than one component > * schematic hierarchy symbols are just collections of "symbols" >
More brainstorming. Looking at things from a different direction, a component "provides" one or more symbols depending on the component. Some of those symbols might meet a "requirement" described in a schematic diagram, in which case you can check both symbols off. Making a component selection means that _all_ the symbols come into your design, however, and if you forgot to deal with the power pins then they'll look like symbols with floating pins if you represent them in a schematic diagram. A symbol is just a graphical entity, and each one that appears in a schematic diagram defines a requirement that must be satisfied by a component. A symbol: two-input-nand.symbol: "symbol=two-input-nand" "input=A" "input=B" "output=C" (verbage to describe what the symbol looks like on the screen) A component supplies symbol instances to a design described by a schematic. They also have to provide enough information to associate the symbol's "pins" to pins on a footprint. Each time you specify a component, ALL of the component's symbols become a part of the machine-generated version of your schematic diagram: sn74x2x00.component: "component=sn74lvc2g00" "component=sn74lv2g00" "component=sn74act2g00" "symbol1=two-input-nand A:A1 B:B1 C:C1" "symbol2=two-input-nand A:A2 B:B2 C:C2" "symbol3=two-input-nand-power V:VCC G:GND" "footprint=soic8 A1:1 B1:2 C1:3 A2:4 B2:5 C2:6 VCC:7 GND:8" "footprint=dip8 A1:1 B1:2 C1:3 A2:4 B2:5 C2:6 VCC:8 GND:7" # swap VCC and GND pins, just for fun A "footprint" describes the physical layout of a footprint, along with information to map virtual component pins to physical pin locations: soic8.footprint: "footprint=soic8" (text that describes the physical footprint itself, and enumerates each pin) A schematic diagram would be just line after line of something like this: symbol=two-input-nand id=EA89-ab32-ifj2-ee89 # machine-generated, unique (uuid?) x=1 y=2 (other stuff to describe wires, etc.) symbol=two-input-nand id=2aef-789j-ie87-po73 x=100 y=200 (...) Now things get tricky. We want to tell the tool what chips we're going to use, and in some cases which "slot" of the component is utilized by a corresponding symbol. Ultimately, you'd produce a file that looks like this: component=sn74lcv2g00 refdes=U1 footprint=soic8 id.1=EA89-ab32-ifj2-ee89 id.2=2aef-789j-ie87-po73 The above says: * We have a sn74lvc2g00 with reference designator U1 and footprint "soic8" * U1's symbol1 is taken by the schematic symbol with id=2 * U1's symbol2 is taken by the schematic symbol with id=1 * Nobody took U1's symbol3 (now that they know the chip, they need to wire up the power) You'd feed your schematic file, component files and component list file to a tool that would correlate schematic symbols with component symbols, making sure that the tally for each was the same. If the two didn't balance, it would kick out a meta-schematic file with the unused symbols and then complain. Now you go wire up your power pins. Once the symbols and components balanced, a tool could take the above files and produce the same information that comes out of gsch2pcb today, methinks. In the above, I'm not proposing that we change the syntax of any of the existing gaf files. I'm just trying to describe the information itself. b.g. -- Bill Gatliff b...@billgatliff.com _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user