Synopsys Cloud
Cloud native EDA tools & pre-optimized hardware platforms
Request a Free Trial →
In their recent ¡°¡± article, industry thought leaders Joe Convey and Bryan Dickman refer to the need to ¡°scale-up¡± system-level validation capabilities as ASICs trend towards multi-billion gate designs in key market segments such as artificial intelligence/machine learning (AI/ML), enterprise servers, storage, networking, 5G, IoT, automotive, and many others. At the same time, there is a need to ¡°scale-out¡± capacities to enable quadrillions (maybe more) of accumulative pre-silicon validation cycles ¨C what Joe and Bryan refer to as ¡°deep cycles.¡± We need to scale-up to cope with ever larger SoC footprints for sure, but why do we need to run so many validation cycles pre-silicon?
The problem comes when you reason about how few validation cycles normally get run pre-silicon due to the vast speed gap between validation platforms such as simulation and actual silicon. Even scaled-out on-prem, or cloud compute, doesn¡¯t get close. Remember that your production silicon will likely operate at a multi-GHz clock frequency, and there will be multi-millions of them deployed into end-products!
Approximating to Silicon Throughput Levels
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 ¨C that¡¯s 15s on a 2-GHz device, but only ten minutes on a 50-MHz FPGA ¨C 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.
HAPS-100 Meets Scale-Up and Scale-Out Challenges
This demand for more capacity to support both software developers and system validation is driving the trend towards centralized FPGA prototyping farms. This is exactly what we at Synopsys have been seeing with many customers now scaling out their FPGA prototyping capability using the HAPS? solution. HAPS?-100 prototyping system modules (shown above) are designed for both desktop and server rack configurations, supporting up to eight modules in a standard 19¡± wide 42U (6¡¯ high) equipment rack. Thus, prototyping systems can easily be co-located with compute farms, networking hardware, and other electronics systems in a server room.
Other advantages come with centralizing your FPGA prototyping resources such as supporting multiple users, achieving high resource utilization levels, and managing the estate in terms of maintenance, resource allocation, and capacity management. HAPS Gateway software provides all the necessary tools to manage your prototyping estate efficiently, supporting multiple distributed users. A centralized prototype farm enables much higher utilization, lowering the total prototyping cost. Eight HAPS-100 modules support up to thirty-two users, who may be spread among diverse teams and multiple geographies. With this sort of capacity, you can support both the software development teams and the system validation teams.
HAPS prototyping software builds upon Synopsys¡¯ 20+ years of experience in FPGA synthesis and delivers the highest performance using timing optimization for the direct connect architecture. Synopsys customers also benefit from Synopsys DesignWare? IP Prototyping Kits, which are critical to accelerate IP integration, software development, and system validation.
Summary
As an experienced system validation engineer, you will sleep better knowing that the target software executes and performs well on the hardware design prior to tapeout, and you have demonstrated this software running under a broad range of conditions and configurations. When hardware bugs have been encountered, you have been able to use the extensive and performant debug capabilities of HAPS to solve hardware problems quickly and get back up and running.
Choosing not to perform system validation at the deep cycles scale means flying blind into hardware tapeout. Costs and reputations are at stake!