FPGA prototyping
What is FPGA prototyping?
FPGA prototyping is a well-established technique for verifying the functionality and performance of application-specific ICs (ASICs), application-specific standard products (ASSPs) and system-on-chips (SoCs) by porting their RTL to a field programmable gate array (FPGA).
It is being used more widely today because hardware complexity is increasing and the amount of related software that needs validating is rising.
Why do companies use FPGA prototyping?
FPGAs have been used to verify comparatively mature RTL because they can represent a near – though not precise – replica of a design running at speed. These replicas are also often portable enough to be used in field tests. In pure hardware terms, FPGA prototyping has been made easier and more powerful because the FPGA vendors move to the most advanced manufacturing process nodes as soon as possible.
Now that software often represents more than half of the design effort, an FPGA implementation of an SoC’s RTL can be also used as a basis for software development, hardware/software co-verification, and software validation – all before final silicon is available.
All these factors help cut design cost and time-to-market by reducing the risk of respins. For example, software that has been extensively validated on an FPGA prototype should be more easily married to the actual first silicon when it arrives from the fab. The FPGA prototype can also be used to set the path for any possible post-silicon debug.
A working FPGA prototype can also be used for product demonstrations and field trials.
What other prototyping approaches are available?
FPGA prototyping is not the only prototyping option for SoC or ASIC developers.
Virtual prototyping is available at the electronic system level (ESL). It can be used to define and validate portions of a design such as the processor architecture, power management scheme, and some software code.
RTL simulation can provide a lot of visibility into how the design code is working, though at much slower speeds than a real device would run.
Emulators are pre-packaged prototyping FPGA arrays that offer comparatively high debug visibility and run faster than simulators.
Hardware accelerators lie between simulation and emulation, offering some of the benefits of each.
These techniques will be considered in subsequent Tech Design Forum Guides, which will be linked from this page as they are published.
These approaches do not compete directly with FPGA prototyping, since today’s designs are often so complex that engineering teams will use some or all of them at various stages in a design flow.
Given the increasing use of FPGAs as development platforms during the wait for first silicon, it follows that the RTL of the design will typically have reached an advanced stage by the time it is mapped to the FPGA prototype.
What are the benefits of FPGA prototyping?
Performance
FPGAs are usually built on the latest manufacturing processes in order to achieve the highest densities and operating speeds possible. Even FPGAs built on mainstream processes offer high gate-equivalent counts (FPGAs are usually measured on how many standard look-up tables they can accommodate). According to off-the-shelf board vendor Polaris, two Xilinx Virtex-7 devices can offer the equivalent of 48M gates – enough to host nearly 85% of the SoC designs currently undertaken.
Designs which outstrip the capacity of the largest FPGAs are sometimes prototyped on multiple FPGAs. This makes mapping the source RTL to the FPGA prototyping environment more difficult, and is likely to reduce the prototype’s performance.
Cost
FPGAs are volume-produced chips with competitive pricing. A number of companies – notably The Dini Group, S2C, Polaris Design Systems and Synopsys (HAPS) – integrate them into off-the-shelf (OTS) prototyping boards, although some companies prefer to build their own prototype printed circuit boards (PCBs). This so-called ‘build vs buy’ debate is discussed further below.
Infrastructure
Both major FPGA vendors (prototyping market leader Xilinx and its rival Altera) offer extensive tools to support their products. They also have alliances with the major EDA vendors, which offer software suites with enhancements for FPGA prototyping.
Cadence Design Systems offers the Allegro FPGA System Planner. Mentor Graphics has linked its Precision Synthesis tools to the Certus and Corus validiation and debug tools offered by Veridae Systems. Synopsys offers OTS boards, and the Synplify Pro and Premier synthesis tools (which added significant features in the April 2012 release).
Other OTS board vendors also have partnerships with these and other tool vendors, as well as their own software.
In 2011, Synopsys and Xilinx released the FPGA-Based Prototyping Methodology Manual. The book, published by Synopsys Press, inevitably addresses specific case study projects through the two companies’ own products but in more general terms aims to describe a vendor-neutral approach to structuring a prototyping project with programmable logic. You can read a sample chapter that offers their perspectives on many of the higher-level issues discussed in this guide, or access more details on the manual as a whole and download the e-book version here.
Portability
FPGA boards can be tested in the same noisy environments as will confront the final SoC. This has benefits for products intended for use in portable consumer devices, as well as in the industrial, communications infrastructure, medical, and military/aerospace markets.
Availability
The relatively low cost of an FPGA prototype means that companies can often afford to build several of them, which accelerates hardware verification, software development, hardware/software co-verification and software validation. Each team can have its own prototype, possibly several.
What are the challenges with FPGA prototyping?
There are technical and commercial challenges to FPGA prototyping.
The technical challenges
Partitioning
Large designs may have to be split up (partitioned) across multiple FPGAs to achieve the required gate capacity. This task is often cited as the greatest challenge with FPGA prototyping.
Partitioning involves estimating the number of FPGAs necessary to hold the design, and either buying an OTS board (available in various configurations) or building one to hold that many FPGAs. You can estimate how many FPGAs to use by allocating each major functional block in the design to one device, or pre-synthesize the design and work from the results. You can also take advantage of standard third-party IP blocks offered by silicon and OTS board vendors, allocating one FPGA to each block used in your design. Similarly, you need to decide which accessories, such as daughterboards, you will need: ‘proven’ versions of these are available.
The partitioning process itself is likely to be a tricky, iterative process involving numerous judgment calls to map the design to the devices, and filter out and correct mapping errors from actual errors in the RTL or software. Is the utilization-per-FPGA optimal? What about memory requirements? What about I/O and interconnects?
Manual intervention
FPGA prototyping is likely to demand several types of manual intervention.
As the original design RTL is translated to the hardware description language (HDL) required by the FPGA synthesis and layout tools, it is likely that some manual coding will be required to make the prototype work, even if tools have automated much of the translation. It is also quite likely that the engineers who originated the design will be unfamiliar with the HDL coding style for the FPGA. Consequently this can be a lengthy and error-prone process.
Various aspects of the mapping present challenges. Clock tree routing on the FPGA (particularly where the original design has gated clocks) is notoriously difficult. Prototype performance will be hit if critical paths are allowed to run over slow chip-to-board-to-chip paths. Memories and encrypted blocks in the original can also present major difficulties.
For many of these aspects of a design, one-to-one mapping is not possible. Make sure that you have the resources and expertise to handle the more difficult parts of the transition – also potentially the most sensitive parts of your design as they contain its differentiation.
Debug visibility
The workload represented by the two challenges above illustrates why FPGA prototyping is best undertaken with mature RTL code that offers few surprises. The challenge of ensuring visibility for debug rams the point home.
There’s been an issue with getting enough visibility of a design for effective debug ever since the first single-FPGA prototypes. The visibility that is available tends to be confined to individual FPGAs, making debug visibility even more difficult on designs mapped across multiple FPGAs.
Compilation time
Historically, engineers have compiled an FPGA prototype until an error stopped the process. They would fix that error and then resume the compile from the beginning. The potential delays here are obvious. In the latest release of Synplify Premier, Synopsys has incorporated a ‘continue on error’ feature that seeks to relieve this problem. Instead of stopping, the compile will continue and produce a single list of collated errors at the end. (This is not like RTL simulation in which you can encounter an error, fix it and continue from that point.)
The commercial challenges
Time-to-prototype
Some FPGA prototypes have remained unfinished when the first silicon they were supposed to be prototyping arrived. It is a fact of life.
Design managers worry about committing major engineering resources to a prototyping project that runs a risk of failure. The reality is that most failures are the result of not undertaking a thorough risk assessment before work on the prototype begins. What are the appropriate resources and are they available (either in-house or externally)? What methodology is being applied (several are available and discussed below)?
The FPGA prototyping process is becoming more automated, but it would be foolhardy to assume that the design team would not have to make any manual interventions other than those which relate to fixing errors uncovered by a satisfactory prototype. Rather, make a studied and conservative estimate of what is required within the time available.
Build vs buy
One of the most active debates around FPGA prototyping is whether you should source FPGAs and build the PCB yourself, or buy an OTS board and tailor it to your requirements. The answer is, “It depends on the project.”
The ‘build’ side of the argument says that OTS boards are too inflexible to cope with the rapidly changing demands of increasingly complex projects. It continues that although developing your own PCB does entail significant time and effort, there are tools available to assist in this process in a more cost effective way than paying for an OTS equivalent that might not meet your requirements anyway. The ‘build’ side of the argument also points to limited bus widths and operating frequencies for OTS boards.
The ‘buy’ side of the argument says that claims about inflexibility are overstated and that building the PCBs required for advanced FPGA prototypes adds further layers of complexity to the design process. It also says that building your own board could affect time-to-prototype and perhaps even time-to-market. Further, OTS boards are ‘proven’ both in terms of the silicon on them and the interconnects, other local features and availability of accessoriesm such as daughterboards to connect to external systems with which the final silicon may interface. ‘Buy’ proponents also point to boards are also designed to match the performance of today’s FPGAs.
So, is it worth it?
FPGA prototyping is a valuable strategy especially for projects with high embedded software content that address highly time-sensitive or demanding markets.
One recent survey found that half of embedded software projects miss their deadlines and 44% fall short of the functionality originally envisaged. If nothing else, FPGA prototypes enable the software team to start work sooner on the final system integration.
FPGA prototyping provides the most effective ways of performing thorough hardware-software co-verification, particularly at critical stages lower down the stack, and final validation prior to the marrying of software code with final silicon.
The question of whether to undertake an FPGA prototype will largely rest on whether your team can balance the risks and resources needed to undertake what is a complex and often very difficult task.