FPGAs and the Industrial Ethernet Maze
Today, there are more than 25 Ethernet-based industrial communication systems that co-exist in the market. Vendors of industrial devices need to create solutions to optimally support multiple RTE (real-time Ethernet) protocols within a single hardware platform, and that can be field-upgraded to support new versions of existing protocols, or even completely different protocols, without replacing hardware.
|An FPGA-based system supporting both RTE and standard TCP/IP|
Industrial Ethernet (IE) product developers combine the ubiquitous Ethernet physical layer with other hardware or software to create a “proprietary” or specialized RTE protocol, such as EtherCAT, EtherNet/IP, and Profinet. The objective is to add a real time and deterministic communication capability while retaining the advantages, popularity, and openness of Ethernet.
This type of universal access point can simultaneously serve I/O data communication, parameterization, configuration, diagnosis, and other applications. The ideal IE interface simultaneously supports standard protocols like HTTP and FTP in addition to industry specific RTE protocols to ensure scalability and flexibility. The main difference between “standard” and RTE protocols is that RTE protocols have a clear specification for deterministic communication.
Field programmable gate arrays (FPGAs) represent an elegant solution to this problem. When combined with intellectual property (IP) cores for Ethernet, RTE protocols, and other industrial network standards, FPGAs enable designers to implement a single-board design that can support any of these communication standards. This not only reduces the form factor, but also saves time. Device manufacturers can cost effectively add industry standard networking capabilities to their automation products while retaining design flexibility in their systems due to FPGAs’ reprogrammability.
The creation of FPGA configurations is greatly accelerated by the use of pre-built IP cores that implement complex or specialized features, such as microprocessors or DSP functions. These IP cores are easily reused between different designs, different size FPGA devices, and even new generations of FPGA devices. Examples of IP cores include I/O interfaces (such as UARTs, PCI bus structures, or PWM circuits), processing functions such as FFT/FIR filters, or DSP functions, or more complex hardware functions like memory controllers and even microprocessors, such as Altera’s Nios II embedded processor, which is a high-performance 32-but RISC CPU.
When the product requirements change or the RTE protocol needs upgrading, a board redesign is not necessary. Instead, the reconfiguration requires only loading a new set of configuration data into the non-volatile memory. Circuit board design does not depend on proprietary (and sometimes expensive) ASICs that could become obsolete.
One design example uses a Cyclone III FPGA (with 40K LEs) that contains MAC IP cores for RTE hardware support. The RTE could implement any of a range of available protocols. The “FPGA-based system” graphic includes an Ethernet switch with two external ports and one internal port, which enables the RTE device to operate in a daisy-chain topology. The internal port is used to exchange data between the embedded processor and the switch via a first-in, first-out (FIFO) buffer. A second embedded CPU is optional and could be used to run an application program.
It is vital to match a high-quality hardware design with a high-performance operating system (OS), otherwise the software will limit system performance. A designer can choose from a number of operating systems available for the embedded processor. For this discussion,μC-Linux and eCos are relevant choices. Both are available free-of-charge and include a broad community of support. Although a lightweight operating system, eCos includes support for all essential IP applications, such as simple network management protocol (SNMP). Another OS, μC-Linux, offers native support for a wide range of applications and protocols, but requires significantly more resources.
Integration Model 1: all hardware designed by the developer
In this model, the device manufacturer develops the hardware design that will be programmed into an FPGA. This approach is especially effective if the device application requires the integration of additional IP cores that contain vendor or application-specific functionality (such as for drive control).
Designers often use an evaluation-board kit, such as the MercuryCode evaluation board from EBV, as a starting point for evaluating and prototyping FPGA-based technology. The kit consists of an evaluation board with all the required development environments for both hardware and software. Generally, all appropriate operating systems and RTE protocols are available as evaluation and licensed IP cores to run on the evaluation platform. Embedded system developers use such kits for IP core evaluation, interoperability testing, and integrating prototypes into a target device.
Integration Model 2: vendor-supplied RTE module
Using a software vendor’s pre-designed communication module is a second alternative for developing lower-volume products, when developer bandwidth is insufficient, or when lead time is too short to design an RTE interface module from scratch. If custom FPGA design features are not required, incorporating a pre-built design integration package that effectively delivers an off-the-shelf, fully-functional RTE Module (RTEM) with a pre-installed hardware-configuration, protocol software, and operating system can free up scarce developer resources. The communication module is delivered with a complete development environment for creation of device-specific routines necessary for seamless device integration.
There are two main options for the physical device integration: direct integration of the RTEM as supplied, or asking the vendor to perform re-design an off-the-shelf communication module to meet specific customer requirements.
The flexibility of an FPGA-based communications module is demonstrated by a design that runs standard applications using TCP/IP simultaneously with various RTE protocols. To achieve this task, simply use another embedded processor to support all the standard communication protocols (such as by using the
This design incorporates a switch component with two internal Ethernet ports, each with individual Ethernet address. As a result, a product developer can design a field device that offers two IP addresses (one for RT and one for IT traffic) to permit the independent and simultaneous support of, for example, a remote maintenance application and a real-time control application.
FPGAs now offer a realistic alternative to using ASICs at comparable (or even better) price, performance, and power consumption rates. For complex and evolving applications, where built-in flexibility and long lifetimes are a must, FPGAs provide the ideal solution without the additional overhead in cost, performance, or development time.
|Frank Iwanitz is product manager for real-time Ethernet at Softing AG. Stefano Zammattio is a product manager at Altera Corp.|