Using python for a CAD program

Harry George at
Tue May 16 07:59:00 CEST 2006

63q2o4i02 at writes:

> Hi, I'm interested in using python to start writing a CAD program for
> electrical design.  I just got done reading Steven Rubin's book, I've
> used "real" EDA tools, and I have an MSEE, so I know what I *want* at
> the end of this; I just have never taken on a programming task of this
> magnitude.  I've seen that some are using python as a utility language
> for existing CAD environments, and I've also found some guy who's
> writing a 2d drafting tool with python, which is cool.  I've been
> playing with python recently and so far have a SPICE parser
> half-written (it'll do production rules, but no syntax trees yet...)
> I'm wondering if the python experts can provide some opinion on
> python's efficiency/utility in the following areas, and perhaps where
> some things will need to be in C++ and/or pyrex:
> 1.  Databases.  I don't mean sql type database, but design databases,
> which contain all the components for any given design, including
> schematics, layout, simulation parameters, etc.  I'm not concerned
> about python's ability to do fancy data structures, but I'm wondering
> how it'll go in terms of efficiency when things get really big.  If the
> alternative is home-brewed C++ linked-lists, attributes, arrays, binary
> trees, memory management, etc., it looks like python's ability to do
> all this neatly without all the bugs waiting to happen if I did this
> myself are well worth the efficiency loss that may result from its
> uber-generality.
> 2.  GUI.  Yes, I know you can do guis with qt, gtk, tkinter, etc.  I'm
> talking of fancy guis that do alpha blending, animations, nice
> shading/gradients, etc. in a quick, smooth, and slick way, such that
> moving a scroll bar or jiggling the mouse yields fast game-like
> response time, and which gives this program the feeling that you're
> actually in the 21st century... ie this is an *interactive*
> environment, and I f***king hate crass-hatching, so real colors is a
> must.  Can this be portable between linux and windows?  Is it possible
> to "do the whole thing" in opengl, even the 2d stuff?  I guess I dont
> know enough about guis here.  My fear is that my app will turn into
> x-hell if I try to do more than 8-bit colors in linux, with flashing
> background windows and complaints from the server about bit planes.
> Maybe I need to play with linux a bit more from the development side
> before commenting on this, since I get the feeling I'm working on old
> information here...
> 3.  Computational stuff.  I imagine the really heavy computing needs to
> be done in c++, especially if I'm stupid enough to write my own
> simulator, which my brain seems to want to do (I'm imagining a small
> homer simpson brain with a mind of its own telling me what to do...).
> But what about other things like rules and constraints about layout,
> routing, compaction, undo/redo, etc?  These aren't really
> computationally expensive, I don't think, but do munge about quite a
> bit with the database.  Is it likely I'll write something faster in
> C++?  (answer: no).
> 4.  Programmability.  I imagine this is a slam-dunk, relatively
> speaking, to have a python interpreter as part-and-parcel of the design
> system.  But how do I customize the command window to do custom things
> like adding special shortcuts (eg '?' brings up help, or help on
> commands a la Matlab), or making an API into the CAD program?  I'm not
> sure conceptually how to merge an embedded python interpreter into the
> rest of the CAD program in an intelligent way, so some stuff is
> exposed, but not all, and which interacts dynamically with the
> graphical portion so that, for instance, context-sensitive help is
> available in the console window, or so you can access information about
> the currently selected object, or so you can do stuff from the command
> line that is based on your current graphical context.
> 5.  Threads and parallelism.  One of the things about this is that I'd
> like there to be some real-time simulator running so when you change
> the values of parts, the output changes, and I'd like to be able to
> take advantage of mulitple processors, or dual-core, or whatever.  I've
> seen fake multi-threading in python (read about it, but I haven't done
> it), but that doesn't really use any extra cycles from a separate
> processor.
> So why am I thinking about this?  I've used a few  "real" CAD systems,
> and from using them, it's obvious the modus is to kludge shit  together
> over 20 years and screw the user experience.  So basically I'd like to
> take over the world with my nifty new python-based cad system because
> it's so beautiful and fun to use, and so flexible that my time to
> market for any given new idea is 5x shorter than the existing tools.
> Any comments on the above from people who've actually written stuff
> would be greatly appreciated! :)
> thanks
> ms

As a BSEE, MSCS, and developer using Lisp and Prolog for
Knowledge-Based Engineering (KBE) of structures and systems, I'm
interested in where you are going.  Nothing wrong with reinventing a
few wheels, but I always like to start with a literature search.  It
wasn't clear if you had done so.  At a minimum, take a look at:

1. OSS EE suites:

I don't see rewriting ngspice or Icarus Verilog -- people of people
doing that.  Putting a good DBMS behind gscheme on the other hand
makes sense.  Also, I write Python scripts around geda and there has
been discussion of embedding Python.

2. Databases: 

Locally, we have struggled with various DBMSs.  It seems OO is
mandatory, so I look to Postgresql with inheritance, or (smaller
scale) ZODB.  I really wouldn't want to grow one from B+ trees.

3. 2D CAD and game engines:

4. 3D CAD

Locally we write Python code against several commercial CAD packages
(I agree with your assessment).  For an OSS effort, the only game in
town seems to be:

5. Knowledge Based Engineering (KBE) inference engines:

Python already gives you lazy evaluation and memoizing, but a
prolog-based backward chaining engine helps too.  We wrote
CAD-engine-calls-python-and-prolog and
python-and-prolog-calls-CAD-engine scripts.

6. Simulation

Also need FEM for electromagnetic analysis, and CFD for heat

Harry George
PLM Engineering Architecture

More information about the Python-list mailing list