基于嵌入式Linux的可自重构片上系统(2)

Small bit manipulations – the contents or configurations of individual FPGA logic elements such as LUTs are modified, but no overall logic or module-level changes are performed [7]. An example of this mode might be the dynamic modification of filter coefficients stored in FPGA LUTs.

Dynamically loaded modules – pre-implemented partial bitstreams are used to configure a portion of the FPGA’s logic resources, to implement either a new functional module, or replace an existing module [7]. One can imagine a network encryption/acceleration co-processor, in which new hardware encryption modules might be swapped in at run time.

Many systems will fall somewhere between these two extremes. A reconfigurable system using internally pre-placed and routed modules that are dynamically modified to place at an arbitrary location is one example.

C. Summary

Several groups are developing systems and methodologies to manage the FPGA logic space, in terms of logic area assignment and partitioning (e.g. [8, 9]), and dynamic mapping of computations onto reconfigurable modules. This work will continue to have influence across the axes described above. It is important to note that our research complements these existing approaches to DRS, and in fact enhances them by providing a high-level interface to the reconfiguration mechanism. It also permits direct translation of most exo-reconfigurable system concepts into endo-reconfigurable systems, by removing the requirement for the external controlling device.

III. Self reconfiguration in Linux

In this section we detail our approach to providing an abstraction layer for the Xilinx Internal Configuration Access Port (ICAP), and show some ways in which it can be used to implement dynamic self-reconfiguring systems. We first present a very brief introduction to the Microblaze system architecture and uClinux port, to provide context for the ensuing discussion. A. Microblaze Architecture

and

uClinux

Introduction

1) Microblaze

Microblaze is a classic 32 bit RISC processor, with 32 general purpose registers, and an orthogonal instruction set. It uses a 3 stage instruction

pipeline, with delayed branch capability for improved instruction throughput.

The Microblaze design is specifically targeted to hardware features present in the various Xilinx FPGA devices, such as hardware multipliers and on chip block RAM (BRAM).

Microblaze utilizes Harvard-style separate instruction and data buses, which conform to IBM’s CoreConnect OPB (On-Chip Peripheral Bus) standard. Bus arbiters can be automatically instantiated, permitting the instruction and data buses to be tied together, to create conventional von Neumann-style system architectures.

2) Microblaze uClinux

In most respects, the Microblaze port of uClinux is very similar to other ports to more conventional processors such as the Motorola Coldfire and ARM cores.

To minimize changes in the kernel memory architecture, the Microblaze systems used for uClinux are designed in the von Neumann style described above, with the instruction and data buses tied together. Peripherals such as timers, interrupt controllers, memory controllers, GPIOs and an Ethernet MAC are used to build up a complete system. Linux device drivers have been wrapped around these cores for interfacing with the kernel and user space applications.

B. The ICAP device driver

Xilinx developed an OPB interface to the ICAP module for self-reconfiguration experiments [1], which permits frame-by-frame readback and partial configuration in ICAP-supported devices. The OPB interface permits connection of this peripheral to the Microblaze soft-core processor. The architecture of OPB/ICAP interface is illustrated in Figure 2.

To integrate this device within the Linux kernel, we

use the standard device driver architecture used by

基于嵌入式Linux的可自重构片上系统

all Linux devices. The Linux philosophy is that device drivers should implement mechanism, not policy, and this was adopted for the ICAP peripheral.

We developed a simple character-based device driver, which implements the read(), write() and ioctl() system calls:

read – initiates a read from the ICAP into a user memory buffer, of the specified number of bytes. write – specified number of bytes are written to the ICAP from a user memory buffer

ioctl – interface to device specific control operations, such as querying the status, or changing operating modes

Upon system boot, this device is registered in the Linux device subsystem, appearing as /dev/icap. Like any Linux device, the ICAP may be accessed using standard Linux system calls, such as open, read, and write. Thus, the kernel mediates between user programs (implementing policy), and the device driver (implementing mechanism).

C. Using the ICAP device in a user program

Accessing the ICAP device from within a user program is simple:

1. open() the /dev/icap device

2. Construct a command sequence in a local

buffer

3. write() the command sequence buffer 4. read() the result data (if applicable)

The format of the various command and data sequences is documented in the Xilinx Virtex2 User Guide [10]. For example, to perform a readback, a command sequence is constructed to

1. Issue dummy and synchronisation packets 2. Set the device ID code

3. Set the Frame Address Register (FAR) 4. Issue the ReadFrame command

After this command sequence is written to the device, the frame configuration data is read back as used as required.

IV. Linux shell programming for

dynamic reconfiguration

One of the underlying principles of Un*x-like operating systems is to provide a collection of small tools, each focussed on performing a single job. The shell provides mechanism for chaining these tools together (e.g. pipes and …… 此处隐藏：5843字，全部文档内容请下载后查看。喜欢就下载吧 ……