Re: gEDA-user: wishful UI

[John Doty <jpd@xxxxxxxxx>]

On Aug 8, 2010, at 3:47 PM, kai-martin knaak wrote:

> John Doty wrote:
> 
>>> Unfortunately  we
>>> need gnetlist with guile to transfer information.
>> 
>> Gnetlist is the *key* utility in the flow.
> 
> It is just the glue between major components. No need to glorify this role.

On the contrary, there is every need to glorify this role. An engineer should understand that the interfaces are the most critical part of any system. But people foolishly take them for granted.

If you want to know the breadth of gEDA's capability, there is no better way to survey it than "man gnetlist".

> 
> 
>> That's what makes it possible
>> for gEDA to support abstract circuit analysis, simulation, VLSI design,
> 
> However, currently everything except for pcb design is only marginally 
> useful.

Oh, really? My latest VLSI designs, from schematics drawn and simulated in gEDA, are going to fly in space. gEDA is *radically* useful for all kinds of EDA.

> Simulation is still so weakly supported that it can only be 
> recommended to enthusiasts.

You mean "professionals". gEDA is a wonderful, powerful, flexible front end for simulation.

> 
> 
>> If gEDA wasn't so flexible, pcb couldn't use it for schematic capture,
>> because pcb has nothing like that flexibility.
> 
> geda and pcb coevolved.
> It is pointless to speculate what one would be without the other.

As someone whose gEDA designs have been realized in printed circuit boards from three different layout tools, I must disagree. "pcb" is in no way essential to gEDA, but "pcb" is apparently almost completely dependent on gnetlist.

> 
> 
>> Guile? An implementation of Scheme, one of the simplest, easiest to learn
>> programming languages around. A major factor in gEDA's radical
>> flexibility.
> 
> It is a major factor in gedas near stagnation during the last five years.

What stagnation? Consider the impressive list of projects at http://geda.seul.org/wiki/geda:links. At toolkit is to be judged by its products. Or do you mean that the code hasn't changed? Code stability is a sign of quality in software.

> The pool of scheme hackers among the candidate geda hackers is, well, small. 
> As appropriate as the language may be, it blocks me and others to start 
> hacking.

I have little patience with this attitude.

> In addition the internal API between the C and the scheme component 
> lacks documentation. 

True. Been working on it. Here are my notes:

gnetlist:get-packages level

Yields a list of refdes values for the set of schematics. Duplicated values are only listed once. The "level" argument must be present, but is unused.

gnetlist:get-non-unique-packages level

Yields a list of refdes values for the set of schematics. Duplicated values are listed as many times as they appear. The "level" argument must be present, but is unused.

gnetlist:get-pins refdes

Yields a list of pin numbers for the specified refdes value.

gnetlist:get-all-nets level

Yields a list of net names for the set of schematics. Duplicated values are listed as many times as they appear (once per segment?). The "level" argument must be present, but is unused.

gnetlist:get-all-unique-nets level

Yields a list of net names for the set of schematics. Duplicated values are only listed once. The "level" argument must be present, but is unused.

gnetlist:get-all-connections net

Yields a list of all connections to the named net. Each element of the list is itself a two element list of the form (refdes pinnumber).

gnetlist:get-nets refdes pin

This is apparently intended to yield the netname connected to the given pin along with all pins connected to that net, including the pin in the initial query. A little experimentation, however, shows that it does not reliably list all of the connections, possibly due to a problem with net= connections. Most (all?) existing back ends that use this appear to use only the netname.

gnetlist:get-pins-nets refdes

Yields a list of (pinnumber . netname) pairs detailing all connections for the given refdes.

gnetlist:get-package-attribute refdes attribute

Yields the value of the named attribute attached to a symbol instance with the given refdes. Yields "unknown" if the attribute is absent. It only yields one value, regardless of how many matching attributes exist in the set of schematics. If there is more than one instance only the first instance encountered is inspected, so it may yield "unknown, even if a matching attribute is present.

gnetlist:get-toplevel-attribute attribute

Yields the value of the named attribute at top level, that is, an attribute present in one of the schematics unattached to any object. Yields "not found" if no matching attribute is present.

gnetlist:get-renamed-nets level

When gnetlist expands a hierarchical subcircuit, it first assigns every net within the subcircuit a unique name based on the refdes of the subcircuit instance and, if present, the netname within the subcircuit. If a net is attached to the higher level circuit, gnetlist then changes the name of the subcircuit net to the name of the higher level net to which it is attached. "gnetlist:get-renamed-nets" returns a list of lists of pairs of names. The first name in a pair is the initial unique netname within the subcircuit, the second is the higher level netname it has acquired. The "level" argument must be present, but is unused.

gnetlist:get-attribute-by-pinseq refdes pinseq attribute

Yields the value of the named attribute attached to the pin with the named pinseq attribute to the package with the named refdes attribute.

gnetlist:get-attribute-by-pinnumber refdes pinnumber attribute

Yields the value of the named attribute attached to the pin with the named pinnumber attribute to the package with the named refdes attribute.

gnetlist:vams-get-package-attributes refdes

Yields a list of the names of attributes attached to the symbol at schematic level?

gnetlist:get-slots refdes

Yields a list of all slot attributes associated with a given refdes. Duplicated values are listed as many times as they appear.

gnetlist:get-unique-slots refdes

Yields a list of all slot attributes associated with a given refdes. Duplicated values are listed only once.

gnetlist:graphical-objs-in-net-with-attrib-get-attrib netname attrstring attribute

This searches for a graphical symbol attached to a net with the given netname. The symbol must have attrstring (of the form name=value) attached. It yields the value of the specified attribute,

gnetlist:get-calling-flags

Yields a list of lists of command line flags and values. Each flag must be known to the gnetlist front end. For example, the "--nomunge" flag will yield ("nomunge_mode" #t).

gnetlist:get-command-line

Broken or unimplemented? Yields #f.


> 
> 
>> Without the capability "gnetlist with guile" brings here, neither you nor
>> I would be using gEDA.
> 
> Nope. 
> There would be some other scheme(*) to derive netlists from schematics. 

Well, of course there is. But apparently few use xcircuit. And regardless, you wouldn't be posting to the geda-user group (pcb needs its own group: the discussion here is dominated by the problems and limitations of pcb).

> Probably a more flexible scheme that allows for back annotation, too. 

Back annotation is a throwback to pencil and paper practices. It is an impediment to design reuse and automation. Thankfully, gEDA facilitates design reuse and automation (although it could be better).

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