If there is one overriding success story in the semiconductor industry at the present time, it’s the exploding use of programmable logic devices (PLDs) in general, and field-programmable gate arrays (FPGAs) in particular.
The current state-of-the-art FPGA devices at the 45/40 nm technology node boast hundreds of thousands of look-up-tables (LUTs), thousands of DSP cores, multi-mega-bits of memory, and thousands of general-purpose input/output (GPIO) pins coupled with a humongous serial I/O bandwidth. These devices are now making their presence felt in a vast range of applications across multiple market segments, including aerospace and defense; automotive, broadcast, and consumer; high-performance computing (HPC); industrial, scientific, and medical; and wired and wireless communications.
Combine that with the dynamic nature of many end markets – evolutions in standards, market-specific feature requirements, and the need for real-time product updates – and there really is a sense of the “Programmable Imperative,” as Moshe Gavrielov of Xilinx calls it.
Altera and Xilinx have already announced that they are working on their next-generation FPGA families, which will be implemented at the 28 nm technology node. These devices – which will offer significantly more capacity and performance – will allow FPGAs to displace still more ASIC and ASSP seats. In fact, ASIC and ASSP design starts now account for only a few thousand projects per year. By comparison, there are believed to be more than 100,000 FPGA design starts thus far in 2010 alone. Some of this is owed to their use as ASIC/ASSP prototyping platforms, but unquestionably today’s modern FPGA is a viable high-performance, high-volume option for production use.
iSuppli Corporation, a leading market research firm focused on the electronics value chain, defines "core silicon" as PLDs, application-specific integrated circuits (ASICs), and application-specific standard products (ASSPs). According to an iSuppli report published in September 2010, PLDs will grow the fastest among the three major core silicon segments, finishing the year at $4.7 billion, up 43 percent from 2009 levels.
Similarly, the electronics industry market research and knowledge network – Electronics.ca – recently announced the availability of a new report entitled "Programmable Logic ICs Market Shares and Forecasts, Worldwide, 2010-2016". This report notes that programmable logic vendors are able to address an increasing number of ASIC and ASSP opportunities. As a result, the report predicts that the PLD market will rise to $9.6 billion by 2016.
The verification gap redux
But haven’t we heard this story before, when ASICs were taking hold, taking share from less customizable options? It all sounds great until you realize there are significant design challenges, most notably in verification, that are in the way of taking advantage of the great potential. Back in the day, there was a “verification gap” in the ASIC domain and these days we’re seeing a similar situation in the FPGA world as illustrated below (source of FPGA capacity = vendor websites; source of verification capability = GateRocket):
The FPGA Verification Gap
Newcomers to FPGA space often have an underlying belief that working with these components is relatively easy, fast, and painless. This may have been true in the early days when FPGAs contained the equivalent of only a few thousand logic gates. But today's state-of-the-art FPGAs are a completely different ballgame. It's true that FPGA design tools have grown alongside the devices in terms of capacity and performance. The problem is that the technologies used to verify FPGA designs have not kept pace. The result is a new version of the "verification gap."
In the ASIC world, this gap was addressed by a variety of techniques, including hardware acceleration and emulation. But these technologies are not applicable with regard to verifying FPGA designs because of nuances in the FPGA design flow such as the inability of traditional emulators to natively consume FPGA IP.
The verification problem really becomes acute when the design appears to function as planned in the software simulation domain, but fails when it's moved over into an FPGA on the workbench. What do you do when the physical device fails to perform as expected? The traditional solution is to add instrumentation into the design to monitor selected signals, then re-synthesize the design, re-load it into the FPGA, re-run the test-bench, and keep on cycling around and around trying to hone in on the problem area. This process is resource-intensive, time-consuming, error-prone, and very unproductive for large designs, to say the least.
Closing the verification gap
To date, the best verification solution for FPGA designs is a "Device Native" approach in which a physical FPGA runs in conjunction with the software simulator – much like an emulator does but with the native FPGA device. Some would call this a Hardware-in-the-Loop (HIL) solution, and it is like that -- but different in a very important way. Traditional HIL solutions have significant limitations because the hardware is the constrained item. Therefore, the design or a portion of the design has to be modified to conform to it, which means that you cannot perform significant or complete design verification without a significant engineering effort. With a Device Native "emulator-like" solution, the design is the constrained item and the hardware conforms to it with the ability to handle anything the FPGA design can throw at it.
Using this technology – combining conventional simulation with a physical FPGA device and an advanced debugging environment – it is possible to very quickly detect, isolate, identify, and resolve bugs, irrespective of where they originated in the FPGA design flow while accelerating verification. The result is a closing of the FPGA verification gap, enabling the electronics industry to fully realize the benefits of the “Programmable Imperative.” GateRocket is proud to part of the evolving ecosystem that is enabling this type of progress. Please visit our company, GateRocket (www.GateRocket.com
) for details on a solution like the one I describe here.