Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Implementation suggestions for creating a Hierarchical circuitdatabase

Reply
Thread Tools

Implementation suggestions for creating a Hierarchical circuitdatabase

 
 
nick
Guest
Posts: n/a
 
      12-09-2009
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
 
Reply With Quote
 
 
 
 
Ask me about System Design
Guest
Posts: n/a
 
      12-09-2009
On Dec 9, 9:57*am, nick <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      12-09-2009
nick <(E-Mail Removed)> 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.velocityreviews.com/forums/(E-Mail Removed) <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"
 
Reply With Quote
 
Paul E. Black
Guest
Posts: n/a
 
      12-10-2009
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 ((E-Mail Removed))
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Implementation suggestions for creating a Hierarchical circuitdatabase nick C Programming 3 12-10-2009 05:58 PM
Implementation suggestions for creating a Hierarchical circuitdatabase nick Python 2 12-09-2009 07:13 PM
Hierarchical Membership Implementation rwoodruf ASP .Net 2 12-28-2007 08:42 AM
Suggestions for hierarchical display of data Rodrigo S. Novelli ASP .Net Web Controls 5 05-25-2004 06:34 AM
Hierarchical Credit-based Queuing (HCQ): QoS implementation feedback? Vicky Cisco 0 05-09-2004 07:07 AM



Advertisments