On Jan 24, 2011, at 5:51 AM, Kai-Martin Knaak wrote: > Stephan Boettcher wrote: > >> You need to invent some 2-pin symbol with some special attributes, and >> teach the pcb gnetlist backend(s) to interpret those attributes > ^^^ > > If there is a way to mark two net-names as physically the same net, > then each and every backend should act accordingly.
By default, yes, I agree completely. > It would be an > invitation for nasty surprises if some back-ends would support the > fusion and others don't. This calls for an interpretation by the > frontend. The problem is that each downstream tool potentially has its own model of connectivity, so the default model in gnetlist must address the "lowest common denominator" here. I think that would require that gnetlist simply merge the nets, choosing a common name. But that's probably not good enough for users of specific tools with advanced capabilities. Therefore, these semantics should not be in the front-end. They should be in the middle layer (gnetlist.scm), where a plug-in or back-end can modify the semantics as needed for the downstream tool. Putting them in the front-end will case trouble similar to that we now experience with slotting, where the front-end model doesn't fit simulation flows. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ [email protected] _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
