The combination of programmable logic with embedded processor technology opens a host of new communications capabilities for programmable logic. For example, a programmable logic device (PLD) with an embedded processor core can run a real-time operating system (RTOS) along with a TCP/IP stack and a media access controller (MAC). That enables the PLD to communicate with a remote user via a local-area network, a wide-area network or through the Internet. The embedded processor could also run a Web server application, allowing it to post status information about the device or the board on which it resides. Users can control reconfiguration of the PLD, modifying the system at a hardware level over a network link.
The fact that PLDs are easy to modify has long been the key feature of programmable logic technology. In-system programmability is nothing new in the PLD realm. Whether reconfiguring a device with a download cable, or a configuration device dedicated to automatically configuring the PLD upon board power-up, changing device functionality in the system is a well-understood practice.
Doing that over a network link extends the capability so that a communications link can be used to transmit the configuration data to update the PLD remotely. In-field upgrade capability of that type is increasingly in demand, particularly in communications applications. Such applications already require the system to connect to a network and use some local processing power to perform network-level functions.
One way to implement in-field upgrades is to design an embedded system that acts as a Web server with minimum functionality. In this case, the embedded Web server needs only to be able to serve an HTML text page. Such an example uses the Internet, but a similar system could also support a modem connection or other proprietary communications link. At the heart of such Web servers is a PLD with an embedded processor core. Using an RTOS that supports the TCP/IP protocol for the processor core, the embedded system stores and loads HTML text that contains the PLD design version, board version and any other relevant real-time information. The Internet connection can also be used to download new configuration data for the PLD.
Embedding a processor in the PLD has a number of benefits. These include increasing integration to reduce cost, adding system flexibility and giving the system designer greater control. One example of a processor implementation for programmable logic is the Excalibur embedded processor solution from Altera Corp. Excalibur includes both the Nios soft-core embedded processor products and ARM- and MIPS-based hard-core embedded processors for PLDs.
Whether the PLD uses a hard- or soft-core embedded processor, designers can implement a MAC in general-purpose logic to provide the necessary connectivity to the Internet. Using the Excalibur embedded processor, both 10/100 Ethernet and Gigabit Ethernet MACs are available. The PLD talks to the Internet through a chip set that implements the physical layer (PHY) of the Open Systems Interconnection (OSI) model.
Internet via RTOS
At the higher layers of OSI, an RTOS runs on top of the embedded processor core along with the TCP/IP stack that allows native applications to communicate over the Internet. This includes the local Web server that serves a Web page showing the current status of the embedded system. Information like the design revision within the PLD, board version, local memory revision and other items are easily stored and updated by the embedded processor software. Local memory is used by the processor to store the HTML page, kernel for the RTOS and binaries for the Web server application.
The Web server application runs on top of the system hardware and manages communication with other Web applications that request information from it. Application software to manage this exchange of information is used to properly communicate with the outside world. Since different applications may have different security requirements, there are options as to what level of authentication must take place. Once the hardware has an open connection, the embedded system enters the authentication phase. At that point various forms of access authorization are possible.
If the system is installed in an open network, it may be necessary to use security measures to restrict access. These measures can be anything from requiring a password to third-party verification where a service is provided to verify that the requesting operator is not only making a valid request, but is also giving accurate information about their identity.
Once authentication is established, the remote operator has permission to query the server in the PLD and have it transmit the Web page containing relevant information about itself. The remote operator can then determine if an upgrade is necessary.
A useful feature of the browsable PLD is the ability to easily upgrade it in the field. Since the system is Web-enabled, changing the functionality of the PLD is as simple as using the existing Internet connection to download new configuration data. If some thought is given to the architecture of the system, the PLD can even be designed to reconfigure itself. Since the communications system may not be 100 percent reliable, the PLD must be able to recover from a system error without disrupting system functionality.
Of primary concern is the operation of the processor in the event of incomplete configuration. Additional hardware must be built into the system to manage configuration while the processor is off-line. This additional hardware can be a second, smaller configuration-management PLD that monitors the larger PLD during configuration.
If configuration is unsuccessful, the configuration-management PLD reverts to the "known good" configuration data. The configuration-management PLD adds the necessary robustness to the system to bring it back on-line, no matter what may happen during configuration.
When the system PLD is to be updated, configuration data is sent via the Internet connection to the embedded processor where it's programmed into flash memory. It's important for the configuration data to be stored in nonvolatile memory for several reasons. First, the information can be checked for integrity before loading the device with potentially harmful data. Second, the system must be able to fall back on a known good configuration image, if there is an interruption during configuration.
The configuration spaces for the system PLD let the embedded processor ping-pong back and forth between two memory locations to store new configuration data that is sent to it. The flash configuration select bit tells the embedded processor and configuration-management PLD which flash block contains the current target configuration image.
The configuration-management PLD multiplexes the updated configuration data into the system PLD, after the system PLD instructs it to begin configuration. In this system architecture, the configuration-management PLD can also be updated. If the system requires that the configuration-management PLD be updatable, then a hard-core embedded processor is preferred.
If power fails in the middle of programming the configuration-management PLD, then the entire system would be unrecoverable. However, if the PLD contains a hard-core embedded processor, then even if power is lost, the processor can revert to a known good programming image for the configuration-management PLD. In that case, every hardware component of the system (except the PHY) can be updated by a software upgrade over the Internet.
The flash area in this example also contains the boot block, which has the RTOS kernel, TCP/IP stack, Web server application code, default HTML Web page and any other software.
It's clear that many diverse pieces are needed to make a browsable PLD application possible. The usefulness of such an application is at least partially determined by the amount of development effort required.
Programmable logic vendors are beginning to provide varying levels of assistance in making their devices more easily connected. This includes everything from software for device configuration to complete packages with all of the software, IP blocks and documentation to simplify the development of applications using programmables in a connected environment.