Re: gEDA-user: Soft and Hard symbols

[Peter Clifton <pcjc2@xxxxxxxxx>]

On Tue, 2011-01-18 at 16:05 +0900, John Doty wrote:

> If I was thin skinned, I would be insulted by the above.

I'm glad you weren't insulted, as that wasn't what I intended.

[Lots of snips below]

> As a developer of gnetlist back ends, I am frustrated by the way the
> core code hides critical information. 

Yes, it does that.. we should change that where possible.

> Bas Gjeltes and I developed a partial fix...[snip]

I'd rather not get into that as I wasn't involved with the changes - and
was only peripherally aware of them.

> At the same time, the API available to a gnetlist back end can often
> make export to printed circuit layout a breeze. This tells me that the
> existing API is good, but it should be helpers atop the lower level,
> not primitive.

Probably true.

> Note that there's a bit of terminology confusion. gschem actually
> manipulates segments of nets (other tools sometimes call these
> "wires"), while "net" in EE theory is usually a topological whole,
> where the connection is assumed to be structureless.

wires is a useful distinction here, although it sounds like it implies
something physical. I'll try to call them "net segments" from now on.

Sometimes a gnetlist backend might wish to request the connectivity of a
net (the topological whole). IMO libgeda should be able to provide that.
(A library or convenience function if you will).

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

> Mere topological connectivity can't express the (very common) need for
> certain wires within a net to be short, others to be thick, others to
> match the length of a different wire, single-point grounds, etc.

I'm following your example to only talk about a PCB flow here ;), as it
most closely fits your example. I presume simulation here would treat
this kind of net as 0-ohms, and there would be other attributes if you
wanted to extract the net-segments as a components and model them as
non-ideal.

That would be a decent thing to add. It could feed a DRC in whatever
layout tool you use, such as max length, or ensuring tracks can cope
with a specified current.

What I find more difficult to imagine is how the user demarcates which
netsegments map into connections which have a given property. We could
turn off auto-merge nets, but still - it needs to be clear on the
schematic what is going on.

I'm very tempted to suggest that a given "net" should have the same
property thought unless it is interrupted by some kind of junction - be
it an explicit "junction" node (perhaps your star ground point), or a
pin, or whatever.

It is quite a hard thing to visualise how this should all look in the
schematic / user interface. Perhaps an attribute "net.preserve-topology"
or something like springs to mind.

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

Terminology muddle again I think.

I would have said "topological model" conveys the shape of the
net-segments into the backend. I would have said gEDA currently only
supports a "connectivity model". Or rather, _gnetlist_ (internals) turn
libgeda's "not-very-much-model-at-all" into a flat "connectivity-model".

libgeda can currently tell you what a single object node (pin, net end
etc..) is connected to. It doesn't go further. In that sense, it could
be used to derive either a "topological model" or a "connectivity
model", but it isn't exactly being as helpful as it might be.

I would like to get libgeda able to give output in terms of a fully
processed connectivity (using either 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.

> You mean a graph of wire and pin connectivity corresponding to a given
> net? That's more primitive than a list of pins associated
> topologically with a net. But it still wouldn't let someone write a
> plug-in for bus connectivity, for example.

Why not?

The net-segments / bus-segments which trace out the connectivity of the
bus still have a topology and connectivity. If the netlist backend can
query that connectivity / topology, they can do what they like with it.

What is impossible without teaching libgeda semantics (something I
presume you're not generally in favour of), is cross-probing within
gschem which relies on the netlist backend's "insight" into what it ends
up doing with the topology and connectivity.

I have in the past said though.. that I would like (or consider) moving
some of the special semantics out of individual netlist backends, into
"libgeda plugins" which could get loaded during schematic entry as well
as for gnetlist runs.

That is the only compromise I can see which has the ability to get the
edit-time features people (rightly) want, without compromising gEDA's
flow agnosticism.

The only pre-requisite is some kind of project concept to define which
plugins to load for a particular schematic. Some semantics might require
oversight of the whole project in order to construct the proper
connectivity for probing though.


> You're confusing topology with geometry.

You could well be correct there.

> A bunch of wires connected together without loops are topologically
> just a lump of metal.

I was abusing / misunderstanding the term to include details of the
branching / structure. To me geometry included to much X,Y coordinate
detail, and topology was the step down. A quick Wikipedia search reminds
me I'm not a mathematician, and "topology" is a confusing subject ;)

e.g. Take a schematic, make a graph of nets-segments, where the end of
each net-segment forms a node on the graph, and each net-segment forms
an edge.

I was calling the result a "topology", but in fact, I would probably
better just calling it a connectivity graph or something like that.

>  But gschem can schematically represent geometry. And I'd like to do
> that. Indeed, when I draw a "net" whose segments have geometric
> constraints, I try to imitate those constraints, and put in a note to
> the layout person about this. But it would be nice to be able to pass
> this information to downstream programs as well as people.

If you have a non-trivial example schematic you could send, that would
help me visualise how it looks. I was imagining it would make everything
very cluttered on the page.

> I know I'm not the only user who'd like to do this. The fact that you
> flirt with dismissing it is exactly the kind of behavior that worries
> me. It's outside your horizon, so it doesn't matter to you.

When I think about it - I probably use it myself, when I draw power
supply circuits with an explicit separate ground and sense track for
4-terminal sensing of a low-ohms resistor.

What I was questioning - is whether one could go as far as to extract
useful machine-readable structure from arbitrary schematics. You've sold
me on the answer being "yes" (at least in cases where the user has meant
to do it explicitly).

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

> But now you've just transformed the representation in gschem to
> something that's almost as complicated, but probably lost information
> in the process. Probably still can't support a bus plug-in, for
> example. If you haven't lost information, the representation is *more*
> complicated than the schematic file itself. But implement this as
> helper functions, and now back end writers like me will use them or
> not, as appropriate.

Got it.. "implement this as helper functions". I don't think the
representation has lost any detail though. Granted, it might be a little
more complex to describe, but it is neat.

All I've notionally done is to look for some level at which things can
be treated as "connectivity" without regard for topology. It actually
maps pretty directly to what libgeda already gives you. Connectivity at
a point in space, and net-segments become like components the back-end
must deal with.

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

> That's the attitude that worries me. The toolkit's horizons are wider
> than yours (or mine). When you're confident that you've identified all
> use cases, you're probably wrong.

At some point, you reach a level where you can express all the
information on the schematic and represent any problem you wish. I was
inviting you to find a counter-example which found deficiency in the
representation, not assume I was wrong.

> > 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).
> 
> I'm currently running Peter B's branch for most of my work. Can't do
> too many experiments at once ;-)

I wouldn't suggest running my gschem branches.. they still contain some
bugs, and provide no real benefit. (Unless you fancy copy+pasting
graphics as SVG images into Inkscape).

> With three dozen export paths currently, and many more possible, I
> think universal semantics beyond those implied by the .sch format
> itself are impossible, and their pursuit is destructive. However, a
> common set of conventions is a good thing, and helper functions
> propagating those conventions to common flows are essential.

I'll be happy with that, but only if some of the flow-specific back-ends
which provide semantic meaning to these conventions can be loaded in
libgeda and operate to help the user during schematic entry as well as
at netlist time.


> There's not much redundancy in the .sch file format. I thought it was
> orderless, but Peter B. showed me the error of my ways. Almost any
> data reduction applied to it therefore loses information. Don't be
> confident that you can judge what's acceptable to lose for all cases.

It is probable that g_netlist_ backends would not care about X,Y
coordinates of individual items, or purely graphical elements. libgeda
still exposes everything - but probably not with a scheme API.

> OK, I'll make you a deal. Show real awareness of the breadth of gEDA's
> application space, and I can give you the benefit of the doubt. But
> remember that I've been burned by a change in attribute promotion
> policy that was arguably good for small scale projects using light
> symbols, but certainly bad for big projects using heavy symbols.
> Apparently, whoever put that in didn't really understand the
> consequences. Convince me that the developers' commitment to
> maintaining and extending the flexibility of the toolkit isn't just
> lip service, but is backed by genuine understanding of gEDA's unusual
> flexibility and where it takes those who exploit it (Oliver is a
> prominent recent example).

Sounds fair enough.

> Please remember that it is equally possible for you to be surprised by
> the damage you can cause.

True -- but mistakes can be reverted. We just need to spot them when
they occur.

Best wishes,

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