Genetic FPGA

Pity about the efficiency, but it does get there in the end. Your superior scheme depended on the DNA knowing when it was mutated, which doesn't happen to be possible.

Something will probably evolve. Biology does seem to have evolved us, and some of us are potentially capable of doing intelligent design - though it does depend on acquiring more background knowledge than you seem to have bothered to pick up.

In John Larkin's case, transformers. If he can't buy one to do a job he won't even try to think about designing one.

Unique only at the time? Do you mean modern ones are fully specified too?

Not sure what your point is. I don't think genetic algorithms can run a pig farm either. So?

BTW, they have algorithms to learn what you like to listen to and send more like that your way.

I'm not sure what "fully specified" is intended to mean. If FPGAs are not fully specified how does *anyone* generate a bitstream for them?

I think what is meant is that there was *no* combination of configuration bits that would cause damage to the part, so the bits could be twitled at will and tested in a real chip with no harm.

That's not really the best way to do genetic design I think since the designs can depend on arbitrary and unspecified features of the chip, sometimes the individual chip. Better to do the modifications at a circuit level and selection in a simulator where only the documented features have an effect. But then I haven't done any of this work, so I don't know much details of how it is done. Maybe this idea just isn't practical.

Again, you know little about this. If people don't do async designs right, they are just people doing designs they don't know how to do, like many at some point in their careers. Async design is completely practical, it is just detailed and often of little benefit.

Clock domain crossings in ASICs, FPGAs or any other logic are well understood and are simple to deal with. Again, you need to actually know about them to do them right... that's all.

That is exactly the point. Constrain the problem correctly and you can get past the more trivial problems of previous attempts at genetic programming. I'm still not sure it will produce great designs, but part of the reason people are doing this is to study the designs and find potentially new ideas in how to design circuits.

Human thought is limited and often takes only very small steps away from anything done before. Genetic design can potentially uncover completely new aspects of design.

Fully specified = an end user (not a Xilinx employee) could read a datasheet that described the function of every bit in the configuration and every programmable feature of the chip.

This still isn't done for the "big two" companies (Xilinx and Intel/ Altera).

I believe it is done for some Lattice devices. I haven't used them (or the resulting open source toolchain) though.

Nothing I said could be misconstrued to mean that. In fact, it was possible to destroy that chip with a bad configuration (by e.g. connecting VCC to GND via many routes at the same time). The researchers had to include a pass in their genetic compiler (after the sexing and mutating) that would fix design rule violations.

Regards, Allan

It wasn't portable or practical, but I don't think that detracts from the wonder of a design that managed to be a frequency discriminator in an ostensibly digital device without using a clock.

Allan

Bill Sloman = snarkier than a 29 year old female craft beer aficionado from Cambridge, Massachusetts with a PhD in comparative literature

That shouldn't be difficult. What's more difficult would be to make it reproducible.

No, I believe Lattice does not publish specs on the bitstream. But they make some smaller, simpler devices that allowed a brute force analysis to figure it out... at least well enough to produce a working bit stream for most designs.

I don't recall that being the case. I remember this being discussed in c.a.fpga and that was mentioned as a key feature, no damage possible. However, it was some 15 or 20 years ago. So I may not be remembering it properly.

The "right" way to do genetic design is to control documented chip features through a tool, not by twiddling bits in a configuration file. That lets you bypass an entire level of rather rude errors that don't need to be tried allowing the design to be tested on any FPGA hardware without damage. I seriously doubt genetic development stopped when they stopped making the XC6000 devices.

Whoever she is, she sounds like fun. What did you do to her to get her snark-engine running? My wife did a post-doc at MIT, and used to like real beer ...

I thought the whole point of the original (1990s) article was that there is no "right" way to do genetic design and that by twiddling configuration bits directly, the "design" process was able to exploit undocumented features in a way that would never be dreamed up by a human designer.

I may not be remembering it properly either.

BTW, This appears to be the original paper from 1996:

Regards, Allan

Of course, if you intend to randomize it, then the bitstream doesn't even need to be documented.

Except for the damage thing. It has been indicated clearly that most FPGAs will fry themselves if configured by a random bit stream. I think most have some sort of checksum on the header to prevent a random stream of bits from being loaded. So you would at least need to deal with the format.

Allen may well be right that the XC6000 series was used because they could scan bit streams and prevent destruction.

I believe that series was special in that all bit streams were safe

-Lasse

That's what I remember, but a quick scan by Google didn't find anything to support that. It was some 15-20 years ago so I can't recall for sure.