Internet Reconfigurable Logic: Leveraging PLDs to Enhance Embedded System Functionality

Communications and similar industries often use digital equipment, interconnected through networks. These systems commonly have functionality distributed over the network, allowing system software to be upgraded using the available network connection.

Programmable logic devices (PLDs) extend standard capabilities by electronically upgrading hardware without the need to send a repair technician to each site. With PLDs, hardware fixes for design errors can be deployed at a fraction of today's cost. In addition, PLD technology lays the groundwork for the incorporation of dynamic reconfigurability as an essential portion of system function. The pervasiveness of network-based systems as well as the ubiquity of Java as an easy, network-friendly development platform has facilitated rapid and easy development of these once complicated systems by the casual systems designer.

The techniques and tools used in Internet Reconfigurable Logic, or IRL-based enterprise development, can be directly applied to the embedded systems market to extend and enhance their capabilities. These techniques are uniquely applicable to the embedded systems market because of the typical operating environment: an installation that is remote or isolated and deeply embedded or tightly integrated into a larger system with limited accessibility.

By examining several applications that use IRL techniques, this paper provides a methodology for upgrading embedded system functionality to effect functionality fixes or updates and discusses reconfigurability as an essential system component. This paper also demonstrates how the cost of ownership of such systems is dramatically reduced when it is possible to implement fixes and hardware features electronically, significantly extending the useful life of the purchased equipment. For example, new protocol standards could be retrofitted electronically into equipment already deployed in the network. Electronic hardware upgrades could be applied to many forms of digital equipment, such as digital cellular base stations, switches, line cards, PBXs, radio equipment, and satellites.

Programmable Logic Devices

A programmable logic device is loosely defined as a device with configurable logic and flip-flops linked together via programmable interconnect. Memory cells control and define the function that the logic performs and how the various logic functions are interconnected. Though various devices use different architectures, all are based on this fundamental idea.

There are a few major programmable logic architectures available today. Each architecture typically has vendor-specific sub-variants within each type. The major types include:

• Simple Programmable Logic Devices (SPLDs)
• Complex Programmable Logic Devices (CPLDs)
• Field Programmable Gate Arrays (FPGAs)

SPLD—Simple Programmable Logic Device
Also known as:

• PAL (Programmable Array Logic)
• GAL (Generic Array Logic)
• PLA (Programmable Logic Array)
• PLD (Programmable Logic Device)

SPLDs are the smallest and consequently the least expensive form of programmable logic. An SPLD is usually comprised of four to 22 macrocells and can replace a few 7400-series TTL devices. Each of the macrocells is fully connected to the others in the device. Most SPLDs use either fuses or non-volatile memory cells such as EPROM, EEPROM, or FLASH to define the functionality.

CPLD—Complex Programmable Logic Device
Also known as:

• EPLD (Erasable Programmable Logic Device)
• EEPLD (Electrically-Erasable Programmable Logic Device)
• MAX (Multiple Array matriX)

CPLDs are similar to SPLDs with a significantly higher capacity. A CPLD is the equivalent of two to 64 SPLDs and contains from ten to a few hundred macrocells. Eight to 16 macrocells group together into a larger function block. The macrocells within a function block are usually fully connected. If a device contains multiple function blocks, then the function blocks are further interconnected. Connections are vendor and family-specific, and not all CPLDs are fully connected between functions. Less that 100% connection between function blocks indicates that the device will not route or may have problems keeping the same pin-out between design revisions.

Conceptually, CPLDs consist of multiple PAL-like logic blocks (generally four or more) interconnected via a programmable switch matrix. Each logic block contains 4- to 16-macrocells, depending on the architecture. CPLDs provide a natural migration path for SPLD designers seeking higher density. CPLDs are often best for control-oriented designs, due in part to their fast pin-to-pin performance. The wide fan-in of their macrocells makes them well suited to complex, high performance state machines.

CPLDs are manufactured using one of three process technologies, EPROM, EEPROM, or FLASH. EPROM-based CPLDs are usually one-time programmable (OTP) unless they are in an UY-erasable windowed package. A special purpose device programmer, the manufacturer, or distributor programs an EPROM-based CPLD.

CPLDs are CMOS and use non-volatile memory cells such as EPROM, EEPROM, or FLASH to define the functionality. Many of the most recently introduced CPLD families have been designed so that they can be programmed in-circuit (also called ISP for in-system programmable). ISP access techniques are based on IEEE Std 1149.1 (also known as Boundary-Scan or JTAG).

FPGA—Field Programmable Gate Array
Also known as:

• LCA (Logic Cell Array)
• pASIC (programmable ASIC)

FPGAs are distinct from SPLDs and CPLDs and generally offer the highest logic capacity. An FPGA consists of an array of logic blocks, surrounded by programmable I/O blocks connected via programmable interconnect. An FPGA contains from 64 to tens of thousands of logic blocks and an even greater number of flip-flops. Most FPGAs do not provide 100% interconnect between logic blocks (to do so would be prohibitively expensive). Instead, sophisticated software places and routes the logic on the device much like a PCB auto-router would place and route components.

A generic FPGA can be described as a programmable device with an internal array of logic blocks, surrounded by a ring of programmable input/output blocks, connected together via programmable interconnect. There are a wide variety of sub-architectures within this group. The secret to density and performance in these devices lies in the logic contained in their logic blocks and on the performance and efficiency of their routing architecture.

There are two primary classes of FPGA architectures, coarse-grained and fine-grained. Coarse-grained architectures consist of fairly large logic blocks, often containing two or more look-up tables and two or more flip-flops. In a majority of these architectures, a four-input look-up table (think of it as a 16x1 ROM) implements the actual logic. A larger logic block usually corresponds to improved performance.

The other architecture type is called fine-grained. In these devices, there are a large number of relatively simple logic blocks containing either a two-input logic function or a 4-to-i multiplexer and a flip-flop. These devices are good at systolic functions and have some benefits for designs created by logic synthesis.

Most FPGAs use either SRAM or anti-fuse CMOS technology. SRAM-based FPGAs are in-system programmable whereas anti-fuse-based FPGAs are one-time programmable. As with CPLDs, the ISP access techniques are typically based on IEEE Std 1149.1, although other proprietary methods may be made available.

Internet Reconfigurable Logic

Although the term used is Internet Reconfigurable Logic, in reality any network, public or private can be used to facilitate system access. If a product utilizes PLDs and is properly architected then once it is shipped to the customer, the reconfigurable characteristic of the PLDs can be used to allow for system reprogramming by changing the device configuration data over the network. The required technology elements are a network, a network interface at the embedded system, a controlling microprocessor connected to the configuration bus of the system, and optionally some dedicated configuration memory.

The network is utilized to send the new configuration data to the target system. The embedded processor is used to receive these bits and then reprogram the PLDs along the configuration bus. A separate dedicated configuration memory may be used to store temporary or back-up configuration data that can be used in the case of system outage.

Planning for IRL

In implementing an IRL-based system there are a number of issues that must be addressed.

Data Transmission

The type of communication channel that the update information will travel across will affect the speed, security and integrity of the data that is used to update the PLD. If a communication interface is already being used for sending and receiving data in the system, it can usually also be used by the designer to perform the remote update. Some of the issues that should be considered when evaluating an interface's suitability for doing remote upgrades are listed below.

Data Integrity and Verification

It is extremely important that the integrity and reliability of the update data be assessed by the system before the configuration process even begins. Some PLDs incorporate a cyclic redundancy check (CRC) built into the configuration data so that an error in the bitstream will most likely cause the configuration of the PLD to fail.

In the absence of such built-in support, the system itself must be able to detect transmission errors from the sender, and potentially request a re-send of the data. The system also needs to let the sender know that the PLD or PLDs have been configured successfully, and that the system is back on line. Some devices return a completion status notification while others might require verification of the programmed contents of the device. The use of Java as the development platform is helpful here because it provides turnkey protocol support of TCP/IP and UDP as well as a generalized socket interface.

Security

Security can be broken up into a few general areas, protecting data as it is transferred across an insecure network, protecting a system from being updated by unauthorized configuration data, and protecting existing configuration data from being copied from a working system.

If PLD update information is sent over an insecure network, design security may be an issue. Deciphering configuration data to extract information on the functionality of a design or to make intelligent modifications is virtually impossible. PLD vendors generally keep the interpretation of the configuration data a closely guarded secret. Designers who feel the need for an additional level of security may wish to scrutinize the various aspects of the update process to ensure that their data is secure throughout any transfer. For instance, use of the built-in Java data encryption methods may be helpful to add a higher level of security to the configuration data as it is transferred.

Whenever the data transfer medium is not secured, only authorized configuration data must have access to the system. Unauthorized accesses not only subjects the system to the risk of being brought down, but also make the system vulnerable to serious damage. Designers can use the existing Java security mechanisms to give the system the ability to differentiate and restrict the access of rogue update data.

Although copying the configuration data for the purpose of deciphering its functionality would be nearly impossible, copying it for the purpose of cloning a system is conceivable. Depending on the application's susceptibility to being cloned, it may be necessary to protect the configuration data from being copied directly from the application. The simplest method would be to prohibit the configuration data from being transmitted back across the communication channel unencrypted.

IRL System Considerations

Once you have decided on the appropriate architecture of PLD that you require (i.e., CPLD vs. FPGA), you should consider device configuration characteristics. The configuration capabilities of your chosen PLD may affect your system design. For instance, it is necessary to know the behavior of the device IOs during configuration as well as the estimated reconfiguration time.

If the device IOs three-state during configuration, you need to know how that will affect the rest of the system. Your system might tolerate floating nodes for a short time, but if the reconfiguration time is very long you might be required to add special system control logic to freeze all or portions of your system.

The sections of the system that need to be controlled may be different for the configuration of different devices in your system. You need to decide if the entire system will be shut down during configuration or just the necessary portions of it.

Some PLDs allow you to specifically configure one or more sections of the PLD while allowing the other sections to continue operating. If you are using such a PLD and are considering utilizing this feature then you must apply the above design considerations section by section to the affected areas of the system.

In assigning device pin outs you should also consider connecting currently unused pins between PLDs to facilitate inter-device communication that might be required as functionality is added to your system.

Planning for New Features and Bug Fixes

One of the major benefits of using PLDs and supporting remote field upgrades is the ability to fix and add features after a product has been deployed in the field. Designing the system so that it can implement the current functionality and still be flexible enough to meet the requirements for future design revisions requires some advanced planning. Designing and testing a system for future enhancements is simpler when the functionality changes are self-contained within a specific FPGA. In some cases the board itself might have to be designed to account for future enhancements. For example, if additional connections between the FPGA and other devices are required in future revisions, then defining the interface between devices will need to be done during the initial product revision so that the connections are implemented and tested when newer revisions are created later. Designers can create small test cases that toggle these future I/O connections in order to test specific interfaces without actually completing the design, or alternatively use the built-in IEEE Std 1149.1 Boundary Scan functionality to perform an EXTEST.

Choosing the Right Size for the PLD

When choosing the size of the PLD in a remotely updateable application, consider future expandability and compatibility. To determine which size PLD to use, consider the size of the current design and the size of any potential future design enhancements. Look for PLDs with footprint compatible device sizes among devices in the same package. This gives designers the ability to select and work with a specific device and still have the flexibility to easily change to a larger or smaller device before going to production.

Memory

Depending on whether volatile or non-volatile PLDs are used as well as the level of reliability needed, the system designer may chose to incorporate dedicated configuration memory to store back-up or fail-safe configuration data in the case of a system outage during re-configuration. It may be desirable that the contents of the dedicated configuration memory be re-written to all PLDs at each power up to ensure that no device has been partially and incorrectly configured.

A separate configuration memory may be used to store system test designs and stimulus to facilitate diagnostic test of non-programmable portions of the system.

Enabling Software Technology

To manipulate programmable devices in embedded systems you need to have both appropriate development tools and a stable execution platform for these applications. Initially, standard hardware design tools are needed to create the logic elements, whether they are cores or the entire initial design. However, to manipulate these designs, combine them, reconfigure them, and deliver them over networks, additional tools are required. Java-based enabling technology makes the deployment of such systems much simpler by leveraging the existing capabilities of the language.

The Java programming language was developed by Sun Microsystems as an object oriented, easy-to-use programming language. It was designed to allow large amounts of code reuse as well as total portability across a myriad of platforms. This high level of portability is achieved by having the language compile into processor non-specific code. The processor code is then interpreted by software (called a Java Virtual Machine or JVM). Portability is therefore achieved by creating JVMs which exist for all popular processors. A single Java program after development can be deployed on any possible platform. The execution behavior is also identical on all platforms.

Further, the Java programming language was enriched through the development and deployment of a wide variety of system class libraries that offer reusable, easily integrated capabilities for such high utility operations as data manipulation, security protocols, multi-threading, exception handling, and Internet-based file access.

The use of Java therefore provides several immediate tangible benefits:

• Rapid application development because of the structure and feature set of the language
• A large number of development and debug tools
• Lower development costs because of the functionality of the available system class libraries
• Lower maintenance and porting costs because of the inherent language portability
• Suitability for heterogeneous network-based systems because of the language portability and the available system class libraries.

IRL Application-System Upgrading

To initiate a remote field update, a command is sent across the network to the embedded system communication processor. This signals to the system that the PLD needs to be updated. The command indicates which PLDs in the system are to be updated if many are available. It also provides information about the amount of data to be transmitted to effect reconfiguration. For the purposes of this system, the configuration communications protocol used within the system is IEEE Std 1149.1. Although this serial communications and hardware standard was originally intended only to facilitate systems interconnect testing, it was conceived with extensibility in mind. In light of this fact, it has been extended to include PLD configuration both formally (under IEEE Std P1532, currently under review) and informally (by individual vendor's proprietary instruction sequences). The benefit here is that a single four-wire port can be used to access many devices.

Once the communications processor receives the command indicating that an update is required, it accepts the data packet and facilitates PLD reconfiguration using IEEE Std 1149.1 interface. Note as well that for SRAM-based technologies, the update for persistent (rather than temporary) operations would be a non-volatile memory, typically a serial PROM. In this second case, after the update of the configuration PROM the system has several options for initiating the update of the FPGA functionality.

The configuration is under control of a Java application that contains an executable description of the device configuration algorithm. The Java application makes use of the Java API for Boundary-Scan, an industry-standard Java API that provides all the methods necessary to perform all possible IEEE Std 1149.1 operations. The Java application is distributed in any of three possible ways:

• A central office runs the Java application that transmits the configuration data, properly packaged for direct execution on the target embedded system
• The application and its associated data (or a pointer to it) is transmitted to the embedded system for direct execution
• The application is resident on the embedded system and a start execution instruction is transmitted to the target system including the configuration data (or a pointer to it).

In the first scenario, the central office is a PC or workstation running Java. It has a network connection and formats the data in a manner appropriate for interpretation and execution by the target embedded system. This means that the data is fully processed by the host, and a dedicated communications kernel exists on the embedded processor system waiting for the appropriately formatted messages that are then captured and read into the embedded system. These messages are stripped of their network information and the coded device configuration algorithm is executed to configure the device.

This approach leaves as an exercise to the user the development of an appropriate data format to describe the device configuration algorithm and data. The solution is complicated, not turnkey, and customized for every device type and potentially each embedded system.

The second and third scenarios are more desirable because they leverage existing, readily available technology and yield reusable and portable solutions appropriate even for heterogeneous embedded systems.

In the second scenario, the entire Java application is transmitted to the embedded system. This application is loaded and then the central office provides a command to begin execution of the configuration. The configuration data is either transmitted with the application for local storage within the embedded system or a data location is provided to the embedded system that uses the Java net methods to access the data in its stored location.

The third scenario is really just a variation of the second excepting that the application is permanently stored in the embedded system. The central office informs the embedded system that the execution is to begin. New configuration data will either be loaded into the embedded processor configuration memory store prior to execution or a data location will be provided, accessed via Java net methods.

IRL Application-Dynamic Functionality Assignment

One could consider that there is a spectrum of reconfigurability that describes the frequency of access to the PLDs configuration memory. At one extreme is the scenario illustrated above, describing the relatively rare requirement for system bug fixing as well as the more frequent feature upgrade. At the other extreme lays the sphere of evolvable hardware in which PLDs are reconfigured every few milliseconds as they evolve toward a target function. The target function itself could be evolving, although more slowly, meaning that the device configuration is constantly undergoing change at relatively short intervals.

Somewhere in the middle of this spectrum is the scenario in which a system, like a communications switch, might process a variety of protocols across a large number of channels. Say that there are 256 channels handling protocols A, B and C. If the load of messages in A, B or C protocol is not predictable, it would be beneficial to have each channel capable of handling any protocol. Rather than tripling the hardware requirement at each channel, you can design your system using PLDs. You can then use IRL techniques to dynamically reprogram each channel with the appropriate protocol, as it becomes aware of the load requirements. Suppose that at 4 PM, 250 channels are needed to adequately handle C protocol, 5 are needed for B and 1 for A but then at 8 PM, 125 are needed for B, 125 for A and 6 for C. An appropriately designed IRL-based system would utilize the system software techniques described above to accomplish this.

In this system scenario, the configuration data is fixed and can be stored either remotely or as part of the embedded system. The configuration software interacts with the load balancing software and configures the devices associated with each channel according to the needs defined by the load balance. If a single embedded processor controls each channel or a small group of channels then memory requirement can be limited through the use of a centralized configuration data store accessible via the Java net methods. In addition, even if each channel controller is based on a different microprocessor, the exact same Java code can be use on each node without modification, saving development and maintenance costs.

Summary

IRL applications developed with PLDs and Java based enabling technology bring incredible flexibility and power to an exploding embedded systems marketplace. This marketplace is driven by an extreme need for customization and reconfiguration of installed systems. By making embedded systems field upgradable over digital networks, designers can deliver products that radically reduce the cost of ownership while extending the useful lifetime of the product.

References

1. Boundary-Scan Test—A Practical Approach, Harry Bleeker et al., Kluwer Academic Publishers, 1993.
2. 1149.1-1990 IEEE Standard Test Access Port and Boundary-Scan Architecture (Incorporates IEEE Std 1149.la-1993), IEEE, 1994.
3. Java API for Boundary-Scan, http://www.xilinx.com/products/software/sxli avaoi.htm
4. Remote Field Updates using FPGA, Thomas Branca, Xilinx White Paper 1999. (http://www.xilinx.com/xilinxonline/remote wp.htm)
5. Internet Reconfigurable Logic, Richard Sevcik, Xilinx White Paper, 1999. (http://www.xilinx.com/xilinxonline/irlwpaper.htm)
6. Java API for Boundary-Scan, Neil G. Jacobson, Xilinx White Paper. 1998. (http://www.xilinx.com/products/software/sxlsxwhitePaPr.Pdf)

Contact Information