gEDA-user: Some minor contributions: automatic subsheet symbols

[Oliver Florian <florian@xxxxxxxxx>]

Hi,

I just finished my diploma thesis at the Technical University of Munich 
(Technische Universität München), entitled "design techniques for 
dataflow oriented processor architechtures", involving the gEDA suite.
(If you're curious about my work and would like to know more, please 
read my other post.)

In the course of this thesis I did some work that the community might 
benefit from as well:

   * automatic generation of sub sheet symbols via a gnetlist backend
   * one or two svg figures explaining the way some things work

I also volunteer for some basic documentation work:
(since some things took me quite a lot of time to figure out and I don't 
want other people to undergo the same time consuming process, no offense 
mates)

   * some text to go with the mentioned figures
   * a netlister backend creation howto, netlister frontend/backend 
interface description, or something like that; believe me, the code is 
not nearly as documentative as some of you might think, I really would 
have apreciated this)
   * and I also could describe the way I used gnetlist recursively to 
handle hierarchy.


You can get the backend here:
http://home.in.tum.de/~florian/geda/
there is also a preview of the mentioned figures (I will replace the 
german text in the figures, of course, but for now this should do).
Details on the backend follow below.

Regards,
Oliver




the sybsheet symbol backend
---------------------------
since I didn't have much to do with the gschem source code and the job 
of generating some sort of textual interpretation out of a schematic is 
gnetlist country anyway, for me it was best to solve the problem of 
creating subsheet symbols by means of a gnetlist backend.

The gnetlist backend gnet-sybsheetsymbol.scm takes a subsheet and 
generates the according subsheet symbol out of it. Obviously, hierarchy 
traversal has to be disabled, since otherwise the backend wouldn't get 
the io component.

Now, before you rejoyce be advised: this is a quite primitive solution, 
meaning that it just generates a rectangular symbol with all the input 
pins on the left, and all the output pins to the right, equidistantly 
distributed down along the side of the box. that's it, no magic here.
there is no optical fine-tuning of the symbol based on geometrical or 
logical interpretations of the schematic.
This means, gnetlist doesn't know about the position of components in 
the schematic (at least afaik), so any user defined geometrical 
arrangement inside the schematic is not considered.
Furthermore, io symbols are processed in the order the gnetlist backend 
gets them, so there is no guarantee e.g. two io symbols connected to the 
same component result in two adjacent pins. I guess the latter matter 
could be solved someday, even within this gnetlist solution.

However, I think that still this backend saves a lot of time, since 
retouching a rudimentary symbol with gschem and moving a pin is way 
faster than drawing the whole symbol, pins and attributes by hand.

usage:
gnetlist -g subsheetsymbol [options] -o subsheet.sym subsheet.sch

options:
   -O boxwidth=X
       sets the width of the box to X; default is 2300.
   -O spacing=X
       sets the vertical spacing between pins to X; default is 300.

note: X is a int value, no spaces on both sides of the equal sign allowed.

some details:
A box is drwan, depending on the pin count and the command line 
parameters (see usage above).
The symbol gets a constant "device=none" attribute.
The "refdes" attribute is created one of three ways:
 - first, from the filename by parsing the command line via 
gnetlist:get-command-line. unfortunately, this doesn't work yet, since 
this function is only defined by the frontend for "spice-" backends 
(see: gnetlist source code, src/gnetlist.c:139).
 - second, a userdefined top level attribute module-name is looked for.
 - finally the refdes attr is set to "SUB?"
The "source" attribute is set to:
 - the filename, if command line can be retrieved. see above.
 - the string "source?"

An input pin is generated for each in-1.sym in the schematic, and an 
output pin for each out-1.sym respectively.
The in/out symbol's refdes attribute is used as "pinlabel" pin attribute.


questions/requests
------------------
- The obvious request: if the developers might find the time to tell me 
what they think about the backend and the other stuff, that'd be great 
(no hurry, though).

- Is there any reason why gnetlist:get-command-line is retricted to 
backends beginning with "spice-" (see: gnetlist source code, 
src/gnetlist.c:139)? I think this is a very crucial function if one neds 
to get the filename, and should therefore made available to all backends 
(power to the people! ;)). probably even the parsing of the filename 
should by done centrally in some function available to backends, so it 
doesn't have to be implemented or at least c&p-ed by each backend 
programmer. Just my two cent's worth, I know there is always somthing 
that *could* or *should* be done, again don't be offended...

- I still couldn't figure out: is it possible to get top level text 
(plain text, not tl attributes) of a schematic inside a gnetlist 
backend? (Imho it really needs a comprehensive list of all functions 
available to the scheme backends...Hey, I'm not just criticising, I 
volunteered for that remember? ;)



_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user