Using python for a CAD program

Tue May 16 01:59:00 EDT 2006

63q2o4i02 at sneakemail.com 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:
http://www.opencollector.org/
http://www.geda.seul.org/

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.

http://www.postgresql.org/
http://www.zope.org/Products/StandaloneZODB

3. 2D CAD and game engines:
http://directory.fsf.org/PythonCAD.html
http://pygame.seul.org/news.html

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: 
http://www.opencascade.org/
http://free-cad.sourceforge.net/

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.

http://sourceforge.net/projects/pyprolog/
http://christophe.delord.free.fr/en/pylog/
http://arts.anu.edu.au/linguistics/People/AveryAndrews/Software/AmziPy/Doc/manual.pyfrompro.html
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/303057

6. Simulation

http://simpy.sourceforge.net/

Also need FEM for electromagnetic analysis, and CFD for heat
dissapation.

-- 
Harry George
PLM Engineering Architecture