Embedded Systems: Programmable Logic -> FPGAs don remote reprogram habits

Device networking for remote access can be viewed as a client/server relationship. For example, the local interface, which a technician would use to control the reconfiguration of a remote device, is a client and the remote device is a server. The network architecture can be the most significant factor influencing the overall system design and cost. There are several network architectures from which to choose , depending on product needs.

In choosing a device network architecture, it's important to consider communication bandwidth requirements; protocol complexity; processing requirements; peripheral resources; and open standards. Three different classes of device network architectures will be examined here: heavyweight, lightweight and gateway networks. Heavyweight networks have complex protocols that typically use a high-bandwidth medium. Lightweight networks have simple protocols that typically use a low-bandwidth medium. Gateway networks comprise a gateway that bridges a heavyweight and a lightweight network.

Often the first solution considered when networking a device is to use a TCP/IP-based network. This type of network connects the local interface to the remote devices through the Internet. TCP/IP is not a complete solution; additional protocols are required that support and manage TCP/IP as well as higher-level protocols that ride on top of TCP/IP. TCP/IP and the accompanying protocols re quire significant resources on the device and significant bandwidth. Internet security overhead and network administration costs can be significant, as well.

Heavyweight network
For these reasons, TCP/IP is considered a heavyweight network protocol. Some of TCP/IP's advantages are its large deployed base, available programming tools and the fact that it is widely understood by programmers. TCP/IP also allows for multiple local interfaces to simultaneously access multiple remote devices. Note: TCP/IP is considered a heavyweight protocol independent of the medium in which it resides. For example, Ethernet and modems by themselves are not considered heavyweight networks because they use simple protocols. When combined with TCP/IP, however, they become heavyweight networks.

If the device has access to a telephone line, direct connection over a modem to a PC is an option. Because this is a basic point-to-point connection, the communication protocol can be simple and lightweight. In this architecture, the modems, line installation and line charges can be the most significant part of the device network cost. This network architecture does not support Internet connectivity. The local interface could access several modem-enabled devices, but only one at a time.

Another alternative is the use of a PC-based gateway, which has a number of advantages. First, a gateway network architecture is able to act as a bridge between a heavyweight network such as TCP/IP and lightweight networks such as modem, RS485, modem to RS485 and Ethernet. The gateway offloads functions from the client such as subnet protocols, subnet management and data representation. The device is offloaded from a heavyweight network protocol.

There are security advantages, as well, particularly important in the remote reprogramming of hardware. The gateway shields the device from the hazards associated with the Internet by handling standard Internet security issues, client authentication and user access rights. The gateway also manages security on the device network. Also, the gateway provides data subscriptions, alarm monitoring, address management, diagnostics and multidevice data aggregation.

Common look
Another advantage is that the gateway presents a common device representation to the client in the form of application programming interfaces and standard object classes. The gateway can present proxies for the devices so that they can be interoperable with device object networking strategies such as Universal Plug and Play, Jini and OSGi. And device resources can be distributed to the gateway by taking over device file system management, server capabilities, common object proxies and information processing.

Also, by adding a layer between the client and the device, each are indirectly represented, shielded from changes to address or interface. Gateways handle multiple client sessions, data synchronization, metering and caching. A gateway's lightweight subnets can uti lize peer-to-peer or master-slave protocols. The gateway architecture can access several subnets simultaneously.

• Special considerations must be made when dealing with remotely programmable FPGA systems:
• A microcontroller is needed to handle the communication and programming tasks so the FPGA can recover from programming errors;
• Attention must be paid to whether there is a maximum program download time;
• Communications or power may glitch or fail during program download; and
• Programming can take place through the JTAG debug port or by communicating directly with the program storage device, usually a serial E2PROM.

Dual storage helps
A design may need one or two storage locations for the FPGA programs. There are two drawbacks to having only a single storage location for the program. The first is that, depending on the design, the FPGA may not operate during program download. The second is that if there is a communications or power failur e during download, the FPGA will not operate until a successful download is completed. Having two storage locations for the programs allows one location to be designated for the current program and the other to be designated for the new program. Once the download is complete, the designations are switched.

To demonstrate the remote programming of logic devices, two prototypes were assembled. The first demonstrates remote programming on a Xilinx CoolRunner complex PLD. The second demonstrates remote programming on a Xilinx Spartan FPGA. Both used the Emit device-networking technology. A gateway architecture with a modem lightweight network was chosen because it fit a likely scenario. The components of the system included the following:

• The gateway was a PC with emGateway software;
• A modem using emNet, a lightweight, open device-networking protocol, enabled communication between the gateway and the device used;

The microcontroller featured emMicro, a device-ne tworking kernel. The microcontroller programmed the logic device through that part's JTAG debug port and used a single program storage location; and

• The local interface involved PHP-based HTML pages served from emGateway to a standard browser.

The CoolRunner CPLD prototype used the CoolRunner XPLA-3 CPLD Demo Board with the addition of a Microchip PIC-16C73 using an assembly port of emMicro, an RS232 driver and an external modem. Meanwhile, the Spartan FPGA prototype used a Spartan XCS30 Demo Board, an Emit software development kit with an Hitachi H8S/2134 em-Ware SDK board, a C-language port of emMicro and an external modem.

The applications on the programmable device display marquis messages on the demo boards' LCD screens. No changes to the programmable-device applications were needed to make them remotely programmable. Remote programming was demonstrated by having different messages displayed for different programs. The applications on the microcontrollers were almost trivial. Besides the emMicro and JTAG libraries, there were only 25 lines of executable C code.