[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: gEDA-user: How to deal with single/dual parts?



On Wed, 2009-11-18 at 18:57 +0100, Stephan Boettcher wrote:
> Peter Clifton <pcjc2@xxxxxxxxx> 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
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user