On Wed, 2009-11-18 at 18:57 +0100, Stephan Boettcher wrote: > Peter Clifton <[email protected]> writes:
> > It is a perfect example of why gEDA can never grow more "friendly" > > interfaces to these problems. _Because_ the existing interface can be > > abused - and people think it is a good idea to encourage such > > "flexibility", we end up with designs out there relying on the > > behaviour. > > I'd not call that abuse. The current sloting mechanism allows to change > pin numpers on a drawn component to switch to a different instance of the > component inside the same package. http://www.geda.seul.org/wiki/geda:master_attributes_list#numslots What we're lacking is a definition of what constitutes a slot. I contend that the intended meaning for a 4-NAND gate chip, is that there are 4 slots. Not however many permutations of gate/pin swapping, or whatever else you want to do. I hold that a "slot" is related to a multiplicity of identical units within the chip, and the slotting mechanism was _not_ intended as an arbitrary way of fudging different combinations of pin-numbers into the netlist in various situations. As an implementation detail of the current mechanism - yes, it is possible to use it for that - but it is "abuse". > The GUI may implement user-frienly policies how to use very flexible > mechanism in a newby-firenly way, without restricting how other UIs uses > the same mechanisms for other purposes, and without calling those other > uses "abuse". If you start trying to use it for permuting pin combinations - you can then shoot yourself in the foot by choosing combinations which conflict. How well does this interact with a (supposed) auto-renumbering feature, where the user is offered every slot of the given symbol to use (U1a, U1b, U1c. U1d), before moving on to the next "U2a".. If your symbols are misusing slot=, this breaks the feature. The knowledge that the feature won't be safe for some symbols may stop the feature being implemented - then we loose market share. We get complaints when our tool cannot automate mind numbingly simple tasks to help users be more productive. "Sorry, we can't provide that feature - some symbols use slot= to mean something different". If we state here and now - that slots have a physical interpretation on the chip, it is legal to use all the given slots on a chip etc.., THEN any behavioural addition to gEDA which wants to look at the slot= attribute, can have confidence on its meaning. Those who wish to use it as an arbitrary pin-munging mechanism need to define their own attribute for that, get it standardised - such that any add-on module knows to ignore symbols with it present. > > If you propose adding extra attributes to steer the DRC system around > > the hack, you might as well propose an expressive attribute based scheme > > for pin / gate swapping instead. > > I think I'd prefer flexible mechanism instead of multiple mechanism > doing almost the same. Fine, condemn us to the status quo - where gEDA has no ability to identify potential gate-swaps automatically, (or pass them to the layout tool to do so). We need generic (but explicitly defined) attributes to handle the back-annotation and display of altered data (without policy). That is not "slot=" We need explicitly defined attributes, with a tightly focussed specification to provide policy relating to individual issues, e.g. slotting. By keeping the meaning specific, we can develop tools which help the user do their work. gschem is precious more than a drawing application at present. It has been targeted towards electronics, so it actually makes drawing diagrams with electronics in them quite easy. That is as far as it currently goes. Any user expecting intelligence about slot handling, auto-numbering should not look to gschem to provide it if we aren't willing to provide more explicit definitions of the problem. gschem _could_ become (part of) an EDA tool - rather than just a graphics editor.. if users would just allow it to gain a bit more explicit knowledge about what the heck is going on. If not, tell the world gschem is a vector graphics package. Let me hand you the ultimate flexibility... an attribute "c-code=..." where you can type arbitrary C code, which gnetlist passes to a compiler and then executes to produce a netlist. Flexible, yes.. practical no - it also guarantees that the UI can do nothing useful with it. My battery is running low, so I'm going to send this now.. Peter. _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
