A New Class of Microcontroller-Based FPGAs

Fractal Realms series. Backdrop of fractal elements, grids and symbols on the subject of education, science and technology

by Ted Marena, Microsemi Corp.

Despite the growing use of FPGAs across a broad spectrum of applications, major vendors have been pursuing two rather narrow and divergent paths with today’s FPGA architectures. The market is very clearly divided, with high-end SoC FPGAs on the one end that incorporate multiple application processor cores, and low-end FPGA solutions on the other, consisting mainly of logic elements. Suppliers have gravitated to one of two very different approaches: they either offer SoC FPGAs with high-performance ARM A class application processors, or they deliver low-end FPGAs with no processor.


Applications such as server farms and high-performance computing require ever- increasing performance, and to address these markets, SoC FPGAs are incorporating multiple ARM A class application processors that are well-suited for high-performance applications. However, the reality is that these ARM A-class SoC FPGAs are overkill for a multitude of other applications. They are often too expensive, create too much of a software support burden because of the required operating system, and generate significant heat because of their higher power consumption. Often, the raw compute performance is simply not required.  But replacing these solutions with low-end FPGAs isn’t always the answer, either, for a growing range of applications. With no hard microcontroller or processor, low-end FPGAs and are mainly a collection of logic elements, and while they do offer soft microcontrollers, there are no accompanying peripherals or a subsystem. If peripherals are required, they must be created by using FPGA gates. Low-end FPGAs with a soft microcontroller run slowly, are inefficient due to the FPGA gates that are needed to create the microcontroller and subsystem, offer virtually no design security, and are developed on proprietary architectures. In a large and growing variety of general-purpose applications, neither of these two FPGA choices is satisfactory.


A third choice is now available. This new class of microcontroller-based SoC FPGA delivers more features than low-end FPGAs, without the high cost and support requirements of ARM A-class SoC FPGAs. They incorporates hard microcontroller cores and peripherals, I/Os and other functionality that, together, enable developers in the embedded market to implement a broader range of general-purpose applications. For numerous designs, a hardened microcontroller-based SoC FPGA is often the most effective solution — after all, there are scores of 32-bit microcontroller architectures produced each year because of the numerous applications for which they can be used.


When an FPGA fabric is coupled with a hard microcontroller and a full peripheral subsystem, the result is a compelling platform that facilitates an ideal division of labor within the system design.

Examples of Design Partitioning Strategies

An ARM Cortex M3 SoC FPGA is able to leverage both a microcontroller and an FPGA fabric. The microcontroller is ideal for slower-speed serial tasks because of the architecture and requirement to access memory for instructions. An FPGA fabric is best suited for parallel-processed functions that are more time-critical. When partitioning a design in this manner, it becomes clear which functions each component should implement.


For instance, in many designs, the ARM Cortex M3 and peripherals would be used for communications, control and other slower-speed functions. The FPGA fabric would be used to implement unique logic functions or to perform time-critical acceleration functions. When used in this way, an ARM Cortex M3 SoC FPGA can be viewed as a microcontroller with configurable hardware acceleration, and the FPGA fabric becomes the ideal solution for hardware acceleration and the implementation of logic functions — two places where FPGA fabrics excel. The combination of an ARM Cortex M3 and an FPGA fabric in a single solution creates the opportunity for an ideal partitioning of serial and parallel tasks across a wide variety of system design applications. Following are several specific design examples.


Multi Axis Motor Control: One of the main challenges of controlling multiple motors is the requirement that the motor control loops have a deterministic response. To ensure a reliable design, each motor must be serviced within a tight, deterministic time with no wide timing variation. Because the multi-axis motor control algorithm is a time-critical function, it should reside in the FPGA fabric. The FPGA is ideal for implementing the control loops with tight deterministic timing. Figure 1 shows a block diagram of a multi-axis motor control design. The bulk of the motor control algorithm is in the FPGA fabric, while the slower-speed interfaces are connected to the ARM M3.

The motor-control algorithm is not the only required function. Often, one or more communications interfaces and control I/Os are required for a complete motor-control design. These interfaces are not high-performance-oriented and are ideal for a microcontroller such as the M3 to implement. The communication interfaces could be Control Area Network (CAN) bus, Serial Peripheral Interface (SPI), Universal Asynchronous Receiver/Transmitter (UART) or other control buses.

Adding MACsec (MKA) to an Ethernet Switch: Because of growing concerns about the security of network data, the IEEE committee created the 802.1AE MAC security standard. This is often referenced as MACsec or MACsec Key Agreement (MKA). The MKA standard specifies a series of protocols to protect data traveling over Ethernet. One of the requirements is to have the data encrypted on the link. Encrypting data is done by generating keys and exchanging them. Although MACsec is built into many Ethernet physical layer devices (PHYs), very few Ethernet switches incorporate the MKA protocol. For MKA to work, both a switch and the PHY need to be supported – an ideal task for an ARM Cortex M3-based FPGA to assist.


To add MKA to an Ethernet switch, the switch must be connected to a MACsec-based PHY (Figure 2). An external device is also needed to manage the keys, run the MKA protocol and monitor the Ethernet link.


The key management and the MKA software are not compute-intensive. Monitoring the Ethernet link, however, does require line-rate capability. These tasks map well into an M3-based FPGA. The microcontroller runs the MKA protocol and handles key generation. Independent of the type of network and the security that is required, these tasks are infrequently run. For example, if the network wants to change the security keys every hour and if a FPGA is supporting two links, then the MKA protocol is only going to execute heavily a couple times per hour. The FPGA logic provides the physical interface to the Serial Gigabit Media Independent Interface (SGMII) link and can filter the line for specific IP addresses or commands. The logic also signals to the PHY when the new key should be loaded.


Implementing a complete IEEE1588 Client: IEEE1588 is a standard which synchronizes timing across an Ethernet network. It is used in many wireless communication products, but is also being leveraged for financial networks, smart grid applications, broadcast video and more. An IEEE1588 network consist of Ethernet switches, gateways and access points as well as slave/client end point devices (Figure 3). A slave/client end-point only requires a single Ethernet port. Many industrial applications, such as a smart grid relay or a machine vision camera, only require a single IEEE1588 port. Although a slave/client device requires only a single port, adding IEEE 1588 to a design is not a trivial task.


The following four key functions need to be implemented in an IEEE 1588 design:

  • An Ethernet PHY or other device to support time stamping
  • A software routine that will run on a processor to implement the required application profile
  • IP that runs an algorithm that adjusts the Phase-Locked Loop (PLL) based on the IEEE 1588 profile output
  • A PLL that can be dynamically adjusted to output the network timing clock


An ARM Cortex M3-based FPGA is ideal to be used at the heart of an IEEE 1588 client. The M3 runs the software timing routine and the algorithm to control the PLL. This software monitors the network clock and adjusts the PLL, if necessary. The FPGA provides the logic to interface to the Ethernet PHY and the necessary interface buses to simplify system host integration. This complete validated solution minimizes system software integration and testing. An M3-based FPGA solution also allows quicker field updates when new IEEE 1588 profiles or enhancements are available.

Unlocking New Opportunities

System designers have typically had only two FPGA choices for general-purpose applications, and neither was ideal. Now, there is a third choice, with microcontroller-based SoC FPGAs that enable solutions such as bridging, I/O expansion, hardware acceleration, protocol management, board initialization and more. This new class of microcontroller-based FPGA is often more than adequate for a growing array of applications, and is poised to help unlock many new market opportunities for embedded system designers.

Fig. 1: Block diagram of a multi-axis motor control design

Fig. 2: MKA protocol implementation

Fig. 3: A complete IEEE 1588 Client Solution