On Wed, 2009-11-18 at 14:31 -0600, Bill Gatliff wrote: > Steven Michalske 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" You're clearly thinking of PCB layout _____^ > * "footprints" are used by more than one component > * schematic hierarchy symbols are just collections of "symbols" Think at the netlist / design hierarchy level, with arbitrary technology, the possibilities of the tool-kit really open up then. See this old diagram Peter B and I drew: http://geda.seul.org/wiki/geda:data_structure_design_discussion?s=data% 20structure The diagram is somewhat conceptually different from gEDA, especially in the fact that it treats attributes as a primitive entity belonging to a circuit, circuit instance, net or Mport - gEDA just requires you to place some text define the attribute and its contents. In gEDA, they notionally belong to a symbol instance, net, or pin. The core of the diagram (blue and yellow) would apply as a hierarchical design / netlist representation _without_ the need for any schematic. That was its real purpose - defining the logic required in a hierarchical netlist representation. I would call any non-graphical entity a "circuit" with "Mports" (a gnetman term). Symbols either represent sub-circuits defined logically by more schematics, or instantiations of physical devices, VHDL primitives, VHDL code, .... "Symbols" are a graphical representation of "circuits", such as to be able to connect instances of those circuits using schematics. For chips / components on a board layout, ports correspond to device pins, and the nets connecting them correspond to tracks. NB: I don't just see gEDA useful for schematics / VHDL / IC design though.. I draw all kinds of logical diagrams with it. Some make sense represented as a hierarchy. I can imagine a netlist of a "simulink" type digram being used to define a system for simulation - where "nets" represent abstract signals, rather than electrical connectivity. > Man, the scripts to make all the above work just sound like a > connect-the-dots type of exercise. But the computer scientist that > isn't in me just isn't jumping up and down going "oooh, I know! I > know!!" just yet. :) > > The good news is, perhaps, that implementing a workflow based on the > above should be possible with the current gaf tools. It's really just > an exercise in not using functionality in the existing tools that are > trying to implement certain cases of the above already. > > Does any of this sound familiar to anyone? Solved problem anywhere we > can look to for inspiration? > > > b.g. > _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
