EDIT: by resources, I mean, the specialized logic and chunks of RAM that exist inside FPGAs.
Found it: https://groups.google.com/forum/#!topic/comp.arch.fpga/BTojR...
I suspect that the reason everything is taking so long is that they have to re-write so much of the core stuff (standard library, OS, drivers, etc). But once you can boot linux on a very slow FPGA I can't see a lot of reasons not to start making the ASICs.
However, to get it into fast and power-efficient silicon is still a ridiculous amount of work. FPGA technology is vastly different from directly designing VLSI circuits. For one thing, they'll most likely have to use different pipeline designs to squeeze the cycle times low enough.
I worry that the Mill people are vastly overconfident. There are very interesting ideas there, but I suspect that they are trying to improve so many aspects of a CPU at once that they will be unable to execute any of them well. The end result is likely that sub-par execution leads to inefficiencies that accumulate to the point where any of the theoretical advantages of their design gets overwhelmed - especially since many of their ideas can be integrated by competitors as well. That said, I'd love to be proven wrong here.
The really interesting thing about the Mill is that it does away with a HUGE portion of what a CPU does: out-of-order execution (OOE). These days the amount of die space that's dedicated to reordering and dependency checking and the commit engine is substantial, and that stuff really slows a processor down because the thing that are happening at the end of the pipeline depend on what's happening at the beginning. At 4GHz the best-case scenario the wavelength is 75mm, and the 1/4 wavelength is thus 19mm, on the order of the size of the die!
What the Mill does is push the reordering and dependency checking to the compiler so that the hardware itself is "dumb" at least insofar as not doing all the checking for OOE and multiple dispatch, etc. Further since the instructions are ordered as blocks and that blocking is done by the compiler, the processor doesn't even need any logic to assign instructions to functional units; that's done at compile time.
I agree that fast and power efficient silicon is a challenge, but again because they're not mixing execution with reasoning about execution (OOE, multiple dispatch, commit engine, etc) it's much, much easier to make the layout fast. I believe that instructions and data will flow through the Mill in a way that makes regular CPU architects envious.
I still suspect that a huge amount of the delay is due largely to the general weirdness of the architecture; it's not like an x86 to ARM port because those have a lot of the same basic assumptions baked in and the only difference is the instruction and data encoding. On the Mill few of the assumptions are the same and so you might have to re-write a LOT of code to boot a Linux kernel.
In the end, I have only seen CPU design from a physical design tool support point of view. I don't really have the necessary experience to judge the relative complexity of out-of-order+register renaming vs. whatever the Mill aims to do. You're probably right that the Mill is simpler.
Part of it is that all we really know about all this comes from a bunch of talks that focus on what the Mill looks like to the user. Who knows what their physical design story is. I just hope, for their own sake, that they have been working on that part of it for a significant amount of time as well.
I suspect they use the same machinery for that as they use for handling mispredicted control flow and interrupts/exceptions/faults.
If that happened, I would figure out why before spending $$ on that ASIC.