Implementation suggestions for creating a Hierarchical circuitdatabase

Discussion in 'C++' started by nick, Dec 9, 2009.

  1. nick

    nick Guest

    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
     
    nick, Dec 9, 2009
    #1
    1. Advertising

  2. On Dec 9, 9:57 am, nick <> wrote:
    > 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
     
    Ask me about System Design, Dec 9, 2009
    #2
    1. Advertising

  3. Re: Implementation suggestions for creating a Hierarchical circuit database

    nick <> writes:
    > 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.)

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Dec 9, 2009
    #3
  4. Re: Implementation suggestions for creating a Hierarchical circuit database

    On Wednesday 09 December 2009 12:57, nick wrote:
    > 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-
    --
    Paul E. Black ()
     
    Paul E. Black, Dec 10, 2009
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. John
    Replies:
    2
    Views:
    609
    Wole Ogunremi
    Nov 18, 2004
  2. rwoodruf
    Replies:
    2
    Views:
    311
    Mark Stevens
    Dec 28, 2007
  3. nick
    Replies:
    3
    Views:
    307
    Paul E. Black
    Dec 10, 2009
  4. nick
    Replies:
    2
    Views:
    310
    Keith Thompson
    Dec 9, 2009
  5. Rodrigo S. Novelli

    Suggestions for hierarchical display of data

    Rodrigo S. Novelli, May 24, 2004, in forum: ASP .Net Web Controls
    Replies:
    5
    Views:
    180
    Robert Koritnik
    May 25, 2004
Loading...

Share This Page