On Jan 15, 2011, at 1:42 AM, Peter Clifton wrote: > I want to see all connectivity code move into libgeda, and > flattening be optional.
Connectivity is precisely the kind of thing that should not be in libgeda. The connectivity model depends on the application of the schematic. Right now, gEDA basically only supports a topological model. This prevents it from expressing most geometric properties of the connections: parasitic inductances and resistances, high current net segments, single point grounds, etc. A related limitation that some wish to relieve is the fact that busses are mere graphical decoration. There cannot be a single correct way to address these issues because the appropriate connectivity model depends on the capabilities of other tools in the flow, not just gschem/gnetlist, as well as the needs of the project. There are other places where the core code implements semantics that are useful in common cases but not universal. Consider for a moment a dual opamp. Manufacturers' SPICE models for these are conventionally coded for a single device. Therefore, if you're going to simulate with SPICE, it makes sense to use a slotted symbol, but treat the slots as separate devices. On the other hand, in printed circuit layout it's a single device. The semantics of slotting therefore differ beween flows. The tools must not assume either semantic model is universally correct. The fact that the semantics here are in the libgeda core is a barrier to making schematics that can be input to both simulation and layout. Now consider hierarchy. Some circuit representations (like pcb) are flat, others (like SPICE) are hierarchical. Right now, we use incompatable circuit descriptions to express these: we cannot create a pcb netlist from hierarchical SPICE schematics. The problem goes beyond simply turning flattening on and off. It would be very useful to have better standards for the intended meaning of the various attributes, but that won't help the problem of writing universal code to interpret them. The translation to pcb, SPICE, BOM, etc. will remain target and project dependent. Helper functions for common cases are very desirable, but they must not be "wired-in" to the core code. Better standards could lead to better helpers, though. A similar situation exists with busses, where we'd like to make the graphics meaningful, but still face the problem of implementing that meaning downstream using a variety of tools in a variety of flows. The common theme is that the core code in libgeda, gschem, and gnetlist implements semantics that one might think are universal, but in fact differ among different flows. The existing semantics are excellent for creating designs that are exportable to a wide variety of printed circuit layout back ends. They are also good for simulation schematics, ASIC schematics, and symbolic circuit analysis (but nonportably: these schematics must be constructed specifically for the downstream tool). This is a spectacular achievement, but these same semantics block expansion of capability and extension of portability of schematics because they are "wired-in", difficult to bypass when they aren't appropriate. Stephan's diagnosis and suggested treatment in http://www.seul.org/pipermail/geda-user/2010-December/051273.html are spot-on. The API functions that deliver the results of connectivity, slotting, hierarchy expansion, etc. are not sensibly primitive: they are "library functions" to be called when appropriate and ignored when not. The real primitives are at a lower level. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
