Re: gEDA-user: Soft and Hard symbols

[Peter Clifton <pcjc2@xxxxxxxxx>]

Hi John,

Constructive comments below, but first I thought I'd get this out of the
way..

From my point of view, you often seem to treat people here with a less
respect than they deserve. I get the impression you think of the gEDA
developers as being ignorant, blinkered, or incapable directing the
future design and architecture of the suite. You also persist in
repeating the same design choices you have chosen to make as the panacea
for everyone else's work.

I really hope this can stop. Your input has proved valuable on many
occasions, and it would be useful for us to gain from your insight
rather than develop the predilection to dismiss your emails as "yet
another rant from JPD". I already find myself having to skip them over
for later reading, as they often disrupt a thread's natural flow.

Your humorous email sign off suggests that you are aware of the problem,
but not willing to adjust the courtesy of your replies. We are smart
enough to understand a well reasoned design trade-off, and would likely
respond better to that than yet another proclamation of why what we have
suggested is wrong, or inadequate.

I'll humour you with a reply below..


On Mon, 2011-01-17 at 05:31 +0900, John Doty wrote:
> On Jan 15, 2011, at 1:42 AM, Peter Clifton wrote:
> 
> > I want to see all connectivity code move into libgeda, and
> > flattening be optional.
> 
> Connectivity is precisely the kind of thing that should not be in
> libgeda.

I (and all other gEDA developers I've talked to) disagree.

> The connectivity model depends on the application of the schematic.

Not really, it just depends on whether we are talking about the same
thing. I suspect not. I was not thinking of of assigning the
"data-type" (for want of a better word) of nets, width, whatever.

gschem can front schematic entry for various flow based or signal based
topological connectivities, where nets might report block
interconnections, mathematical relations, pipe-work, whatever. In all
these cases, the useful output from libgeda / gschem is the topology /
connectivity of the instantiated modules / symbols.

The model I was assuming was that the exact topology of "nets" in gschem
is unimportant. It is a common model, but my proposal of handling
connectivity in libgeda doesn't _require_ that assumption if it is
unwanted.

> Right now, gEDA basically only supports a topological model. This
> prevents it from expressing most geometric properties of the
> connections: parasitic inductances and resistances, high current net
> segments, single point grounds, etc. A related limitation that some
> wish to relieve is the fact that busses are mere graphical decoration.

One could still wish to query libgeda for a connectivity list or graph
for a given design.

IMO, it is silly to pretend that nets should be treated as components
with parasitic inductance or resistance. For that to be meaningful, one
would have to match the topology of one's schematic to the physical
layout they wished to simulate.

Even with that said, the idea warms to me slightly - and I still cannot
see how "connectivity" in libgeda conflicts with your suggestion.
Granted, each junction node would have to be treated explicitly in the
graph.. and nets themselves would have to become component entities in
the list, rather than flattened - but it is still completely possible.

In effect, you look on a view where a "net" in gschem becomes a two
ported component with properties, a peer to other symbols representing
components such as "resistor", "n-mos FET", etc. _Connectivity_ still
exists, and libgeda could usefully contain routines to extract that.

> There cannot be a single correct way to address these issues because
> the appropriate connectivity model depends on the capabilities of
> other tools in the flow, not just gschem/gnetlist, as well as the
> needs of the project.

I don't see anything which can't be handled as above.

> There are other places where the core code implements semantics that
> are useful in common cases but not universal.

Gah, yes - The best example I can think of is that I'd love to get rid
of slotting from the core. (Along with all the pinseq nastiness).

I've taken steps to put that code at arms length from the rest of
libgeda and gschem, so it is not so interwoven with the rest of the
suite. I assume you won't have noticed that though, especially because
the majority of the changes are in my repo.or.cz branches (it has other
issues needing fixing before it can merge).

> Consider for a moment a dual opamp.... [snip]

I'm familiar with the problem.

> Now consider hierarchy... [snip]

I'm familiar with the problem.

> It would be very useful to have better standards for the intended
> meaning of the various attributes, but that won't help the problem of
> writing universal code to interpret them. The translation to pcb,
> SPICE, BOM, etc. will remain target and project dependent. Helper
> functions for common cases are very desirable, but they must not be
> "wired-in" to the core code. Better standards could lead to better
> helpers, though. A similar situation exists with busses, where we'd
> like to make the graphics meaningful, but still face the problem of
> implementing that meaning downstream using a variety of tools in a
> variety of flows.

I think we agree here. (80% at least)

> The common theme is that the core code in libgeda, gschem, and
> gnetlist implements semantics that one might think are universal, but
> in fact differ among different flows.

At some point, we must define what is our universal set of semantics. I
expect it will be far smaller than most packages, but there is no point
in letting the suite die a death just because "we" are unable to commit
to some design decisions.

If you want a really small set of semantics, you might try "ms-paint"
for drawing schematics. It doesn't even constrain you to straight lines,
and boring colours. gnetlist doesn't handle .bmp import though, sorry.

That was unfair though. (Yes... I do grumpy sarcasm from time to time).

>  The existing semantics are excellent for creating designs that are
> exportable to a wide variety of printed circuit layout back ends. They
> are also good for simulation schematics, ASIC schematics, and symbolic
> circuit analysis (but nonportably: these schematics must be
> constructed specifically for the downstream tool). This is a
> spectacular achievement, but these same semantics block expansion of
> capability and extension of portability of schematics because they are
> "wired-in", difficult to bypass when they aren't appropriate.

You forgot one. Schematics for the sake of beautiful printed schematics
- as documentation. Schematic (or strictly, PS or PDF export of it) is
the output, not a netlist ;)

> Stephan's diagnosis and suggested treatment in
> http://www.seul.org/pipermail/geda-user/2010-December/051273.html

Yes, that was good. It is a principle I try to follow when writing code,
and is the direction I'm slowly going in with PCB's rendering code.

It is also what naturally falls out from the connectivity code I
suggested for libgeda, but to be fair - most of the design details are
still in my head - so you could be forgiven for not reading my mind on
those.

Overall, if you take one thing from this email John, it is that giving
us the benefit of the doubt would be nice. You might be worried every
time we suggest some change - but if you were to have a little faith,
you might be pleasantly surprised at the quality of results which we can
achieve.

-- 
Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA

Tel: +44 (0)7729 980173 - (No signal in the lab!)
Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me)



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