Re: gEDA-user: Re: hierarchy of schematics

[AR <radecki@xxxxxxxxxxxxx>]

John Griessen wrote:
> > What is missing is a
> > design "database" (a well-defined directory structure would do fine), 
> > with clear separation what is a symbol, schematics or other data. 
>
> We now have that in gnetman and datadraw.  No one's spent the time to 
> start using it yet though...   If you have experience making good 
> choices of data structures with databases, I urge you to read up the 
> docs on gnetman and datadraw and suggest the structure that would make 
> for hierarchic schematics.

Well, I'm not competent enough for doing a "real job". The following is 
a sketch of schema that I would like to have in gschem:

database -* library
         -* parameter (global)
library - name
        -* cell
        -* parameter (library-level)
cell - name
     -* subcell (e.g. symbol slot or multi-sheet schematic page)
     -* view
     -* pin
     -* parameter (cell-level)
subcell - name
        -* view
        -* pin (subset of cell pins + offsheet pins)
view - name
     - view_type (symbol, schematic, pcb, layout, vhdl, ngspice...)
     -* parameter
parameter - name
          - value
          - type
          - description
pin - name
    - direction (in, out, inout...)
    - type (hierarchical, offsheet)
    - width (for buses)
    - net name to connect at higher hierarchy level (like "avdd" or null)
    - netlisting order
    - description
symbol -* shape
schematic -* shape
          -* net
          -* instance
shape - bounding box
      - shape_type (line, path, rectangle, polygon, oval, arc, text...)
      - layer (could be useful for layout/pcb)
net - name
    - width
    -* shapes
instance - instance_name
         - cell
         -* pin_wire_mapping
...

Some comments:
1. Why "subcell"?
   There are two ways of drawing schematics hierarchical and "flat" 
(multi-sheet schematics). First is used in simulation, transistor-level 
IC design etc., second - mostly for component-level design (PCB, BoM). 
We need some way to abstract these concepts. So, for example:
- cells can be used only for pure-hierarchical design. Each cell has its 
own namespace (pins, nets, instances names).
- subcells can be used for making multi-sheet schematics, multi-slot 
symbols, etc. All subcells share their parent cell's namespace. I.e. all 
pins, nets and instances names are global in respect to parent cell. 
Drawing tool should warn if there is any name clash (like same net name 
without offsheet pin).
2. View types. Each tool should register its own list of view types in. 
For example ngspice netlister could register/use views "ngspice", 
"spice", "schematic".
3. Pin, net name to connect at higher hierarchy level. This can be used 
for making cells like "ground" or "power" which, when connected to a 
net, force its name to this predefined name (like: "agnd", "avdd").
4. Other tools support implicit pin definitions, however (IMHO) this 
practice should not be encouraged and above schema does not provide such 
possibility.
5. Storage. What data should be stored in a single file/database and 
what should be written to another file/directory? Cadence dfii is using 
separate files down to "view" level. This is good for very large view 
databases (like flat layout design) but keeping inter-view data in sync 
is difficult.

AR



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