Implementation suggestions for creating a Hierarchical circuit database
in [Theory]
|
Prev: P Versus NP Resolutions Abounding?
Next: Implementation suggestions for creating a Hierarchical circuit database
From: nick on 9 Dec 2009 12:57 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
From: Ask me about System Design on 9 Dec 2009 14:09 On Dec 9, 9:57 am, nick <freesof...(a)gmail.com> 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
From: Paul E. Black on 10 Dec 2009 12:58
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 (p.black(a)acm.org) |