Evolving circuits (was Re: ebay - cardamatic)

[Sean 'Captain Napalm' Conner]

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