As FPGAs have gotten larger and larger, the target audience for the biggest, baddest devices has grown smaller and smaller.  These days, the audience has pretty much dwindled to a single group – those using FPGAs to prototype even larger systems.  Engineering teams designing the biggest, most complicated SoCs need as many gates worth of prototyping as they can get – and the people developing software for those systems need to start well before the actual hardware is working.

The FPGAs for this type of work come almost exclusively from Xilinx and Altera.  On the Xilinx side, the flagship is the gargantuan Virtex-7 2000T, a 6.8 billion (yep, with a B) transistor device with two million 4-input LUT equivalent cells.  The device achieves its size by 2.5D interposer-based packaging (it’s actually 4 FPGA chips interconnected on a silicon interposer) using what Xilinx calls “Stacked Silicon Interconnect (SSI)” Technology.  Altera’s biggest current prototyping-targeted device is the Stratix V E – which packs a respectable 1M equivalent 4-input LUTs on a monolithic device.  Not content to have the second-biggest chip in town, however, Altera has already announced a 4-million cell device in their upcoming Intel-fabbed 14nm FinFET-based device. 

For years, FPGA companies didn’t give the prototypers much attention.  After all, most of these folks used to build one or two prototype boards – with four or so FPGAs each – to prototype their ASIC designs.  Big customers buying 8 chips at a time was hardly a lucrative business for the FPGA companies – when compared with telecommunications infrastructure companies who were putting large numbers of the biggest FPGAs in every single production system they shipped. 

That all changed when the software component of SoC development became critical path.  With software engineers outnumbering hardware engineers by a five-to-one ratio on many SoC design projects, it just doesn’t make sense for all those software engineers to be sitting around twiddling their thumbs while the hardware folks try to get the chips working.  FPGA-based prototypes began to gain popularity as early software development platforms, rather than as simply high-speed hardware debugging systems.  Large companies began deploying prototypes in significant qualities, and that completely changed the economics of the prototyping market segment.

Suddenly, FPGA companies are stretching to build even larger FPGAs – with the needs of prototypers specifically in mind.  Witness the aforementioned V2000T, which has an “if you have to ask” price tag, yet has sold like hotcakes to the companies who produce prototyping boards.  Those companies, in turn, have seen a big jump in business as their customers went from ordering one or two (or making their own FPGA boards) to deploying standard FPGA-based prototypes en masse among their software development teams.

Where there is more money, of course, there is quickly more competition.  The field of available FPGA-based prototyping solutions has rapidly expanded from the old days – when we had two well-known options:  HAPS (originally from Hardi, who were acquired by Synplicity, who were then acquired by Synopsys), and DINI (which has been loping along nicely with Mike Dini at the helm, pumping out dozens of FPGA-covered boards for decades.)  Now, Aldec, Cadence, S2C, proFPGA, and a number of other players have rushed into the fray, working to differentiate themselves from the crowd and capture a lasting share of the loot in this expanding market. 

If you count emulators and emulator-like systems (which are often difficult to differentiate from FPGA-based prototyping solutions), there is even more confusion and chaos in the market.  Emulators are more often used during the hardware debugging and verification part of the design, and FPGA-based prototypes are more often used during firmware and embedded software development, and during integration testing.  If you’re having difficulty telling whether you’re looking at an emulator or an FPGA-based prototyping system, one easy trick is to count the zeros on the price tag.  If you stopped at five or fewer zeroes, it ain’t no emulator. 

In order to understand the finer points of differentiating prototyping solutions, we should look a bit at the challenges of FPGA-based prototyping.  We’d all like to believe that you can simply take your SoC design – all that nice HDL that you wrote (along with the IP you integrated), and drop it onto a big FPGA board, yielding a nice, speedy prototype that you can hand to your software development team (thus getting them to shut up about the hardware schedule for awhile).  We’d all like to believe that, and it never, ever happens.  Not even close.

First, the HDL that you wrote for your SoC won’t work on an FPGA.  We promise.  You may think you wrote it really carefully with prototyping in mind, and it completely will not matter.  When you run it through FPGA tools for the first time, you’re basically guaranteed to get a big frowny face with dozens of things to clean up and repair to make your code FPGA friendly.  The part of the code you didn’t write – that IP you bought from a garage shop in another country – is an even bigger problem.  It may not work in FPGAs, and you can’t do much to fix it.  Combine that with the entirely different clocking structure of FPGAs (hint: they don’t have as many clock lines as your real design, they don’t distribute them the same way, and all that clock gating you did for power optimization is gonna come back to haunt you on the FPGA version), and you get a big ‘ol headache getting your code running nicely on your FPGA boards.

Nobody has yet cooked up a solution that completely removes the pain from that phase of the prototyping operation, but Synopsys probably comes closest.  Since the company owns the most popular ASIC/SoC synthesis tool, the most popular third-party FPGA synthesis tool, and the HAPS prototyping platform, and is the largest supplier of re-usable IP, Synopsys has all the ingredients needed to help you get your new SoC design all FPGA-i-fied.  Best of all, they’ll do it for free.  Wait, that last part is completely not true – at all. 

Cadence has steadily moved into the prototyping game with increasing authority – starting more from the emulation side.  Cadence’s “Rapid Prototyping Platform” integrates nicely with the company’s other tools, and facilitates a nice transition between the Palladium emulation system and the rapid prototyping environment.  Cadence claims to handle your cross-synthesis issues and multi-FPGA partitioning as well, with their integrated compile engine. 

Aldec is a recent-comer to the prototyping game, but their HES-7 solution takes full advantage of those big Xilinx V2000T FPGAs, and it connects nicely to Aldec’s software tools – which are extremely popular with the high-rel and military/aerospace folks.  They, too, have a software tool expertise advantage that lets them help you get past that “oh crap, my design won’t work at all on FPGAs” milestone.

Since your SoC design is usually way too big to fit on a single FPGA, you also have the problem of partitioning it across multiple FPGAs.  No matter how big they make these devices, custom SoCs will always be bigger – by a significant factor.  That means that most prototypes require multiple FPGAs, and that means you’ll have to partition your design into FPGA-sized pieces.  Usually, you end up with too many signals going between FPGAs for the number of IOs, or timing problems when your critical paths cross FPGA boundaries.  There are two ways to approach this problem – manual partitioning (which has generally always been the favored strategy) and automatic partitioning using a tool like Synopsys Certify.  Certify came to Synopsys along with the rest of the Synplicity tools, and it’s been around for well over a decade.  As designs have gotten bigger, however, and as automatic partitioning technology has improved, more people are opting for the automatic or the manually-assisted automatic approach.

Another issue that can hit you with an FPGA prototype is debug visibility.  While the prototype makes your design run about a zillion times faster than it would in your HDL simulator, you have about a zillion-squared times less visibility into what’s going on with most of the signals.  That means that when you do find a bug (which is the reason you built this thing in the first place, right?), you can have a bear of a time figuring out what caused it.  The companies like Aldec and Synopsys, who offer comprehensive tool solutions along with the FPGA prototyping hardware, have a significant advantage in this area.  If you’re just buying a big board with a bunch of FPGAs on it, you’re pretty much on your own for debugging.  Also, remember that increased debug visibility is one of the biggest reasons for spending an order of magnitude more money on an emulator than your FPGA prototype cost.  Sometimes, you get what you pay for.

With all the recent competition in FPGA-based prototyping, the design community is bound to come out the winner.  There are significant challenges still to overcome in making prototyping a smooth and efficient process, and the companies that can solve those will be reaping rewards from all of our project budgets in the years to come.