How did FPGAs introduce industry-driven architectures?

FPGA is becoming more and more important in industrial machinery design, and it is widely used in various drive architectures. Now let’s take a look at some of the challenges of using FPGAs in an industrial drive/servo architecture, and how the new capabilities of a control system-on-chip (SoC) in the form of a COTS MCU can use FPGAs to change costs for industrial drives valid model.

How did FPGAs introduce industry-driven architectures

Many industrial inverter and servo manufacturers have long relied on Field Programmable Gate Array (FPGA) or ASIC technology to perform functions not supported by commercial off-the-shelf (COTS) products such as 32-bit microcontrollers (MCUs). However, to support position sensor feedback or delta-accumulate filtering, the addition of FPGAs and ASICs in software programmable controllers will increase system cost and development complexity.

Shouldn’t we be asking: Are the features that are being built into FPGAs that drive real change? Has it become standard practice for every driver manufacturer to include these features? In short, have these inflated FPGA gates used to implement the required functionality become the bargaining chip for survival in the industrial drive industry?

While FPGAs are reprogrammable and are believed to have the potential to provide system adaptability and better system performance, they also have certain disadvantages relative to MCUs currently used in industrial drive applications. Developers should measure the specialized engineering skills required, overall project effort, and total system cost.

Many drive systems being developed maintain a C-language programmable microcontroller or microprocessor combined with an FPGA. The C code generation and debugging development environment for this processor is well known and required.

Now, introducing an FPGA into this system requires additional development flows and toolsets. Although these tools have made some progress in ease of use when advertised, usually not the same group of engineers develop the MCU C code and the FPGA VHDL code. The VHDL coding style and development process is very different from MCU software development and requires special engineering resources.

Furthermore, it is precisely the FPGA developers who have to become low-level and system-level experts in the hardware IP they execute. For example, not only do they need to know how to implement VHDL for a BiSS host, they need to understand the BiSS protocol because they need to verify that their FPGA appliances are compliant with BiSS sensors.

This specialized engineering skill is not something every motion control or inverter manufacturer can provide its employees, and it certainly doesn’t play a unique role in motion and motor control performance. Wouldn’t it be simpler to just use a microcontroller that natively supports BiSS encoders?

From a development perspective, managers need to treat FPGA creation as a custom development. Their development teams have additional ownership of, and are responsible for, the product features of commercially available FPGAs. If the VHDL is not properly coded, they cannot turn to the FPGA vendor; they have to find the cause of the problem and find a remedy to fix it.

When you compare VHDL to a model using a COTS MCU, the customization responsibilities associated with FPGA development far outweigh the gate design work inside the FPGA. Printed circuit board (PCB) impact, MCU gate-level/register interface, software abstraction, and overall system integration effort are all non-standard, that is, they are not off-the-shelf solutions. See Figure 1 for details.

In addition to development, this model has additional engineering complexity in terms of user support, product maintenance releases, and long-term quality consistency as new connected components are released or modified. Wouldn’t it be simpler to use a standard MCU with these features and the vendor responsible for the entire product solution (hardware, software, tools and design)?

Comparing FPGA and EnDat development driving SoC
Comparing FPGA and EnDat development driving SoC

Also, perhaps the most obvious point is the impact of additional components on the bill of materials. The cost of an FPGA is by no means limited to its impact on unit price. The FPGA device will require additional PCB area, as well as pins required for MCU interface and power supply. These costs are unavoidable when running with an FPGA, but are unnecessary when these functions already exist on the driving SoC MCU.

In several cases, we have observed that the FPGA itself requires additional and more complex power circuits than driving the SoC device. Additionally, implementing an FPGA introduces redundant gates into the system, such as a register interface to the MCU, and an external analog-to-digital converter (ADC) interface for phase current and voltage sensing.

A driver SoC includes a built-in high-performance ADC for driver applications and does not require this additional logic. Therefore, using a single COTS-driven SoC offers many opportunities to reduce overall system cost relative to an MCU with an additional FPGA fabric.

The 2000™ MCUs that support DesignDRIVE technology are COTS MCUs; they provide a higher level of drive system integration with a holistic product concept that benefits drive developers by reducing the need for specialized engineering talent, saving development time, and simplifying system costs.

Haoxinshengic is a pprofessional FPGA and IC chip supplier in China. We have more than 15 years in this field。 If you need chips or other electronic components and other products, please contact us in time. We have an ultra-high cost performance spot chip supply and look forward to cooperating with you.

If you want to know more about FPGA or want to purchase related chip products, please contact our senior technical experts, we will answer relevant questions for you as soon as possible