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/
[email protected]
_______________________________________________
geda-user mailing list
[email protected]
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
