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
- Boundary-Scan Test—A Practical Approach, Harry Bleeker et
al., Kluwer Academic Publishers, 1993.
- 1149.1-1990 IEEE Standard Test Access Port and Boundary-Scan
Architecture (Incorporates IEEE Std 1149.la-1993), IEEE, 1994.
- Java API for Boundary-Scan,
http://www.xilinx.com/products/software/sxli avaoi.htm
- Remote Field Updates using FPGA, Thomas Branca, Xilinx White
Paper 1999. (http://www.xilinx.com/xilinxonline/remote wp.htm)
- Internet Reconfigurable Logic, Richard Sevcik, Xilinx White
Paper, 1999.
(http://www.xilinx.com/xilinxonline/irlwpaper.htm)
- Java API for Boundary-Scan, Neil G. Jacobson, Xilinx White
Paper. 1998.
(http://www.xilinx.com/products/software/sxlsxwhitePaPr.Pdf)
Contact Information
Xilinx
2100 Logic Drive
San Jose, CA 95124
(408) 879 4885 (Voice)
(408) 879 5171 (Fax)
neil.jacobson@xilinx.com
