There is nothing special abut ASIC, most ASIC vendors just use a custom programmed FPGA; this is called FPGA to ASIC conversion.
To get an FPGA/ASIC project of this scale done you will need 2 very good engineers forking full time for a year.
The original post has multiple false premises and therefore makes false conclusions. I'm going to address just the above two.
Bitcoin hasher is a spectacular example where full-custom ASIC implementation will be much better than the FPGA implementation.
SHA-2 is a rather rare digital circuit that is completely self-testable and observable. All the standard JTAG testing logic required in majority of digital circuits can be omitted. In fact vast majority of the internal D-type flip-flops in the hasher core don't even need the reset signal connected. Order of magnitude less power than FPGA will be easy.
Because of self-testability of SHA-2 and repetativeness of brute force hasher the overall design could be done over a couple of lunch breaks by a single engineer familiar with mixed-signal design and with access to the appropriate software tools. In addition to the above the chip is almost completely solipsist: it really doesn't have to obey any well-known interfacing standard, not even with a second copy of itself. It is sufficient to just communicate between the hashing chip and the I/O controller.
The "mixed-signal" is a key point here. Although the Bitcoin doesn't by itself use analog signals; the hashing chip is limited primarily by (1) power dissipation and (2) simultaneous switching noise. Because of the above two limitation mixed-signal experience would be a key to designing a chip that will be both efficient and will work on the first tapeout.
The optimal package for bitcoin hasher would be something like TO-220 with 7 leads:
http://www.psitechnologies.com/products/todo220.phpThe I/O would be serial, the leads would be VccI/O ClkI/O RxD TxD VccHash ClkHash and Reset. Ground would be provided by the heatsink screw pad. One could even omit reset lead by doing serial reset: hold RxD high over (say) 100 I/O clocks.
Well, from the choice of packages (all with many more pins) one can surmise that none of the Bitcoin ASIC vendors obtained the advice from the power-analog and mixed-signal designers.
I'm not familiar with the commercial toolchains used in ASIC development; but from my past experience with R&D in digital and mixed signal design I'm positive that the main stumbling block would be the learning curve required to understand and learn the tools required. This is a time-to-market or time-to-mine issue.
pcm81 didn't make any manufacturing yield claims, but other people did. The Bitcoin hasher is so repetitive that if correctly designed, with a trivial set of clock-disable-bits, the overall yield would be nearly 100% useable chips. Only the chips with faults in the I/O or clock circuitry would have to be rejected.
Some other people also made wild claims about testing effort and expense. Well, SHA-2 is essentially self-testing: it either fully works or fails nearly every test. There are no hidden states or data-conditional decision making in the algorithm. The test plan for the chip would be as trivial as it gets.
The "millions of dollars" price tags for NRE are just flights of fancy. This really is a project that could be done by a single ASIC engineer over a series of lunch breaks provided that he has both access to and experience with the required toolchain.
