[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

gEDA-user: Comments after successfully running gnetman . . . .



Hi Bill,

I have gotten gnetman now running on my machine.  My last hurdle to
overcome involved updating my ${HOME}/.gEDA/gnetmanrc to:

(reset-component-library)
(reset-source-library)
(component-library "/home/sources/gnetman/sym")
(source-library "/home/sources/gnetman/sch")
(component-library "/home/sources/gnetman/test")

In other words, I should have RTFM and placed the "source-library"
pointer into the RC file.

As far as gnetman goes,  I think I get it.  The top level schematic
holds a bunch of symbols (naturally).  When gnetman creates the SPICE
netlist, it spits out a SPICE card for each symbol it finds.
Additionally, if the symbol itself has an attached "source=foo.sch"
attribute, then gnetman finds the file foo.sch, netlists it, and
sticks the netlist into the top level netlist as a .SUBCKT.   I
presume that this procedure is recursive, right?

So, the general principle is that if gnetman finds a "source"
attribute in a .sym file, it will treat the associated source file as
the underlaying hierarchical block.  Am I right?

Some comments:

*  First off, putting gnetmanrc into the ${HOME}/.gEDA/gnetmanrc
directory is a good thing.  If I am not mistaken, no other prog in
gEDA does this.  Both gnetlist and gschem just look for RC files in
the global location, and then in the local working directory.  

I think that having a ${HOME}/.gEDA/ directory with RC files is a good 
thing 'cause it allows individual users to have their own custom
setups which apply to all their projects, but not to other users.
This becomes important if/when gEDA is used in a larger environment by
many engineers sharing e.g. an NFS file system (i.e. in a commercial
design shop).

Perhaps we should incorporate into future releases of gEDA the
following search path: ${GEDA_HOME}/share/gEDA -> ${HOME}/.gEDA ->
local directory. 


*  It would be nice if the "source" attribute showed up in the
symbol's list of attributes when you double click on it at the
schematic level.  Indeed, I can imagine that you might sometimes want
to attach a different "source" attribute when editing the schematic.

As gschem currently works, the "source" attribute is a "schematic
only" attribute.  However, you are attaching it to the symbol.  As I
see it, "source" should be a "symbol and schematic" attribute.  I have
snooped around gschem to see how to enable this, but haven't figured
out how to do this yet. 


*  It would be nice if gschem offered you the possibility of editing
either the symbol *or* the underlying schematic.  For example, in
Viewdraw if you right click on a symbol you have the option to either
"edit symbol" or "edit underlying schematic".  Gschem should behave
the same way.

I know this is not your probem, Bill, but rather a change to gschem.
Indeed, I have long wished for this, but since hierarchy wasn't really
up to snuff in gschem, felt that it wasn't completely necessary.  Now,
however, this is a different story.


*  You are entering SPICE directives onto the schematic as a text
annotation like:

^.trans 0.1n 2n

This kind of violates the idea that you place components into your
schematic to instantiate a SPICE card in your netlist.  It is also a
little dangerous, because the netlister then incorporates text into
the netlist, and text should only be annotations.  (OK, it's not that
dangerous, but you get my point:  Text should be comments, and not
cause anything to be netlisted.)  I recommend using the spice-directive
symbol instead:

spice-directive-1.sym

It lives in the spice directory of the component library.

I suppose that the spice-directive symbol could use some upgrading so
that you can type in multi-line text.  This is another one of my
wishes:  when you double click on e.g. the spice-directive component,
gschem opens up a text entry box where you can type in lots of text,
not just one line.  This, however, is a big project. . . . .


I have cc'ed geda-user on this e-mail in case my comments are of
interest to anybody else.  Meanwhile, I will continue to play with
gnetman. Thanks for the contribution! 

Stuart