Re: gEDA-user: Soft and Hard symbols

[John Doty <jpd@xxxxxxxxx>]

On Jan 18, 2011, at 2:05 AM, Peter Clifton wrote:

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

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

> 
> Your humorous email sign off suggests that you are aware of the problem,
> but not willing to adjust the courtesy of your replies.

Weird. You find it humorous? It's not a joke.

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

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

Bas Gjeltes and I developed a partial fix for one of the many problems here. Patrick and Peter B. garbled it and turned it into something that doesn't actually deliver the fix to the end user. At least now I can write a plug-in that fixes it for my flows, publish on gedasymbols, but ordinary users will still trip over it.

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.

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

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

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.

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

You're confusing topology with geometry. A bunch of wires connected together without loops are topologically just a lump of metal. 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.

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

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

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

Good. We agree. But only about the paths through the minefield we both use. Let's try to clear the whole minefield, not just those paths.

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

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

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

Make all the design decisions you want, but don't implement them in a way that can obstruct progress. A function like (gnetlist:get-all-connections) is perfect in its place, but if the back end needs more info (geometry, bus connections, ...) it's out of luck. The schematic potentially contains far more information than a gnetlist back end is allowed to see, and nobody knows for sure what's relevant and irrelevant for all use cases. The obvious solution is Stephan's approach: primitives reveal all data, and interfaces like (gnetlist:get-all-connections) become helpers that reduce the data when that's what's needed.

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.

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

I'm sure I "forgot" more than one. Nobody knows all of the places gEDA has gone, or could go. That's why "hard-wired" semantics are dangerous.

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

But you keep arguing against it. In Stephan's approach, network connectivity is exactly the sort of thing that becomes a helper, to be used when it captures the connectivity model needed, and to be bypassed when the model is different.

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

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

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

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

Maybe I should just give up. lambda-geda, even in its current primitive state, can already do schematic processing that gnetlist can't. Further development could push it into gnetlist territory. If gschem becomes restricted to a smaller subset of .sch files due to "design decisions", maybe Stefan's replacement can substitute. But I'd rather be able to stick with the mainstream here. For one thing, I collaborate with Windows users, and that's a place where I really appreciate your efforts (thanks again!).

---
John Doty              Noqsi Aerospace, Ltd.

This message contains technical discussion involving difficult issues. No personal disrespect or malice is intended. If you perceive such, your perception is simply wrong. I'm a busy person, and in my business "go along to get along" causes mission failures and sometimes kills people, so I tend to be a bit blunt.



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