> As a final point, consider that your precious C programs and the C compiler can only run because of the CPU, which was not written in C nor in any Von Neumann language - oh no, they were written functionally, with only logic gates, in a dataflow-oriented way, because you know, they really needed this to work. HDL's are not "only" logic gates. Have you developed anything substantial in a HDL? I'd think the lack of recursion alone would cleanly delineate them from anything functional. My own work with FPGA's started without language, literally wiring things together in a GUI. That's the legacy ASIC design descended from, not a functional ivory tower.
> That's why CPUs don't have bugs - they picked a better starting language than C, with a principled approach (logic) that is amenable to mathematical verification. iHDL is not a "better" language than C. Imagine having to specify the exact opcode you wanted the linker to emit for a particular instruction, that's the level of dipping into implementation details that HDL's allow. It's not uncommon to have "behavioral" code that is checked in concert with the rest of the design, "implementation" code representing the actual circuit, and some poor engineer tasked with signing off that the two are equivalent without the ability to simulate all inputs. Formal verification is a specialized technique that is only used on vanishingly small parts of the design. At no point in the consideration of an HDL for a new design is "amenable to mathematical verification" given weight.
Another slight problem with your argument: CPU's DO have bugs. Google up "Intel Errata" and prepare for your stone castle to be torn apart. If you'd like to duck this and say that they're esoteric and don't matter, I'd really like to know what you think about the TSX-killing errata that's essentially set back parallel computing in a measurable way. Why wasn't this subjected to formal verification magic?
> Guess what - functional programming languages are also increasingly more amenable to mathematical verification. Once this is popularized, you'll be delegated to maintaining the old sand castles from dinosaurs while we will be building stone castles over here. Join us. :) You don't understand what you're comparing to with enough fidelity to trust the end result.
The easiest way to imagine a CPU design team is that it's Just Another Software project. The only extra constraints are that you can't run it full speed. You can simulate a 5GHz chip at 5Hz with SW-like visibility. At some point in the alpha, the team will spend a few million dollars to wait 8 weeks to get a few dozen test chips that will run at full speed, with near-zero visibility. So the question is how much extra unit testing would you do, on each of those models, with those kind of timelines.
Formal verification doesn't make a dent on modern CPU design. It's all these extra considerations (read:bodies) taken during the design process that make up the gap. Please, try to educate yourself before going off on half-baked assumptions based on superficial similarities.