In the first post of this series, we looked at how FPGAs were introduced into the drives architectures. Now, let’s take a look at some of the challenges of using an FPGA in an industrial drive/servo architecture and how new capabilities of control systems-on-a-chip(SoCs) in the form of COTS MCUs shift the cost-benefit model of using FPGAs for industrial drives.
Many industrial inverter and servo drive manufacturers have traditionally relied upon field-programmable gate-array (FPGA) or ASIC technology to complete functions that are not supported by commercial, off-the-shelf (COTS) products, like 32-bit microcontrollers (MCUs). However, adding FPGAs and ASICs to software programmable controllers, in order to support position sensor feedback or sigma-delta filtering, as examples, will increase system cost and add development complexity.
Shouldn’t we really be asking: Are the functions that are being placed in the FPGA bringing any real differentiation to the drive products? Hasn’t it become standard practice for every drive maker to include some of these functions? In short, are these premium-priced FPGA gates being used to fulfill features that have become the table stakes to play in the industrial drives industry?
While FPGAs are reprogrammable and are perceived to potentially provide system adaptability and improved system performance, they also carry some drawbacks when compared to the opportunities with today’s MCUs for industrial drives applications. Developers should weigh the impact of the required specialized engineering skillset, the total project effort and the total system cost.
Many drives systems being developed maintain a 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 now requires an additional development flow and tool set. Despite the claimed advances in ease-of-use of these tools, it is typically not the same engineering staff that develops the MCU C code as well as the FPGA VHDL code. The VHDL coding style and development flow are quite different from MCU software development and require special engineering resources. In addition, it is the FPGA development staff that also must become low-level and system-level experts for the hardware IP they are implementing. Not only do they need to know how to implement the VHDL for a BiSS master, for example, but they also need to know the BiSS protocol since they need to validate that their FPGA implementation meets the BiSS sensor requirements. This specialized engineering skill set 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. Wouldn’t it be easier to just use a microcontroller that supported BiSS encoders natively?
From a development perspective, managers need to view FPGA creation as a custom development, effectively. Their development teams have an additional degree of ownership and responsibility for the product features taken to market in the FPGA. If the VHDL is not coded 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 you compare this to the model of using a COTS MCU, the custom responsibilities associated with FPGA development go well beyond the gates designed into the FPGA. The printed circuit board (PCB) impact, the MCU gate-level/register interface, the software abstraction and overall system integration efforts are all non-standard, i.e. not off-the-shelf solutions. See Figure 1 for details. 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. Wouldn’t it be much easier to turn to a standard MCU with these features implemented and a supplier taking responsibility for whole product solutions (hardware, software, tools and designs)?
Figure 1: EnDat development comparison FPGA vs. drives SoC
Next, and possibly the most obvious, is the impact of an additional component to the bill of materials. The cost of the FPGA goes beyond just the unit price impact. The FPGA device will require additional PCB area, as well as pins required for MCU interfacing and power supply. These costs are unavoidable when working with an FPGA, but are not needed when these functions already exist on the drives SoC MCU. In several cases, it is observed that the FPGAs require an additional and more complex power supply circuit than the drives SoC devices by themselves. Also, implementing the 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. A drives SoC includes a high-performance ADC built for drives applications and does not require this extra logic. So, using a single COTS drives SoC includes many opportunities for overall system cost reduction vs. MCU plus FPGA architectures.
C2000™ MCUs with DesignDRIVE technology are COTS MCUs that 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, saving development time and simplifying system costs.
In the next installment of this blog series about industrial drive control architectures, I will highlight how the off-the-shelf C2000 Delfino™ MCU industrial drive SoCs handles the functions that have traditionally been completed in an FPGA: Fast torque loop calculation, filtering of modulated delta-sigma ADC signals, high-performance PWMs, PWM protection and interfacing with high-performance position sensors.