SoC Configurable Platforms -> Upgradable hardware means risks, rewards

Upgradable hardware means risks, rewards

Upgradable hardware means risks, rewards
By Wallace Westfeldt , Program Manager, Internet Reconfigurable Logic Marketing, Xilinx Inc., San Jose, Calif., EE Times
August 14, 2000 (3:04 p.m. EST)
URL: http://www.eetimes.com/story/OEG20000814S0036

There are compelling technological and business benefits for creating network-upgradable hardware. As more and more system architects consider theses benefits a new realm of design issues and implementations is revealed. The first and most important-a prime directive-is that upgradability must be designed-in up front. This may seem obvious but it is not.

Although hardware has been successfully upgraded in the field for some time, more often than not the important benefits are overlooked in favor of standard design practices established by fixed-logic, or ASIC, designers. These design practices are often highly specialized with respect to the components and environment of a particular application and do not consider the additional features available in FPGAs. The assignment given to an FPGA designer is often narrow in scope and rarely has any reference to bitstream delivery, persistent data flow or allocating space on the chip for future upgrade s. Furthermore, the design issues that surround an upgradable device are not even known, much less considered.

In this new world of Internet reconfigurable logic (IRL), these legacy design practices need to be reconsidered at the network level, the system level and the chip level, to take advantage of the enormous benefits of field-upgradable hardware. Therefore, for proper up-front planning and successful implementation, the system architect must be fully cognizant of these design considerations and share them with the team.

Early questions

At the network and system level there are common areas in most upgradable designs that need to be addressed for successful implementation and successful selection of tools for application development. Some initial queries uncover these common areas: who or what will initiate the upgrade? Will the device (pull) or the server (push) initiate it? Will the end user activate it or will it be done automatically, remotely?

System dependenc ies are also important. If the system is independent-its operations have no impact on other targets-then there is less concern about failed upgrades. For instance, if you can upgrade 90 percent of your printers automatically, then field service only has to handle 10 percent of the upgrades, saving 90 percent of the labor. However, if the target is interdependent, i.e. linked to other targets, different stations with various degrees of upgrades may affect overall system performance, such as in the case of cellular base stations. In this situation, the verification process is critical. It is possible, and wise, to plan on configuring the upgrade so that it may not go into effect until all upgrades are complete and verified.

If the system is push, i.e., server-initiated from a remote controller to interdependent targets, most of that upgrade system will be built and designed in a proprietary fashion because of its special needs. However, generalized tools like Field Upgrader from GoAhead Software can su pplement those development issues.

In all systems, security is an issue. The biggest concern is unauthorized access to the programmable logic. For this, issues standards like DSS and SH1 that employ public and private key security methods are the most popular and are available in tools like Field Upgrader.

Because FPGAs are SRAM-based, network upgrades must be protected from network failures, power failures and programming failures. Therefore, once the upgrade reaches the board, designers need to consider how the chip will be programmed, how the bitstream will be stored, and how the previous bitstream will be protected in case there is need to reset to the previous configuration.

The most common method to address this is to issue a double-buffer architecture where the boot image for the FPGA is loaded in its own area of non-volatile storage and can always be retrieved for reset. The reliability and cost requirements of the application dictate how many buffers are required. For instanc e, an Arctic base station would benefit from more buffers because of the difficulty, inconvenience, and cost involved in reaching it with a field service technician.

To make the process as smooth as possible, the system development environment should include: Web-friendly monitoring tools; flexibility to handle a variety of upgrade applications; interfaces with industry-leading security standards such as SH1 and DSS; and interfaces with industry-leading operating systems, such as Linux and VxWorks from WindRiver. In addition, it should provide reliable monitoring features to reassure that the process is working properly. It should also be easy to use, working on systems running Windows NT/98/95/CE, embedded NT, Linux and embedded Linux.

The advantages of network available software upgrades are well-known, and the process has become a standard for many users. It is still not a common practice to create network upgradable hardware in digital electronic devices.

There is a growing inter est in upgradable or reconfigurable hardware, primarily for cost-savings advantages. Using network upgradable hardware allows service providers to simultaneously upgrade basestations over the Internet. They can complete the entire process in minutes rather than days.