Re: gEDA-user: Hierarchy vs spice-sdb

[Dan McMahill <dan@xxxxxxxxxxxx>]

John Doty wrote:
> I've run into a real paradigm clash here (as well as the ragged edge of
> the docs).
>
> I've experimented adding "source" attributes to a hierarchical
> design. This makes navigation much easier. However, it breaks SPICE
> netlisting with spice-sdb.
>
> Apparently, gnetlist runs down the sources and expands them before the
> spice-sdb backend has a chance to look at the associated symbols. The
> result is chaos, with top level cards inserted into subcircuit definitions
> willy-nilly.
>
> I see two different approaches here:
>
> 1. gnetlist does the netlist expansion, flattening the hierarchy.
>
> 2. gnetlist preserves hierarchy, allowing SPICE to do the expansion (the
> spice-sdb approach).


Here is another data point.  The following is how netlisting works with
the cadence dfII environment.  Note that this is a system which is
targeted to IC design, but there may be some useful concepts.  The
drawback is complexity.


a few definitions
-----------------

library - a collection of cells

cell - a particular block.

cell view - a view for a cell.  Examples of a cell view are a schematic
view, symbol view, or a layout view.


Example:


mylib:

   cell1:
       - schematic
       - veriloga
       - symbol
       - layout

   cell2:
       - schematic
       - veriloga
       - symbol
       - layout
       - extracted

   nmos:
       - symbol
       - spice
       - layout
       - schematic

   pmos:
       - symbol
       - spice
       - layout

In this case, nmos and pmos are primitives which have symbols and
layouts, but no schematic.  Cadence has 2 ways to control netlisting.
The simple way is you define a "view list" and a "stop list".  The way
netlisting works is you start at your top schematic.  For each instance
you find, you try to find a view in the "view list" searching in order.
 Then go into that cell view and recursively netlist it.  If the view
you find is in the "stop list", you don't try to descend.  So lets make
this more concrete with and example.


cell:schematic = top level schematic.  It has 2 instances of cell2 as
well as some nmos and pmos.  cell2 has some nmos and pmos.  view list =
"spice schematic veriloga" stop list = "spice veriloga".  When you netlist,

you start in cell1, you find the instance of cell2.  cell2 does not have
a spice view.  It has a schematic view so descend into cell2:schematic
and netlist it.  Now that you're in cell2:schematic, you find a nmos.
nmos has a spice view so netlist it as a primitive.  Since 'spice' is in
the stop list, don't try to descend into it.

The more complicated netlisting method lets you pick views on a cell by
cell basis.  For example you may want to use a veriloga model of cell2
for faster simulation.

Note that in all of this, the netlisting is hierarchical which is
different from gnetlist currently.  gnetlist flattens the hierarchy.

So this is how cadence controls how it walks through the hierarchy.

Now the other piece is some data called "siminfo" associated with each
cell.  The siminfo data tells how each cell should netlist for a target
netlist format.  For example maybe in spice it should netlist with the
pins in pinA, pinB, pinC order with some set of parameters but with
layout, it should be pinB, pinA, pinC and different parameters.
If you want to be able to deal with multiple netlist targets which 
different ideas about pin ordering or what the device is named, thats 
how you do it (if you're using cadence).


While this is very flexible, it is quite a bit of work to build you
library of primitives.  In IC design you have a very small set of
primitives which need lots of manual setup.  All of the higher level
cells automatically generate the siminfo section because they are all
subcircuits.  Board layout is a bit different because you can have many
primitives.


----------------------------

I think ultimately though, the right thing to do is to allow an
individual gnetlist backend to tell gnetlist to flatten or not flatten
the hierarchy.  I'd really like to see this because spice-like
simulations really want to be hierarchical but most board layout tools
really want a flat netlist.

A sane hierarchy proposal for gnetlist is on my list of things I'd like
to do over the holidays.  I've fantasized about adding true hierarchy 
support to gnetlist for some time now, but want to write up a manual of 
sorts first to make sure I code up the right thing.


-Dan