I have been following the other FPGA related discussion in this thread:
https://bitcointalk.org/index.php?topic=3459858.1480and I find what whitefire990 quite telling: (quote)
"It takes quite a lot of work to transition a bitstream from private use to public use (with dev fee and anti-piracy). Since my original post May 1, the crypto-landscape changed dramatically. Luxcoin forked away from Phi1612, making Phi1612 useless. Baikal began mining Keccak with X10 ASICs, making Keccak non-profitable (and also Digital Cruncher released Keccak for the FPGA as well). The few coins on Skunkhash collapsed, making it so that Skunkhash can only support 2-3 FPGA's at the moment. The network hash rate on Tribus went up 4x (and also Digital Cruncher released Tribus first), so what this all meant is that it was better to focus on high-profit coins for public release rather than package-up old bitstreams that are useless. 0xToken is available now, and I am releasing another algorithm on August 11, and four more in early September. I am no longer going to announce which algorithms will be launched, since it was my original announcement of Phi1612 that was a major factor in LUXcoin forking (in hindsight I should have just launched the bitstream without ever announcing it first).
I hope that clarifies things. If you still want Tribus and Keccak, you can download them Digital Cruncher's github. Phi1612 and Skunkhash are available on Sprocket's github, although it isn't really worth installing them."
and this:
"So basically what I'm getting from all this is, it's very time consuming releasing bitstreams for the public which makes FPGAs vulnerable to forks just like ASICs are. FPGA can't compete with ASICs and can be forked with fairly good success since developers working on bitstreams is scarce..
As a miner you're basically a sitting duck twiddling your thumbs hoping a bistream is released before the coin forks again.
Miners like STAK, SRB and Cast (for gpus) can release new revisions with new algos within hours of a fork.
Say Cryptonight V7 forks again to V8. How long would the wait time be for a updated bitstream?"
whitefire990:
"This true to some extent, it certainly takes longer to develop a bitstream that to change GPU code. Ironically, the biggest reason for the difference is that it takes a PC seconds to recompile GPU software with a 5-line code change. Make the same tiny change in your verilog source code and you are looking at 25-80 hours for the tools to rebuild the bitstream and sometimes it can take 20 tries to get one that passes timing (hopefully run in parallel).
A developer who has built an extensive library of functions for previous algorithms can in many cases 'follow a fork' in a very short time. A developer who does not have access to the same library would take much longer.
Eventually as FPGA's get more popular, developers *will* have access to their own large private libraries of functions and will be able to follow forks pretty quickly, say about 7 days lag time."
So basically, FPGA programmers seem to be also facing the problem of forks and cannot really react quickly enough. They are becoming secretive in their pronouncements, fearing the quick chamges they cannot respond to. They are also facing competition from ASIC designers.
I am actually losing hope that there is a chance to avoid ASIC dominance and that FPGAs are not the answer. I am not interested in experimenting with some obscure coins.
What do you think?
Ps. The dead silence from Squirrels about the results of their tests is not encouraging either.