Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > FPGAs/PLDs

Leveraging PLDs for embedded system functionality

Posted: 01 Mar 1999 ?? ?Print Version ?Bookmark and Share

Keywords:xilinx? jacobson? pld? embedded system? internet?

In this article

? Internet Reconfigurable Logic

? Planning issues for IRL

? Enabling software technology

? IRL Application: System upgrades

? IRL Application: Dynamic functionality assignment

? References

Neil G. Jacobson

Xilinx Inc.

In the communications arena, equipment is often digital and interconnected through networks. Such systems' functionality is generally distributed over the network, allowing system software to be upgraded using a network connection.

The use of programmable logic devices (PLDs) allows for the extension of these techniques to facilitate electronically upgrading hardware without the need to send a repair technician to each site. This permits hardware fixes for design errors to be deployed at a fraction of today's cost. In addition, this lays the groundwork for dynamic reconfigurability as an essential portion of system function. The pervasiveness of network-based systems as well as Java as an easy-to-use development platform has enabled rapid and easy development of these heretofore complicated systems by the casual systems designer. This is the fundamental description of the technology known as Internet Reconfigurable Logic (IRL).

The techniques and tools used in IRL-based enterprise development (figure 1) are uniquely applicable to the embedded systems market because of the typical operating environmentan installation that is typically remote or isolated and deeply embedded or tightly integrated into a larger system with limited accessibility.

IRL is a new enabling methodology for programmable logic that leverages three key elements.

Figure 1: IRL is a new enabling methodology for programmable logic that leverages three key elements.

This article examines several applications that explore the utilization of IRL techniques to provide

  1. A methodology for upgrading embedded system functionality to effect functionality fixes or updates.

  2. Extended functionality of an embedded system by considering reconfigurability as an essential system component.

You will also see how the cost of ownership is reduced because one can implement fixes and add new hardware features electronically. For example, new protocol standards could be retrofitted electronically into equipment already deployed in the network. Hardware upgrades could be applied to equipment such as digital cellular basestations, switches, line cards, PBXs, radio equipment, and satellites.

Internet reconfigurable logic

If a product utilizes properly architected PLDs, then 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.

Basically, the network is used 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 stores temporary or back-up configuration data that can be used in the case of system outage.

Planning issues for IRL

You must address several issues when implementing an IRL-based system.

  • Planning for 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. The following are some issues to consider when evaluating an interface's suitability for doing remote upgrades.

    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 has been configured successfully, and that the system is back on line. Some devices return a completion status notification, while others might require a verification that the programmed contents of the device are as expected.

    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: This can be broken up into a few general areas, such as protecting data as it is transferred across an unsecured network, protecting a system from being updated by unauthorized configuration data, or protecting existing configuration data from being copied from a working system.

    If PLD update information is sent over an unsecured network, design security may be an issue. Deciphering configuration data to extract information on the functionality of a design or to make intelligent modifications to it 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.

    If the data transfer medium is unsecured, a basic requirement is making sure that only authorized configuration data has access to the system. Unauthorized accesses not only subject 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 unauthorized 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 possible. 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 methodology would be to prohibit the configuration data from being transmitted back across the communication channel unencrypted.

  • 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 advance 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 1149.1 Boundary Scan functionality to perform an EXTEST.

Enabling software technology

To effect the described design manipulation of 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. You will need additional tools, however, to manipulate these designs, combine, reconfigure, and deliver them over networks. What is clear is that by utilizing Java-based enabling technology for this purpose the deployment of such systems becomes much simpler by leveraging the existing capabilities of the language.

Java 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 many platforms. This high level of portability is achieved by having the language compile into processor non-specific code. This processor code is then interpreted by software known as a Java Virtual Machine (JVM). Portability is therefore achieved by creating JVMs that exist for all popular processors.

So a single Java program after development can be deployed on any possible platform. The execution behavior is also identical on all platforms. Further, the 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 (see Sidebar: Benefits of Java).

IRL application: System upgrades

To initiate a remote field update (figure 2), a command is sent across the network to the embedded system communication processor. The command indicates which PLDs in the system are to be updated if many are available. It also may provides information about the amount of data to be transmitted (if any) to effect reconfiguration. For the purposes of this system, the configuration communications protocol used within the system is IEEE 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. It has now 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.

Some of things that need to be considered in a field-upgradable system are the ability to be reliable during power outage and network dropout, as well as the size of the FPGA.

Figure 2: Some of things that need to be considered in a field-upgradable system are the ability to be reliable during power outage and network dropout, as well as the size of the FPGA.

Once the communications processor receives the command indicating that an update is required, it accepts the data packet and facilitates PLD reconfiguration using the IEEE 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 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 (CO) 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, 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 then 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, and must be customized for every device type and potentially each embedded system.

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

Some of things that need to be considered in a field-upgradable system are the ability to be reliable during power outage and network dropout, as well as the size of the FPGA.

Figure 3: Some of things that need to be considered in a field-upgradable system are the ability to be reliable during power outage and network dropout, as well as the size of the FPGA.

In the second scenario, the entire Java application is transmitted to the embedded system. This application is loaded and then the CO 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 CO need only inform 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 is provided which is accessed via Java net methods.

IRL Application: Dynamic functionality assignment

One could consider that there is a spectrum of reconfigurability for systems that describes the frequency of access to the PLDs configuration memory. At one extreme is the scenario illustrated above. This described the (one would hope) relatively rare requirement for system bug fixing as well as the relatively 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 (figure 4)itself could be evolving (although more slowly) meaning that the device configuration is constantly undergoing change at relatively short intervals.

Some of things that need to be considered in a field-upgradable system are the ability to be reliable during power outage and network dropout, as well as the size of the FPGA.

Figure 4: Some of things that need to be considered in a field-upgradable system are the ability to be reliable during power outage and network dropout, as well as the size of the FPGA.

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:00 PM, 250 channels are needed to adequately handle C protocol, 5 are needed for B and 1 for A but then at 8:00 PM, 125 are needed for B, 125 for A and 6 for C. An appropriately designed IRL-based system could 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 used on each node without modification, thereby saving development and maintenance costs.

Article Comments - Leveraging PLDs for embedded system ...
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top