FPGA for Evolvable Hardware Implementation

[Altera_Forum]

Hello, which FPGA device is suitable for working on the topic evolvable hardware? I'm planning to use this method: 1. Generate random Bitstream 2. Load Bitstream to FPGA 3. Fitness-Test 4. Modify Bitstream via Genetic/Evolotuinary Algorithm 5. Go to Step 2. [Until perfect solution is found] I already bought a Xilinx Ml310 Development Board as shown here: http://www.xilinx.com/products/boards/ml310/current/ Unfortunately I've come to the conclusion that this device might not be a good way to start this project, because I can't find much information about bitstream-manipulation from Xilinx-FPGAs in general (I've found the tool JBits, but I can't find useful documentation nor the SDK itself). Also In the end I want to reproduce experiments like this from Dr. Adrian Thompson with his tone discriminator: http://archive.bcs.org/bulletin/jan98/leading.htm Can anyone give me some advice on which device I should buy and which lectures I should read before I start this project? I would prefer a chip which is easy in handling the bitstream manipulation, because that's what is the evolutionary process is all about. Thank you for your support and sorry for my bad english :) Sincerely, Dude

[Altera_Forum]

I don't think it is feasible.. bitstream encoding is proprietary

[Altera_Forum]

Cool idea, but I have to agree it's not feasible based on random bitstreams. The fact that the encoding is proprietary may not seem like a problem since you don't care what the bits do, only how the configured chip responds, but the xc2vp30 bitstream is 11,589,920 bits long and has CRC checks throughout if I remember correctly. I don't know offhand how large the CRC-protected blocks are or how many bits of CRC are used, but suppose it's CRC16, that would mean that only one in 65536 of your random bitstream BLOCKS would not trigger an error that prevents the configuration from completing. If there are (making this up) 64kb per block that means 176 blocks per device, and a random bitstream has only one in 64k^176 = 5x10^847 chance of completing configuration, everything else will have equal fitness of zero. So you have to use some kind of tool that knows how to create a viable bitstream. Even if you do, there is such a large design space in that part that I have to think it will be centuries before you get the first wiggle of an output pin and any hint of fitness to your goal. 

 If this doesn't deter you (which I'll applaud!) I'd recommend the smallest / simplest device you can get, like a Spartan 3S50 which has "only" 430kb of configuration. That's assuming you can get or derive a tool that fixes the CRC issue for you.  Good luck!

[Altera_Forum]

Wait, why are you asking about Xilinx parts on an Altera forum? Please change my recommendation from Spartan to the smallest Cyclone available, I forgot where I was....

[Altera_Forum]

--- Quote Start ---  Hello, which FPGA device is suitable for working on the topic evolvable hardware? I'm planning to use this method: 1. Generate random Bitstream 2. Load Bitstream to FPGA 3. Fitness-Test 4. Modify Bitstream via Genetic/Evolotuinary Algorithm 5. Go to Step 2. [Until perfect solution is found] I already bought a Xilinx Ml310 Development Board as shown here: http://www.xilinx.com/products/boards/ml310/current/ Unfortunately I've come to the conclusion that this device might not be a good way to start this project, because I can't find much information about bitstream-manipulation from Xilinx-FPGAs in general (I've found the tool JBits, but I can't find useful documentation nor the SDK itself). Also In the end I want to reproduce experiments like this from Dr. Adrian Thompson with his tone discriminator: http://archive.bcs.org/bulletin/jan98/leading.htm Can anyone give me some advice on which device I should buy and which lectures I should read before I start this project? I would prefer a chip which is easy in handling the bitstream manipulation, because that's what is the evolutionary process is all about. Thank you for your support and sorry for my bad english :) Sincerely, Dude  --- Quote End ---    how can one be certain that generating random bits will ensure a specific circuit implementation on a FPGA , say e.g when implementing a Adaptive Neural Network i wanted to add adders and delay lines on the path to feedback circuit and i want that control logic would implement as many of them as required or when the required pattern is detected . Therefore the master processor had to generate a new config file with added feedback path , the bitstream had to be of certain format so that FPGA JTAG decoder could implement it and input and output signals would land on pins where i expect them to be .

[Altera_Forum]

Also random configuration could be dangerous - if you happen to generate a bit stream which happens to pass CRC checks, it could also happen to implement a design where a LUT output is connected back to its input with a not gate design - that would oscillate very very fast and possibly burn out the cell.

[Altera_Forum]

Work of Dr. Adrian Thompson works only because of crosstalk, a very undesidered design that works only in very tight conditions of PVC.. not the way..

[Altera_Forum]

--- Quote Start ---  Work of Dr. Adrian Thompson works only because of crosstalk, a very undesidered design that works only in very tight conditions of PVC.. not the way..  --- Quote End ---    Amusing! From the article: "Adrian Thompson's research has progressed so far that he no longer knows how his chips work." I'm glad someone was able to figure out how the circuit was really working.   Dude, if you really want to explore this idea I would suggest the following approach: Take an RTL model of a single FPGA logic cell, including all the internal configuration. Pick any FPGA family such as the one on your board. Allow yourself up to N instances, and the configuration of those devices will be part of the genome. Then devise a way to map another part of the genome to random connections between those components, including tying various inputs to 1 or 0. Now you can build a simulation model, connect it to your testbench, and get results. Shuffle & mutate genes, repeat. I think that would be interesting by itself though I don't know how useful it might be. The next step would be to include delays for both logic and wiring, and if that's done then you could run any resulting design on your hardware. If that's not enough for you then include memories and multipliers in the mix with the logic cells.