This Microwaves & RF article is reprinted here with permission.
What you’ll learn:
- How to build a better silicon testbed.
- Modern software-based testing approaches can automate many aspects of testbed setup.
If we didn’t realize it before, the post-COVID-19 marketplace has been a helpful reminder of just how much our modern world runs on silicon. From vehicles to smartphones to PS5s to dog washing machines, countless industries have seen their supply chains disrupted, in some cases grinding business to a halt.
Eventually, these semiconductor shortages and production delays will work themselves out. Plants in Asia will come back online, manufacturing capacity will increase, and supply chains will return to normal. But for chipset makers, network vendors, or OEMs depending on new silicon, “normal” still leaves plenty of room for improvement.
In truth, chip design and manufacturing processes have long been plagued by delays and inefficiencies, and the prime suspects include slow, antiquated testing processes. Even when supply chains run perfectly, silicon development often consists of endless back-and-forth between design teams and manufacturers, with each cycle adding costs and delays. Bugs turn up late in the process, thousands of hours get burned fixing them, and delivery targets are pushed back months.
Now, as we rush toward a world of 800G optics, ultra-high-density data centers, and novel 5G and edge solutions, the demand for new application-specific integrated circuits (ASICs) and system-on-chip (SoC) technologies will only grow. If we’re reevaluating the semiconductor industry to try to prevent future disruptions, we should take this opportunity to rethink testing workflows as well. By embracing more modern approaches, we can eliminate some of the most stubborn (and costliest) obstacles to silicon innovation.
The Problem with Traditional Testing
The next-generation technologies planned for tomorrow’s ASICs and SoCs could come straight from science fiction. Yet, test workflows we’re depending on to bring new solutions to market feel woefully past their prime. To test an ASIC or printed-circuit-board design, we must emulate how it will behave in silicon. Historically, the only way to do that has been through physical testing with huge, hardware-based, electronic-design-automation (EDA) emulation systems.
Legacy EDA systems can only generate traffic into 20 to 30 ports at a time and require different test sets for each port and interface. For modern ICs, the process gets incredibly tedious and time-consuming. Indeed, pre-silicon verification is so slow and expensive, many companies rush through it due to cost and time pressures. Some even skip it entirely, opting to deal with any issues via post-silicon validation. Of course, this is a risky bet to take.
When a serious bug is discovered after a design is baked into silicon, companies often must go back to the drawing board, adding months of delays and thousands of hours of extra, expensive work to the project. In the worst-case scenario—uncovering a major issue after a product has already been adopted by customers—they can take a huge hit to their balance sheet and reputation cleaning up the mess. According to the National Institute of Standards and Technology (NIST), defects discovered post-release cost 30X more to correct than when identified earlier in the design process.
Building a Better Testbed
What can we do to fix this problem? We can start by drawing a line in the sand on what the “right” approach looks like: the goal should be to identify and correct most bugs before they’re baked into silicon. And to get there, we should standardize on a more modern, automated, and software-centric approach to pre-silicon verification and post-silicon validation.
The good news is that we now have the tools at our disposal to put these ideas into action. Modern EDA systems and emulators are smaller and more efficient than their hardware-based predecessors and are increasingly virtualized and cloud-based. All-software emulators can now use traffic emulation capabilities that already exist in the network. In addition, new virtualized testing systems are able to scale up to test thousands of ports in a fraction of the time of previous approaches.
Just as important, modern software-based testing approaches can automate many aspects of testbed setup—modeling complex network environments in minutes that previously took a week or longer to build manually. These capabilities empower engineers to easily modify the functional building blocks under test and emulate many more protocols and traffic scenarios much more quickly.
It’s becoming common to conduct the same number of test cases per hour that engineering teams used to test per day. With no need to learn different scripts or write millions of lines of code, even engineers with minimal test design expertise can conduct rigorous, thorough design verification and validation.
Looking Ahead
The need to speed up development of more innovative ASICs and SoC technologies isn’t going away. If anything, the emerging data-center, edge, and 5G applications on the horizon will put more pressure on chip designers and manufacturers than ever before.
We’ve all now seen just how critical an efficient, smoothly running silicon ecosystem is to millions of businesses around the world. Industry and government leaders are already taking action to add manufacturing capacity and prevent future disruptions in the global semiconductor supply chain. These are important and welcome steps. But as an industry, we can do more.
The time has come to move away from silicon testing approaches that can barely keep up with the needs of today, much less the high-pressure market demands of tomorrow. By standardizing on modern, software-centric approaches to pre-silicon verification and post-silicon validation, we can shortcut one of the industry’s most common sources of delays and runaway costs. We can ensure that when tomorrow’s technology visionaries want to bring new solutions to market, the silicon they’re depending on is ready to fuel their most transformative innovations.