Re: gEDA-dev: New diagram (attempt at UML)

[Dan McMahill <dan-at-NOSPAMmcmahill_dot_net>]

Stuart Brorson wrote:
>>> > gEDA/gaf was intentionally designed to have a one-to-one relationship
>>> > between schematic pages and files.  This allowed all sorts of easy and
>>> > interesting post processing (read: shell script, perl, etc...) to 
>>> occur
>>> > on a individual schematic page.  Changing or even augmenting this core
>>> > assumption should be done with care.
> 
> 
>>> I'm way behind on this thread, but for the record, I'm fairly strongly
>>> opposed to having multiple pages per file if these multiple pages are
>>> different hierarchy levels.  If is is a flat multiple pages per a file,
>>> than I'm not so sure.
> 
> 
> There are good arguments to keep the one page <-> one file mapping.
> However, this makes it hard to incorporate hierarchy into a design
> (besides a kind of myopic hierarchy using source= attributes, that is).
> 
> I wonder if the best way to deal with hierachy is to keep all
> hierarchical information (i.e. some type of tree representing the
> structure of the hierarchical design) in a separate file which is read
> and parsed by the (soon to be written) project manager?  Or would this
> stand in the way of implementing a schema similar to that proposed by
> Peter and Peter?

  I disagree that it makes hierarchy hard.  I don't think you need 
source= either, why not just look for a .sch with the same name as the 
.sym in the same directory?  I also don't see why you need a seperate 
file for the same reason.

I'll point out that the cadence IC tools which clearly deal with large 
hierarchies basically work this way.  Cadence libraries are organized by 
a directory structure like this:

library/
   cell1/
     view1/
     view2/
     ...
   cell2/
...


where a view is something like a symbol, schematic, verilog-a, etc.  The 
actual data files are stored then in the cellview subdirectories.

The only time any sort of extra file is used is if you want more fine 
grained control over which views are used during netlisting.  The way 
netlisting works is you have a switch view list and a stop view list. 
You start out at the top level of the hierarchy and iterate over each 
instance.  For each instance you go through the switch view list to see 
if a view of that type exists for the instance.  For example your switch 
view list may be "schematic veriloga gnucap" in which case the netlister 
first looks for a schematic view to descend into, if there is no 
schematic view, it looks for a veriloga view, if there is no veriloga 
view it looks for a gnucap view (basically meaning the element is a 
gnucap primitive or something you provide in a model file).  The stop 
view list says "if you pick one of these views, stop following the 
hierarchy".  In my short example, "gnucap" might be whats in the stop 
view list.  Meaning you recurse down into schematics and veriloga blocks 
but not a gnucap view.

Ok, now suppose you want more fine grained control.  You want to use 
schematics for everything but veriloga for some blocks.  The hierarchy 
editor lets you specify this.  This is the only time you have any sort 
of extra file laying around that specifies anything about the hierarchy.

I really think embedding much more than this into the design becomes 
really clumsly really quickly.

-Dan


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