Evolving circuits (was Re: ebay - cardamatic)

From: Sean 'Captain Napalm' Conner <spc_at_conman.org>
Date: Thu Feb 17 19:44:47 2005

It was thus said that the Great Tony Duell once stated:
>
> > He didn't "design" the circuit. What he did was generate X number of
> > random FPGA configurations for the 10x10 cell area, tested each one, and
>
> Sure. But presumably it's possible to read out the final configuration
> from the FPGA and analyse it assuming the FPGA behaves exactly as the
> data sheet claims (i.e. no hidden capacitive coupling, etc). Has this
> been done? If not, why not?

  Don't know. The article didn't go into *that* depth of detail.

> > those that were more promising kept and randomly mutated with each other;
> > the configurations that didn't pass were dropped. This process is then
>
> Obviously I don;t know how this was done, but I know from bitter (and
> expensive) experience that some configuration patterns for some FPGAs can
> do things like connect outputs together inside the chip (and other things
> that no sane designer would want to do). I got a rather expensive FPGA
> hot enought to let the magic smoke out by doing that...
>
> Do we know that there are no illegal things like that in the final
> configuration.

  I assume that since no magic smoke was let out, then no, there were no
illegal things in the final configuration---or at least, illegal things that
were actually connected to the ciruit (there were five gates nearby, not
connected, that when removed, caused the circuit to fail).

> > > OK, it must be some kind of coupling. Either capacitive coupling between
> > > traces, or via the PSU, or...
> >
> > I do know that in another article I read on this, that moving the
> > configuration to another area *on the same chip* caused it to fail. And
> > yes, I've encounted programs like that 8-)
>
> OK, that would seem to indicate there's more to this than the observed
> connections. But it doesn't isolate coupling from threshold effects. Both
> would change if you moved the circuit around the chip.
>
> > The way around that is to run the "configurations" on multiple chips and
> > breed those; that should breed a version that isn't supsceptible to minor
> > variations in the gates of the FPGA.
>
> Unless of course it _depecds_ on these variations, in which case you'll
> end up breeding something that doesn't work at all.

  Quite possibly. Or you might get a design that uses most of the 100 gates
used instead of the 40 (35 actively used, 5 not connected at all but
required) in the final design.

> There's nothing random about it.

  -spc (Unless you're detecting decaying atoms 8-P
Received on Thu Feb 17 2005 - 19:44:47 GMT