Implementation suggestions for creating a Hierarchical circuitdatabase

[nick]

Hi,

I am writing a personal software that will read circuit design/
netlist. I will be using the MCNC benchmarks that contain different
types of designs in SPICE netlist format.

I need some pointers/papers/suggestions on creating a "hierarchical"
netlist database. The netlist database can, at times, be fully
flattened, partially flattened or fully hierarchical. I should be able
to answer queries like: are there any capacitors connected to node:
x1.x2.n1?

My program is currently only for analyzing designs for connectivity,
types of elements (resistors/capacitors) and figuring out some simple
electrical properties.

I am just starting, so please bear with me if I haven't thought about
corner cases.

Regards
Nick

 

[Ask me about System Design]

Hi,

I am writing a personal software that will read circuit design/
netlist. I will be using the MCNC benchmarks that contain different
types of designs in SPICE netlist format.

I need some pointers/papers/suggestions on creating a "hierarchical"
netlist database. The netlist database can, at times, be fully
flattened, partially flattened or fully hierarchical. I should be able
to answer queries like: are there any capacitors connected to node:
x1.x2.n1?

My program is currently only for analyzing designs for connectivity,
types of elements (resistors/capacitors) and figuring out some simple
electrical properties.

I am just starting, so please bear with me if I haven't thought about
corner cases.

Regards
Nick

If you start by considering just the flattened case,
you will find that the underlying database is not much
more than a labeled graph. Make sure the code (or
specs anyway) to handle that case is rock solid before
trying non-flattened versions. You don't want to be
fixing those problems when you move to the non-flat
situations.

I used to work at a CAE (computer-aided enigineering)
vendor where commercial software was developed to do
this, plus simulation and layout (and other
considerations). One issue was name resolution and
linking signals across different levels. Another issue
was using shared (nested) designs, where one page was
used to specify a component and other pages used several
instances of that component, but I don't know if the
flattened version contained copies of the subcircuit
or different references to (virtual) copies of the
subcircuit. I advise implementing limited hierarchical
features and debugging them thoroughly before you move
on. E.g., make sure mutli-page designs work, then
try multi-level, then nested, etc.

If you limit your specs in the beginning, you will be
able to build and test prototype versions quickly.
Your eventual end-design will hinge on answers to
questions like: Am I only doing lookup and simple
local queries, or will I have to provide a flattened
version of the design? If you only have to do local
queries, then you can "build" a virtual copy of what
you need in a subcircuit and then throw it away; if
you need a flattened version, then several actual
copies of the subcircuit need to be built and printed
out. So even before you build a good spec, you should
have a good set of questions whose answers will help
determine the specification and direct the design.

Mentor Graphics is still around; they may have someone
who can give you pointers to aid in your project. Also
many issues are addressed by CAD software; hopefully
you will ask on those forums. Try hardware and CAD
forums as well as comp.* forums

Gerhard "Ask Me About System Design" Paseman, 2009.12.09

 

[Keith Thompson]

I am writing a personal software that will read circuit design/
netlist. I will be using the MCNC benchmarks that contain different
types of designs in SPICE netlist format.

[snip]

You cross-posted this question to comp.theory, comp.lang.c++,
comp.lang.c, comp.lang.python, and sci.math. Since you don't
mention anything about any implementation language, I don't see
how your question is relevant to any of the comp.lang.* groups.

If you have questions about a particular language, feel free to
post to comp.lang.whatever.

(I won't bother to redirect followups, since that affects only
followups to *this* article, but please consider trimming the
newsgroups line.)

 

[Paul E. Black]

I am writing a personal software that will read circuit design/
netlist. I will be using the MCNC benchmarks that contain different
types of designs in SPICE netlist format.

I need some pointers/papers/suggestions on creating a "hierarchical"
netlist database. The netlist database can, at times, be fully
flattened, partially flattened or fully hierarchical. I should be able
to answer queries like: are there any capacitors connected to node:
x1.x2.n1?

My program is currently only for analyzing designs for connectivity,
types of elements (resistors/capacitors) and figuring out some simple
electrical properties.

Nick,

I built a sophisticated database similar to this. One thing I can
pass along is unless you are SURE you'll never add any new types of
components, separate class information from instance information. For
example, all capacitors have the same letter representation ("C"),
print name ("capacitor"), and number of terminals (2), but each
instance has capacitance and connections. Collect the component type
information in one place rather than, say hardcoding it in routines:
componentPrintname(cp *item) {
switch (item.type) {
case 1:
return "capacitor";
case 2:
return "transistor";
WRONG
Objected-oriented languages make this much easier ...

-paul-