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

[Peter Clifton <pcjc2@xxxxxxxxx>]

On Wed, 2009-11-18 at 12:54 -0600, Bill Gatliff wrote:

> Why not change the workflow so that during schematic capture, there are
> no pin numbers anywhere?  "Pins" on symbols get assigned a physical pin
> number during some some later step, at the same time that footprints are
> selected.  And then a backwards data flow brings the pin assignments
> back to gschem for display?  Of course, I really have little idea of the
> implications of what I'm saying...  :)

I agree whole-heartedly, to the extent - that pinnumber information
should not be present until you've selected a part to use. (or slot of a
part). To achieve it though - would require some notion mapping real
parts to abstract symbols. (Bernd did some work on this idea a while
back).

It vaguely relates to my "secret" plans for how the slot feature will
get re-written _if_ I ever did so..


Basics:

Modules are loaded into libgeda as required for "special behaviours" -
as defined for the currently defined work-flow, or configured to be
used... whatever.

Those behavioural modules will have similar powers to the kind of name
munging / attribute fiddling which could be done in a current gnetlist
back-end - only more powerful, they are able to back-annotate data into
the in-memory representation of the design. "slot" handling will be one
of them.

Relevant attribute changes trigger processing by behavioural modules,
such as any change to the effective "slot, slotdef, numslots" attributes
would trigger an update by the slotting behaviour module on the relevant
component.

Action taken by the slotting module would either be (as present), to
modify the in-memory representation of the symbol instance, re-writing
its pinnumbers..

OR: to attach a "back-annotation" entry to the symbol instance.
Something CSS like, or to give an example:

(NB: Attachment to a particular symbol instance is assumed)

children[attributes.pinseq=1] {replace_attribute(pinnumber=3)}
children[attributes.pinseq=2] {replace_attribute(pinnumber=2)}
children[attributes.pinseq=3] {replace_attribute(pinnumber=1)}

Yes.. I know that example syntax is lame.. in reality, it would be some
in-memory data-structure defining a rule to find something to change -
and a rule as to how to change it.


Anyhow.. if you separated component choice as a later stage of the game,
your behavioural modules could well introduce previously non-existent
pinnumber= information into the schematic.

(Or into a new, "implementation" schematic, as John pointed out)

Just where the data came from would of course depend on the workflow /
symbol library / parts database, and any relevant behavioural modules.

Similar could also be used to annotate data from a running (or
previously ran) simulation onto the schematic.

I'm not sure whether (back)annotated data would be saved with the
schematic or not, new marked-up schematics produced - or what.

> Of course, you have to deal with making sure that the four-gate chip has
> a decoupling capacitor vs. four caps for the four-chip solution, and a
> convenient way to note that is on some power-related pages attached to
> your schematic diagram.

DRC can't tell one cap from another unfortunately - otherwise
auto-placement of the right decoupling capacitor near a chip would be
possible ;)

Perhaps some new attribute could be defined for a DRC (or auto-placer)
to infer purpose of a component..

OBJ.refdes=C1
OBJ.value=1uF
OBJ.mfr_part_no=134r5t25
OBJ.footprint=0805
OBJ.elec_drc:purpose=decoupling
OBJ.elec_drc:decouples=U1

OBJ.refdes=U1
OBJ.part_number=7401
OBJ.footprint=so14
OBJ.elec_drc:requires_local_decoupling=1



Some attributes / annotations (defined such as to enable back-annotation
of arbitrary data or attributes) can provide the mechanism for the
flexibility people want. Behavioural modules would define the policy for
attributes such as "slot=" - and their authors would be wise to keep
their specifications narrow.

Right now we're stuck in a situation where users come up with "clever"
ways to use attributes in a way they were probably never intended for
(or at best, take different interpretations of an ambiguous definition),
and they effectively end up relying on the implementation details of the
program.

We get abuse (or use in un-intended ways) - and are then are stuck with
whatever implementation details we might rightly want to fix in the
future. The narrower the specification applied, the more flexibility it
provides us to fix problems later.

If users come up with a valid reason why a particular task warrants an
extension, or increase of flexibility for a given attribute, then that
can be considered - and applied in a later version if warranted.


>   But I find that almost everyone puts those on
> their own pages, so that they don't "pollute" the rest of their
> schematic.  That suggests to me that other people view schematic
> diagrams as logical entities too, at least except for those
> power-related pages.

I know several people who abhor the idea of demoting power to its own
forgotten area in the system schematics.. since for some applications,
correct power routing is an important concept which the schematics
convey - even if the netlist output says all the power rails end up
connected together.

(Personally, I tend to put my decoupling caps right next to the symbols
with the power pins - and on the same page as the logically functional
portions of the devices).

> Because of what I view the schematic capture process as being, stuff
> like slotting and footprint= don't really fit in with my mental model of
> what schematic symbols are.  As I see it, those concepts exist only
> because we're trying trying to force part of the layout process upstream
> into schematic capture.  I don't know how to fix the problem, but I
> think that's what it is.

It can be fixed if we could figure out where the data should end up
living within the project.




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