Embedded system engineering magazine 2006.05,06

IHAVE SPENT most of my career working on architectures that deliver performance and from my experiences in constructing processing sys-

tems with different architectures and processing devices, I see the greatest potential for FPGA-centric computing.

The initial driver behind Nallatech’s formation, in 1993, was creating the best high-per- formance computing systems without a bias to a particular processing solution. In 1993, the typical technique used to gain additional processing capability was to put many microprocessors into the system to create a parallel processing system. One processor developed from the ground up for this approach was the Transputer processor developed by Inmos. We took our knowledge of parallel processing and used it to create heterogeneous microprocessor systems. These systems included processors such as the Transputer, Texas Instruments C80 and C40 and also Intel’s i860 devices. We had previously used FPGAs mainly for glue logic applications, but came to appreciate that FPGAs were great devices for handling I/O and in particular fast I/O. Because they could be directly coupled to the I/O devices themselves, they optimised the process of transferring the data and minimized the latency in getting data in and out of the system. So we built architectures with parallel microprocessor systems using FPGAs to assist in offloading data I/O and for simple mathematical operations. These systems used the 4K series from Xilinx, an infant in terms of today’s FPGAs capabilities.

A processor change

An interesting thing happened in 1998. Many of the processors that we used were reaching their end of life and were not recommended for new designs. Furthermore, Xilinx was creating their Virtex family. This created a step change in the capabilities of FPGAs and came with a roadmap that promised to continue to drive the capacity of future families of FPGAs. FPGAs were now able to take a more central role within high-performance computing systems and had reached the critical point where they could handle the system management, data management and data processing. This

offered greater flexibility in how systems were architected allowing the development of the DIME modular system for FPGA-centric systems. Utilizing the FPGA as the central processing engine enabled us to have very high I/O bandwidths, well beyond what was available with microprocessors, and with the reconfigurable nature of the FPGAs we could choose the type and protocol of the I/O, based on the application implemented.

This architectural approach created two issues. The first was that microprocessors were still better at certain tasks, such as floating point performance and complex serial control algorithms. This was easily accommodated by using the microprocessor as a coprocessor to the FPGA to provide these specialised operations.

Tools

The other issue we needed to address was that of tools. We were already familiar with microprocessor tools that enabled the detection, reprogramming and data transfer to the system under development from a GUI. This feature was also created in 1998 when we created DIME to provide plug and play capability to the FPGA system. We created an intelligent software interface called FUSE which enabled the control and management of multi-FPGA systems. This software would enable any FPGA within the system to be reconfigured and enabled data transfers over an abstracted interface.

With the first generation of DIME we learned a lot regarding FPGA-centric systems, their usage models and the requirements from our customers for the next generation of product. FPGAs and the associated technology moved on, so we evolved our architecture to DIME-II. DIME-II extended the I/O bandwidth capability and was engineered to ensure that we could support several more generations of FPGAs. Today we are shipping DIME-II with Xilinx Virtex-4 for our highest levels of performance.

Communication framework

The key driver to wider adoption of the technology is continuing to make FPGA-centric

Figure 1: Increasing FPGA-centric computing

systems easier to use. To manage multiFPGA systems we created DIMEtalk, a design tool and management system for the rapid design of a communications framework for FPGAs through a GUI. It provide the connection of memories, IP cores, embedded processors cores and external multi-gigabit transceivers and greatly simplifies the process of creating the system framework: application engineers can focus on their algorithms rather than the low level details of pin outs or memory control.

DIMEtalk also provides linking for highlevel language tools: today, it is possible to design FPGAs from C or Simulink without needing to understand VHDL or Verilog. FPGAs are truly becoming a processing technology that can be fully utilized by software engineers.

Moving forward, there continues to be a lot of emphasis on making FPGAs more accessible and easier to use by simplifying the programming model for them. The goal is to provide the highest performance in the simplest product. The other key development going on is that many vendors and users are collaborating to create standards associated with FPGAs. This includes the work being done by the FPGA High Performance Computing Alliance (FHPCA), OpenFPGA (www.openfpga.org) and VITA. This will lead to focus and stability in the marketplace and enable developments which will allow systems to be created based on open standards that ensure interoperability. A critical component to enable the market to flourish is the continued developments in FPGA-centric computing architectures. <End/>

www.xxx.com

THERE ARE MANY different consider in security. This overview at the different approaches

offer in different areas of the

In the OS

The increasing use of internet trading worked systems of all descriptions construction of highly secure systems a of many developments. The use of a OS as part of the system can leave open for intruders and some very system crashes. Greenhills has approach to solving this problem by

protected environment, known as Padded which allows users to run commercial type operating systems such as Linux, as guest operating systems in user mode. Multiple padded cell applications can run concurrently in a single physical computer, each hosting its own guest OS. An impenetrable wall around each guest operating system ensures that errant, insecure or malicious code can never compromise security. Integrity PC combines the Integrity OS with Green Hills Software’s Padded Cell. It protects secure applications in several ways:

●Each partition has its own memory-protected virtual address to ensure that software cannot corrupt, disrupt, or spy on another partition.

●Guest OSs and their applications run as user mode Integrity applications. They cannot

THERE ARE MANY methods devices around the world

data and privacy. It credit card or a digital

management protected IP that secured. This information may be locally on the device or transmitted network using a protocol such as the Sockets Layer (SSL), Internet Security (IPsec) or IEEE 802.11i, also as Wi-Fi Protected Access 2. These along with other security-related

and techniques, have a set of algorithms in common, which can be thought of as the building blocks of security. This article will focus primarily on defining the building blocks while touching briefly on the methods in which they are used.

Symmetric key encryption

The main algorithms that are used to encrypt data are known as symmetric key encryption algorithms. These algorithms have one key quality that makes them well suited for this task; they are faster than their asymmetric key encryption algorithm counterparts. Since large amounts of data are usually encrypted or decrypted at a time, this quality is very important. For example, you may want to secure a

key algorithms are also reversible. This means that once a piece of data is encrypted, it can be decrypted. This is not the case for hashing algorithms (more on this below). The Data Encryption Standard (DES) and the Advanced Encryption Standard (AES) are examples of symmetric key algorithms.

Asymmetric key encryption

Asymmetric key encryption algorithms, on the other hand, are more computationally intensive and therefore much slower than symmetric key algorithms. These are predominately used by networking security protocols at the start of a secure session, not during normal network communication. Usually when secure

Figure 1: Symmetric key encryption.

Figure 2: Asymmetric key encryption.

symmetric encryption algorithms are used at that time.

The other important difference in how asymmetric key encryption algorithms function is that, unlike symmetric encryption algorithms, they use two keys. One key is used for encryption and a second, different key is used for decryption (see figure 2). This is what enables the exchange of encryption keys before a secure session starts, as mentioned earlier. Examples of these are Rivest Shamir

Adleman (RSA) and Diffie-Hellman (DH). These

www.mentor.com

types of encryption algorithms are also known

CONVENTIONAL WISDOM says that microprocessor implementations of cryptoalgorithms are too slow for dataplane applications. However, this wis-

dom is wrong when the processor’s ISA (instruc- tion-set architecture) is tailored for optimal algorithm performance. The addition of a mere handful of instructions to a configurable processor core using an automated processor generator can accelerate application performance to hardware speeds. There are many encryption and decryption schemes in use and all are amenable to performance enhancement through ISA tailoring. This article discusses ways to accelerate two popular cryptographic schemes: DES and AES.

DES: oldie but goodie

While DES is often criticized for its relatively short 56-bit key, a simple algorithm variant called triple-DES (3DES) extends the key to 168 bits by iterating the DES algorithm three times with different keys. Even though DES has been around since 1977, there is still no known attack on 3DES that is much faster than exhaustive search. Consequently, the 3DES encryption algorithm is used for both the Secure Shell tools (SSH) and the Internet Protocol for Security (IPSEC). General-purpose microprocessors are too slow to encrypt or decrypt high-speed digital-media and Internet-packet streams. However, tailoring a configurable microprocessor’s ISA by adding only four instructions can improve DES algorithm performance by 40x to 80x.

Firmware DES implementations run slowly on general-purpose RISC processors due to the algorithm’s numerous bit permutations. However, these permutations are easy to implement in hardware and they execute quickly because each permutation corresponds to simple wire scrambling (no gates required). Likewise, the DES algorithm’s 28-bit rotations are inefficient on general-purpose, 32-bit RISC microprocessors, which lack 28-bit rotation instructions. However, these rotations are easy to perform in custom hardware.

Tailoring a microprocessor’s ISA to improve algorithm performance essentially adds DES - specific hardware to the processor, which gives the processor the execution speed of DES hardware while retaining the processor’s firmware

programmability. Only three new processor registers and four new instructions are needed to accelerate the DES code. The three new registers are: 28-bit C and D registers and a 64-bit DATA register. The custom DES instructions are:

●STKEY (move data to C and D)

●STDATA (move data to DATA)

●LDDATA (move DATA to general-purpose registers)

●DES (inner-loop iteration instruction). Adding custom DES registers and instructions reduces the code-and-data memory footprint from 5560 bytes to only 156 bytes. ISA tailoring adds 5,000 gates to the processor but saves 45,216 bits of RAM. Hence, the net silicon cost for the processor with the DES extensions is less than 5,000 gates yet the resulting DES algorithm runs much faster.

New crypto on the block: AES

In 1997, the US National Institute of Standards and Technology (NIST) chose the Rijndael block cipher for AES (the Advanced Encryption Standard) from amongst several candidates. The AES cipher encrypts plaintext to ciphertext on a block-by-block basis. The plaintext block is conceptually stored and operated upon in a 16-byte state array. The AES cipher performs transformations on rows or columns of the state array. AES encryption consists of four transformations:

●SubBytes: performs byte-wise substitutions for each byte in the state array using a fixed table

●ShiftRows: rearranges the bytes within the state array

●MixColumns: treats each column of the state array as a polynomial and performs a Galois field multiplication with a fixed 4x4 matrix

●AddRoundKey:performs byte-wise Galois field additions using bytes from the key schedule

Porting the AES cipher to a general-purpose RISC processor is simple but the performance of such an implementation is usually unacceptable. Consequently, SOC designers will generally rule out firmware-only implementations except when bandwidth requirements are low.

ISA tailoring, as described above in the DES example, can transform a configurable processor into a fast, efficient AES engine by adding

Figure 1: Simplified DES algorithm

www.tensilica.com

ATHE NUMBER of features in cell phones, personal media players, video recorders and still cameras increases, the extra processing puts a drag on bat-

tery life. However, the capacity of batteries is not keeping up, leaving users with reduced playback time or active-time.For example, the processors, LCD, RF and earphones in a typical hand-held media player consume close to 4 Watts (table 1), while the batteries typically used in these applications are 3.7V with 900-2000 mAh energy.

Since processing alone accounts for 1/3 of total system power consumption with the DSP and MCU, the processor is the obvious target for improving system power consumption, and the obvious thing to do is increase processor throughput so applications can be run with slower clocks. SoC-level integration and bus clock management is also critical to be able to remove power-hungry components like the DSP.

Atmel’s AP7000 has taken this approach by integrating the company’s high-throughput AVR32 MCU/CPU core with a vectored multiplier coprocessor, on-chip SRAM, CPU caches, memory management unit, and multiple on-chip DMA controllers. Peripherals include bit-stream audio DAC, TFT/STN LCD & HDD controllers, 480 Mbps USB 2.0 with on chip transceivers (PHY), two 10/100 Ethernet MACs adds to the connectivity of the application, while serial interfaces like RS232, USART, I2S, TWI/I2C, SPI, PS/2 and several synchronous serial modules (SSC) supporting most serial communication protocols help replace the majority of external components in these systems. The bus structure allows clocks to be set to individual frequencies in four domains (CPU, bus matrix, peripheral bridge A and peripheral bridge B) to minimize power consumption at all times.

AVR32 CPU

Atmel’s AVR32 DSP/MCU core was built from