FPGA-based prototyping is now indispensible for SoC and ASIC development.
By Ann Steffora Mutschler
No longer a ‘nice to have,’ FPGA-based prototyping is now indispensible for SoC and ASIC development. Semiconductor companies are investing in the infrastructure, the EDA tool chain, the human resources and everything needed to set up an entire department to focus on prototyping, emulation and validation.
“We are seeing these customers invest in significant amounts of equipment because if you look at a lot of these different companies are not just building one chip. They are doing one chip this quarter and they are doing another one next quarter,” observed Kirk Saban, a senior product line manager at Xilinx.
As the name implies, FPGA-based prototyping tools allow a design team to map their RTL code into one or more FPGAs to allow for analysis, debug, and software development long before the actual chip is manufactured. The beauty of this technology for the user is that because the FPGAs are programmable, investment can be made in a hardware infrastructure and scaled up as the need arises.
Driving the use of FPGA-based prototyping is partly due to shrinking process geometries. The mask cost to spin an ASIC at those geometries goes up every node and the barriers of entry to play in that game are very high, he noted. Another market driver is the explosion of smart devices, mobile handsets and tablets—all of which contain multiple processor cores. “If you crack open an iPhone or an iPad or Samsung tablet they all have a system-on-a-chip in there that has multiple processor cores with some custom logic around it. Everybody wants a new gadget every 18 months so all the guys that build these chips have to crank them out at that pace, and the only way they can do that is by turning to this approach to validate their methodology,” Saban asserted.
From the IP provider perspective, Javier Orensanz, director of product management at ARM, said the company is working with partners to improve the software debug experience. “In general, the areas where we focus are modeling software development on processors that are either inside or implemented alongside FPGAs. The big problems for the software developer are actually quite similar to the ones that the silicon vendors face. So when we are talking about hardware, which is buggy or nonfunctional, software-hardware integration problems, issues that happen at the boundary with the FPGA itself and the FPGA subsystem—these are normally the ones that are causing most problems today. The difference between a software developer working around an FPGA and a silicon vendor is that normally OEMs don’t have access to the EDA simulation tools and the development tools that are available for the silicon partners.”
What this means is that the software developer doesn’t always have the visibility into the hardware that they may need, which is what the prototyping provides. There also are specific technical challenges between the FPGA and the CPU that are design-dependent.
“It really depends on the hardware design,” said Orensanz. “Some do a better job than others in providing enough hooks into the subsystem. If the customer designs extra holes on the FPGA, somehow they need to make them available for connection of a debugger to the main data interface of the FPGA. Otherwise they may not be able to have a software debugger connection of all the signals in the system. And then, if we want to concentrate a system trace on some corners of the FPGA, again you need to provide trace interfaces that connects both the FPGA subsystem and the CPU subsystem.”
As such, the ability to thoroughly debug is crucial. Fast turnaround time is needed to locate problems, as well as having as much debug data as possible for greater visibility into the correct module in the design where the bug is occurring.
“We support what is known as real-time debug,” said Mick Posner, director of product marketing for FPGA-based prototyping at Synopsys. “Customers like to use logic analyzers if there are signals or I/O interfaces that they want to see. You can select that to be real time debug to route it out to a standard Mictor card, they plug their logic analyzer in that has fundamentally virtually unlimited storage. Part of that real-time debug flow is also to set up that analyzer to capture those signals. During those early stages of bringing up the system you want that rapid turnaround time, you want to over instrument and look at everything; later on in the design cycle you will probably want a deeper visibility.”
Both Synopsys and Xilinx offer debug tools. Xilinx’s approach is more geared toward debugging at the multi-chip partitioning level, though. “What we see is that most of the customers that are using these types of systems are building very large ASICs and SOCs and typically—even with our very largest chip—they need more than one of them to be able to prototype their ASIC so they need to figure out how they are going to partition their ASIC into multiple FPGAs to be able to prototype it and emulate it,” Saban said. “The ASIC prototyping guys are taking it to another level where they are having to take a huge ASIC and split it into two or four or six or eight [Xilinx] 2000Ts and figure out how to make that all speak together through multiple connectors on HAPS board. Or they’re building their own board with 8 of our largest FPGAs on it and figuring out how they’re going to partition that and debug it, and make it all work together.”
The good news is that with the FPGA-based prototyping market growing at a fast clip, leveraging the latest-generation FPGAs, and tool vendors trying to capture their share of the market, users will benefit—especially because it is non-negotiable to utilize this technology going forward in SoC and ASICs.
Leave a Reply