Using python for a CAD program

[Harry George]

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.

 

[63q2o4i02]

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

 

[BartlebyScrivener]

Art Haas posts from time to time regarding a program called PythonCad
that he maintains:

http://tinyurl.com/o36t8

Also, here is a search of this forum on "Cad":

http://tinyurl.com/nuobe

 

[skip]

> Hi, I'm interested in using python to start writing a CAD program for
> electrical design.

Google for PythonCAD.

Skip

 

[63q2o4i02]

Cool. thanks for the links. I've already looked around quite a bit,
and am very hesitant to just write more shit on top of other shit. The
idea behind this is it's completely mine. So yes, I have a tendency to
want to reinvent a few wheels, but I think it'll give me greater
satisfaction. The problem with geda, etc., is that it's taking the
unix approach -- a buncha little command line tools that somehow make a
"system", using text files as communication medium. I hate that,
largely because it allows the infectious spread of little files all
over your system, encourages people to write scripts from outside the
system that probably won't work for you, and exposes the user
unnecessarily to the implementation of where you keep files,
directories, blabla. I'm more of the windows approach, where you have
one integrated environment, and any text you type is from within the
application itself, and most application-related data is hidden from
the user unless he *really* wants to get at it. (disclosure: I've
never actually installed geda, but I tried icarus once and couldn't get
it to compile -- another bane of open source stuff I can't stand. I'm
not a CS person, so when I download something, I just want it to work,
and I don't get off trying to *make* it work...). Another reason for
doing this on my own is that I'd like a general-purpose CAD/design
framework, of which electrical/IC design is only one part. Also, I
think geda simulations are spice-based, which is batch, which is sooo
your-father's buick, which I hate as much as text files... aaand
another thing is I'm very big on user-experience. I'd like my program
to *look* slick, like it belongs in a movie or something. I think that
means starting from scratch, since I've not seen any CAD program take
any artistic/human/psychological approach to its design.

 

[Paddy]

Unfortunately, Cadence got their first with their DFII environment for
Schematic based design and their Lisp based language SKILL
(http://www-mtl.mit.edu/users/xiaolin/skill/sklanguser/sklanguserTOC.html)

I used their environment several years ago and can only say that it was
all you have stated above, and probably more. The environment seems to
be totally accessable by SKILL, from the Schematic database to dash
patterns for drawing lines. Their stuff is optimised for working with
todays Electronics designs.

I too have played what-if games about this and thought wouldn't it be
great to tie Python for the language together with SVG for the graphics
and ??? for the database but it remains a dream for me as it is a BIG
job.

Before you set out on this path, you might waant to see if you can be
shown around Cadence Virtuoso and SKILL?

- Pad.

 

[Hannu Krosing]

Ühel kenal päeval, E, 2006-05-15 kell 23:49, kirjutas
(e-mail address removed):

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

for a nice fast corel-draw clone written in python see http://www.skencil.org/

 

[skip]

That seems like a gratuitously unkind way to refer to tools you haven't
tried. Have you checked out PythonCAD? <http://www.pythoncad.org/>. I
don't use it, but the guy's been trickling out new releases periodically for
the past four years or so (30 so far). Might be worth a peek.

Skip

 

[63q2o4i02]

Yes, I figured I should be pretty expert at what's out there first
before redoing something and making in inferior to the existing
solution. I took a quick peek at cadence courses, and they're out of
my personal price range. I have a new job coming up which should lead
into IC design after some time, and I should probably ask them to send
me to the course.

 

[Grant Edwards]

Yes, I figured I should be pretty expert at what's out there
first before redoing something and making in inferior to the
existing solution.

Eagle from Cadsoft.de is a pretty decent (and free for
educational/hobby use) integrated schematic capture and board
layout package (including a quite usable auto-router). It
doesn't have integrated simulation, but after messing about
with both gEDA and Eagle for an hour or two the you get a good
feel for the difference between an integrated tool-set and
something cobbled together from disparate utilities.

 

[baalbek]

1. Databases. I don't mean sql type database, but design databases,

If you really want to revolutionize the CAD business, PLEASE don't base
your CAD system on a file based system (ala Autocad).

CAD systems available today (Autocad, Archicad, Architectural Desktop,
etc) have one huge flaw: they don't store data to a SQL database, but to
binary files.

This fact has created so much problems (user problems as well as
technical problems) in projects that involve several people.

I know, I have 15 years of experience supporting teams using CAD, as
well as CAD programming (mostly C++).

The fact that Autodesk still to this day has not produced an Autocad
version for a SQL database, shows how little innovation there is in
large companies.

I don't know where to start to list the numerous problems with a CAD
system based on raw binary files, so I won't bother.

Regards, and Good Luck,
Baalbek

 

[Ben Finney]

If you really want to revolutionize the CAD business, PLEASE don't
base your CAD system on a file based system (ala Autocad).

CAD systems available today (Autocad, Archicad, Architectural
Desktop, etc) have one huge flaw: they don't store data to a SQL
database, but to binary files.

Using Python 2.5, one could store (and distribute to others) the data
in a binary file that *is* an SQL database:

<URL:http://docs.python.org/dev/lib/module-sqlite3.html>

 

[Frithiof Andreas Jensen]

Cool. thanks for the links. I've already looked around quite a bit,
and am very hesitant to just write more shit on top of other shit.

All software suck. If you think that yours will not then:

a) you are a narcissist
b) you are the only user
c) all of the above

The
idea behind this is it's completely mine. So yes, I have a tendency to
want to reinvent a few wheels, but I think it'll give me greater
satisfaction.

*I* think you bite off way too much and will waste two years and never
get anything usable done.

The problem with geda, etc., is that it's taking the
unix approach -- a buncha little command line tools that somehow make a
"system", using text files as communication medium.

That is because this approach actually works, it is proven in serious
work, it can be tested without writing a test application of about the
same complexity as the real job and it deals neatly with the users
needs for automation without forcing the application to contain thick,
bloated object management code for the users extensions.

I hate that,
largely because it allows the infectious spread of little files all
over your system, encourages people to write scripts from outside the
system that probably won't work for you, and exposes the user
unnecessarily to the implementation of where you keep files,
directories, blabla.

Wrong on many levels:

The idiot users will get into trouble no matter what you do; while the
user that is smart enough to write an extension will need to deal with
the implementation anyway.

You, the developer, has to decide on wheather it is smarter to write
your very own object manager, API's and the user/developer
documentation thereoff or leave it to the operating system by simply
using what is already there.

I'm more of the windows approach, where you have
one integrated environment, and any text you type is from within the
application itself, and most application-related data is hidden from
the user unless he *really* wants to get at it.

I.M.O. The reason for the "integrated" windows approach is simply
because that OS lacked/lacks efficient tasks, interproces
communication and it does not support scripting.

So each developer will end up rolling his own monolith and because all
the code monkeys see this, it becomes "the way".

(disclosure: I've
never actually installed geda, but I tried icarus once and couldn't get
it to compile -- another bane of open source stuff I can't stand.

The odds are great that the problem is to be found in front of the
screen rather than the code.

I'm
not a CS person, so when I download something, I just want it to work,
and I don't get off trying to *make* it work...). Another reason for
doing this on my own is that I'd like a general-purpose CAD/design
framework, of which electrical/IC design is only one part. Also, I
think geda simulations are spice-based, which is batch,

And this matters ... in what way exactly??

which is sooo
your-father's buick, which I hate as much as text files... aaand
another thing is I'm very big on user-experience.

"Experience" over "Functionality". I see - well, it worked for Bill.

The "knowledge workers" forced to use the pretty etch-a-schetch tools
are less than happy and will seek to minimise the pain by avoiding
most of the alledged functionality. Last time I felt "the pain of the
little used feature" was setting headers and footers in Excel - No,
it does NOT work the same as in Word ("work" is perhaps a strong
word).

I'd like my program
to *look* slick, like it belongs in a movie or something. I think that
means starting from scratch, since I've not seen any CAD program take
any artistic/human/psychological approach to its design.

That *is* true - the problem with CAD programs are that they need the
*exact* details to be entered at design time so one cannot easily
schetch in them and fix the design errors later.

But it does not follow that there is a need for rewriting the
rendering engine or the design rules checker - you could actually
achieve something by writing a tool that allow an existing CAD system
to support the way designers actually work so that they use the tool
up front instead of as it is now where CAD is the digitiser for a
paper-based design.

 

[Brendan]

That *is* true - the problem with CAD programs are that they need the
*exact* details to be entered at design time so one cannot easily
schetch in them and fix the design errors later.

Not universally true, and here's a niche for you Andreas:

Most 2D cad requires that you enter ALL design information as you go.
You can't, for instance, draw a line at 30degrees to another line and
then change the second without having to redraw the first. "Sketchers"
from 3D cad programs (like Solidworks, Inventor, Solid Edge,
Pro/Engineer) are more like geometry solvers - by putting in a
dimension, you say "line a is always 30 degrees to line b". Now
when you change the angle of line b, line a changes too! In this way,
you can sketch out the SHAPE of your drawing, and worry about the
DIMENSIONS later. You can't imagine how useful this is. Now that I've
switched to Solidworks, my
drafting speed has doubled.

I haven't seen anyone make a 2D cad package with this behaviour. I'm
sure there's a market for one if you go that route.

-Brendan

 

[63q2o4i02]

Hi,

Actually, I've wondered about using a custom-rolled binary or
text-based database, vs. something that uses the OpenEDA standard, vs a
'real' database like sql. I guess my impression is that something like
SQL is not designed for something as multi-... uh, dimensional? as an
EE design. Perhaps it would be good for just storing the data, but can
it also store relationships or other meta-things besides the raw
literalness of a design? I'd imagine it can store arbitrary binary
data, but then what's the advantage over a custom binary file? If the
application provides a nice API for geting into its custom binary file,
then what's the problem?

ms

 

[63q2o4i02]

Thanks for this. I'm enjoying this discussion and I'm learning a lot
about people's views and how they differ from mine.

However, I'm still wondering about my original post.

Can the experts please comment on python's usage for the following:

1. Databases. Assuming I roll my own, does python have any
performance issues for this sort of thing?


2. GUI. Can Python command the various gui libraries fast enough to
qualify as game-quality, with transparency, anti-aliasing, animations,
etc?

3. Computational stuff like simulations and rules-checking. I'm just
going to assume this needs to be in C++ or pyrex or SciPy or something.

4. Programmability. How do I embed an interpreter which has some
custom CLI commands and knowledge of the graphical conext and which has
exposure to the API used in the main application, such that to the user
all the necessary things are exposed by default, and so that it doesn't
feel like it's just a disconnected console window that he/she needs to
set up manually each time?

5. Threads and parallelism. Should I even bother? I've read that
it's possibly more tricky with python than with normal dev tools. I've
never done it, but I'd like to at least think about it up front so
if/when this goes MT it's not a complete rewrite from the ground up.

thanks
ms

 

[skip]

Most databases are written in a compiled language (gadfly being an
exception). Even so, in my apps that use databases (mostly SQL-based), the
database is the bottleneck, not Python.

Threads help if you're going to be I/O-bound. If you're going to be
CPU-bound I wouldn't bother unless it provides some major structural
advantage to your code. If you think you need more than a couple CPUs, you
probably want a multi-process model anyway so you can leverage multiple
computers on a LAN (think Beowulf-style multiprocessing).

Skip

 

[David Cuthbert]

Unfortunately, Cadence got their first with their DFII environment for
Schematic based design and their Lisp based language SKILL

Well, SKILL (a Franz Lisp derivative) is very old and has some peculiar
design quirks. Interfacing with anything not written by Cadence or not
written in SKILL is painful, at best.

Interestingly, Python is being used as an extension language for the
OpenAccess database. LSI Logic had a Python wrapper for 2.0 (it looked
like they used SWIG). I had written one for 2.1, but never was able to
release it before my company was acquired by Cadence (and that project
quashed).

There is some interest... just not quite critical mass.

 

[David Cuthbert]

CAD systems available today (Autocad, Archicad, Architectural Desktop,
etc) have one huge flaw: they don't store data to a SQL database, but to
binary files.

There's a reason for this. Most CAD data is not in a form (First Normal
Form) suitable for a relational database. In addition, the sheer number
of objects involved in each operation brings performance to its knees.
Finally, most RDBMS provide (and are optimized for) transactional
semantics -- for a CAD system, this is wasted overhead.

People dabbled in this years back but quickly discovered just how
different they are.

If you have access to it, you should take a peek at the source for the
OpenAccess database. Although this is for chips, I suspect some of the
same design principles would go into designing a CAD database.

 

[Terry Hancock]

baalbek wrote:



There's a reason for this. Most CAD data is not in a form (First Normal
Form) suitable for a relational database. In addition, the sheer number
of objects involved in each operation brings performance to its knees.
Finally, most RDBMS provide (and are optimized for) transactional
semantics -- for a CAD system, this is wasted overhead.

Object database systems (ODBMS) like ZODB are probably a
much better fit for CAD data than RDBMS. The hierarchical
structure in an object database is a natural fit to the way
CAD drawings are created and manipulated, and most CAD
systems internally represent drawings as some kind of object
tree.

Of course, ZODB *can* serialize its data to an SQL backend,
among several other possibilities. One of the more intriguing
possibilities would be using a CVS or Subversion based back-end
to provide more complete version control help.

I disagree that transactions are bad for CAD -- they may have
a different semantic role and the needed granularity may be
different, but the need to roll data back to an earlier revision
is just as present in drawings as it is for code or financial
transactions.

Cheers,
Terry