Picking a Controller Technology

Using FPGAs and ASICs, designers of embedded control systems can implement very complex algorithms that execute at high speed in a compact, reprogrammable hardware package.

Embedded control systems vary from temporary data acquisition and control systems running experiments to “brains” for standard mass-market products. Embedded control systems also range in complexity from telecommunications switching systems to alarm clocks. Different applications have different requirements, with several form factors available to meet them. Which will meet your needs best depends not only on the ultimate use, but where the system is in its life cycle.

Three CPU form factors are especially well suited for embedded applications: microcontrollers, field programmable gate arrays (FPGAs), and application-specific integrated circuits (ASICs).

Microcontrollers’ biggest advantage is that they are highly adaptable by being programmable in human-readable languages, such as C and C++. Many microcontroller applications are complex enough to require use of an operating system, such as Linux or Microsoft Windows Embedded as well.

Microcontrollers’ biggest disadvantage is also that they are highly adaptable, often requiring high-level programming and resource-intensive operating systems. For many applications, microcontrollers are overkill of sometimes monumental proportions.

ASIC, FPGA characteristics

Two compute-engine technologies stand out as microcontroller alternatives: field programmable gate arrays (FPGAs) and application-specific integrated circuits (ASICs). Both implement Boolean-logic algorithms in hardware. Both are highly adaptable, being capable of addressing a wide range of logical functions from simple on-off controls to entire microprocessors. Both are programmed using standard hardware description language (HDL), such as VHDL and Verilog, rather than software written in third-generation and higher programming languages.

They differ in non-recurring engineering (NRE) cost levels and variable costs, as well as re-programmability, scalability, and development time associated with volume production.

FPGA characteristics include being reprogrammable to facilitate prototyping, production adjustments, and in-field upgrades, thus reducing the time-to-market for deploying solutions. An FPGA platform could support multiple products, leveraging the development costs and resources otherwise required for an ASIC design or MCU development.

Wikipedia describes FPGAs as semiconductor devices containing programmable logic components called “logic blocks,” and programmable interconnects. Logic blocks can be programmed to perform basic logic gate functions, such as AND, and XOR, or more complex combinational functions such as decoders or mathematical functions.

Embedded control system designers can debug hardware designs using FPGAs, then, when production volumes permit, port them to custom ASICs.

An ASIC is an integrated circuit customized for a particular use, rather than intended for general-purpose use. For example, a chip designed solely to perform a certain operation in a cell phone is an ASIC.

A full-custom ASIC design defines all the device’s photolithographic layers. Translating HDL code into semiconductor fabrication steps accounts for the technology’s large NRE cost.

Both FPGAs and ASICs start out as hardware description language (HDL) programs. Before generating HDL code, however, it is best to conceive, test, and debug all system algorithms using software and/or hardware simulation.

Algorithm development process

Algorithms begin, of course, as system-engineering strategies based on user-driven application requirements.

一个机器人法律nmower, for example, would likely start out as a completein silicosimulation, where the algorithm under development (AUD) would consist as a patchwork of C or C++ program modules previously developed for other projects and possibly obtained from a variety of sources.

These modules would be called from a custom supervisory program that acts as a wrapper for the embedded system software. It would run on a desktopdevelopment system, which simultaneously runs other C or C++ modules that simulate motors, drivers, sensors, and graphical user interfaces.

算法发展的年代tartsin silicoto ensure that the algorithm will do what it’s supposed to do, and will always remain under control. It’s wise to make sure the algorithm will behave in a sane way, and can be brought to heel by test engineers before putting it in charge of potentially dangerous hardware. Otherwise, you could end up with runaway robots right out of science fiction. That’s test engineering 101!

Once the algorithm can be trusted to behave well, system developers can download it into their first robot-lawnmower prototype, and run it through a series of tests to develop the hardware platform. The algorithm acts as a robotic test pilot for the hardware-development program.

Hardware subsystems will probably have already been bench tested using a PC-based data acquisition and control system whose test program has no resemblance to the AUD except for shared hardware interface specifications. Hardware subsystems, however, likely haven’t operated together before, so this last stage of system development is to integrate all subsystems and debug them together.

System integration likely starts with the AUD running on an embedded single-board computer (SBC) running the same program written in high-level language and debugged during thein silicosimulation tests. This is the first time the AUD has had control of actual hardware.

在这个阶段,很多硬件/软件交互problems come to light, as well as hardware/hardware issues. Hardware and software are so interdependent in embedded control systems that any change to one likely forces a change to the other. The flexibility and reprogrammability of the SBC format are necessary to make debugging the complete system feasible.

Hardware implementation

Once all the software and and hardware issues have been resolved, it’s time to prototype something that will look and act exactly like the final system. ASICs and FPGAs require similar spatial footprints—they both mount on a small motherboard that also carries any support chips.

FPGAs do need an additional chip on the motherboard: a programmer chip that will load the FPGA interconnects that implement the AUD in hardware. FPGAs share with dynamic RAM technology the Achilles’ heel of being volatile. Removing power from the FPGA wipes clean its program.

Likely, system developers at this stage will implement the design as an FPGA because the controller module will have a footprint similar to an ASIC version, but has the advantage of being reprogrammable. Its Achilles’ heel is also the FPGA’s most endearing asset: until the system has been proven in the field, there is a significant probability that software updates will be needed, and making new production runs to update ASIC programs is cost prohibitive.

Even if the design becomes a standard product with thousands of units manufactured, economics still favor the FPGA. Only when production runs reach into the millions of units or more will it be possible to amortize the large NRE investment needed to transfer the AUD to an ASIC. Of course, for consumer-oriented designs, that may happen very quickly.

Transferring the AUD to an HDL program for an FPGA may or may not be difficult, depending on the tools available for converting the existing debugged software design into HDL for the chosen hardware, and where the conversion is done.

For example, The Mathworks has worked with ASIC and FPGA vendors to create toolkits that help engineers generate HDL for AUDs written in Matlab and Simulink. There are also tools available for porting C and C++ code to HDL.

Of course, basic test engineering best practice dictates that any major change in the system will require retracing all of the development test steps. Simulations and tests will be needed to make sure an FPGA programmed by the HDL code will actually perform as well exactly like the original AUD. Similar issues arise when converting the FPGA program to a custom-ASIC design.

Control Engineeringwould like to thank the following sources, who contributed information and insights to this article’s preparation:

• Richard (Dick) Toftness, division vice president, research and development, Vision Research ( www.visionresearch.com ).

• Joey Stubbs, North American representative for the EtherCAT Technology Group (ETG). Beckhoff Automation (www.beckhoff.com)

• Jim Tung, Mathworks fellow, The Mathworks (www.mathworks.com)

• Michael Samuelian, director of industrial business unit, Altera Corporation (www.altera.com)

Author Information

C.G. Masi is a senior editor withControl Engineering.Contact him by email atcharlie.masi@reedbusiness.com.

Do you have experience and expertise with the topics mentioned in this content? You should consider contributing to our CFE Media editorial team and getting the recognition you and your company deserve. Clickhereto start this process.