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

[John Doty <jpd@xxxxxxxxx>]

On Nov 18, 2009, at 1:53 PM, Peter Clifton wrote:

> 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.

One defines a machine by its properties.

>
> 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.

Intent doesn't matter here. The U309 is intended as a UHF amplifier,  
but for the Chandra measurement chains I used it as a switch. What  
not use a device intended as a switch? Because the U309 had better  
specs for this particular case.

>
> 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.

Intent doesn't matter here. A clean design performs a simple, clean  
function. Intent is provided by the user.

>
> As an implementation detail of the current mechanism - yes, it is
> possible to use it for that - but it is "abuse".

Is using the J309 as a switch "abuse"? I call it good engineering if  
it works better than the alternatives.

>
>
>> 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.

True. And that's a reason *I* wouldn't do it that way. But it may  
work just fine in DJ's flow. Maybe he has another way to check.

>
> 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.

Some flows are incompatible with other flows. That's a reason why the  
core tools should be agnostic about "intent".

>
> The knowledge that the feature won't be safe for some symbols may stop
> the feature being implemented - then we loose market share.

Is market share what we want? I just want a high productivity tool.

> 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".

No symbol can be universal across all flows. Symbols are necessarily  
customized to the flow. Now, if we had superlight symbols and  
postprocessing to encumber their instances, those could be universal.

>
>
> 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.

And you can define the requirements for such a flow, provide scripts  
to utilize and enforce the limits, and provide symbol libraries in  
support. Many may find this to be what they want. But apparently it's  
not what DJ wants, so don't inflict it on him.

>
>
> 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).

I have no intention of that. But that is an *orthogonal* function,  
optionally applied. DJ might want a function that gives him the  
option to swap gates between dual and single parts. How are you going  
to allow him that freedom. And I'd prefer to draw a gate and have  
downstream tools define logic family, packaging, gate-swaps, pin- 
swaps, etc.

>
> We need generic (but explicitly defined) attributes to handle the
> back-annotation and display of altered data (without policy). That is
> not "slot="

I consider "back annotation" evil, the equivalent of having your  
linker edit your source code. But the ability to annotate a derived  
schematic (not a source schematic) is good. And others prefer back  
annotation. So the machinery should provide annotation without  
forcing the role of the derived schematic.

>
> 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.

We need explicitly defined attributes for *SPECIFIC FLOWS*. w= isn't  
going to mean anything for a pcb flow, but the SPICE netlisters know  
what to do with it (and they can't handle slot=).

>
>
> gschem is precious more than a drawing application at present.

Hurray! Orthogonal design!

> 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.

Hurray!

>
> 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.

What functionality is it that libgeda/gschem/gnetlist fail to expose  
that you would need to implement these as a "personality" in Guile?  
The most brilliant part of gEDA is the ease of writing gnetlist back  
ends, and all of the back end flows that are thereby supported.

Remember that a hobbyist flow, a VLSI flow, and an aerospace flow are  
very different. The core should be clean and simple, with  
specialization provided by scripting. The way we so successfully do  
it on the back end of gnetlist (but the front end needs work there).

>
> 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.


A powerful component of an electronic design *automation* process.  
Not the usual fritterware tool that forces you to tell it what to do,  
repeatedly, by manual operation. Do graphics with GUI, do flow with  
scripts. High productivity rather than cute a marketable.

John Doty              Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd@xxxxxxxxx




_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user