As Joe and Bryan point out, modern FPGA prototyping systems can get you within one or two orders of magnitude of silicon speed. If your design achieves an FPGA clock speed of, say, 50 MHz for example, then with 20 instances you have in aggregate a 1-GHz capability in terms of throughput in cycles! So, think multiple systems (i.e. an FPGA prototyping farm) and you have the equivalent of a silicon device, or devices, to play with. It’s the closest approximation to silicon throughput achievable without having actual silicon!
With this scaled-out capacity you can support both your software developers and your system validation teams. While the software development team focuses on software development and software validation, the system validation team can build a hardware test plan that covers significant volumes of real-world software such as the OS, firmware, device drivers, applications, benchmarks, test suites, and stress testing payloads. The total combined hardware and software configuration space can be huge, and you will need a strategy to cover the configuration space, ensuring that all known use cases are validated. You can see how this cycle requirement grows rapidly and will require a methodical approach to completing the system validation test plan, involving multiple builds of the hardware FPGA prototype models, along with multiple parallel execution runs. Remember that these software payloads consume many cycles. Android alone can take 30 billion cycles to boot – that’s 15s on a 2-GHz device, but only ten minutes on a 50-MHz FPGA – not even enough time to grab a coffee! In addition, you want your FPGA prototyping environment to interface to real-world I/O so that you have realistic system traffic profiles acting in concert with your realistic software payloads. Don’t expect to find huge numbers of hardware bugs at this stage. If you do, you may need to revisit your simulation or formal verification environments. It remains the goal to wring out all of the easier-to-find and most of the hard-to-find hardware bugs in these environments. However, it remains the case that certain bugs will only be found when running realistic software payloads at the system level. When you do find bugs here, you’ll know that you have saved an escape that would otherwise have made it into the silicon. The costs to fix bugs post silicon can be catastrophic, as we know.