[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
gEDA-user: Comments after successfully running gnetman . . . .
- To: bill@viasic.com (Bill Cox)
- Subject: gEDA-user: Comments after successfully running gnetman . . . .
- From: sdb@cloud9.net (Stuart Brorson)
- Date: Mon, 17 Nov 2003 16:00:59 -0500 (EST)
- Cc: geda-user@geda.seul.org
- Delivered-to: archiver@seul.org
- Delivered-to: geda-user-outgoing@seul.org
- Delivered-to: geda-user@moria.seul.org
- Delivery-date: Mon, 17 Nov 2003 16:01:24 -0500
- In-reply-to: <no.id> from "Bill Cox" at Nov 17, 2003 01:48:10 PM
- Reply-to: geda-user@seul.org
- Sender: owner-geda-user@seul.org
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