Implementation suggestions for creating a Hierarchical circuitdatabase

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

  1. nick

    nick Guest


    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:

    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.

    nick, Dec 9, 2009
    1. Advertisements

  2. 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

    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
    1. Advertisements

  3. [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, Dec 9, 2009
  4. 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";
    Objected-oriented languages make this much easier ...

    Paul E. Black, Dec 10, 2009
    1. Advertisements

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.