-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mon, Mar 03, 2008 at 11:05:44AM +0000, Peter TB Brett wrote:
> On Sunday 02 March 2008 17:53, you wrote:
> > Hi Peter,
> >
> > I got your email from the gEDA developers page.
> >
> > I'ven been using gEDA for about 1 year (moved from EAGLE since I wanted a
> > free alternative with open fileformat) and I found two things that I find
> > missing:
> >
> > * Support for a script language (like EAGLE:s ULP script lang.) - Makes
> > drawing big circuits like FPGA:s and so on way easier.
>
> Guile Scheme is the official scripting language for gEDA. A (large, but very
> useful) SoC project could be to make the Scheme API more complete & better
> documented.
I'm working on something sort of along those lines actually. I've done a
number of project involving very large grids of something, like 1600
leds, and I'm kinda tired of laying that sort of stuff out by hand. More
importantly I've also got a project coming up next year for my thesis
that will basically involve writing a program that generates a basic
layout of elements, kinda line a model train set, that then need to be
automagically turned into schematics and further more a pcb design. The
former, the repeated elements, looks like it has a number of solutions
used in the industry, such as the repeated sheets and propegating
routing between identical modules in Altium.
The latter usage case though is much more difficult. I think I'll need a
consistant hiarchical model of the schematic, and the pcb layout
associated with it. Having hooks into a good autorouter will be
essential as well. The scripting languages I've seen so far seem to
solve bits and peices, but they are all designed to help automate tasks,
rather than automate design. FPGA and ASIC synthesis is really much
closer to what I want to do.
So I've been working on a library called Tuke for just over a month now.
It's written in Python and hasn't yet had any optimization for speed.
The core concept of it is that everything is an Element, with an Id, and
zero or more sub-Elements. Components then build upon that, adding
Netlist information and Pins/Buses. Symbols are Components with a
Footprint. The Netlit in a symbol is then used to connect symbolic pin
names, 'vcc', to numerical footprint pins, '1' Footprints have various
bits of Geometry under them, but no Netlist. The Geometry would be
something like a pcb.Pad, which in turn would have various
Polygons/Circles/Holes whatever. Symbols may also have Geometry as well,
but for the schematic view, rather than a pcb layout.
The important bit is that Element Id's work like filesystem paths. So
say I have a Component with an Id of 'frobber' It in turn has a Symbol
with an Id 'foo', which in turn has Pin 'vcc' From the Component's
perspective when it needs to make up it's Netlist, the code looks like
the following:
self.link('vcc','foo/vcc')
Or alternatively using a __getattr__ hook in Python:
self.link(self.vcc,self.foo.vcc)
This version of the syntax will eventually make implementing Bus
varients of Pins possible too, like a standard IoPowerBus class that
would in turn have vcc and gnd pins...
Now say the frobber wants to connect it's vcc to it's parents source of
power:
self.link('vcc','../vcc')
All the above is currently working, capturing the netlist information is
relatively simple. PCB layout is going to be where things get
interesting... In the simple case, say for a simple LedGrid component,
the code would then just draw, manually, Traces between various physical
pins:
self.add(new_trace(self.led1-1.footprint.2,self.led1-2.footprint.1))
Where:
def new_trace(a,b):
va = center(a)
vb = center(b)
# Some stuff here to add another vertex or so if you want to "kink"
# the trace rather than do a direct line.
return Trace(va,vb) # omitting trace width, etc
Obviously, this is a pain in the butt, but I will have this implemented
in a week or two and have a working LedGrid maker that generates
useful gerbers at that point.
More interesting though is that due to the hiarchial nature of all of
this, I think auto-routers would be a lot more useful. To make a
series/parallel led grid, you could create a LedString component for the
strings of leds. When it calls the autorouter, even a dead simple
connect pins in the most direct route possible "autorouter" would work.
The LedGrid then just has to connect the vcc and gnd's of the LedStrings
up. My thesis project will involve standardized magnet actuator drivers
with vcc,gnd bus and a two pin I2C bus. The autorouter would be called
to route the drivers, then called to route busses between the drivers.
Anyway if you want to look at some code go to:
http://petertodd.org/mtn/branch/head/info/io.pkt.soft.tuke
http://petertodd.org/mtn/branch/head/info/io.pkt.art.64-bit-counter
The first is the main library, which has some interesting stuff in the
examples directory, such as led_grid, export_gerbers and graph_netlist
You can also run ./tuke test for the unit tests.
The second is a work in progress to automatically create a n-bit ripple
counter implemented with 74109's. Note that you'll need to set
PYTHONPATH for the latter if you want to run export_gerbers on it's
output.
And yeah, if this interests you guys, I'd love to work on this for
Google Summer of Code. Obviously right now this is parallel to gEDA,
but I have written, for instance, a gEDA symbol importer and intend to
do future work along those lines. It should be possible to create
schematic exporters/importers as well. In any case, no need to make any
decisions immediately, student applications don't even start for another
month. I can say I'm at least motivated enough to be working on it
before, and after the gSOC period, given that my thesis project will
depend on it, and getting at least the led grid example, if not the
64-bit-counter, working is what I'm handing in for one of my courses
this semester. :)
- --
http://petertodd.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFHzC1x3bMhDbI9xWQRAtBEAJ9963DR405mzAWc7VlZzg/ukGk4RQCfYPeM
gA6ObDvW2CJlAshninaB9ps=
=IOeM
-----END PGP SIGNATURE-----
_______________________________________________
geda-dev mailing list
[email protected]
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
