By Brian Fortman | DesignDRIVE Marketing Manager, C2000 Microcontrollers | Texas Instruments
Many industrial inverter and servodrive manufacturers rely on field-programmable gate-array (FPGA) or ASIC technology to complete functions unsupported by commercial off-the-shelf (COTS) products such as 32-bit microcontrollers (MCUs).

There are drawbacks to these technologies, though.

Case in point: Adding FPGAs and ASICs to software-programmable controllers to support position sensor feedback (or sigma-delta filtering) also increases system cost and development complexity. So designers should ask if the functions placed in the FPGA are bringing real differentiation to drive products. Will customers pay more for the functions in FPGAs? Or have those functions become standard features for every drive maker to include? In short, are they just table stakes to play in the industrial drives and servo industries? Let’s find out.

History of FPGA-enabled drive architecture evolution

There are challenges to introducing an FPGA into a drives development flow, and (as we’ll see) new capabilities of industrial drive control SoCs (COTS MCUs) shift the cost-benefit model of using FPGAs for industrial drives.

First some background: FPGAs became common in inverter-drive architectures when new system functions were impossible with the COTS MCUs available at the time. For example, many developers had to implement their specific PWM/IGBT protection scheme outside the MCU. Others may have felt that their current loop timing was too short to be handled by a programmable MCU so could only be accomplished in gates.

Once an FPGA is in a system, it then becomes the logical place to integrate support for new technologies introduced to the evolving market. So, FPGAs came to integrate clockwise-and-counter-clockwise (CW/CCW) and pulse-train-output (PTO) ports for communications with PLCs and motion controllers. Then FPGAs began to support emerging standard and proprietary position sensor interfaces such as EnDat and BiSS. Next, filtering circuits for modulated outputs of isolated sigma-delta ADCs were integrated into FPGA devices. In addition, some industrial Ethernet standards have made their MAC controllers available in FPGA gates.

As FPGAs absorbed this expansion of drive functions, a new dynamic was emerging. COTS controllers started bringing these functions on-chip and creating off-the-shelf features for any drive developer to use.

The difference here is substantial: On-chip functions are available for the developer to use immediately — that is, to purchase an MCU from a catalog without needing to construct these solutions themselves using an FPGA. So developers can now avoid many FPGA pitfalls.

Drawbacks of FPGAs for drive applications

FPGAs are reprogrammable and most believe they provide system adaptability and improved system performance, but they have drawbacks when compared to MCUs for industrial-drive applications. Developers should weigh the impact of the specialized engineering skillset, the total project effort and the total system cost when an FPGA is employed.

Many drives systems being developed maintain a COTS C programmable microcontroller or microprocessor coupled with an FPGA. The processor’s C code generation and debug development environments are well known and required. Introducing an FPGA into the system necessitates an additional development flow and toolset. Despite claimed advances in ease-of-use of these tools, it’s typically not the same engineering staff that develops the MCU C code and FPGA VHDL code.

What’s more, the VHDL coding style and development flow are quite different from MCU software development and require special engineering resources. Plus it’s the FPGA development staff that also must become low-level and system-level experts for the hardware IP they’re implementing. Not only must they know how to implement the VHDL for a BiSS master, for example, but they also need to know the BiSS protocol — as they need to validate that their FPGA implementation meets (in this example) BiSS sensor requirements.

This specialized engineering skillset may not be something every motion control or inverter manufacturer can afford to staff — and it certainly is a diversion of effort away from their true differentiation of motion and motor control performance

As we’ll see, it’s probably easier to just use a microcontroller that supports BiSS encoders natively.

FGPA development is custom design. From a development perspective, managers should view FPGA creation as a custom development. Their development teams have heightened ownership and responsibility for the product features taken to market in the FPGA. If the VHDL isn’t coded or tested properly, they cannot turn to the FPGA vendor; they can only turn to themselves as the cause of the issue and to themselves as the source for the remedy as well.

When comparing the FPGA development model to using a COTS MCU, custom responsibilities go well beyond custom gates designed into the FPGA. The printed circuit board (PCB) impact, the MCU gate-level/register interface, the software abstraction and overall system integration are all nonstandard — not off-the-shelf solutions. Beyond just development, this model has the added engineering complications in customer support, product maintenance releases and long-term conformance as new interfacing components are released or revised.

As we’ll explore, it’s easier to use a standard MCU with these features implemented and let the supplier take responsibility for the whole product solution — including hardware, software, tools, and design.

Next and most obvious is the impact of an additional components on the bill of materials. FPGA cost goes beyond just the unit price. FPGA devices need additional PCB area and pins for MCU interfacing and power supply. These costs are unavoidable when using FPGAs but avoided when these functions already exist on the drives SoC MCU. Investigations show that some FPGAs even need an additional (or more complex) power supply circuit than the drives SoC devices by themselves.

What’s worse, implementing FPGA introduces gates that are otherwise unnecessary to the system — such as the register interface to the MCU and the interface to an external analog to digital converter (ADC) for phase current and voltage sensing. In contrast, drives SoCs include high-performance ADCs built for drives applications and don’t require this extra logic. So using a single COTS drives SoC includes many opportunities for overall system cost reduction vs. MCU plus FPGA architectures.

In fact, some MCUs deliver this higher-level of drive system integration with a whole-product philosophy that benefit drives developers by reducing the need for specialty engineering talents. These system-on-chip (SoC) devices handle several items FPGAs traditionally handled — including fast torque loop calculation; filtering of modulated delta-sigma ADC signals; high-performance PWMs; PWM protection and interfacing with performance position sensors.

In fact, one MCU’s on-chip comparator subsystem and PWM trip-zone capabilities can invoke a safe PWM state (off) in 50 nsec. These MCUs are flexible when generating on-chip conditions for triggering a trip-zone event. Designers can implement myriad PWM protection concepts using these on-chip resources — eliminating the need to place the circuits in external FPGAs.

Consider that some new MCUs and software also allow for easy and direct connections to EnDat2.2 and BiSS-C absolute position sensors, which are features that required FPGAs in the past. What’s more, by using some of the sophisticated analog circuits on-chip, these devices can decode resolver signals as well as angles from SIN/COS transducers. One such solution is the first of its kind to offer a breadth of position-sensor support, flexibility, scalability and robustness to let developers decrease system cost — specifically by reducing the board area of the FPGA or ASIC.

To be clear, on-chip solutions for industrial drives (integrated into COTS real-time MCUs) save board space and development effort, which frees developers from making unnecessary investments in features that are non-differentiating in the industry. Instead, developers can focus on product differentiation and competencies such as motor control and motion control — and not on building FPGAs or writing complex code needed to complete non-differentiating tasks.

Texas Instruments | www.ti.com/c2000 • www.ti.com/tool/designdrive