Designing with FMCs: A different thought process
The FPGA Mezzanine Card (FMC – ANSI VITA 57.1) format provides a very powerful solution to high-end I/O requirements. FMCs offer a simple and straightforward, yet elegant, low-level interface. Their power comes from eschewing the burden of unneeded bus interfaces. However, successful implementation of the FMC requires that the system designer ask some critical questions beyond “does a driver exist for the right operating system?” Performing due diligence concerning electrical, mechanical, and software/HDL considerations will enable users to leverage the full benefits of the FMC format.
New generations of FPGAs present developers with a level of processing performance and potential I/O bandwidth not easily matched by conventional CPU configurations. Their perform-ance is ideal for demanding applications such as Electronic Counter Measures (ECMs), RADAR, and Signals Intelligence (SIGINT). The FMC mezzanine card format is only concerned with I/O devices, such as ADCs, DACs or transceivers, and board-level infrastructure. FMCs directly connect the I/O de-vices to the host FPGA and bypass generic interfaces; FMCs have no on-board processors, bus interfaces, or bridges, such as PCI (as required by the PMC module format, for example). This lack of overhead results in more functionality, lower cost, and a more responsive solution.
FMCs: High I/O, low cooling and cost
The direct linking of the physical I/O devices on an FMC to the FPGA on the host board could mean code changes are necessary for interoperability. However, the advantages of FMC for high-performance applications – including their high bandwidth, low latency interfaces, lower power for better cooling and increased I/O real estate – typically outweigh the effort of this task.
An FMC’s maximum number of connections (in addition to high-speed serial links) for High Pin Count (HPC) variants is 160 signals. The Low Pin Count (LPC) variant is a subset al-lowing up to 68 signals. HPC and LPC FMCs are mechani-cally interchangeable, but use different sized connectors. The difference between LPC and HPC FMCs is analogous to how some PMC boards have a 32-bit interface while others provide a 64-bit interface via an additional connector. See Figure 1 for a summary of FMC connectivity.
The FMC standard, like specifications for other mezzanine I/O card standards, makes provision for use of multiple options for connectivity, usually for cost optimization variants or for fu-ture expansion. So, FMC defines high- and low-density ver-sions (HPC and LPC), but unlike most other specifications it also provides for greater freedom regarding the actual number of electrical connections and a programmable power supply. These unusual features of FMCs should be noted for design or integration as they define compatibility and the limits of what devices can fit on a particular FMC.
Variable number of connections
More than just a generic interface, the FMC format defines a maximum number of FPGA connections rather than a mini-mum number. Because only the maximum number of connec-tions is defined, not all FMCs will have the same number of connections. This is also true for the FMC host: Not all hosts will provide the same number of FPGA connections. This is a practical tradeoff because the FMC specification allows for up to 160 connections, and some designs simply cannot afford to dedicate this volume of FPGA connections to the FMC site.
Although the number of FMC-to-host connections is not de-fined, the order in which the links are established is set. Con-nections are assigned to the FMC starting at a common point and are added in a defined manner with no gaps in the se-quence. For example, two FMC hosts that provide 140 connec-tions each will use the same 140 pins. If one host uses 135 connections and another uses 155, both hosts will occupy the same 135 pins but the larger host will have more signals above the sequence as per FMC rules. This ensures there is control between hosts. If an FMC requires a certain number of con-nections and a host advertises the appropriate number of con-nections, then connectivity will be provided without the risk of missing connections. Care should be taken that an appropriate host is chosen for a given FMC solution.
Programmable power supply
An FMC module is relatively small. This is typically an ad-vantage because of their more efficient cooling and inherently reduced cost due to the removal of unnecessary components. This is achieved in part by the use of a programmable power supply.
During power up, core power supplies are provided to the FMC module. The FMC is then interrogated for identification purposes, as well as to determine its power supply requirement (VADJ). The host then provides the correct VADJ and com-pletes the power up cycle. For the FMC developer this means a simplified power design and a freeing up of resources to the FMC for functionality. This helps ensure, too, that the avail-able real estate on the compact FMC module format is maxi-mized.
The FMC specification defines multiple profiles to suit differ-ent environments, ranging from commercial builds to conduc-tion-cooled rugged solutions. Using a card of one profile may have implications on what can be fitted to a given host. How-ever, in small board formats additional real estate may still be needed, and hence the profile options have been defined and should be understood. In addition, the FMC structure and size also have thermal benefits.
Profiles and compatibility
The FMC specification allows for different profiles depending on whether front panel I/O is required, and additional areas for conduction cooling. Three regions are defined within the FMC specification (see Figure 2). The regions are not areas simply reserved for a particular purpose, except for region 3 which is the primary real-estate area for functionality, but are optionally omitted. Region 1 is used for I/O or as a thermal interface for a rugged solution. Region 3 is an optional rugged ther-mal/mechanical interface. The majority of FMCs will use re-gions 1 and 2. Conduction-cooled cards will usually require all three regions. FMCs may also populate the area defined as secondary thermal interface. However, such cards cannot be fitted to hosts (assuming this area is a thermal interface), as components in this area will cause mechanical interference. Consequently, it is advised that even commercial-only (non-rugged) cards not use the area defined for secondary thermal interface due to possible interoperability issues. However, some FMC hosts may provide removable ribs in recognition of this possibility. If required for I/O, Region 1 is used for con-duction-cooled hosts and it’s likely that mechanical modifica-tion will be required for the host in order to provide I/O through the front panel/stiffening rib.
Considering regions 1, 2, and 3 together with the secondary thermal interface, all FMCs are mechanically compatible with all commercial FMC hosts. However, care needs to be taken with rugged FMC hosts, especially conduction-cooled hosts.
In addition to profiles, the FMC specification supports a num-ber of stacking heights. 8.5 mm is the most common stacking height, but the specification allows for up to 10 mm through the use of higher connectors.
An FMC format card is nearly half the size of the popular PMC or XMC formats. Since the FMC does not include un-necessary bridges or even a simplified power supply, the mod-ule is not burdened by unnecessary heat generators and can also maintain a small footprint for a given function, as a greater proportion of the space is used for board functionality. When mounted onto a 3U VPX host, for example, the FMC covers less than 50 percent of the host’s circuitry. This enables the host to be designed so that the heat generators do not need to be located under the FMC. This makes it easier to cool the host. By comparison, on a PMC/3U host combination, the PMC would cover the majority of the host making both the PMC and host more difficult to cool. A typical FMC would dissipate less than 10 W – much less than a similar function PMC.
Software and Hardware Description Language considerations
In the same way that operating systems are different but achieve similar results, so too are vendor tools and component libraries. This is due to the low-level nature of FPGAs and the differences in vendor Hardware Description Language (HDL) architectures. Some solutions focus on providing the developer with as much FPGA resource as possible. Other solutions pro-vide a sophisticated harness with which to insert user code into a system infrastructure for dealing with external interfaces. This interface component approach could ease the task of moving data between FPGAs or to a CPU, external memory interfaces, or peripherals such as ADCs or networking. This approach allows the developer to focus on their core HDL code generation. Although AMBA AXI is securing a foothold as a common interface to add in new components, the overall environment between vendors is different, particularly with the more sophisticated system solutions.
Software and HDL optimization
When the FMC and host card each come from different ven-dors, the code provided by one vendor will either be in the form of a HDL abstracted to a generic FPGA host (requiring further host-specific integration), or as a fully integrated host-specific FPGA combination. Even the speed of the FPGA can play a role. For some larger devices it may actually be more difficult to achieve timing closure and meet the application’s requirements, so smaller FPGAs may be better in some cases. Regardless, mixing products from two vendors usually re-quires integration development work at the hardware and HDL level. At its simplest, this may involve re-associating the exact FPGA pinout definitions. For example, it is possible that two vendors offer the same I/O device on their respective products and the block diagrams may even look the same. However, the pinout and timing are likely to be different, and the products are therefore unlikely to be interchangeable. To ensure that the FMC and host interoperate, it is often best to source the com-bination from a common vendor.
Typically, when a single vendor supplies both the host FPGA board and the FMC, there will be software/HDL optimized for the low-level connectivity of the combination. However, the designer can make the choice of developing their code from scratch to maximize the FPGA resource and optimize the solu-tion to a particular application. The low-level nature of FPGA code development provides this option too.
Maximizing FMC benefits
As FMCs continue to grow in popularity – thanks to their high bandwidth, low latency interfaces, lower power, and efficient I/O real-estate – it’s important to be familiar with the differ-ences between different classes of FMC cards so that interop-erability can be maximized and the benefits of these flexible, compact I/O cards can be optimized.
Key considerations could include:
· The FMC stacking height
· The desired FMC profiles
· Conduction-cooling requirements
· HPC or LPC FMCs and host support
· Host connectivity for full FMC support
· Host FPGA speed
· Fully integrated solution requirements
· Sufficient example HDL code
Leading COTS vendors such as Curtiss-Wright Controls De-fense Solutions offer a broad range of high-performance FMC cards and host processor products, such as the FMC-518, a quad-channel, 500 MSps 14-bit analog input card (see Figure 3 for an example FMC with a 6U VPX host).
FMCs require a modified thought process, perhaps more hardware than software, but the benefit can be the rare combi-nation of high performance at a lowered cost. FMCs are very powerful and provide an elegant I/O solution, but to fully real-ize their potential, due diligence is worthwhile.
Curtiss Wright Controls Defense Solutions