空间管理您的位置: EDA中国门户网站 » forrest1的个人空间 » 日志

The FPGA "Fountain of Youth" (field logic updates)

上一篇 / 下一篇 2007-10-08 16:12:50

查看( 71 ) / 评论( 0 )

Increasingly, system designers must be able to update their FPGA-based systems in the field so as to add years of life to their otherwise soon-to-be obsolete system designs.EDA中国门户网站G~@[:S3szz$q`
By Steve Stark, Lattice Semiconductor
#C0s,E{yQa0
Programmable Logic DesignLine
hK}2B*Z5x0
Introduction ;lhS%y)zqg G0Long gone are the days when a single, complex system design could enjoy a 5- or 10-year market life. System requirements are changing at an explosive rate. I/O standards, datacommunicationsstandards, system performance requirements, and demands on system functionality are all changing faster than ever before. System designers have two choices as follows: Design systems with fixed capabilities, meeting today's requirements only and be forced to redesign the system when the system is no longer competitive in the marketplace. EDA中国门户网站l.e;AeMiMZw Design FPGA-based systems with the ability to be "rejuvenated" over time with an in-system reconfiguration or field logic update. Extend the life of current systems. Expand the capabilities and performance of boxes already installed in the field. Fix bugs without having to touch hardware. Reconfigure FPGAs, already deployed in the field, without taking the system off line ... and do it in a highly reliable and secure fashion. Sip from the FPGA* "Fountain of Youth"! Real-world examplesEDA中国门户网站VQ'oW^2e E More and more system designers are taking advantage of the FPGA's capability to be reconfigured – after initial system design and deployment – to solve problems, extend system life cycles and expand system capabilities. For example, there is an entire class of mainstream server vendors who now have a "hard" system requirement to support field logic updates of their FPGAs. Being able to remotely upgrade systems is essential for developing, deploying and maintaining a network of hundreds to thousands of servers located across diverse geographic locations. Technicians no longer have to tear apart a system to replace or upgrade an FPGA. It can all be done remotely ... no technician required. A leading telecom solutions provider (base stations, network servers, routers etc.) based in China has a requirement to support remote field upgrades to implementbugfixes and to install new features and services. Further, their end customers have a requirement that any system update require no more than 50 milliseconds of system downtime! A manufacturer of PC-based, broadcast video add-on cards takes advantage of FPGA field logic updates to incorporate refinements in video algorithms and to deliver enhanced feature support to users who pay for the upgrade. Reliability of the remote upgrade process is the critical concern for this supplier. There is also a strong desire to protect the intellectual property (IP) embedded in these video algorithms, so security of the FPGA code during the field logic update process is also critically important. FPGA field logic update requirements $u+e(u;]%^Z9pD0In order to execute a field logic update of an FPGA effectively, there are four fundamental requirements as follows: Embedded Programming –The system microprocessor must be able to program the FPGA. Generally, this is an FPGA vendor-supplied C-code program that can be compiled and executed by the system microprocessor. The microprocessor is then able to provide the communication link (via Ethernet, Internet, RF or a land line) between the outside world and the target FPGA. The microprocessor can now access the new FPGA programming file;downloadthis new bitstream to a dedicatedmemorychipor, potentially, to the FPGA's on-chipFlashmemory; and then subsequently control the reconfiguration of the FPGA itself. Minimum System Downtime –More and more users are insisting on "5 Nines" (99.999%) system availability. The system is not available while the FPGA is being reprogrammed, so this process must happen very quickly to be useful. This is an area that must be researched carefully by any FPGA system designer. For the common SRAM-based FPGA, the time required to download the new bitstream to the target FPGA from the dedicated SPI Flash orEEPROMbootmemory will range between tens and hundreds of milliseconds. If the designer takes advantage of a single chip, non-volatile, SRAM-based FPGA with dedicated Flash configuration memory, the complete FPGA reconfiguration will take a maximum of 2 milliseconds. The actual configuration of the boot PROM (SRAM-based FPGA) or the on-chipFlash memory(SRAM/Flash FPGA) will take place in "background" mode, while the system is still fully operational, so it is only the time required to actually download the new bitstream to the FPGA SRAM cells that determines how long the system must pause before it is able to continue operation with its newfound youth. .G p)ZJ0]E0 I/O States Must Be Controlled –The outputs from the FPGA often drive key control signals within the system (chip resets, power supply enable, etc.). During the FPGA reconfiguration, it is critical that these signals continue to be driven in the correct state. A glitch on one of these signals could cause a system reset/re-boot. This is another area for FPGA designers to evaluate very carefully. Many FPGA architecturesdefaultall of their I/Os to tri-state values once the programming mode is entered, which will most certainly cause a significant interruption in system operation. Other FPGA solutions in the marketplace allow the user to pre-define – on a pin-by-pin basis – the state of I/Os (i.e. high, low, high-impedance or sampled and then driven to the current value) to support a transparent and orderly pause of the system. EDA中国门户网站adUZK!bt Device State Must Be Controlled –*It is essential to control the state of the logic within the FPGA prior to exiting the configuration process. This allows the device logic to drive to correct levels on the outputs immediately after the device configuration is complete. Phase Lock Loops (PLLs) must also relock if necessary. These capabilities are essential to allow the system to smoothly waken from its brief nap and resume full speed operation with its rejuvenated FPGA. FPGA designers will find that most volatile (SRAM-based) FPGA architectures in the marketplace today do not support these critical capabilities. By comparison, the single chip, non-volatile, SRAM/Flash FPGAs in the marketplace do support these requirements.

As an example of this basic field logic update process,Fig 1illustrates Lattice's four-step "TransparentFieldReconfiguration" or TransFR process. A number of Lattice's FPGA architectures support this flow.

1. The four-step TransFR process.

These four requirements are the basic steps to follow for access to the FPGA "Fountain of Youth": the ability torefreshand add years of life to FPGA-based designs. However, there are also issues of field logic update reliability and security to be considered as follows:

What happens to the system if the new, updated FPGA bitstream gets corrupted during the remote configuration process?
How is the Intellectual Property (IP) embedded in the FPGA bitstream protected throughout the field logic update process?

Dual boot for field logic update reliability
}/D&gP&g0While the stored FPGA configuration is being updated, there is always the risk that a power or communications failure could result in a corrupted configuration and a non-operational system. One approach to guard against this possibility is the use of Dual Boot, whereby a second, or "golden," configuration is stored in boot memory and is always available in the event of a failed configuration attempt. With this approach, the system will always recover.

Some SRAM-based FPGA architectures support multiple boot images (or configuration bitstreams) in a single SPI Flash boot memory. Some non-volatile SRAM/Flash FPGA architectures store the active boot image in the on-chip Flash and have the golden boot image available in a dedicated SPI Flash boot memory.

As an example of a Dual Boot implementation,Fig 2illustrates theDual Bootcapability of the LatticeXP2 family of non-volatile, embedded Flash, FPGAs.

2. Dual boot capability.

Encryption for design securityEDA中国门户网站1O r8}#q$mj
There are a number of FPGA architectures in the marketplace that support bitstream encryption (typically 128-bitAESEncryption). The FPGA system designer creates an encryption key that is programmed into the FPGA silicon and also incorporated into the encrypted bitstream itself. The encrypted bitstream is introduced to the FPGA silicon, whose on-chip decryption engine – in combination with the storedencryptionkey – decrypts the encrypted bitstream prior to downloading to theSRAMconfiguration memory. This flow allows sensitive design data to be protected during the field logic update process.

As an example of a 128-bit AES Encryption flow,Fig 3illustrates the encryption capability of the LatticeXP2 family of non-volatile, embedded Flash, FPGAs.

3. Example encryption scenario.

Summary
1E-uT`l g6y:u0Increasingly, system designers must be able to update their FPGA-based systems in the field so as to add years of life to their otherwise soon-to-be obsolete system designs. The challenge is to design with an FPGA fabric that – in addition to meeting the demands for field update reliability and security – supports the four fundamental requirements for field logic updates presented earlier in this article. Fortunately, there are FPGAs available in the marketplace today that support all of these requirements.

Steve Starkis the Director of Product Marketing forLattice Semiconductor. Steve has been with Lattice 17 years and in the semiconductor industry 28 years.

Steve holds a B.S. Industrial Engineering degree from the University of Illinois and an MBA from Houston Baptist University. He can be contacted atsteve.stark@latticesemi.com.
%f/ArE3}/f]0

FPGA/CPLD器件价格查询