Using FPGAs that run at speeds closer to the required speed of the final system alleviates many problems.
One of the ironies of prototyping for high-speed system design using FPGAs is that in the past most FPGAs did not run at the speeds required by the end system. Many of these FPGAs today have high speed SerDes channels used for communicating with other elements of the system at close to the speeds specified by the designer. Unfortunately most of the FPGAs used for the prototyping phase of the system layout do not run at anything close to the final system speed and this can pose a problem for the designers when trying to run the software applications written for the system.
A partial solution is to do extensive modeling and simulation of the system operation to determine if the software is written correctly. However, this is only a substitute for the final version of the system that will run at the desired speeds.
What then can be done to prototype a system that must run at very high speeds to meet market requirements?
Today, the newest FPGAs can run at gigabit speeds. A good solution is to use FPGAs that run at, or close to, the desired system speed to eliminate as much low-speed testing as possible. This allows for more of the test and debug effort to go directly to identifying errors that would otherwise be missed because they only occur above a certain system speed. While usually few in number, this type of error is very hard to track down and correct because they can be dependant on reaching certain system conditions; namely speed above a certain level.
Prototyping with FPGAs that natively run at speeds closer to the required speed of the final system help to alleviate many of these issues and allow system software to run at speeds that are closer to ‘real world’ conditions. It is also highly advantageous when prototyping a new system to have FPGAs that already include the SerDes channels so that less time is spent on getting the SerDes to function correctly and more time is dedicated to ensuring the entire system functions properly.
This is especially true when a system is using SerDes channels for high-speed communications. These channels must run at close to final speeds to allow the design team to spot problem areas before the final product enters the market. Debugging SerDes implementations in a system can be difficult, especially when the SerDes is implemented on a part that is separate from the computational elements necessary for the system.
Of course, cost is also a major consideration when determining what inputs can be used for prototyping. These issues will be explored during the panel, “How Do We Get to Next-Generation High Speed Data Transfer Rates?” at the Semico IMPACT 2015 conference tomorrow (Oct. 13). The panel will be comprised of Lee Ritchey, Speeding Edge; Scott McMorrow, Samtec; Geoffrey Hazelett, Polar Instruments; Daniel DeAraujo, Mentor Graphics; and Nathaniel Unger, Altera. Brian Fuller, Editor in Chief at ARM, will moderate this panel.
The Semico IMPACT 2015 conference will be held at the Computer History Museum in Mountain View, CA. For more information, contact Rick Vogelei at firstname.lastname@example.org (480-435-8564).