By: Pawel Makyla, Central Applications Engineer, Future Electronics and Wafy Butty, FPGA Specialist, Future Electronics
The microcontroller is the default choice of core component in almost every portable or low power embedded design today. Microcontrollers are cheap, small, use little power, and are familiar and easy to work with. Given these attributes, it is hardly surprising that they are so popular.
But developments in the technology of FPGAs are prompting a rethink by some embedded designers. A new generation of FPGAs is emerging which can meet the low power requirements of portable and battery-powered designs, and which fit in tight Bill-of-Materials (BoM) cost budgets. This article describes the most important attributes of this new strain of FPGA, and the types of applications to which it is best suited.
New Territory for FPGAs
The new generation of low cost and low power FPGAs is typified by the iCE40 UltraLite series from Lattice Semiconductor. Featuring a static power rating of just 35μA, the iCE40 UltraLite’s power consumption is comfortably low enough for mobile applications – indeed, it was the first FPGA to be used in a mobile phone design. In its smallest, chip-scale package option, it measures just 1.4 x 1.4 x 0.45mm. This device has sufficient die area to provide either 640 or 1,248 Look-Up Tables (LUTs), 56kbits of RAM, three 24mA constant-current sinks and a 100mA+400mA current sink.
These specifications are in marked contrast to those of conventional FPGAs. Traditionally, FPGA manufacturers have sought to provide their users with a premium product, offering high performance and a rich feature set for which customers in markets such as telecoms and networking equipment or defense and aerospace have been prepared to pay a high unit price. In the past, this meant that each new process step in the wafer fabrication roadmap was used to cram more gates and more features into a given die area in order to defend and extend the high end of the FPGA market.
The development of devices such as the iCE40 series represents the opposite approach; here, FPGA manufacturers are using advances in silicon fabrication to reduce die area and power consumption, while deliberately reducing gate count and the feature set in order to be able to produce a device with a tiny footprint, a low unit cost and power consumption low enough even for a mobile phone’s power system.
This is not a strategy to undercut the price of high-end FPGAs; rather, this new type of FPGA is aimed at extending the reach of these programmable devices into new applications in which they were never previously used, and this includes applications that today use an MCU.
So on what basis might an MCU user now consider using an FPGA instead, or in addition?
Favoring Parallel Operation
To describe the two types of device in broad terms, MCUs perform sequential processing (running one task at a time) while FPGAs can run multiple processes in parallel (running more than one task at a time) – in other words, FPGAs are ‘concurrent’ devices.
An MCU, therefore, is ideal for control applications characterized by a high degree of dependency, so that decisions are determined in the core by the prior state of some input device, such as a sensor or keypad.
By contrast, FPGAs support the simultaneous operation of multiple, independent functions, which may be implemented in parallel in separate portions of the device’s ‘sea of gates’. This bias towards parallel operation might be put to good use, for example, in wearable fitness or health- monitoring devices (see Figure 1). A fitness wristband will contain multiple sensors and user-interface devices such as:
• Biometric sensors such as a heart-rate sensor, a sweat sensor, and a blood oxygen sensor
• Environmental sensors, such as an ultra-violet radiation sensor
• Motion sensors
• System sensors – a temperature sensor and current sensor
• A microphone
• Touch-sensing buttons
• A sounder or speaker
In this application, which uses an FPGA as a sensor hub, sensor readings for the most part have no dependency; the device is not expected to do anything in response to a measurement taken by a step counter, for instance; it just has to count steps while, in parallel, counting heartbeats, measuring the concentration of pollutant particles in the air and so on.
In a device such as a fitness wristband, the mode of operation of an MCU is dramatically different from that of an FPGA. In an MCU, the whole device must wake up in order to execute any action, such as receiving data from a sensor and logging it in memory. This means that a power-hungry crystal must also be woken up – and a crystal typically requires around 10ms to settle, an interval in which the MCU itself is also drawing power but is unable to do anything useful. This wake-up/wait/act/shut-down cycle occurs every time the device has to log a step or a heartbeat or a measurement of Volatile Organic Compounds (VOCs) in the air.
By contrast, the wearable application can easily be partitioned in an FPGA, with each sensor interfacing to its own dedicated set of logic gates. Now, an input from the optical heart rate sensor only needs to wake up the small portion of the FPGA that handles heart rate measurement, while the rest of the device can remain in power-down mode. The same applies for each of the other many sensor interfaces in a fitness wristband. As a result, average power consumption may be markedly lower in the FPGA implementation than in the MCU implementation.
There is also a potential BoM cost implication of choosing an MCU for this application. Most of the time, instructions will need to be handled at intervals, and so the instruction throughput is relatively low. But every good engineer, of course, predicts and allows for the worst-case scenario. What if the MCU has to handle multiple actions almost simultaneously, with no perceptible lag?
This might call for a high-performance core which, most of the time, will be considerably over-specified, but is required to be available for the few occasions on which multiple instructions have to be executed extremely fast. Again, the FPGA’s naturally parallel mode of operation will easily handle the simultaneous implementation of multiple actions, and so there is no need for the same over-specification of the FPGA’s performance. Equally, one or more FPGAs may be used for sensor interfacing functions, handling the inputs from sensors such as accelerometers for step counting and allowing the power-hungry MCU or applications processor to stay in power-down most of the time (see Figure 2).
All of these potential advantages of an FPGA come in addition to the most obvious one: the device’s programmability, which enables the designer to reconfigure the chip’s functions at will without affecting the board design. An FPGA can therefore operate as a flexible design platform, from which multiple product variants can quickly be developed from the same basic hardware design, giving the user a potential time-to-market advantage when introducing new product variants compared to the user of a fixed- function MCU.
FPGA Implementation for MCU Users
The case for a re-examination of the normal architecture of small embedded systems, then, and for consideration of the potential benefits of using FPGAs, is growing stronger with the proliferation of sensors and connections. But users of MCUs have remained users of MCUs in part because the development tool chain and ecosystem are familiar to them and well understood. How difficult is it for an MCU user to integrate an FPGA into a new design?
In fact, FPGA providers offer a comprehensive ecosystem of tools, boards and IP to accelerate the system-development process. The new FPGA user does not have to start with a blank screen; FPGA manufacturers and third-party software/firmware providers offer a huge range of Intellectual Property (IP) which may be integrated into a design. For example the Open Cores website (opencores.org) provides many IP packages which may be implemented by most FPGAs on the market today.
The IP elements available to FPGA users include a wide menu of individual functional blocks of many kinds – for instance, for Lattice FPGAs Helion Technologies (www.heliontech.com) provides security IP such as a fast hash core, DES and triple-DES cores, and an AES core.
The IP offer extends all the way up to comprehensive reference designs – for the iCE40 FPGAs, Lattice provides reference designs for:
• Barcode emulation
• Infra-red remote controller
• Sensor interfacing
• RGB LED control
• USB Type-C Cable Detect and Power Delivery
Language support and IP provision are backed by the FPGA manufacturers’ own integrated development environments, which offer facilities for managing debugging, power analysis and other useful functions. So while the FPGA’s hardware description language, Verilog or VHDL, might be unfamiliar to MCU users, the amount of hardware configuration required is kept to a minimum by the availability of off-the-shelf software resources.
Putting an MCU inside an FPGA
An FPGA, then, may operate as an alternative to an MCU. It may, equally, include an MCU. A developer can do this by describing the functional blocks of an MCU in hardware description language. Alternatively, they can implement the desired MCU code in the form of soft-core IP from a third-party provider.
This can be useful, for instance, for a product in production, the processor of which has reached End-Of-Life (EOL) status. Emulating the MCU in an FPGA enables production to continue. A second use case is size reduction; by absorbing into an FPGA functions currently implemented in multiple discrete components interfaced to an MCU, the designer can minimize production and BoM costs and simplify the board layout.
FPGAs also offer a marked advantage over MCUs in terms of board layout. FPGAs offer various logic interfaces, such as LVTTL, LVCMOS and LVDS, of varying voltages and even drive strengths. The pins in the FPGA are also swappable; the PCB designer can run the signals into the chip in almost any order that is convenient.
There are, then, many ways in which an FPGA provides a better way to implement a circuit that would previously have used an MCU. And by providing a flexible means to handle multiple streams of activity in parallel, a small, low power FPGA provides an inherently suitable framework for the implementation of today’s ever more sensor-rich embedded designs.