The obvious reward for the FPGA prototyper's hard work is a bug-free Asic design ready in time for the tape-out. However, another benefit of prototyping is that the software embedded into the Asic or SoC can be integrated with at-speed hardware much earlier in the project.
Why prototype?
Since many unforeseen software bugs are related to the complexity of integrating operating system (OS), applications and hardware, an at-speed FPGA prototype allows for many extra months of rigorous software testing at the crucial integration stage. This benefit is multiplied again if clones of the FPGA prototype are proliferated to many software labs. The availability of high-quality, off-the-shelf FPGA boards make this a question of economics rather than time.
The software can be put in the hands of a large number of potential users who will surely find a multitude of ways to lock up the OS, crash an application or generally do things that the software engineer never imagined.
When to Prototype
It is obviously valuable if debug is performed before the SoC design is signed off. Fig. 1 shows the typical emphasis on simulation, emulation and prototyping during the various stages of a large Asic project. As can be seen, FPGA prototypes are mostly used as the project requires high speed and capacity during the integration stages.
Consider the case where the ideal fix for a software integration problem lies in a hardware modification. For example, this may involve the extraction of a cycle-hungry DSP algorithm into a co-processor or tailored device logic. If the point of discovery of such a requirement occurs after the SoC is already a long way through tape-out or maybe even finished and sampled, then it is unlikely that the required change to the device will be considered; whatever the benefit to the end product.
Fig 1. The relative usage of different verification techniques during a project
The challenges of prototyping
Surprisingly, creating the hardware itself is not the most challenging problem. Indeed, purpose-built Asic prototyping boards, such as HAPS are available from a number of vendors. The real challenges occur when trying to implement the design in the FPGA.
Partitioning and I/O handling
Even though today's largest FPGAs can handle over two million Asic gates each, many Asic designs are far larger still. This requires that only a critical part of the SoC is prototyped or that the design must be partitioned across multiple FPGAs. This presents some interesting obstacles because our whole purpose is verification, and therefore the goal must be to partition with as few changes to the Asic RTL as possible. Partitioning the design creates artificial boundaries and for designs with wide internal buses or wide datapaths partitioning can cause an explosion in the number of required I/O pins. The FPGA's pins become the limiting resource, even when using the latest FPGAs with over 1000 I/Os each.
Extra I/O resource can be created by muxing multiple signals onto the same FPGA pin, then demuxing at the target FPGA. Once again, we do not want to change the Asic RTL to make this possible so automatic pin-multiplexing is performed. This would clearly introduce some performance penalty; however, FPGAs have fast enough I/O that, even when multiplexed, they still deliver sufficient performance to validate complex embedded software "at-speed".
Fig. 2 Automatic Gated-Clock Conversion
Topographical changes without altering RTL
With some manual intervention and designer intelligence we might alleviate the I/O limits by replicating sub-block into more than one FPGA, reducing the need for interconnect between them. Further specialized operations on RTL, such as bit-slicing low-level gates or zippering more complex blocks (both possible without RTL changes) will further reduce the need for FPGA I/O.
Asic clocks and FPGA clocks are not the same
Additional problems facing the team when porting an SoC design to an FPGA are that little or no regard for the FPGA may have been given by the authors of the original RTL. Asic cell instantiations or RAM BIST are two examples of FPGA-hostile objects in the RTL, but the foremost problems are IP and clock complexity. FPGAs struggle to support the gated-clock design styles commonly used in Asics for power reduction. Instead, the clock gating signals must be converted to clock enables in the FPGA hardware. Performing this conversion manually would be prohibitively tedious and risk introducing new bugs. Instead, some synthesis tools can perform this gated-clock conversion automatically even on complex clock generation circuits. Fig. 2 shows an example of such an automatic generated clock conversion in Synplicity's Synplify Premier.
Handling IP
Large IP blocks, such as ARM processors, can be acquired as complete chips and interfaced to the rest of the prototyping hardware. The only requirement is that the hardware be flexible enough to accommodate a variety of IP-ready daughter cards, such as the ARM Coretile. However, smaller common functions such as memory, FIFOs, multipliers and adders, will be too numerous to handle in this way. Again, the right EDA software can automatically convert these functions to FPGA compatible implementations, or provide easy ways to isolate them for external implementation.
We're on the FPGA board: now what?
Once the design has been ported to the FPGA, and it is running at-speed, another problem emerges: How can debug be accomplished effectively? Logic analysers, embedded or external, can help in this effort, but generally operate in the gate-level namespace. Therefore, tracing these signals back to the RTL (i.e. where the design was originally entered) can be a time consuming process because it requires working backward through the synthesis step. It is preferable to do the debug using tools which seamlessly maintain the symbolic link between the gate and RTL namespaces.
What's next for FPGA prototyping?
At-speed FPGA prototypes are a powerful solution for the verification of complex embedded systems and SoCs. As discussed above, EDA tools which overcome the traditional challenges in this arena are available today as are off-the-shelf prototyping boards. Even so, there is room for improvement to integrate the prototyping hardware and tool components more fully. We could also shorten the time to bring up the prototype and decrease the amount of time required to iterate modifications. As these capabilities develop, at-speed verification systems will take their place along side the other established verification methodologies as a necessary part of every SoC development.
Doug Amos is director of European business development at Synplicity Europe