For firms deploying or looking to deploy FPGA-based applications, there are a variety of options available to them. Though many options appear similar as they offer the same component FPGA, usually an Intel (Altera) or Xilinx part, there are numerous key differences between platforms. These differences can have a significant impact upon such factors as the physical space required to host them, the power and cooling they require on an ongoing basis as well as the amount of internal resource required to actually deploy, manage and subsequently support them.
The following list highlights some of the key differences between the available options for deploying FPGA platforms.
1. Type of Platform — Self-contained versus a component part requiring additional server hardware and integration
2. OPEX — Rack Unit (RU), power and cooling
3. FPGA Capacity — per RU and/or per Watt
4. Platform Management — How is the platform deployed, managed, monitored, debugged?
5. Network Connectivity — Number of interfaces, media support/signal integrity, integrated port replication and fanout.
1. Type of Platform
A number of options are available when it comes to the type of FPGA platform ranging from build-your-own to turnkey.
In order of difficulty:
1. Design, build, debug, support a custom FPGA platform
2. Purchase an FPGA Card, usually in a PCI Express form-factor, then integrate into a server
3. Purchase an integrated, turnkey FPGA platform
Given the complexity, time and skill set required to produce and support the first option, this is generally only done by vendors and hyperscale-sized businesses. Moving to the second, FPGA boards are popular given their relatively low acquisition cost however when coupled with the required integration into a server and ongoing maintenance and support across multiple vendors (FPGA/Server), the TCO (total cost of ownership) is often higher than planned. The third option has numerous advantages: integrated FPGA platforms are available off-the-shelf, come with support for the platform as a whole and often include everything needed to host the FPGA application.
When considering which type of platform is best for your business, it is important to take into consideration the integration costs, the amount of ongoing support needed and whether that support is available internally as well as the cost of ownership and the overall complexity.
2. OPEX
In data center environments, operational expenditure can exceed capital expenditure as the cost of space in equipment racks is dictated by a combination of how many devices can be mounted per rack and how much power and cooling is required.
When looking at an FPGA platform it is crucial to take into consideration how to minimise operating expenditure; ensuring that your chosen FPGA platform fits in as few RUs as possible, consumes as little power and generates the minimum amount of heat possible. FPGA cards mounted in servers can provide good density per RU however they generally consume more power and hence generate more heat than a integrated FPGA platform. Integrated platforms generally have higher density with offerings available with multiple large FPGAs housed in a 1 RU chassis.
The choice of FPGA platform will have an operational expenditure cost associated with it; platforms offering the highest FPGA density in the smallest number of RU drawing the least power could provide an appreciable saving in ongoing operational costs.
3. FPGA Capacity
When deploying FPGA platforms, more can be less.
There are several options of deployment: firms can choose to deploy a device containing multiple-FPGAs or they can choose to deploy several single-FPGA devices. The former can be hugely beneficial, particularly if it provides the same amount of network connectivity as several single-FPGA platforms together.
The benefits are higher FPGA density and significantly better interconnection (ultra-high bandwidth and ultra-low latency) between FPGAs as well as offering reductions in power and cooling per FPGA. FPGA capacity can also be significantly increased by choosing a platform capable of supporting larger FPGA parts containing more logic, memory and digital signal processors (DSPs). These parts can have five times the capacity of the smaller parts in the range. Platforms offering multiple FPGAs in the same device and/or larger FPGAs from a range can significantly increase capacity and inter-FPGA performance.
4. Platform Management
FPGA applications, even networked ones, are seldom black boxes. They need to interface with other systems as they generally have no operating system of their own. They need a management platform to start them, stop them, deploy and troubleshoot them. As they are often managed remotely, secure remote management is a must and increasingly, support for commonly used configuration management tools e.g. Puppet, Chef and standard monitoring tools such as those leveraging SNMP are also required.
Like most applications, FGPA software images ideally need to be version-controlled, deployed, stored and uploaded in a standardised way. Management platforms should also offer an integrated JTAG interface to the FPGA(s) for programming, monitoring and control. Tight integration between the specific FPGA and management platform is key in reducing complexity and hence operational cost. The level of integration between the FPGA and management platform as well as the richness of the management platform’s interface offerings has a significant impact on the operational management of the FPGA application.
5. Network Connectivity
The form factor of most FPGA cards dictates the number of physical network connections available to the FPGA(s) as they are generally designed to fit into a standardised PCI Express bay in a server. It is therefore extremely difficult to find boards that have more than four physical quad-port transceiver interfaces limiting the board to a maximum of 16 Ethernet ports. Dual quad-port interfaces offering 8 Ethernet ports is far more common. The majority of FPGA boards have the transceiver cages wired directly to the FPGA requiring the Ethernet interface portion of the FPGA application to store “tuned” signal integrity profiles to handle any media type that can be plugged into the interface; Twinax copper cables of varying lengths, different types of fibre transceiver.
Some FPGA platforms contain Layer 1+ switches between the external transceiver cages and the FPGA interfaces removing the need for FPGA development work every time a previously unused type or length of cable or transceiver is used FPGA platforms often have much higher port density with up to 48 Ethernet ports available in 1 RU. An additional benefit of the Layer 1+ switch being present is that network traffic from the FPGA application can be replicated and broadcast by the switch to multiple egress ports. This also holds true for ingress traffic in the case where multiple FPGA ports need to receive the same stream of incoming traffic. In this scenario this feature is particularly useful when the platform contains multiple FPGAs.
In summary
The purpose of this short guide was to highlight that there is far more to choosing an FPGA platform than just the model of FPGA(s) contained within. Different offerings on the market require vastly different levels of integration, management and support as well as consume varying amounts of space, power and cooling. There is no best-fit for all but we suggest that if not already the case, the above factors should be taken into consideration before making a decision on a FPGA platform to deploy.
Source: Metamako
www.metamako.com
Metamako is a technology company that specialises in solutions for latency sensitive businesses. It was founded by Scott Newham, Dave Snowdon and Charles Thomas who have a background in ultra-low latency hardware, software and algorithmic trading. Our engineering team brings together a wealth of skills and experience in digital hardware design (Boards, FPGA, ASIC), PCB design, embedded software (kernel, drivers, applications), low-level networking and full product lifecycle from design to manufacturing and support.