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

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




The "^spice directive" feature was something I had asked Bill
To put in. For the very reason you mentioned...I found it
Painful that the spice-directive symbol could only handle single
Lines. If that symbol could handle multi-line, it's the better
Way to go.


/sri

-----Original Message-----
From: owner-geda-user@seul.org [mailto:owner-geda-user@seul.org] On
Behalf Of Stuart Brorson
Sent: Monday, November 17, 2003 1:01 PM
To: Bill Cox
Cc: geda-user@geda.seul.org
Subject: 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