On Sun, Jan 23, 2011 at 6:30 PM, John Doty <[email protected]> wrote: > > 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. >
We would also need a way to force the chosen name of the net to choose when merging nets. e.g. When you merge a net named power with a net named 3v3_power, who wins? Steve > 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 > _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
